Es fácil integrarse a una tendencia y terminar en una zanja. Esto no podría ser más evidente que en el desarrollo agile. Muchas organizaciones se introducen en agile buscando sus ventajas (la facilidad de adoptar cambios, la reducción en los tiempos de los ciclos, la arquitectura evolutiva y más) solo para encontrar que los mejores expertos de agile se van de la compañía, y los que quedan están tan incómodos que no pueden arreglar un proceso de desarrollo que ha fracasado.

El problema con la mayoría de los enfoques de agile no tienen que ver con un problema con agile; es un problema con la Capitalized Methodology de Agile. Agile no es una metodología. Tratarla como una metodología confunde el proceso con la filosofía y la cultura, y eso es un boleto directo al error -o algo peor.

Afortunadamente, no es difícil reconocer las señales de un enfoque de agile que ha terminado por equivocarse, y tomar los pasos necesarios para restaurar la armonía. Aquí tenemos 15 signos de que está ejecutando agile de forma errónea. Uno de estos signos podría hasta descarrilar seriamente su trabajo de desarrollo de software.

Hacer agile versus ser agile

Agile comienza con la actitud. Si su compañía enfatiza ejecutar agile en lugar de ser agile, ya empezó con el pie equivocado. Agile es un paradigma, un cambio mental sobre cómo se concibe el desarrollo de software. Las técnicas específicas y ceremonias vienen después, y son la parte menos importante. El punto es ser agile; adopte y emplee la filosofía establecida por el Agile Manifesto y se “hará “agile” automáticamente.

Asegúrese de ver con detenimiento el manifiesto; su selección de palabras no es accidental. Piense: Deshágase de las ceremonias, administración y papelería inútiles; concéntrese en trabajar con códigos y ciclos rápidos de retroalimentación; auto organícese, auto examínese y auto optimícese. Esta es la revolución. Los procedimientos específicos de cómo lograr lo que el manifiesto subraya continúan evolucionando.

Si sigue un “proceso” agile de tamaño único que aplica para todo y que es obligatorio para todo el equipo, lo está haciendo mal. La noción de un agile “estándar” es contradictoria –agile significa adaptarse y mejorar continuamente.

Para remediar esto, recuerde que la meta principal es producir un software que funcione, no seguir una receta; no existe una receta que funcione siempre para todos los proyectos y todos los equipos. Por lo tanto, deje que cada equipo adopte sus propios procedimientos y responsabilícese por ajustarlos y mejorarlos.

Tratar a los puntos de historia como metas

Las historias de los usuarios son una faceta clave de agile, capturar una función de software desde la perspectiva de los usuarios. Las historias son puntos asignados de valor con el propósito de estimar el nivel de trabajo necesario para implementar la historia.

Estos puntos de historia no son ni promesas ni metas. No tienen una medida o un significado intrínseco. Los puntos son un acuerdo informal entre los miembros del equipo que reflejan un acuerdo común entre las complejidades de un proyecto y las capacidades del equipo.

La historia de tres puntos de su equipo podría ser una de cinco puntos para la historia de otro equipo. Usar los puntos de historia como una medida de éxito destruye su utilidad como medio de estimación e invita a “jugar con el sistema” para aparentar ser exitosos (velocidad X lograda) sin ser exitosos en realidad (la producción de un software útil y operativo).

La solución es simple: póngase de acuerdo y mida las metas útiles con el propietario del producto (mejor aún, con los usuarios). No confunda la conformidad para estimar o el cumplimiento del plan con el “éxito”; el éxito es la producción de valor.

Comparar velocidades de equipo e individuos

Obsesionarse con las métricas es prácticamente la segunda naturaleza de la mayoría de los programadores. Pero, si su equipo considera a la velocidad, la medida (promedio) de los puntos de historia por iteración utilizada a nivel de equipo en el planeamiento del “sprint”, como punto de comparación, lo está haciendo mal.

Una vez más, la velocidad es una métrica neutral pensada solo para estimar. Comparar las velocidades de los equipos no significa nada porque la unidad básica (un punto de historia) es “definida” de forma distinta por cada equipo. Debido a que los equipos son únicos, la comparación de velocidad no tiene valor, y hacerlo puede motivar comportamientos negativos y competencia entre equipos en lugar de cooperación.

