aspgems.com @aspgems

Nuestra metodología de desarrollo Web

SCRUMgem

2

Indice El desarrollo software y el desarrollo Web ¿Cómo se ha resuelto el problema hasta el

momento? La propuesta de ASPgems El compromiso entre las partes ¿Cómo lo hacemos exactamente? ¿Por qué podemos hacerlo?

3

El desarrollo software

No siempre se tiene claro que es lo que necesita

Concepto de negocio nuevo Proyectos con Moving Target Requisitos cambiantes durante los propios

desarrollos

“Aproximadamente el 80% de los proyectos de desarrollo software se completan fuera de plazo

o con sobrecoste”

4

El desarrollo en la web

Desarrollos muy dinámicos Deben adaptarse rápidamente a los

requisitos del mercado y de los usuarios El desarrollo debe estar enfocado hacia el

usuario final y no hacia el promotor del proyecto Son los que sugieren nuevos servicios Nuevas funcionalidades en las que no

habíamos pensado

5

¿A qué lleva esta situación?

Ciclos largos de especificación de los proyectos Proyectos que se retrasan en arranque por no

tener especificación Esfuerzo en revisiones continuas de

documentación Contrato con el cliente Clientes no conformes con el 100% de los

desarrollos Percepción del cliente de IT

6

¿Cómo se ha resuelto el problema hasta el momento?

Especificación cerradas de requisitos Rigidez con respecto a lo especificado Revisiones de documentos Actas de reuniones Negociación de ampliaciones

“Se intenta fijar y bloquear las especificaciones

en documentos”

7

¿Cuál es nuestra propuesta?

Asumir que los cambios son inevitables Utilizar una metodología Ágil Realizar prototipados que lleven al producto

final con revisiones continuas. Iteración. Pruebas en entornos reales. Menos es más

lanzarlo cuanto antes

e interar

8

¿Cuál es nuestra propuesta?

Entrega de resultados en tiempo mediante la iteración y un prototipado rápido y flexible de los proyectos y aplicaciones.

Respuesta rápida ante los cambios Rápido desarrollo de nuevos servicios Mayores ratios de adopción Reducción del riesgo Menor coste

9

El compromiso entre las partes

Para lograrlo las partes deben aceptar: El prototipado como medio Un proceso participativo Transparencia de los desarrollos Revisiones periódicas Compromiso en realizar las revisiones

“Todos deseamos el mejor producto posible. La confianza es imprescindible”

10

¿Cómo lo hacemos? Definimos el objetivo del proyecto Definimos las funcionalidades imprescindibles

para el lanzamiento Fijamos las prioridades para saber por donde

empezar. Analizamos e identificamos: La más importante para el éxito del proyecto La más larga en tiempos La que posee un interfaz más difícil y por tanto más

iteración La menos definida La que necesita más integración

11

¿ Cómo lo hacemos ? Fijamos el equipo y su incorporación

Dependiendo de las prioridades Teniendo en cuenta que “ Nueve mujeres no hacen

un niño en un mes” Definimos en Pivotal Tracker las stories

Igual no están completas Igual más tarde hay que dividirlas en más Lo importante:

Es apuntar y fijar prioridades Dar una herramienta al cliente para que se sienta

participe y colabore en la definición de la funcionalidad Máxima transparencia

12

¿Cuál es el papel del cliente en Pivotal ?

Fijar prioridades Definir junto con IT el alcance las stories Aceptar las stories

Es importante que el cliente entienda que si una story se ha comenzado a desarrollar no se puede cambiar. Se abrirá otra y se aceptará esa

13

¿Cuál es el papel de ASPgems en Pivotal? Definir junto con IT las stories Dividir las stories si la complejidad es excesiva Informar de los tiempos esperados de

desarrollo Informar cuando se comienzan las stories Informar cuando se han finalizado Fijar stories que aunque no tienen reflejo en la

web son necesarias ( preparar caches, poner indices en la BBDD)

14

15

¿Por qué podemos hacerlo así?

Media experiencia de plantilla de 10 años Más de 60 proyectos No hacemos documentos de especificaciones No hacemos integración de código Tecnología Ruby on Rails Pivotal Tracker

“Por qué creemos en ello. Es nuestra pasión”

16

!gracias!