subscripción
programania
Lo que los gurús nunca te cuentan sobre Kanban y SCRUM
Junio 17th, 2010 - [Enlace local]
A principios de año comencé un nuevo proyecto de migración de una extensa intranet. Un proyecto que me va a llevar todo un año y, por supuesto, una buena oportunidad para aplicar todo lo que he ido leyendo sobre métodos ágiles (y superar la vergüenza del desarrollo de software).
Realizar el Product Backlog no fue algo especialmente complicado. No se trata de un proyecto especulativo con un “escenario siempre cambiante”, las user stories básicamente se sacaban de “lo que hace la vieja intranet que lo haga la nueva”. Por supuesto nada es tan sencillo (cada user story tiene que tener el tamaño adecuado, etc.), pero no me pararé aquí.
La priorización de las user stories se hizo pensando en la mejor forma de ponerlas en marcha. Aquí hay una cosa clave: la puesta en marcha no es “desplegarla en el servidor de producción”, sino que los usuarios realmente se pongan a utilizarla y cumplan sus necesidades. Son dos cosas muy distintas.
Una vez definidas la user stories y priorizadas, solo quedaba decidir la manera de ir poniéndolas en marcha. Aquí teníamos dos posibles filosofías para seguir:
- scrum: cada X semanas poner en producción una serie de user stories y que los usuarios comiencen a utilizarlas (desactivando la posibilidad de hacerlo en la intranet migrada).
- kanban: cada vez que una nueva user story es terminada (desarrollada, testeada, nosecuantizada…) ponerla en marcha.
Aquí entra el factor humano. Ir poniendo una a una las user stories en producción introducía mucho ruido en los usuarios (“ahora te quito un botón de aquí y te lo pongo allá”), así que comenzamos haciendo unos sprints de 3 semanas, con un periodo inicial de puesta en marcha del proyecto.
Aquí todo normal. El escenario es bastante favorable para la aplicación de métodos ágiles. Quizá la única característica algo molesta es que el presupuesto era fijo. Pero dado que el alcance también era fijo, no era uno de los principales caballos de batalla: se aplicó un “pos se tienen que poder” y punto. 
Bueno… ¿y qué es lo que los gurús nunca te cuentan sobre Kanban y SCRUM? Porque hasta ahora todo lo que he escrito es de manual.
Lo que los gurús nunca te cuentan es que para poder hacer todo esto necesitas tener un entorno de desarrollo EXCELENTE y un conocimiento TÉCNICO de ALTO NIVEL.
Detrás de tanta filosofada Lean hace falta que, a nivel técnico muchas cosas funcionen como un reloj:
- si quieres poner en marcha nuevas funcionalidades en periodos cortos (primero igual lo haces cada tres semanas, pero luego te das cuenta de que quizá sea mejor cada dos… finalmente y cuando el proyecto ya va como un tiro… ambicionas hacer kanban) necesitas un buen sistema de integración contínua TOTALMENTE AUTOMATIZADO.
- para automatizar algo, debes estar haciéndolo de manera manual. Si automatizas la ejecución de pruebas unitarias… pero no estabas haciendo pruebas unitarias… estarás automatizando la nada absoluta. A veces uno se pone como objetivo algo técnico “tener un hudson con un phing, que genere nosecuantas métricas inútiles y lo automatice toro toro toro”…
- integración continua implica TDD (o al menos pruebas unitarias), que implican una MUY BUENA orientación a objetos, que implica un buen uso de patrones (sobre todo de inyección de dependencias) y un conocimiento bastante profundo de los frameworks que utilizas (tanto para pruebas como para desarrollar).
- integración continua implica el uso de un repositorio de versiones (subversion, git, loquesea…). Pero no vale con hacer unos commits aquí y allá: seguramente vas a necesitar branches y los consiguientes merges. Y seguramente te van a surgir unos maravillosos conflictos que vas a tener que saber solucionar. El conocimiento de tu repositorio de versiones tiene que ser MUY BUENO.
- integración continua implica la división entre el servidor de desarrollo (probablemente uno para cada programador), el de pruebas y el de producción. Lo cuál implica una MUY BUENA gestión de configuraciones y que tu aplicación sepa en cada momento si está en pruebas y debe coger la configuración de pruebas o cuál. Esto me remite al punto 1: si tienes un sistema totalmente AUTOMATIZADO de integración continua capaz de desplegar tu aplicación en el servidor de pruebas o en el de producción como si no costara, estás triunfando. En caso contrario, prepárate a perder el tiempo a base de bien.
- integración continua implica desarrollo evolutivo del producto, lo cuál implica un MUY BUEN CLIENTE capaz de hacer piña contigo y que cuando los usuarios monten en cólera porque se sienten algo mareados al ver botones aparecer y desaparecer, al verse obligados a dar feedback, etc. esté contigo. También hace falta que tenga fe en que “la versión que hay ahora evolucionará para bien”. Si los puntos del 1 al 4 funcionan como un reloj, es posible que con el tiempo vayas ganando en credibilidad (porque al principio nadie te cree), sino prepárate para perder credibilidad hasta entre tus jefes….
O sea que necesitas un profundo conocimiento de la orientación a objetos, los patrones, las pruebas unitarias, subversion, hudson (y phing en mi caso), gestión de configuraciones, y un buen cliente. ¿Alguien da más?
A lo que voy es a que las metodologías ágiles sólo marcarán la diferencia cuando seas capaz de juntar la filosofía lean, con unas buenas prácticas de SCRUM o KANBAN y con una FORTÍSIMA CAPACIDAD TÉCNICA. Sin TÉCNICA no hay metodologías ágiles que valgan. Si cada iteración de dos semanas, tardas dos días en poner en marcha la nueva iteración, no vas a ningún lado. Tiene que ser algo AUTOMÁTICO y, para que sea automático, tiene que ser algo TÉCNICAMENTE MUY BUENO.
¿Pero entonces los métodos ágiles, la integración contínua, etc.. no valen la pena?
Valen la pena totalmente. Si te quieres a ti mismo como profesional hazlo, porque verás la luz y marcarás la diferencia.
¿Entonces primero debo ser un experto en todo eso que has dicho y luego ya me hago ágil?
No hay esa posibilidad. Intenta aplicar agilismo desde el principio en la manera en que te sea posible.
¿Entonces a dónde vas con este rant?
A que sepas que va a doler. Eso es lo que no te cuentan los gurús. Que el camino es doloroso. Podrás poner los medios para que el dolor se minimice. Vas a pasarte horas y horas pegándote con problemas técnicos porque eres incapaz de hacer un commit por un tree conflict, o porque hudson da un extrañísimo “segmentation error” a un comando de terminal que ejecutas (y que funciona de lujo en la propia terminal), y no te digo ya como te tomes Selenium en serio….
Dolerá aunque repito, vale la pena totalmente.