Metodologia Agil Scrumgem ASPgems
3 recomendaciones626 vistas
El documento presenta la metodología SCRUM de ASPgems para el desarrollo ágil de proyectos web. Propone iteraciones cortas con prototipados y revisiones continuas para adaptarse rápidamente a los cambios. El cliente y el equipo de desarrollo colaboran estrechamente en Pivotal Tracker para priorizar historias de usuario y entregar funcionalidad de forma incremental.
Metodologia Agil Scrumgem ASPgems
- 1. Nuestra metodología de desarrollo Web SCRUMgem aspgems.com @aspgems
- 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
- 14. 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” 15
- 16. !gracias! 16