Lo mismo aplica para los individuos que conforman un equipo. La contribución individual al trabajo de un punto de historia es fraccional. Y, como se mencionó, los puntos de historia mismos no se consideran métricas. Comparar la velocidad de los individuos, inclusive dentro de un mismo equipo, no sirve de nada. La única métrica que importa es una métrica subjetiva: El valor otorgado a través del software que funciona.

La forma más fácil de arreglar esto: Deténgase. Es contraproducente y una pérdida de tiempo.

Escribir tareas en lugar de historias

El modelo de la historia “agile” es útil para darle un marco a una función en términos de sus beneficios para un usuario/rol en particular. Esto nos recuerda que nuestra meta es proporcionar un software que funcione a alguien que espera beneficios específicos al usarlo. Si la mayoría de sus “historias” son tareas camufladas, entonces el proceso de desarrollo se convierte en un proceso centrado en la tarea (hacer cosas) en lugar de centrado en producir (crear valor). Es importante que el equipo de desarrollo permanezca conectado con sus usuarios; un software sin usuarios es inútil.

La solución para esto es el equilibrio: Siempre habrá ítems similares a tareas que deberán hacerse, pero una historia debería ser de un tamaño lo suficientemente bueno como para ser completado en una sola iteración, así que partirla en tareas no sirve. Una historia “hecha”; al 75% es inútil. Hágala o no la haga; no existe un crédito parcial. Si una historia es tan complicada que no puede hacerse en una sola iteración, y no se subdivide en dos historias naturalmente, reprodúzcala más de una vez (vea la próxima sección).

Historias sin iteración

Si está desagregando historias más grandes en historias más pequeñas meramente para que puedan ser completadas en un solo sprint, lo está haciendo mal. El resultado de este tipo de procedimiento es un conjunto de “historias”; menos cohesivas y orientadas a las tareas. En lugar de hacer eso, quédese con historias más grandes y más naturales, y déjelas reproducirse en múltiples “sprints”. Ataque la historia de comienzo a fin, empezando con el “esqueleto andant” de las funcionalidades que activan la capacidad que tiene como objetivo; después haga capas de comportamientos y elementos adicionales en otros sprints. Esto permite que la historia se mantenga intacta, evolucionando de un esqueleto andante a una capacidad de uso.

Una vez que el esqueleto andante está en su lugar, su estructura y comportamiento podrían implicar subhistorias, o podría encontrar que las prioridades han cambiado en el próximo “sprint”, donde el esqueleto andante puede dejarse de lado. Pero si descompuso la historia en tareas porque aparentemente es más fácil completar una tarea como si fuese una “historia”, el software resultante no tendrá ningún valor añadido, puesto que las tareas tienen a centrarse en componentes desconectados, no en flujos de valor conectados.

Confundir Scrum con agile

Scrum es una técnica de administración de procesos, no una técnica de desarrollo de software. Lo mismo aplica con Kanban, Scrum y Kanban sin principios “agile” sólidos, eventualmente revierten en una cascada. Esto es exacerbado en muchos ambientes empresariales por medio de muchos backlogs gigantes (generando diseños de cascada en lugar de evolución incremental) y procedimientos agile “estandarizados”.

Backlogs gigantes

Si está preocupado por el lead time de las funciones -qué tanto tiempo le toma a una idea pasar desde su concepción a su producción- la mejor manera de estropearlo es tener grandes listas de espera. Desafortunadamente, muchas organizaciones aún planean, autorizan y ejecutan proyectos de desarrollo de software por (grandes) bloques, lo que da como resultado grandes backlogs desde el inicio, y garantiza que las funciones al final de la lista tengan un “lead time” terrible.

Suponga que tiene prisa por encontrar un lago escondido del que escuchó hablar. ¿Llenaría una mochila con todo lo que posee o empacaría solo lo que necesitaría, para así poder mantener un buen ritmo? Los backlogs gigantes son así; usted está buscando descubrir/validar el valor de una función lo más rápido posible, pero su mochila está sobrecargada desde al comienzo.

