Principios Ágiles #2

Siguiendo con la temática de los principios ágiles, hoy voy a hablar de el segundo de ellos:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Aceptamos requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

¿Por qué se aceptan los requisitos cambiantes?
Porque es la forma más sencilla de adaptarse a la realidad. Aunque exista un contrato firmado por el cliente en el que se fija el "alcance" del proyecto, lo cierto es que los requisitos cambian. Normalmente un cliente no sabe exactamente lo que quiere. Su conocimiento va aumentando según avanza el proyecto y es así como consigue definir realmente su objetivo. Dado que es imposible que el proyecto no cambie hay que hacer algo para que ese cambio no sea doloroso. Ahí es donde entra este principio. Aceptar los requisitos cambiantes significa que, si el cliente cambia de opinión, hay que hacerle caso y se debe modificar el desarrollo (Recordad que "nuestra máxima prioridad es satisfacer al cliente"). No hay que utilizar el contrato como escudo contra el cliente. Hay que utilizar al cliente como compañero para conseguir que el contrato llegue a buen puerto. Es decir, se debe establecer una relación de confianza entre el cliente y el proveedor para aprovechar las ideas de ambos.

¿Por qué no importa que los cambios lleguen en etapas avanzadas de desarrollo?
Porque, al tener "entregas continuas y tempranas de software valioso", es sencillo introducir los cambios que pida el cliente en cualquier etapa. La obligación de entregar software funcionando en cualquier momento del desarrollo hace que la complejidad al introducir cambios sea constante a lo largo del tiempo. Para que este modelo sea mantenible es necesario que el equipo de desarrollo se preocupe de que la base de código sea de calidad (Prácticas XP). Si no se mejora la base de código de forma continua, aceptar los cambios será cada vez más complicado, faltando así a este principio.

¿Cómo aprovechar el cambio para proporcionar ventaja competitiva?
Al aceptar el cambio lo que en realidad se está haciendo es aumentar la velocidad de reacción del cliente, que puede reaccionar antes a los proyectos de la competencia. Es capaz de adaptar su producto para eliminar las ventajas del rival y crear las suyas propias (o, al menos, intentarlo).


Conclusiones

El segundo principio ágil:

• se basa en abrazar el cambio. No hay que protegerse contra el cambio.
• introduce la colaboración con el cliente. Un cliente implicado que quiere la mejor herramienta posible.
• asume ciertas prácticas en el área de desarrollo (XP).
• aumenta la velocidad de reacción del cliente ante el mercado.

Principios Ágiles #1

Cuando uno entra en esto del agilismo lo primero que le cuentan es el Manifiesto Ágil. Conocer el manifiesto ágil es importante, pero no basta con quedarse ahí. Los autores originales del manifiesto se tomaron muchas molestias para redactar los 12 principios detrás del manifiesto y es necesario que nos los tomemos tan en serio como al propio manifiesto.
He decidido dedicar un post a cada principio. Empecemos por el primero:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Nuestra prioridad más alta es satisfacer al cliente mediante entregas continuas y tempranas de software valioso.

¿Por qué la prioridad más alta?
Es importante destacar que los firmantes del manifiesto ágil tienen un objetivo por encima del resto. Además, dicho objetivo no es negociable. Siempre debe estar presente y siempre debe cumplirse. Si no se cumple es un fracaso.Dicho objetivo es satisfacer al cliente.

¿Qué significa satisfacer al cliente?
A la hora de realizar un desarrollo es importante tener un cliente que lo demande (Cuando hablo de cliente me refiero a quien demanda dicho desarrollo. Por ejemplo, un cliente puede ser el propio desarrollador que necesita una nueva librería para un proyecto más grande. No tiene porque ser siempre un cliente que firma un contrato). Si no existe el cliente no existe el desarrollo. El cliente es el leitmotiv del desarrollo. Esto, que parece tan simple, se pierde muchas veces de vista a lo largo del desarrollo, provocando que se tomen decisiones sin contar con el cliente con lo que el desarrollo se va alejando de las necesidades de dicho cliente.

¿Por qué con entregas continuas y tempranas?
Por varios motivos. Deben realizarse entregas tempranas porque es una forma de involucrar al cliente en el desarrollo (Puede validar la usabilidad del desarrollo, puede opinar sobre el entregable, etc...). A su vez, deben realizarse entregas continuas porque de esa forma se es capaz de adaptarse a lo que el cliente quiere en cada momento. Los requisitos del cliente no son inmutables, por eso, cuanto antes se le enseñe software funcionando antes se podrá modificar de acuerdo a las nuevas necesidades del cliente.
Mediante este tipo de entregas se consigue un feedback del cliente que permite que el rumbo del desarrollo siempre apunte hacía donde el cliente desea.

