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?
2
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”
3
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
4
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
5
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”
6
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
7
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
8
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”
9
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
10
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
11
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
12
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)
13
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”
15