Los proyectos realmente no existen; son un módulo mental, no algo concreto. Nosotros inventamos los proyectos para poder hablar de un flujo nebuloso de trabajo como si fuesen bloques aislados de tiempo y trabajo. No existen los proyectos; solo existen los productos. La clave está en recortar. Organice los proyectos alrededor de un conjunto inicial de funciones que pueden producir un valor medible, seguido de “olas”; de pequeñas mejoras medibles.

Nunca formar parejas (o siempre hacerlo)

La programación en pareja es amada por algunos y odiada por otros. Es una herramienta, compañeros, no es una religión. Debería ser usada cuando es apropiado hacerlo -y sí, siempre es apropiado tener un cierto nivel de emparejamiento.

Emparejar esparce el conocimiento sobre el sistema, herramientas, técnicas, trucos y más, en todo el equipo; refuerza las conexiones humanas; respalda la enseñanza mutua; y en muchos casos puede producir software de mayor calidad y en menor tiempo que cuando los desarrolladores trabajan solos. Si revisa una historia y piensa “dos cabezas podrían ser mejor que una en este caso”, entonces emparejar es una opción obvia. Si cualquiera en el equipo fuese capaz de implementar una historia, emparejar no sería de ayuda. Como en todo procedimiento agile, emparejar es una herramienta; úsela dependiendo de cuándo y dónde pueda ser efectiva.

No refactorizar

Refactorizar no solo ayuda a mejorar la calidad mecánica de un código; también le ayuda a que aprenda de su código. Cuando refactoriza, usted converge hacia mejores modelos. Ahora mismo, su código funciona, pero podría sentirse tenso, y hasta un poco inestable. Refactorizar revela el modelo implícito, lo cual le informa sobre su entendimiento del campo. En el ciclo de desarrollo basado en pruebas del tipo verde-rojo-refactorizar, “refactorizar” no es opcional, en caso de que acumule una deuda técnica y no aprenda de la experiencia de codificación.

Stand-ups que no terminan

Es fácil que las stand-ups, que supuestamente deberían ser ceremonias breves de interacción grupal, se conviertan en largas reuniones. Limite la conversación a declaraciones simples sobre cosas que el equipo completo debería saber -lo que hizo ayer, lo que está haciendo hoy y cualquier obstáculo o ayuda que necesite. Adicionalmente, una oración o dos sobre lo que ha aprendido puede ser provechoso. Nada más. Utilice el método que su grupo prefiera.

Los stand-ups no son lugar para las discusiones técnicas, toma de decisiones, propuesta de diseños, intercambiar historias, reorganizar un sprint, o hacer algo que no sea comunicar lo necesario para la coordinación del grupo. Venga preparado, para que pueda escuchar sobre lo que han hecho los demás, lo que están haciendo y así pueda decidir si es relevante para usted, en lugar de pensar en qué va a decir. Todo lo que quede fuera de las actualizaciones mutuas de estado debería ser pospuesto para un correo electrónico o una cadena de mensajes. Un stand-up no debería tomar más de 15 a 30 segundos por miembro del equipo.

No realizar Retros

Los equipos de agile deberían organizarse solos, seleccionando prácticas y ceremonias que encajen con su comportamiento colectivo. Esto, también, debería examinarse periódicamente, con la contribución de todos para identificar formas de mejorar el proceso y tomar las acciones correspondientes. Eso es llamado con frecuencia “retrospectiva” y es un enfoque neutral para reparar procesos sin perder el tiempo en culpar a otras personas.

Por ejemplo, un miembro del equipo podría haber notado que la retroalimentación de los usuarios de producción está llegando demasiado tarde y sugerir que los sprints más cortos podrían ser más útiles. El equipo se pone de acuerdo, intenta un tiempo de sprint más corto, y se reúne en la próxima retro para ver si funcionó. De esta manera, los procesos del equipo son afinados continuamente.

