Ahora hazlo en sprints
Ahora hazlo en sprints
¿Cómo no empezar a practicar agile en tu organización?
Mi nombre es Ramón. Llevo programando desde cuando programar no molaba (sí, estudié EGB e hice la mili).
Al principio el trabajo era relativamente tranquilo. Los jefes pedían hacer cambios en el mainframe de los clientes y mi compañero y yo los íbamos desarrollando según llegaban los pedidos.
Los últimos años la cosa ha cambiado bastante. Con todo eso de Facebook y Google, nuestros clientes nos han ido pidiendo más cosas. Al principio sólo eran webs. Luego empezamos hacer pequeños desarrollos en sus sistemas y con el tiempo la cosa siguió creciendo. La verdad es que todo iba bien, pero un día….
- Ramón, acércate - dijo mi jefe. Necesito que rehagas la propuesta para Gamma. Nos ha pedido que lo estructuremos en sprints para poder coordinarnos con la otra consultora que han contratado. - ¿En sprints jefe? Pero, si han pedido una migración de base de datos. ¿Para qué quieren sprints? - Ay Ramón (dijo con rintintín), los sprints son lo que se lleva ahora. ¡Es agile! Todas las empresas de software lo están utilizando para ser más ágiles, para desarrollar más rápido.
Aberraciones como esta pasan. Es muy fácil confundir la agilidad con la velocidad. Sobre todo cuando llegas a ciertos niveles dentro de la empresa. Si yo me tiro de un avión, puedo ir muy rápido, pero no por ello seré más ágil esquivando los obstáculos que me encuentre por el camino.
Para entender por qué agile tiene sentido (y esto es algo que no podré dejar cerrado hoy) me gustaría definir el ceteris paribus del desarrollo de software. Una especie de leyes, que aunque no son para tomarse al pie de la letra, deberíamos aplicarlas con rigurosidad a la hora de entender agile.
Todos los programadores programan igual de rápido e igual de bien, indistintamente de la metodología de trabajo que usen.
Esto quiere decir que si a un desarrollador le toca programar un borrado de una tabla de la base de datos, cuando el usuario pulsa el botón “borrar”, el desarrollador tardará lo mismo en programarlo si trabajan en Scrum, en Kanban, en Waterfall o incluso sin metodología alguna. Si quieres programadores que vayan más rápido, necesitas cambiar de programador, no de framework de trabajo.
El tiempo que se tarda en analizar un desarrollo es menor para desarrollos pequeños que para desarrollos grandes.
Es decir, se tarda menos en analizar el borrado de la tabla, por un lado, y el desarrollo del botón por otro que si analizamos ambos desarrollos en conjunto.
El equipo de desarrollo no sabe que quiere el cliente.
Esta es la más complicada de todas. Si eres el descendiente de Steve Jobs, deja de leer este artículo ahora mismo. Tú si sabes lo que queremos. Para el resto, no lo sabéis. No sabes si el nuevo algoritmo de recomendación va a hacer que ganes un 30% más de dinero. Puedes leer más acerca de esto en mi artículo del 12,5%.
Si llevas tiempo trabajando con metodologías ágiles, no te debería extrañar ninguna de estas. Por eso los sprints son cortos, por eso hay que validar con usuarios y sobre todo, por eso meter Scrum a capón no hace que tu percepción de velocidad del equipo de desarrollo mejore.
Si alguna te suena raro, te recomiendo que releas el Manifesto for Agile Software Development. Ni el Scrum guide ni el blog de un cantamañanas acerca del agile 🙂. Recomiendo el Manifesto porque, aunque es verdad que empieza a oler a viejuno, destaca claramente los problemas que pasaban en el desarrollo de software tradicional, y qué cosas tenían que cambiar para que la industria madurase.
Lo más importante de Agile son dos cosas, adaptarse al cambio (de las cosas que no funcionan dentro y fuera de la empresa) y tener una actitud de entregar código que funciona.