(Nota al inicio: Para escribir este artículo trate de seguir el estilo de varias referencias (1) (2) y fracasé, por lo tanto lo haré con mi estilo, espero les guste)
Antes de adentrarnos en porqué pasarnos a metodologías agiles, comencemos haciendo varias aclaraciones.
Haciendo las correspondientes excepciones:
· Existen proyectos tradicionales (implementados con Cascada, RUP, o WaterRUP - como le dice mi amigo Lucho Salazar - ) ejecutados de forma magistral y exitosa
· Y Existe productos y proyectos desarrollados empleando metodologías ágiles que son que son un fracaso
Pero bajo este escenario también es importante definir éxito, a la luz de la experiencia como:
· Se cumplieron las expectativas de tiempo, alcance, costo y calidad
· Se produjo el producto correcto y de valor para la compañía
· El equipo no se sobreesforzó para lograr este objetivo (no se puede llamar ÉXITO a sobreesfozar – reventar- al equipo de trabajo)
Con estas bases comparto varias reflexiones por las cuales pasarse a utilizar metodologías ágiles:
· En términos generales
o Se ha fallado suficiente con las metodologías tradicionales y no tiene sentido insistir en algo que está desgastando a la industria, teniendo a Clientes, Proveedores, Gerentes de Proyecto, Desarrolladores, Tester y demás en una carrera de las ratas en los que todos salen perdiendo.
o Se ha trasnochado lo suficiente generando insatisfacciones en toda la cadena
o Se ha generado demasiada documentación que luego nadie vuelve sobre ella o más aún cuando se lee todos dicen “esto no sirve” hay que volverlo hacer
o No hay transparencia entre cliente- proveedor y entre ambos se dicen mentiras respecto a avances y progresos
· Respecto al alcance
o Se han ha construido demasiado software que hay que volverlo a hacer debido a que
§ Ya no sirve (se demoraron demasiado tiempo en construirlo)
§ No fue bien construido
§ Fue bien construido pero eso no era lo que se quería
o Se ha perdido suficiente dinero y tiempo en cosas funcionalidades que no agregan valor (reportes que nadie usará, funcionalidades que se construyen porque están especificadas pero nadie les ve sentido, entre otros)
· Respecto al tiempo
o Los tiempos no se cumplen (ver la explicación en la parte de riesgos)
o Hay una creencia férrea en los cronogramas pero nos damos cuenta que estos no sirven y que las cosas van mal cuando nos incumplen
o Los cronogramas son mentirosos, pues muchas veces nos demoramos el finalizando el 10% restante otro 90% de tiempo (o sea que el proyecto demoro 90% hasta el 90% del cronograma y otro 90% tratando de cerrarlo, en total 180% aproximadamente)
o Las ideas pierden su valor porqué nos demoramos demasiado en implementarlas, miremos:
§ 2 en aprobación del proyecto de líder funcional que se le ocurrió
§ 6 meses levantando las especificaciones
§ 1 mes negociando con el proveedor
§ 12 meses construyendo el software (habíamos jurado que duraba 6 pero realmente fue el doble con retrasos y controles de cambio)
§ Mínimo 21 meses desde el momento inicial y la salida a producción generando pérdida de valor de la idea y con seguridad oportunidades de negocio.
· Respecto al costos
o Muchos proyectos no son financieramente un gana-gana para cliente proveedor
o Muchas veces creer que contratos a valor cerrado controlan los riesgos a veces
§ Terminamos contratando a otro proveedor para que arregle lo que “otro hizo mal”
§ Terminamos pagando más en controles de cambio que en el costo original
o La mayoría de veces el costo del proyecto lo asume el proveedor.
· Respecto a los riesgos
o Los riesgos saltan y saltan por doquier
§ Entregas tardías de información que recitábamos
§ Componentes que supuesta funcionaban ya no funcionan
§ Alguien se enferma
§ Alguien se vá
§ El servidor no lo entregaron a tiempo
§ Etc, etc.
Todo nos atrasa, pero el cronograma sigue avanzando por más que hayamos querido plasmar holguras para afrontar esos riesgos, el cronograma se termina desfasando en proporciones no esperadas.
· Respecto a la calidad
o Postergamos la calidad para fases finales y terminamos haciendo trasnochar al equipo de pruebas
o Entregamos productos sin calidad y permitimos que se vayan así a producción
o Permitimos que el tiempo de desarrollo se absorba el tiempo de pruebas
o La fuerza bruta en calidad (aumentar los testers) no mejora la calidad del proyecto
Como lo he expresado antes estamos resolviendo el problema de forma incorrecta.(Causas del "MANEJO" o dícese de "LA FALTA DE TRANSPARENCIA")
1. Liberación más rápida de producto (más rápido time to market) (1)
Debido a:
· Enfoque en liberaciones rápidas y de calidad en periodos de 2 semanas a un mes (para SCRUM)
2. Retorno de inversión (ROI) más rápido (1) (3)
Debido a:
· Enfoque en liberar lo antes posible funcionalidades y mostrar valor con software funcionando se logra mas rápido retorno de inversión lo que supera con creces a los 21 meses explicados en los párrafos superiores.
3. Más rápida retroalimentación del cliente. (1)
Debido a:
· La entrega de un producto más rápido lo que permite evolucionar el software con más certeza.
4. Construcción del producto correcto, debido al feedback de cliente. (1)
Debido a:
· Similar al punto anterior, el feedbak se vuelve esencial para construir el producto correcto
· Enfocarse en las funcionalidades de valor al negocio evita que se construya el producto incorrecto.
5. Temprana reducción del riesgo (1) (3) – aclaro, no es que no existan riesgos -
Debido a:
· Los ciclos cortos, la constante comunicación y feedback, el enfoque en la calidad, y la constante implantación de mejoras en el proceso (fruto de las retrospectivas) permite que los riesgos sean gestionados de una forma más eficiente y proactiva.
6. Mayor calidad (2)
Debido a:
· El enfoque a la excelencia técnica
· Las prácticas ágiles de desarrollo
· Y la Definición de Terminado (Defitinion of Done)
Logran que el equipo se enfoque en incluir cada sprint o ciclo la calidad y no postergarlo para fases finales.
7. Mejor cultura y moral del equipo (1) (2)
Debido a:
· Continuo feedback del cliente
· Ciclos de mejora dados por las retrospectivas
· Victorias tempranas y cíclicas
Logran que la moral del equipo se mantenga alta y motivada para producir productos grandiosos.
8. Satisfacción del cliente (1)
Debido a:
· La entrega continua de producto con valor
· El constante feedback a la equipo sobre el producto
· El avance visto como software funcionando
Mejoran la satisfacción del cliente.
9. Mayor calidad (2)
Debido a:
· No postergar la calidad sino embeberla en cada ciclo de desarrollo.
10. Mejor gestión del cambio (2)
Debido a:
· El cambio es bienvenido y es considerado una oportunidad para darle mayor beneficio al negocio del cliente
· Si se requiere algo nuevo, se desplaza o quita algo y se hace la nueva funcionalidad
11. Mayor velocidad y eficiencia (2)
La velocidad no se da porqué se omitan pasos en el desarrollo de software, ocurre debido a:
· los equipos de desarrollo están enfocados en funcionalidades de valor para el negocio
· Las funcionalidades se construyen en ciclos cortos con la calidad inmersa
Debido a lo anterior se logra el feedback del cliente y en consecuencia mayor velocidad para el negocio.
12. Eliminación de Funcionalidades redundantes en el Software (3)
Debido a:
· Enfoque en las funcionalidades que más valor le entrega al negocio
13. Documentación más ligera y útil (3)
Debido a:
· Se produce documentación útil y orientada a que aporte al producto. De forma que no hay desperdicio en documentación y en el tiempo de elaboración.
14. No es una moda, es un enfoque que se decide o no adoptar
Debido a:
· El Departamento de Defensa de los Estados Unidos está trabajando bajo metodologías ágiles (4)
· SAP, Microsoft tiene miles de programadores mejorando sus productos con Scrum (5)
· Entre muchos casos a nivel local (Colombia) como Sura, EPM, Protección entre otros.
15. Alta visibilidad y control sobre el progreso del proyecto y producto (6)
Debido a:
· Al enfoque en la transparencia
· Ciclos cortos que evidencien falencias a corregir
· Los ciclos cortos permiten mejorar el seguimiento del proyecto
16. Un dueño de producto empoderado que proporciona feedback y es clave en el exito (6)
Esto proporciona al equipo una rápida solución de dudas, inquietudes y la posibilidad de caminar ciclo por ciclo sobre requisitos claros y bien definidos. Adicional a esto esta comunicación continua y efectiva mitiga riesgos asociados a la confianza ciega en la documentación
17. Agile ayuda a cumplir los objetivos de IT dentro del Negocio. (6)
Debido a que solo se trabaja en las prioridades de negocio.
18. Un enfoque en la mejora continua
Debido a que el equipo ciclo tras ciclo (al menos cada mes) identifica como mejorar para lograr mayor éxito la siguiente iteración (tanto en lo técnico, como en el proceso y equipo), implica una adopción temprana de lecciones aprendidas que permite la mejora en eficiencia y desempeño de todos los involucrados en la construcción del producto.
Pero una última recomendación, si se decide dar el paso hacia el agilismo no solo se necesitan:
· Certificaciones
· Y capacitaciones
SE REQUIERE DE ACOMPAÑAMIENTO, tanto a los roles directivos como a quienes construirán los productos, en primer lugar para que estén alineados y tengan claros los resultados esperados en la medida que van avanzando y en segundo lugar para que lo hagan bien, pues se requiere remover muchas “malas prácticas” y vicios – como querer tener todo controlado o Mando Control - , para dejar emerger y funcionar los valores ágiles:
· Transparencia
· Confianza
· Enfoque
· Coraje
· Apertura
· Compromiso
· Respeto
Y lograr así los anhelados frutos del agilismo “entrega de SOFTWARE CON VALOR de forma frecuente con EQUIPOS ALTAMENTE MOTIVADOS”
Bienvenidos los proyectos pilotos con acompañamiento…
De todos modos yo ya hice mi elección y ¿usted?
Fuentes:
1. Leading Agile. The 12 Key Reasons Companies Adopt Agile. [En línea] 30 de Enero de 2011. [Citado el: 28 de Enero de 2015.] http://www.leadingagile.com/2011/01/the-12-key-reasons-companies-adopt-agile/.
2. PMOinformatica.com. 10 razones para aplicar metodologías ágiles: Primera parte. [En línea] 28 de Enero de 2013. [Citado el: 28 de Febrero de 2015.] http://www.pmoinformatica.com/2013/01/10-razones-para-aplicar-metodologias.html.
3. PMOinformatica.com. 10 razones para aplicar metodologías ágiles: Segunda Parte. [En línea] 6 de Febrero de 2013. [Citado el: 28 de Febrero de 2015.] http://www.pmoinformatica.com/2013/02/10-razones-para-aplicar-metodologias.html.
4. Pahuja, Savita. InfoQ.com. US Department of Defense (DoD) is Going Agile. [En línea] InfoQ, 31 de Mayo de 2014. [Citado el: 1 de Marzo de 2015.] http://www.infoq.com/news/2014/05/DoD_agile.
5. Suttherland, Jeff. Youtube. Jeff Sutherland | "Scrum: The Future of Work" | Monday Keynote | Global Scrum Gathering® Las Vegas. [En línea] http://www.scruminc.com/, 13 de Mayo de 2013. [Citado el: 1 de Marzo de 2015.] https://www.youtube.com/watch?v=RYIPSPWVc8o&list=PL0IaI6QFvmiTj8qc0vnpW7k0K48HI3Fda&index=6.
6. Proulx, Martin. Analytical Mind. Seven wrong reasons to adopt Agile. [En línea] 4 de Mayo de 2010. [Citado el: 1 de Marzo de 2015.] http://analytical-mind.com/2010/05/04/seven-wrong-reasons-to-adopt-agile/.
7. Elatta, Sally. Scrum Alliance. Destination: Agile - Top Eight Reasons Why Organizations Are Making the Switch. [En línea] 8 de Enero de 2008. [Citado el: 1 de Marzo de 2015.] https://www.scrumalliance.org/community/articles/2008/january/destination-agile.
No hay comentarios.:
Publicar un comentario