¿Qué es software valioso?
Es software que funciona y que hace lo que el cliente necesita. Es fácil decirlo, pero no es nada sencillo conseguirlo.
Software que hace lo que el cliente necesita se puede conseguir mediante entregas continuas y tempranas, tal y como se ha explicado antes.
Conseguir software que funcione es mucho más complicado pero es condición necesaria para conseguir la satisfacción del cliente. Esto, que puede parecer algo obvio, se suele olvidar en la mayoría de los desarrollos. La "industria del software" (clientes y proveedores) está acostumbrada a rebajar las exigencias y a permitir errores en la mayoría de los proyectos que se realizan (ya sea por los tiempos de entrega, por la pobre formación de los desarrolladores, etc). A un desarrollo hay que exigirle que funcione y en eso es en lo que se centra el agilismo, en el software que funciona. Cualquier otra cosa dejará al cliente insatisfecho. Probablemente algún bug aparezca (ya sabéis, cualquier código contiene al menos un bug) pero se debe reducir la tasa de errores al mínimo (sobre todo en las funcionalidades principales). Es cierto que no todos los desarrollos tendrán la misma calidad (Siempre habrá desarrolladores mejores y desarrolladores peores, pero eso solo puede tener influencia en el tiempo que se tarde en realizar el proyecto, en lo fácil o difícil que sea mantener dicho proyecto, etc), pero es necesario exigirnos que funcionen (Un Seat y un Ferrari funcionan, la diferencia está en el proceso de montaje, en la calidad de los materiales, etc).

Conclusiones

El primer principio ágil:

• se basa en el la satisfacción del cliente.
• muestra como obtener un feedback periódico del cliente.
• indica la necesidad de entregar lo que el cliente necesita.
• avisa de la importancia que tiene el entregar software que funciona.

9º Encuentro Agile-Madrid. Kanban

Ayer se celebró la 9ª reunión del grupo local de Madrid en las oficinas de 11870.com. El tema de la reunión era Kanban, un tema que, particularmente, me resultaba muy interesante (en mi empresa soy "Kanban-master" de un equipo). A la llamada acudimos 10 caras conocidas (todos eramos "habituales" de las reuniones, aunque yo falté a las dos últimas...) dispuestos a aprender y compartir experiencias.

La reunión comenzó con una charla de Agustín Yagüe sobre los fundamentos de Kanban (Aquí tenéis la página de la reunión. Están las transparencias de la presentación y las lecturas recomendadas. De estas, yo recomiendo ésta. Muy buen artículo. Además, José Manuel Beas ha colgado el vídeo de la presentación aquí). Normalmente no empezamos así las reuniones pero la verdad es que estuvo bien comenzar con una pequeña introducción sobre el tema porque nos hizo adoptar un vocabulario común (el expresado en la presentación). Además, la gente que no conocía Kanban pudo entender por lo menos de que se iba a discutir en la reunión.

Después de la presentación, Agustín preparó un pequeño ejercicio práctico en el que los asistentes simulábamos un proceso guiado mediante Kanban. La verdad es que fue muy divertido y bastante instructivo.

Lo que me llevo sobre Kanban de la reunión es lo siguiente:

• Kanban es un sistema pull, es decir, no se hace nada hasta que te lo pida la siguiente fase (y la fase final es el cliente que demanda un producto).
• Kanban está basado en señales. En el caso del desarrollo de software esas señales son los post-it con las tareas a realizar y los movimientos de dichos post-it que, al dejar un hueco indican la posibilidad de crear algo.
• Los pilares de Kanban son limitar el trabajo en progreso (evitar la sobreproducción, es decir, no hacer más de lo que el cliente pida) y la mejora continua del proceso (cualquiera de los miembros del equipo es capaz de descubrir posibles mejoras en el proceso).
• Kanban necesita un workflow para funcionar. Dicho workflow puede ser tan simple o tan complicado como se quiera (Desde el típico ToDo-Doing-Done hasta flujos complejos).
• Kanban dice que los equipos deben ser multidisciplinares ya que, cuando una de las fases se convierte en un cuello de botella, las personas bloqueadas por dicha fase deben hacer todo lo posible por desbloquearla (Ayudando a la persona que está en dicha fase). Sin embargo, el basarse en un workflow implica cierto grado de especialidad (Tú vas a estar más tiempo en la fase a la que pertenezcas y menos en las otras, ya que en las otras solo estarás si las cosas van mal).
• Que Kanban sea capaz de modelar flujos complejos puede llevarnos a pensar en desarrollo "waterfall" con equipos específicos para cada taréa. Si bien Kanban te permite modelar un proyecto a la "waterfall" no hay que olvidar que Kanban es simplemente una herramienta y que depende del que la usa.
• Kanban, al limitar el trabajo en progreso de forma explícita evita el multi-tasking en los miembros del equipo, no como Scrum en el que es el propio equipo el que se autogestiona y decide si hace o no multi-tasking (aunque está claro que es una mala práctica hacerlo ;) ).

Lo que me llevo del nuevo formato de la reunión, ya que no pude quedarme a la retrospectiva es:

• Empezar con una introducción/presentación me parece muy buena idea, aunque quizás debería haber sido algo más corta. Ayuda a que todos los asistentes sepan de que se está hablando.
• Aunque nos vamos de hora (yo me fuí a las diez menos veinte y todavía quedaba la retro) me quedo con ganas de más :D
• Me perdí las cañas :(