Un agile de tamaño único aplicado a todo, con frecuencia resulta en que los equipos incumplan las retrospectivas o que las reduzcan a ceremonias rutinarias sin ningún aprendizaje accionable. Si alguna vez nota un problema con el proceso de su equipo, pero tiene miedo de comentarlo en una retrospectiva, la retro se ha convertido en una rutina. Un proceso que no se examina no puede ser mejorado, y los miembros del equipo deben sentirse seguros y animados a hacerlo.

Pruebas manuales (o nada de pruebas manuales)

Realizar pruebas es esencial para producir un software operativo, y si no ha automatizado sus pruebas, se está perdiendo de una eficiencia y precisión significativa. Las técnicas livianas de especificación de pruebas como el behavior-driven development (BDD) son excelentes compañeras de las historias agile. En términos de cascada, las descripciones BDD definen casos de uso, especifican requerimientos y son pruebas de aceptación en un formato bastante compacto.

Automatizar estos casos de prueba -junto con el resto de la “pirámide de prueba” (unidades de pruebas técnicas, pruebas de integración funcional, pruebas de contrato de interfaz, pruebas de aceptación del usuario)- proporciona una opción eficiente y confiable de verificar que un cambio de código funciona como se esperaba, sin tener que romper nada. Las pruebas automatizadas son una red de seguridad, proporcionándole al equipo valor y confianza.

 Evitar por completo el diseño y el desarrollo de modelos

Darle prioridad al software operativo sobre la documentación no significa “no realice actividades de desarrollo de modelos o diseño y solo escriba códigos”. Lo que usted esté intentando evitar es pasar un sinfín de horas llevando a cabo la tarea especulativa de crear diagramas y especificaciones a detalle. Después de todo, la única manera de saber si el modelo de diseño es correcto es probándolo cuando se escribe el código.

Pero, si es que tiene que resolver un problema bastante difícil, use cualquier medio necesario para descifrarlo. Un modelo/diseño de baja fidelidad puede ser probado en los casos de prueba de las historias, y diseños diferentes pueden ser explorados rápidamente. Hasta podría querer capturar el tiempo de esta actividad basándose en el tamaño de la historia, para empezar. Por ejemplo, cinco minutos para una historia de un punto con el propósito de revisar el flujo básico y puntos de contacto, quince minutos para una historia de dos puntos con la finalidad de ver si es que existe alguna complicación oculta, y así en adelante.

Su modelo/diseño debería hablar de los beneficios de la historia y darle un buen inicio a la solución, que debería ser probada en un código. Tenga en cuenta criterios como: con cuánto diseño, con qué nivel de fidelidad, con qué métodos, y con cuánto tiempo cuenta para juzgar cada historia; no sienta que no puede realizar un modelo o diseño porque está “haciendo agile”.

 Evitar DevOps

Si algo es doloroso, hágalo con más frecuencia. Esto incentivará la automatización.

Trate a las maquinas como ganado, no como mascotas, automatizando la infraestructura usando herramientas como Ansible, Chef, Puppet, entre otras. Haga pruebas de ejecución y despliegue activado mediante un botón o automáticamente. Haga que la infraestructura ya no le estorbe; hágala invisible incorporándola como una parte más de la base del código y/o usando plataformas de autoservicio como AWS. El tiempo del ciclo -el tiempo requerido para procesar un cambio de código en un lanzamiento de producción- puede ser reducido drásticamente mediante la automatización, que permite ciclos de retroalimentación más rápida y, por ende, acelera el aprendizaje. El aprendizaje acelerado lleva a un software de mayor calidad producido con mayor frecuencia.

Adoptar las “mejores prácticas”

Las “mejores” prácticas universales no existen. Lo que funciona bien para un equipo puede no hacerlo para otro, hasta en la misma compañía, inclusive en el mismo proyecto. Todo lo que construimos es un copo de nieve único de diseño y circunstancias; todo equipo es una combinación única de personalidades, habilidades y ambiente. Lea sobre procedimientos que hayan sido efectivos para otros, aplíquelos como prueba si les parecen aplicables, pero no los adopte automáticamente solo porque alguna autoridad diga que son “los mejores”.

Las “mejores” prácticas de alguien más podría ser la camisa de fuerza de su equipo.

-Steven A. Lowe, InfoWorld (EE.UU.)