MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

ejemplo, los tests son una forma de redundancia sobre una funcionalidad implementada. Un código actúa de una forma y otro código verifica que actúa como debe actuar. La programación por pares o la revisión del código son una forma de redundancia. La comunicación continua con el cliente es una forma de verificar lo que se pidió en un primer momento.

11. Fallo: hay veces que intentar algo y fallar es mucho mejor que tener interminables reuniones discutiendo las bondades de cada alternativa. Hay gente que denomina “análisis parálisis” al proceso de sobre-analizar algo elucubrando decenas de variantes y situaciones cuando en realidad se podrían haber implementado dos o tres propuestas y haber realizado un análisis empírico, mucho más efectivo. El fallo es una forma de aprender y si se gestiona de forma adecuada, mucho mejor que el análisis parálisis. El lean startup recomienda fallar rápido y barato, como forma de validar modelos de negocio. 12. Calidad: la calidad no es una forma efectiva de control. Un proyecto con mayor calidad no es más costoso que otro con menor calidad. En proyectos pequeños, en forma de prototipos, los desarrolladores pueden relajar mucho la calidad del código y ganar con ello algo de time- to-market. Pero en prácticamente cualquier proyecto real la calidad garantiza que el coste del mantenimiento no se dispara, lo que en el medio plazo reduce los costes y los riesgos del proyecto. Hay veces que la calidad está reñida con la simplicidad. Una solución más mantenible puede ser más compleja y costosa que una solución más simple pero menos mantenible. La regla sería: intenta hacerlo lo mejor que puedas con el tiempo disponible. En la siguiente iteración se mejorará con el trabajo de la primera iteración como base. Esto se puede considerar una pérdida de tiempo, pero también es una forma de luchar contra el análisis- parálisis, aportando valor al cliente desde el principio y reduciendo los riesgos. 13. Pasos de niño: intenta dar los pasos lo más pequeños posibles, eso reducirá los riesgos de fallo de los pasos grandes. Por ejemplo, pasa los test por cada pequeño cambio de código que realices. Eso permitirá detectar más rápidamente los potenciales errores que introduzcas. No esperes dos años a sacar una nueva versión, intenta ofrecer las actualizaciones lo más frecuentes a los usuarios. A priori puede parecer que los pequeños pasos hacen el desarrollo más lento, pero, en la práctica, los pequeños pasos permiten mitigar muchos riesgos y los problemas se solucionan mucho más rápido.

14. Responsabilidad aceptada: la responsabilidad no se puede imponer, solo se puede aceptar voluntariamente. Las prácticas de XP reflejan este principio. El equipo que tiene que realizar un trabajo estima el coste de hacer ese trabajo y se responsabiliza de cumplir con esa estimación

279

European Open Business School