¿Eres realmente ágil todavía?

** Este artículo fue escrito por Jamie Buckley, director de ingeniería de Foundry4, y fue publicado originalmente por ** ** Foundry4 ** , una consultora de tecnología que ayuda a las organizaciones a aprovechar tecnología para resolver los complejos problemas de hoy. Lea el artículo original aquí y más Foundry4 ** [ información aquí ](https://foundry4.com/our- perspectivas).**

Ver que Agile se hace correctamente es una revelación. Cambia su visión de los proyectos de software de la misma manera que ahora es difícil imaginar tener que usar jabón, agua y manos para lavar su ropa desde la invención de la lavadora.

Pero las empresas y proyectos de software homónimos "ágiles" no tienen éxito con demasiada frecuencia. Para el nuevo ingeniero de software, existe el peligro de que esta asombrosa herramienta para entregar proyectos de software exitosos se envenene en sus ojos.

** • ¿Quieres escribir para nosotros? Eche un vistazo a la ** [** guía para colaboradores **] de Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/)

Quizás el problema clave es que Agile no solucionará sus problemas, solo los expondrá. No me gustan los espejos exactamente por la misma razón, es incómodo ver tus defectos y defectos presentados de nuevo ...

Yo describiría Agile como el proceso de ** trabajar en equipo **, en ** pequeñas piezas bien entendidas ** de trabajo, para obtener una ** entrega ** pieza de dichos elementos de trabajo completa, proporcionando ** valor comercial incremental **. Es un conjunto de principios rectores, donde el dominio y la madurez vienen al elegir usar patrones y marcos en lugar de seguirlos ciegamente.

Trabaje en equipo y trate de comprender lo que está construyendo antes que usted constrúyelo. No muerda más de lo que puede masticar. Asegúrese de que los cambios de dirección sean de bajo costo examinando con frecuencia lo que está haciendo y lo que está construyendo. Si todo eso suena a sentido común, es porque eso es todo lo que Agile debería ser.

Stand ups son para el equipo

Las palabras para infundir miedo en el corazón de un ingeniero de software:

_ ** Ayer hice ... Hoy estoy haciendo ... ** _

Como es bien sabido, lo favorito de todos es verse obligados a hablar frente a un semicírculo de otras personas, que los miran en silencio, esperando su turno. La mejor parte es saber que cada persona del grupo ha escuchado aproximadamente el cero por ciento de lo que acaba de decir, y está demasiado preocupado por ensayar lo que están a punto de decir.

Evil Project Manager te mira amenazadoramente y un rayo crepita en lo alto.

_ ** ¿Cómo sigues trabajando en esta historia, cuando solo la clasificamos en tres naranjas y una papaya? ** _

Estoy exagerando un poco, pero esta no es una situación desconocida, especialmente si odias hablar frente a otras personas.

Si alguien te hace decir el formato "ayer lo hice, hoy lo estoy haciendo", no te sientas mal por cómo te hace sentir. Eso no es Agile, es un KPI. No está trabajando en una empresa de software, está trabajando en un centro de llamadas, donde tiene que hacer x número de ventas por día, sin una comprensión más amplia del contexto. Si está obligando a su equipo a hacer esto, solo sepa que están resentidos con usted por ello y hacen muecas a sus espaldas.

El error que se comete aquí es simple. El formato "ayer, hoy" es para asegurar que todos estén tan ocupados como sea posible, o para enfrentar a un miembro del equipo contra otro. Pero la atención debe centrarse en el trabajo en el sprint, no en el individuo.

Aquí tienes una forma diferente de hacerlo:

_ ** A continuación, la función sumergible de azafrán. Veo que todavía está en desarrollo. Paul, ¿cómo te va? ** _

_ ** Paul: De hecho, encontré algunos problemas, creo que esto va a ser más trabajo de lo que anticipamos. ** _

_ ** Ya veo, ¿tal vez alguien más en el equipo pueda ayudar emparejándose contigo? ¿John? ¿Te importaría ayudar? ** _

Discusión. Problema. Solución. Los Beatles están haciendo Agile correctamente ...

Tal vez este proceso exponga que no está dedicando suficiente tiempo a refinar sus historias, o falta su ** definición de listo **. Tal vez exponga que debería haberse realizado un aumento (trabajo exploratorio encuadrado en el tiempo) para comprender completamente el problema. Quizás exponga que las estimaciones son demasiado optimistas. Sea lo que sea, es algo para discutir en retro (el ejercicio retrospectivo al final de un sprint en el que se examina lo que salió bien / mal).

La palabra 'expone' aquí, es la parte clave. Agile asume que está trabajando en un entorno no impulsado por el ego, donde todos se preocupan por hacer el trabajo y están felices de ayudar a otros a resolver sus problemas. Se asume que el equipo tiene la autoridad y la autonomía para identificar lo que se interpone en el camino y solucionar los problemas.

El desafío del refinamiento

