Caso de Éxito: Proyecto Agile en una compañia Cementera
•Descargar como PPTX, PDF•
0 recomendaciones•1,053 vistas
ste artículo describe uno de nuestros proyectos que desarrollamos en Analytics, bajo el enfoque Ágil, de alguna manera muestra cómo llevamos el proyecto de principio y fin, con momentos complicados y felices y aquí mi relato.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Caso de Éxito: Proyecto Agile en una compañia Cementera
Similar a Caso de Éxito: Proyecto Agile en una compañia Cementera (20)
Más de Christian Vera, Agile Coach,SMC,SPOC,ITIL®Expert,PRINCE2,Cobit
Más de Christian Vera, Agile Coach,SMC,SPOC,ITIL®Expert,PRINCE2,Cobit (9)
Último
Último (20)
Caso de Éxito: Proyecto Agile en una compañia Cementera
- 1. ‹#› Christian Vera Livia Gerente de Ingeniería en Analytics PMI-ACP® | SMC® | CAPM® | Agile Practitioner| Design Thinker | M3.0® | LSP® Caso de éxito Proyecto Agile en una compañía cementera @christianv161
- 2. ‹#› Analytics • Empresa de Consultoría en Inteligencia de Negocios, especialista en la Aplicación de Soluciones Cuantitativas para optimizar la Toma de Decisiones. Nuestra misión es ser considerados Trusted Advisor (Consejero de Confianza) en la Consultoría de Soluciones Analíticas de alto impacto para la toma de Decisiones de Negocios. Web transformation Project
- 3. ‹#› Cliente • El cliente, empresa líder en el mercado peruano en la producción y distribución de concreto premezclado a nivel nacional, cuenta con unidades de negocio en los siguientes rubros: Concreto Premezclado, Bombas, Minería, Agregados, Pre-fabricados y Pavimentos. Web transformation Project
- 4. ‹#› Web transformation Project ¡ Ganamos el Proyecto!
- 5. ‹#› Los requisitos, las fechas y el presupuesto ya estaban pactados con el Cliente Web transformation Project Pero OH, el cliente no sabe todo lo que quiere… +
- 7. ‹#› Acuerdos • Confirmamos la fecha de KicKoff con el cliente • Propusimos el marco de trabajo • Analizamos en profundidad todos los requisitos y de paso ayudamos a construir el Product Backlog. • Sin usar términos de Agiles por el momento. • Propusimos un Inception Ágile. • Explicar el concepto de MVP (Producto Mínimo Viable). • Conocer al total de involucrados. Web transformation Project WIKIPEDIA
- 8. ‹#› Acuerdos Mi idea era realizar un INCEPTION, que me permitiera dejar claro a todos las partes del proyecto qué es lo que íbamos a hacer y cómo lo haríamos. De modo que seleccioné aquellas preguntas que creí me permitirían acotar mejor el proyecto: Definir el proyecto en una explicación corta y concisa Definir qué NO es este proyecto Comentar qué podría quitarnos el sueño durante el desarrollo de este proyecto Conocer a los vecinos (lista de implicados, sean personas o no, a los que afectará el proyecto) Web transformation Project
- 9. ‹#› Ganar - Ganar Web transformation Project
- 10. ‹#› Divide y vencerás Mas vale poco y valioso en la mano, que mucho y perfecto volando Web transformation Project
- 11. ‹#› Siguientes pasos • Ayudamos en el descubrimiento y creación de historias de usuario. • Desde luego varios cosas no estuvieran escritas en la oferta. • Identificamos los días laborales • Estimación de esfuerzo. • Identificamos las tareas • Estimamos las tareas • Determinamos la capacidad del trabajo Web transformation Project La calidad era la priorización de tareas por períodos de tiempo de 10 días de entrega, demostración e instalando el producto al final de cada período.
- 12. ‹#› Siguientes pasos Web transformation Project Una vez conocido el esfuerzo total (recalco: inicial) – hicimos un cálculo muy sencillo: Explicamos al cliente que el equipo tenía una velocidad de trabajo de N puntos diarios y que esos puntos reflejaban: Cantidad de trabajo que el equipo era capaz de sacar adelante cada día, es decir, la capacidad diaria de trabajo capacidad diaria (N puntos) es equiparable a los puntos de esfuerzo asignado a las tareas Luego, teniendo la fecha límite para la entrega del producto, contamos los días laborables y determinamos la capacidad de trabajo total - aproximada- hasta la fecha de entrega y vimos que no coincidían, como casi nunca coincidirán.
- 13. ‹#› Web transformation Project Explicamos que eso sucede en la gran mayoría de los proyectos y es por eso que se entregan fuera de plazos, con poca calidad y muchos errores, y que para evitar eso, lo que nos aseguraba la calidad era la priorización de tareas por períodos de tiempo de 10 días y la entrega, demostración e instalación del producto al final de cada período.
- 14. ‹#› En las reuniones de inicio del proyecto le explicamos Necesitamos el compromiso por su parte y que era imprescindible que estuviera al principio, durante y al final de cada Sprint para validar que el trabajo que íbamos a hacer era el que él necesitaba. Web transformation Project
- 15. ‹#› Otro acuerdo. Antes de iniciar cada Sprint, realizamos junto con el cliente la selección de Historias de Usuario. ¿Cómo lo hacíamos? Web transformation Project
- 16. ‹#› Iniciamos los primeros sprint….. Web transformation Project
- 17. ‹#› Por último, definíamos los días que ocuparía el Sprint y la fecha de la próxima reunión, donde realizaríamos la demo y entregaríamos al cliente el desarrollo realizado para que lo instalase en los servidores, junto con la documentación que le permitiría instalar y trabajar con el producto. Web transformation Project
- 18. ‹#› Web transformation Project Trabajando en el primer y segundo Sprint
- 19. ‹#› Reuniones de planificación, seguimiento, entrega y todas (y sólo) las que sean necesarias Web transformation Project
- 20. ‹#› • Respetar el tiempo de los demás es primordial • Realizar una convocatoria, poner bien claro de qué se va a hablar en la reunión. • Durante todo el proyecto intentamos, por todos los medios, mantener las reuniones que recomienda Scrum. • No sólo nos juntábamos en el momento de la reunión. • Es responsabilidad de todo el equipo “incluyendo al cliente, claro está” el no malgastar el tiempo. Web transformation Project
- 21. ‹#› Presentamos los sprint….. Web transformation Project
- 22. ‹#› Mejoramos por cada sprint….. Web transformation Project
- 24. ‹#› Una vez entregado el último paquete del producto, tuvimos 3 días por nuestra cuenta para probar bien el producto e ir solucionando aquello que no funcionase bien. Web transformation Project
- 25. ‹#› El cliente no nos reportó prácticamente ninguna incidencia y las que encontramos por nuestra cuenta las resolvimos e hicimos una última entrega. Web transformation Project
- 26. ‹#› El cliente nos envió un mensaje contándonos lo cómodo que estuvo durante el tiempo de desarrollo y su satisfacción con el producto final. Web transformation Project
- 27. ‹#› Nosotros aprendimos a valorar la comodidad del trabajo con Scrum. Web transformation Project
- 28. ‹#› Celebramos !!! Web transformation Project
- 30. ‹#› Esto no termina aquí…! Web transformation Project
Notas del editor
- Consejero de confianza
- ¿Por qué no toda la Inception? Pues porque era la primera vez que iba a jugar con esta técnica y porque se supone que ya estábamos consumiendo horas del proyecto en la que no se había presupuestado tiempo para esto.
- Para desarrollar todas las historias de usuario se necesitaba más esfuerzo que capacidad tenía el equipo.
- Para desarrollar todas las historias de usuario se necesitaba más esfuerzo que capacidad tenía el equipo.
- En el primer Sprint incluimos todas las tareas necesarias para montar la arquitectura inicial del proyecto. Esas tareas las incluimos delante del cliente, de modo que viera que “eso” también lleva tiempo. No hubo problemas con la asignación de tiempo para ello. En el primer y segundo Sprints decidimos incluir todas aquellas funcionalidades relacionadas con “aquello que nos quita el sueño” y que hablamos en la Inception. Esta decisión nos quitó muchísimas preocupaciones de encima a lo largo del proyecto, ya que todos los problemas que podían surgir se solucionaron en la primera mitad del proyecto, consiguiendo el final feliz que todos queríamos
- En el primer Sprint incluimos todas las tareas necesarias para montar la arquitectura inicial del proyecto. Esas tareas las incluimos delante del cliente, de modo que viera que “eso” también lleva tiempo. No hubo problemas con la asignación de tiempo para ello. En el primer y segundo Sprints decidimos incluir todas aquellas funcionalidades relacionadas con “aquello que nos quita el sueño” y que hablamos en la Inception. Esta decisión nos quitó muchísimas preocupaciones de encima a lo largo del proyecto, ya que todos los problemas que podían surgir se solucionaron en la primera mitad del proyecto, consiguiendo el final feliz que todos queríamos
- Esto nos lo pudimos permitir por la carga de trabajo de ese momento. Por lo general ese tiempo debe estar planificado dentro del proyecto, desde el inicio, y casi nunca se hace para abaratarlo. No debería haber problemas si se desarrolla bien, pero eso es casi una quimera.
- Esto nos lo pudimos permitir por la carga de trabajo de ese momento. Por lo general ese tiempo debe estar planificado dentro del proyecto, desde el inicio, y casi nunca se hace para abaratarlo. No debería haber problemas si se desarrolla bien, pero eso es casi una quimera.
- Esto nos lo pudimos permitir por la carga de trabajo de ese momento. Por lo general ese tiempo debe estar planificado dentro del proyecto, desde el inicio, y casi nunca se hace para abaratarlo. No debería haber problemas si se desarrolla bien, pero eso es casi una quimera.