¿La sobreingeniería de procesos puede llevar al fracaso las metodologías Agile?

Partiendo de 4 afirmaciones, que se aclaran con 12 principios, la industria del desarrollo de software lleva prácticamente 2 décadas en la mitad de una revolución de los procesos productivos, a la busca de implantar las filosofías y metodologías Agiles.

Algo que, como bien conoce todo aquel que tenga experiencias personales de esta clase, es en especial bastante difícil lograr que funcione adecuadamente. Aun si nos decantamos por un framework tan abierto y generalista/ambiguo como pude ser SCRUM.

Además de esto, hay que englobar una dificultad creciente en la aplicación de este manifiesto, al desarrollarse a su alrededor una miríada de procesos, buenas prácticas y metodologías que se muestran como un obstáculo de primera importancia para llegar a buen puerto con la adopción Agile.

Fundamentos

4 simples oraciones que entienden un cosmos de los pies en el suelo y experiencia aplicado a la construcción de software. 4 profundas declaraciones que recuerdan, de manera constante, donde está el valor.

Individuos y también interactúes sobre procesos y herramientas
Software marchando sobre documentación extensiva
Cooperación con el usuario sobre negociación establecido
Contestación frente al cambio sobre continuar un plan

4 declaraciones fáciles, y desde las que se ha creado un enorme mapa de principios, valoraciones, interpretaciones, prácticas, mejoras, evoluciones y puntualizaciones.

4 comparaciones de valor, que hubieran de ser la medida sobre las que debiésemos esclarecer las dudas que broten sobre la adopción de Agile en nuestros procesos de construcción.

Desde estos fundamentos, el manifiesto Agile describe doce principios que son reglas de aplicación de los procesos agiles en nuestros equipos de desarrollo. Incluyendo en ellos, toda la experiencia acumulada por profesionales y metodologías ya reconocidos en el instante de la redacción del propio documento.

Y ya está, 4 fundamentos así como 12 principios y una metodología – más bien framework – como Scrum, y es todo cuanto precisamos para adoptar el Muy ágil en nuestro equipo.

Mas no es así…

PBI, o bien el principio del infierno

Olvidémonos del primordial inconveniente que nos hallamos cuando deseamos aplicar una metodología Agile como Scrum, que no es otro que la práctica inexistencia del Product Owner o bien Dueño del Producto. Por lo que el fundamento de “Colaboración (próxima) con el cliente” se queda en agua de borrajas en demasiados casos, surgiendo figuras parcialmente supletorias como los proxy.

Y ahora centrémonos más en técnicas concretas como son los PBI (Product Backlog Items), instrumentos que vamos a emplear para edificar nuestra Pila de Producto en donde se seccionará el valor que espera el cliente del servicio, de forma priorizada.

La aproximación es parcialmente sencilla: vamos a edificarlo a través de Historias de Usuario. Pequeñas cartulinas o bien artículo-consejo, en donde utilizaremos la fórmula de las tres C’s: Card, Conversation y Confirmation

Esto es, la primera C la cubro en el formato tradicional de: De qué manera tal, Deseo hacer…, Porqué/Para que me aporte este valor… La segunda ce sería el cuerpo de la documentación en donde guardaría todos y cada uno de los recordatorios de la charla en cualquier formato que me resulte útil. Y la tercera quiere decir que debo dejar claros los criterios de aceptación que van a permitir dar por válida la realización de la Historia de Usuario.

El término de K.I.S.S y la reflexión sobre los fundamentos Agiles habrían de ser la guía en la implantación de los procesos en nuestros equipos de desarrollo

Asimismo debo estar seguro que mis Historias de Usuario cumplen con el acrónimo de INVEST: Independiente, Discutible, Valiosa, Estimable, Pequeña (Small) y Testeable; para asegurarme que son adecuadas y útiles en su función de describir cada requisito.

Y, además de esto, debo poder priorizarla por el valor que aporta (Product Owner) y por estimación (Develop Team) para poder comprometer un número dado de PBI’s en todos y cada esprint.

Esto quiere decir que el equipo de Scrum debe conocer técnicas de estimación Agiles, como puede ser Wall, Triangulación o bien afines, que dejan hacer estimaciones iniciales de un elevado número de PBI.

Aplicando por su parte, técnicas de estimación concretas para el esprint planning, como es el Planning Poker. Que son considerablemente más lentas, a cambio de conseguir estimaciones bastante más afinadas, siguiendo lo aguardado en un gráfico de cono de inseguridad.

