La forma más fácil de ejemplificar el movimiento Ágil es pensar en un helado, no por lo fresco y frio sino porque viene en capas y sabores y a todo el mundo le encanta :)
La base del cono de los sabores agiles reside en toda la teoría que trae consigo el Toyota Production System que luego evoluciono hacia el Toyota Way. Subiendo un poco más hacia arriba vemos que lo anterior dio origen a la escuela de pensamiento Lean que Mary and Tom Poppendiek magistralmente plasmaron en su propuesta de Lean Software Development[1].
Lean fue uno de los puntos de inspiración para la redacción del Manifiesto Ágil[2]. Este manifiesto ha sido leído, consultado y citado en innumerables publicaciones. Sin embargo, por si solo el manifiesto no es algo que pueda ponerse directamente en la práctica.
De hecho tanto Lean como Agile son en esencia herramientas de razonamiento[3] que permiten observar, pensar y actuar de cierta forma. Por ejemplo el Lean sugiere principios como eliminar desperdicios[4] que lo que hacen es colocarnos en un estado mental predispuesto para identificar tareas que no contribuyan directamente a la generación de valor en el producto-desperdicio y que por tanto deban ser eliminadas.
En consecuencia alguien podrá decir “yo pienso agile o yo pienso lean” pero no podrá decir “yo implemento agile o yo implemento lean”. La diferencia entre el pensar y el hacer es lo que separa el cono de los sabores del helado.
El primer sabor es XP (eXtremme Programming[5]) y como en la figura es el sabor sobre el cual se apilan los demás. XP aglutina un conjunto de prácticas de ingeniería pensadas y orientadas totalmente al desarrollo de software. Consecuentemente las practicas de XP son cosas de las cuales no se puede (ni debe) prescindir en cualquier proyecto de desarrollo de software.
Me encanta hacer la analogía entre XP y un auto de F1 que fue construido con un único propósito: correr lo más rápida y efectivamente posible. A un F1 no es posible (bueno posible si pero peligroso :)) recortarle piezas; ya es una joya de ingeniería en sí que tiene lo mínimo necesario para correr. Similarmente XP es una obra maestra de buenas prácticas que deben existir (insisto todas) en un proyecto de software. XP ya es ligero como es, no hay necesidad de recortarle nada. En este sentido XP es el más prescriptivo de los sabores agiles.
El siguiente sabor es Scrum[6] que se concibió como un marco de trabajo[7] ligero que sugiere (no impone) roles, artefactos y ceremonias. Scrum es un marco de trabajo no necesariamente asociado a desarrollo de software, de hecho es tan flexible que puede ser adaptado a otros dominios de aplicación. Un ejemplo interesante ocurre en mi organización donde se está usando Scrum para impartir cursos de inglés.
Scrum formalizo-y porque no mejoro-algunas de las buenas prácticas agiles que existían desde hace tiempo como iteraciones y user stories. Una de las grandes ventajas-o desventajas como quiera verse-es que Scrum tiene detrás una organización sin fines de lucro: el Scrum Alliance[8] que es especialmente activa proporcionando entrenamientos y certificaciones.
La cereza sobre el helado es kanban[9] que es una gran mejora sobre el taskboard recomendado por Scrum.
Helado sin cono
¿Es posible aplicar kanban sin hacer Scrum/XP y pensar en Agile/Lean? Equivale a preguntarse ¿es posible tener solo el ultimo sabor del helado y además sin el cono? La respuesta es obvia, desde luego que si pero uno acaba perdiéndose los demás sabores y comodidad de tener un cono que sostenga el helado mientras uno se lo come.
¿Sería posible aplicar solo Scrum sin nada de XP? Desde luego que sí, pero en algo que no tenga que ver con software. Por ejemplo, ¿de que me serviría utilizar a cabalidad Scrum si mi proyecto no cuenta con un build machine que garantice la integración continua del código producido?
¿Tiene sentido aplicar los principios de XP sin pensar en Agile y Lean? Muchos equipos lo hacen, pero por mas fuertes que sean los principios XP estos no hacen hincapié en los factores humanos (me encanta llamar a esto peopleware) que son el gran capital de un proyecto. Lean es especialmente útil aquí, después de todo Lean es aquella cosa mágica que permitió que Toyota llegue donde llego, algo de bueno ha de tener como para dejarlo pasar :)
[1] Lean Software Development: An Agile Toolkit (Agile Software Development Series) by Mary Poppendieck and Tom Poppendieck (Paperback - May 18, 2003)
[2] http://www.agilemanifesto.org/
[3] Traduccion literal de “thinking tools”
[5] http://xprogramming.com/index.php
[8] www.scrumalliance.org
[9] http://www.infoq.com/minibooks/kanban-scrum-minibook
Concuerdo la base de cualquier emprendimiento o proyecto deberia ser el enfoque (Lean thinking).
ReplyDeleteLas practicas (XP) y marco de trabajo (Scrum)
surgen como consecuencia, ademas claro por experimentacion y experiencia.
Sin duda tanto lean como las distintas disciplinas agile ayudan a mejorar cualquier tipo de proyecto o linea de produccion al menos en contraposicion a enfoques y practicas tradicioinales, excepto lean que tiene un espectro mas amplio.
Es reconocible el logro de Toyota como mejor ejemplo (tal vez) de la aplicacion de este enfoque y practicas, pero ciertamente dudo que este enfoque y practicas sean la unica razon para su exito, no creen que tambien existen otras razones como ser:
- El incremento continuo del precio de los combustibles
- Japon es ahora mismo la segunda economia mundial sin embargo su cultura no solo los ayudo a llegar donde estan al parecer tambien los protege ya que no es desconocido que son pocos productos extranjeros que tienen exito en ese pais.
- La cultura Estadounidense ¿Comó? poco a poco fueron consumiendo mas y mas productos extranjeros a tal punto de casi llevar a la extincion a su propia industria automotriz.
Rodrigo,
ReplyDeleteJustamente las tres razones que expones al final estan entre las muchas que los estudiosos norteamericanos propusieron para justificar el exito de Toyota. De hecho se debatio muchisimo acerca de lo circunstancial que habia sido el exito de lean.
Sin embargo existieron casos como las filiales de Toyota dentro de EEUU y con empleados norteamericanos que superaron a las ensambladoras de Detroit.
Esto acabo probando que Lean si funciona pese a todo, al fin y al cabo Lean se concentra en las personas, que las circunstancias les sean favorables siempre ayuda mas no es delimitante.
Saludos,
Juan
Estoy enteramente deacuerdo con lo que expones, como muy bien dices, y cito [“yo pienso agile o yo pienso lean” pero no podrá decir “yo implemento agile o yo implemento lean”. La diferencia entre el pensar y el hacer es lo que separa el cono de los sabores del helado.]
ReplyDeletePara emprender un nuevo proyecto de software abria que estar mentalizado con estas metodologias, al decir mentalizado me refiero a pensar y actuar de cierta forma, como en Lean y su practica waste, mentalizar y actuar de forma de eliminar waste: y no memorizar o leer sobre estas metodologias y ya, trabajo concluido, vuelvo a mi puesto de trabajo y continuo haciendo lo que siempre hago. Es el clasico problema de la brecha de la teoria y la practica.
Mi pregunta es, que medidas se deben tomar si en el grupo de desarrollo se tomo la desicion de emplear metodologias agiles (XP, Scrum, Lean...), nos enteramos de que es y como funciona, nos gusta y lo entendemos, pero a la hora de la hora todos siguen haciendo lo que saben hacer y si cumplen con algunos de los objetivos, tareas o principios de las metodologias agiles lo hacen por compromiso y no por conviccion. El problema creo yo es que no hay valor para comenzar, tienen miedo a equivocarse y como dicen por mi pueblo mas vale chola conocida que...!!!
Ref: http://www.agile-spain.com/abismoparalamejora
Saludos.
Hay varias etapas en el aprendizaje, la primera es en un salon de clases en el cual de forma teorica, practica, vivencial, guiada o como se quiera implementar, la gente aprenda algo.
ReplyDeleteEsto se quedara siempre corto si en la practica no se aplica lo aprendido. Aqui intervinen los coaches que lo que hacen en reforzar y animar a la gente a tomar el riesgo de aplicar lo aprendido.
Quienes son los coaches? Pueden ser internos, alguien del mismo equipo, o externos, alguien con mas experiencia o un mananger involucrado.
Saludos,
Juan
E aquí un pequeño post de la primera experiencia con agile y scrum
ReplyDelete