Si ha elegido una función en la que trabajar y falta la información en el ticket, hay problemas al principio de la cadena. Estoy seguro de que muchos ingenieros tendrán alguna experiencia en que se les pida que escriban algo como:

_ ** Construye algo que haga esto ** _

Seguido de un correo electrónico a la mitad del trabajo que dice.

_ ** Espera no, excepto en este caso donde lo hace. ** _

Estos requisitos deberían haberse resuelto de antemano, y buena suerte para el evaluador que no estaba en la cadena de correo electrónico. Parte del problema es que la gente no es muy buena para describir lo que quiere (pregúntele a cualquier profesional de la industria del arte), y la gente tampoco es muy buena para pedirle a la gente que describa lo que quiere.

Luchar por describir lo que quiere no es un defecto de carácter personal. Si es propietario de un producto nuevo, no se sienta mal porque su experiencia en su campo no se traduzca inmediatamente en requisitos concretos, se necesita mucha práctica.

Consulte mi artículo sobre BDD (Behavior Driven Development) para ver una herramienta potencial para usar aquí, o simplemente recoger cualquier libro sobre BDD y mapeo de ejemplo. De lo contrario, simplemente dibuje lo que se necesita. Cualquier cosa que no sea danza interpretativa que proporcione un significado inequívoco y rastreable, y que genere las preguntas correctas, es útil.

La profesión de Analista en ingeniería de software es esencialmente la aplicación profesional de tener conversaciones útiles, que es más difícil de lo que parece. Esto es genial, pero a menos que el refinamiento pueda responder preguntas de manera significativa, solo se está introduciendo una nueva capa a la que culpar en la cadena cuando ocurren los mismos problemas. Todas las partes involucradas necesitan estar dispuestas a sentarse y comprender el problema, un marco para capturar la comprensión y hacer las preguntas correctas.

Peor aún, a veces el refinamiento puede ser simplemente gente de negocios y técnica en una habitación, pensando incorrectamente que están de acuerdo entre sí. Esto es tan malo como no tener una conversación en absoluto, hay una razón por la cual el famoso "Tres Amigos" no es "Dos Amigos".

** Una solución simple aquí ** es ampliar los tipos de personas en la sala. Debe haber como mínimo una persona que hable negocios, una persona que hable tecnología y un QA / tester / quien se le pedirá que eventualmente verifique que los dos idiomas hablados coinciden.

Estas personas deberían poder estar en desacuerdo de manera amistosa. Los refinamientos deben sentirse como un argumento amistoso para cualquier trabajo no trivial. BDD es excelente aquí porque proporciona un lenguaje común con el que las tres partes pueden resolver sus desacuerdos.

¿Te estás divirtiendo todavía?

Lo anterior no siempre va a funcionar. Parte de la naturaleza de Agile es aceptar que las cosas van mal, que el software es difícil y que, hasta cierto punto, todos estamos a tientas en la oscuridad. Si parece que Agile es solo un conjunto interminable de dudas sobre sí mismo, "¿estamos haciendo esto bien?" reuniones, eso se debe a que administrar un proyecto es difícil. (Waterfall no era mejor en este sentido, era solo el equivalente a una pareja casada reprimiendo sus sentimientos hasta que uno de ellos envenena los huevos revueltos …)

Sin un marco para resaltar y solucionar problemas, puede surgir un ejercicio negativo en el que los equipos o las personas se culpen entre sí.

_ ** Es culpa de la empresa por no explicar lo que querían ** _

_ ** Es culpa del ingeniero de software por malinterpretar lo que se pidió ** _

_ ** Es culpa del probador por permitir que ese error se filtre ** _

Todo esto es reactivo y no ayudará. Siéntese en una habitación, discuta lo que pensó que salió mal en ** _ historia reciente _ ** _, es decir, el último sprint. Luego proponga lo que podría mejorarse. Escuche lo que dice la gente y esté abierto a la idea de cambiar su forma de trabajar.

Tal vez la empresa no entendía cuán complejo era entregar lo que pedían.

Tal vez los ingenieros estén demasiado entusiasmados para construir cosas interesantes y ya no estén pensando en construir un MVP bien enfocado. Por supuesto, yo mismo nunca he sido culpable de esto ...

Tal vez los probadores estén luchando por comprender lo que realmente se pidió en medio de las facciones en guerra y el caos.

Di lo que piensas, di lo que te molesta y di lo que te ayudaría. Hagan algo bueno juntos como equipo para celebrar un sprint exitoso. Tenemos la suerte de trabajar en lo que es fundamentalmente una profesión divertida. Agile debería hacerte decir que ayer disfrutaste tu día en el trabajo y que hoy te lo estás pasando genial. ** - ** ** Jamie Buckley **

** Queremos escuchar lo que piensa sobre este artículo. ** ** Envíenos un artículo ** ** para nosotros o envíe sus comentarios a ** hello@apolitical.co

(Crédito de la imagen: Unsplash)