Mas volvamos con nuestras Historias de Usuario y vamos a ver de qué manera las podemos progresar. Aplicando técnicas de Desing Thinking conseguiremos una construcción más completa de nuestros PBI, incluyendo prácticas como los storyboards, story telling, mapas de empatía, pitch elevator y una miríada más.

¿Y si la historia de usuario es muy grande? ¡No hay inconveniente! Utilizaremos agrupaciones a través de Historias de Usuario Épicas o bien asimismo Features. Que, ojo, por su parte tiene su técnica para ser subdivididas de forma eficiente.
Eso sí, apliquemos el término Lean de eludir el Waste y solo poner foco en lo que aporte Valor, y breguemos con labores no funcionales o bien con bugs que deben aparecer en algún lado, mas no en el Product Backlog… ¿o bien sí?

Como es ineludible, en este punto nacen diferentes escuelas para abordar esta clase de disyuntivas de procesos que, realmente, al usuario se la traen al pairo. Mas son críticas para el equipo de desarrollo.

De este modo vemos que algo tan simple como una lista ordenada de labores, en la realidad se ha transformado en un instrumento complicado de edificar y sostener de forma eficaz en los proyectos Agiles; tanto por el trabajo a tiempo completo que requiere a lo largo de todo el proyecto, como por el abanico de conocimientos que semeja de obligado estudio.

Y sin tener en consideración todas y cada una la técnicas sicológicas, sociológicas y tecnológicas que existen para el proceso de atrapa y diseño del producto. Entre aquéllas que nos hallamos con el reconocido brainstorming, el foco en el interrogante, los cinco Porqué, las cinco E’s, Descubrimiento por Hipótesis, MVP, y un largo etcétera

De la mejora continua al coaching

Vamos un paso más allí, y hemos arrancado nuestro Scrum. Tenemos un Product Backlog y un Product Owner, listos para comenzar a trabajar, y arrancamos nuestro esprint con todas y cada una de las ceremonias asociadas a framework.

Mas uno de los objetivos clave de Agile es establecer un marco de mejora continua en donde, al final de cada iteración, el equipo sea capaz de detenerse, meditar, sacar conclusiones y comprometerse a efectuar acciones. O sea, la retrospectiva.

Puesto que bien, hay suficientes técnicas de esta ceremonia, que podríamos redactar existen multiples libros dedicados plenamente a de qué forma aplicar de forma eficaz esta asamblea en el transcurso del proyecto. De esta forma te hallas con técnicas como la de “Estrella de Mar”, “Barco de Vela”, “6x3x5”, “Mad, Sad, Glad”, “Positivo, Negativo, Delta, Flor”, “Esqueleto de Pescado”, Timeline”, etcétera

Aun podemos ir múltiples pasos más allí, muy “Lean”, en donde entramos en medidores de la dicha del equipo, del departamento o bien de la compañía. Con propuestas tan fáciles como puede ser un calendario Niko-Niko y sus caritas sensibles.

Y con la filosofía y el psicoanálisis hemos encontrado. De forma gradual mas consistente se ha implantado el empleo de conceptos filosóficos y de mejora continua procedente de procesos industriales y empresariales para aplicarlos en campos mucho alén de la pura construcción del software, origen de todo este tinglado, englobando la cultura de la compañía en su globalidad y la vida diaria en lo más personal y también íntimo.

Hemos visto surgir profesionales en técnicas de entrenamiento (el adiestrador, en roman palantino), llenándonos la cabeza y los sentimientos de buenos propósitos y deseos de mejora.

Verdaderos guías que nos acompañan en el camino para llegar a un éxito improrrogable, y que han transformado conceptos de desarrollo como “Kaizen” o bien metodologías como “Lean”, en el centro central indispensable de lograr, para poder aplicar correctamente y emergente los principios Agiles.

Evidentemente, los libros y conocimientos precisos se marchan amontonando, los cursos se aúnan los unos a los otros, y las certificaciones cierran el circulo al validar el conocimiento y experiencias adquiridas.

Del tablero al cosmos “Kanban”

Una de las herramientas más conocidas del planeta Agile es el tablero Kanban, en su vertiente Scrum.
Una forma visual de describir el flujo de trabajo, el estado de las labores, de los bloqueos que existan o bien puedan existir, y de los puntos de mejora en el ciclo.

En suma una forma muy eficiente de auto organización y colectivización de la información.

Habría de ser suficiente con un tablero físico, dibujar 4 columnas, subdividir y priorizar las tarjetas con la descripción simple del trabajo a efectuar para cada PBI comprometido a lo largo de la iteración actual, un visión o bien objetivo del esprint, y tener clarísimo el término de Done que deja asegurar el finalizado un trabajo.

Mas puesto que estamos, podemos incorporar las capacidades push