Antipatrón de adopción ágil: "Somos especiales"
- Detalles
- Publicado: Jueves, 02 Abril 2009 10:42
- Escrito por Leonardo De Seta
Existe una excusa frecuente con la que me encuentro dentro de organizaciones que están en proceso de adoptar técnicas ágiles de desarollo, que se conoce como el anti-patrón "Somos especiales". Las personas involucradas creen que su situación es especial, que hay un factor único en su entorno que hace completamente imposible adoptar técnicas ágiles, y por lo tanto necesitan continuar trabajando de la manera que lo hacen, sin importar que tan obviamente ineficiente sea.
A pesar de la aplicación de metodologías y el despliegue de factorías de software, la industria del desarrollo está aún lejos de alcanzar los niveles de eficiencia y productividad obtenidos en otras ingenierías. Reflexionamos sobre las características que hacen del software una disciplina diferente a las demás y por qué la agilidad y la adaptabilidad constituyen las claves del éxito.
Varias personas que quieren trabajar en un entorno ágil inevitablmente dicen "No podes ser ágiles porque [completar aquí]". Se escuchan todo tipo de cosas: que nuestro equipo es muy grande, que nuestro proyecto es muy grande, que nuestra cultura no lo va a permitir, que trabajamos bajo un contrato estatal y no está permitido, que nadie más va a apoyornos en ágil, que no hay plata para la capacitación, blah, blah, blah. Da dolor de cabeza de sólo pensar en todas las excusas que se inventan.
Los problemas que surgen durante una iteración no son "bugs", y sólo el Dueño del Producto tiene el derecho a llamar a algo un "bug". Más aún, un equipo ágil sano no debería tener necesidad de usar un Bug Tracker (esas herramientas bonitas para el seguimiento de bugs). De hecho, hasta podría resultar contraproducente...
Estoy cansado de leer información errónea acerca de 
El desarrollo Ágil de software comenzó para atender la problemática humana del desarrollo de software. Es que, en el fondo, el gran asunto en los procesos de desarrollo son siempre las personas que participan de él.
Cada vez que tengo la oportunidad de hablar con alguien que le disgusta la 
Hace poco cometimos un error. Estuvimos observando lo que creíamos hacian las organizaciones Lean, leimos libros y asumimos que Lean se trataba de aplicar las cosas que vimos y leimos. Invertimos tiempo en presentar sistemas pull, procesos Kanban y just-a-tiempo, y por un período obtuvimos mejores resultados. Sin embargo, nunca logramos los resultados sobresalientes que esperábamos, y cuando nos descuidamos todo volvió a cómo se hacían las cosas antes. ¿Por qué? 
Es comun presenciar muchas discusiones acaloradas sobre el proceso del software, las prácticas de diseño y temas parecidos. Muchas de estas discusiones son imposibles de resolver porque la industria del software no tiene una forma de medir algunos de los elementos básicos sobre la efectividad del desarrollo de software. En particular, no existe una forma razonable para medir la productividad.
La arquitectura y el diseño de software son temas que generan mucho debate polémico, pero pocas conclusiones concretas. La Arquitectura Evolutiva y el Diseño Emergente son técnicas ágiles para posponer las decisiones hasta el último momento responsable. En este artículo definimos la arquitectura y el diseño, y luego identificamos preocupaciones comunes a estos temas.
¿Existe algo como un Líder de Producto Ágil? De hecho, si. En