La confusión proviene del malentendido de “cascada” y “ágil”.
En primer lugar, la industria no entendió bien a Waterfall y, por lo demás, a PMI, RUP y otros. Cuando Winston Royce publicó el documento sobre “Gestión del desarrollo de grandes sistemas de software” (página en typepad.com) en 1970, en realidad describió lo que actualmente conocemos como “cascada” (una secuencia secuencial sin retroceso) en los primeros dos De hecho, en las páginas siguientes obtuvo el modelo iterativo, indicando claramente que es arriesgado probar un modelo puramente secuencial.
Lo que se considera metodologías ágiles es en la práctica una secuencia de pequeños ciclos de cascada. Y esto no es un problema.
- Cómo instalar el sistema operativo Android en un teléfono con Windows (8.1 o 8.0)
- ¿Cuáles son las oportunidades de crecimiento en Cisco (India) como desarrollador de software para una nueva?
- ¿Qué tipo de tecnología P2P es adecuada para la transmisión de video de Netflix?
- ¿Qué campo tiene un mejor mercado laboral en Europa y los EE. UU. - informática o ingeniería de software?
- ¿Puede tener éxito como ingeniero de software en Microsoft sin conocer C #?
Muchas personas piensan que las “mini cascadas” son un problema, y en realidad no lo son. El origen de los principios ágiles proviene del modelo PDCA del Dr. Edward Deming (PDCA) y significa “Plan-Do-Check-Act”. Lo encontrará similar con el ciclo “Planificación, implementación, revisión, retrospectiva” de muchas metodologías ágiles. Y esto no es una coincidencia: son lo mismo.
Y el Dr. Deming realmente tuvo la idea del empirista Francis Bacon de 1600 y sus derivaciones sobre lo que hoy conocemos como el “Método Científico”, la hipótesis, el experimento, los ciclos de evaluación.
Retrocediendo tantos siglos atrás en el tiempo, ¿cuál es el punto? El punto es que, en realidad, nunca podemos estar seguros de conocer todas las variables, así que hacemos lo que hacen los empiristas, observamos, derivamos hipótesis, las probamos, estudiamos los resultados, rechazamos lo que no funcionó y refinamos el proceso en orden para volver a intentarlo. Este es el ciclo más natural de todos. Se vuelve vital cuanto más largo sea algo (de ahí que Royce haya titulado su artículo “… de grandes sistemas de software” no “… de todos los sistemas de software”). Presta atención.
Los desarrolladores de software tienen esta idea romántica e ingenua de que el software es algo que comienzas y simplemente “sigues haciendo” y se hará cuando esté listo. De ahí por qué existe esta estúpida ideología #noEstimates.
El ciclo del Método Científico es en realidad el nombre de lo que observamos que hace la naturaleza: la evolución darwiniana de la selección natural. Cada nueva mutación es una hipótesis, sobrevivir al medio ambiente es la implementación, si es capaz de reproducirse, es la evaluación. Si no puede sobrevivir o no puede reproducirse, es el rechazo de la hipótesis. Este es el principio “ágil” o “delgado”: la supervivencia del “más apto”, el “más adaptable”, el más “rentable”.
Este ciclo es necesario en cualquier entorno con escasos recursos. La definición completa de un “proyecto” es algo temporal, con recursos limitados y un objetivo definido. Si no hay una meta que alcanzar, ¿por qué lo estás haciendo?
El objetivo no es el “alcance”, tampoco es la parte del edificio. Y aquí está lo primero que la gente no entiende. Un alcance se describe más comúnmente como lo definió PMI: como una estructura de desglose de trabajo (WBS), “componentes” principales que hacen que todo el “elemento” se construya, ya sea un edificio o un software.
“Pero los edificios y los softwares no son lo mismo”. Por supuesto que no, en general. Pero lo son, en la práctica. La mayor diferencia es que los edificios están sujetos a las leyes de la física. El software no obedece ninguna ley física. Por lo tanto, los errores se corrigen automáticamente en la ingeniería de un edificio, porque si pone un ladrillo fuera de servicio, algo se derrumba, y esto es una respuesta inmediata. Ponga un ladrillo fuera de servicio en Software y no colapsará por mucho tiempo, y esta retroalimentación es la causa de la mayoría de los problemas. Por eso tenemos pequeños ciclos de retroalimentación en metodologías ágiles. Cuanto antes sepamos algo mal, antes se solucionará.
Los proyectos de código abierto funcionan de la misma manera. La gente piensa en ellos como “un esfuerzo continuo, sin restricciones, sin alcances definidos, sin límites” y al principio se siente como “geek nirvana”. Pero no lo es. En primer lugar, el código abierto no se trata de “ser social”, “devolver”, “caridad”. Esos son todos los efectos secundarios, no los objetivos. El código abierto es la forma más rentable de lidiar con el software mercantilizado jamás inventado en el capitalismo moderno (sí, el código abierto es el capitalismo. Sí, el capitalismo es otra abstracción que puede derivarse directamente del darwinismo biológico).
Incluso los proyectos de código abierto tienen restricciones. Tienes que coordinar los esfuerzos de muchas personas que trabajan bajo diferentes agendas. Es por eso que evoluciona la integración continua, los conjuntos de pruebas, los conjuntos de pruebas de regresión, la convención de pequeños compromisos, los bucles de retroalimentación rápidos. Todas esas prácticas se pueden resumir en lo que podemos llamar “prácticas ágiles”, que incluyen TDD, integración continua, pequeñas versiones, estándares de codificación, refactorización, propiedad de código colectivo (todas las prácticas de programación extrema).
Dicho todo esto, los únicos principios que debemos tener en cuenta son:
- ¿Cuáles son los objetivos de lo que sea que estés haciendo? Software o no. Si no tienes objetivos claros, ¿por qué lo estás haciendo? La programación nunca es el objetivo. Codificamos algo como el “medio” para un “fin”, un objetivo. Este fin puede ser hacer que algún proceso sea más rentable, puede ser vender más, puede ser para lograr una mejor comunicación, etc.
- Si tiene un objetivo, definitivamente tiene restricciones para lograrlo. Ya sea tiempo, dinero, fuerza laboral, competencia, tiempo de comercialización, etc. Lo único inteligente que tiene que hacer todo el tiempo es “priorizar”. La priorización solo existe porque no puede hacer todo lo que quiere. Aprender a priorizar es una forma de arte en sí misma.
- Nunca se sabe todo, pero sí se sabe algo. Conoces tus restricciones. Eso generalmente significa tiempo y / o dinero. Es por eso que #noEstimates nunca puede funcionar. Sabes cuánto dinero tienes. Aproximadamente sabes lo que debes construir y tienes una idea de cómo hacerlo. Ahí es cuando comienzas a estimar. “Pero las estimaciones siempre están mal”. ¡Por supuesto que lo son, tontos! La estimación es una suposición. Es por eso que hay otra palabra, “predicción”, para conjeturas exactas.
- Ahora tienes una hipótesis. Salgamos a probar esta hipótesis. Ahora implementa el software en un pequeño ciclo de implementación. Ya sea una tarea por ciclo de tarea (tipo Kanban) o un ciclo de cuadro de tiempo fijo (tipo Scrum), lo importante para cualquier hipótesis es verificar si lo ha refutado (como explicará Karl Popper, es difícil demostrar algo correcto, pero es más fácil demostrar que está equivocado). Esto lleva a la etapa “Retrospectiva” en Scrum (que, de ninguna manera, es algo relacionado con la comodidad del desarrollador, el aire acondicionado o la máquina de café como hacen muchos equipos estúpidos). La retrospectiva es simplemente una etapa para confrontar la hipótesis original con los resultados empíricos y refinar el proceso (el plan, las estimaciones, las prácticas, el equipo mismo). Una vez que se da cuenta de lo que puede cambiar, presenta una nueva hipótesis y comienza un nuevo ciclo.
Este es el “ciclo” o “mini-cascada” que mucha gente ve. Y si considera que “Cascada” es una etapa de “Planificar-Ejecutar-Prueba”, entonces sí, es una secuencia de mini-Cascada o secuencia de PDCA. Esto es lo que los japoneses llamaron “Kaizen” o “Mejora continua”, o lo que Darwin llamó “Evolución por medio de la selección natural”. Un proyecto es como la cría de perros: “evolución mediante selección artificial”.
Todo lo demás escrito en el cuerpo de conocimiento de Project Management, ya sea PMI, RUP, Scrum, XP, Kanban, son “prácticas”. Recopilaron lo que sabemos sobre detalles en términos de implementación. No son ni buenos ni malos. Son simplemente una colección de “cosas” que vimos trabajando en algunos escenarios y que valdría la pena probar. ¡Pero todos usan exactamente el mismo ciclo! El hecho de que alguien haya hecho suposiciones erróneas sobre cómo usar esas prácticas, no significa que las prácticas en sí mismas estén equivocadas. Es como usar un cañón para matar una mosca. No hace que el cañón esté mal, solo la persona que lo usa.
Los ciclos tratan de sobrevivir de la manera más efectiva. Acumular lo que funcionó y rechazar lo que no es la base para la Mejora Continua (es por eso que la Ciencia es un esfuerzo cada vez mejor, en los hombros de muchos gigantes, durante siglos). En las grandes empresas esto está menos claro: solo porque no estás pagando por algo, no significa que alguien no lo esté. Ten eso en mente.