La adopción de prácticas ágiles para el desarrollo de software requieren muchos cambios en la organización, tanto a nivel cultural, de roles individuales y procesos. A medida que la organización va migrando hacia Ágil, las personas deberán poder gestionar este cambio.

En este artículo veremos los cambios esperados en los diferentes roles para una organización Ágil, junto con técnicas para manejar mejor la transición desde una Cascada tradicional hacia metodologías Ágiles.

Introducción

El enfoque Ágil se basa en objetivos de proyecto a corto plazo. A diferencia del modelo en Cascada, en Ágil se producen piezas funcionales de software cada 2-4 semanas. Este sistema asegura la motivación del equipo y la satisfacción del cliente, con ciclos frecuentes de inspección y adaptación. Ágil tiene la habilidad de repensar las posiciones de las personas y crear un ambiente en donde logren la máxima eficiencia y el máximo potencial individual, logrando así una estrategia de desarrollo de software en la cual se justifican los cambios asociados con sus resultados: Ágil es un enfoque económico y orientado a los resultados para el desarrollo de software.

Adoptar Ágil requiere de cambios considerables en la organización en la cultura corporativa, en los roles y en los procesos. A medida que una organización va migrando a Ágil se hará necesario poder manejar los cambios. En este artículo cubriremos los cambios que ocurrirán en los siguientes roles de la organización: 

1. Cliente
2. Gerente de Producto
3. Gerente General
4. Gerente de Proyecto
5. Desarrolladores
6. QA

Es importante notar que no toda la información siguiente aplica a cualquier organización, ya que cada equipo trabaja distinto y tiene diferentes capacidades.

Cliente

Con los proyectos tradicionales en Cascada, los cliente usualmente se mantenían a distancia y sólo se involucraban al principio y al final de un proyecto. Nueve de cada diez veces, el equipo de desarrollo intentaba que el cliente fuera sincero y directo. Le dejábamos en claro que cualquier cambio luego del inicio del proyecto requiere un proceso de control de cambios y penalidades. Después de terminar la codificación, que podía ocurrir varios meses después del inicio del proyecto, entregamos el código para descubrir "lo que salió mal". No es necesario decir que este enfoque es una receta para el desastre.

En los proyectos Ágiles, el cliente necesita estar mucho más involucrado en todo el proceso de desarrollo. De hecho, los proyectos Ágiles esperan el cambio, y siempre es bienvenido el feedback del cliente.

1. Los clientes tienen que participar y brindar feedback en todos los puntos de "inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a los interesados. Nota: en los proyectos XP, es obligatorio que el Cliente forme parte del equipo.
2. Los clientes tienen que trabajar con el Dueño del Producto para definir historias de usuario y detallar dichas historias durante las reuniones de planificación.
3. Los clientes trabajan con el Dueño del Producto para priorizar el backlog.
4. Los clientes y los interesados participan en las demos de los print y, dependiendo en la relación entre el cliente y el Dueño del Producto, el Cliente puede participar en la retrospectiva del sprint.

Gerente del Producto

Los Gerentes de Producto también tienen cambios. Para empezar, el título cambio de "Gerente del Producto" a "Dueño del Producto". Pero eso no es todo. En un entorno tradicioanl, los Gerentes de Producto son la "entrada" y "salida" . Además de sus tarears de marketing específicas, los Gerentes de Producto suelen ser responsables por el Documento de Requerimientos del Producto. Por otro lado, los Dueños de Producto son la voz del cliente. Migrar de un Gerente de Producto a un Dueño del Producto en proyectos Ágiles requiere los siguientes cambios en tareas y responsabilidades: 

1. El Dueño del Producto es un participantes activo del equipo. Son los responsables por la dirección del producto y las prioridades del proyecto.
2. El Dueño del Producto debe estar presente en la planificación del Sprint. El Dueño del Producto tiene la primer parte de la reunión de planificación, y es responsable de definir los objetivos del Sprint y también detallar la funcionalidad de cada historia de usuario planificada para ese Sprint.
3. El Dueño del Producto es responsable de crear, mantener y priorizar el backlog del producto.
4. El Dueño del Producto tiene que estar disponible para el equipo en todo momento. Se puede debatir si el Dueño del Producto está presente en todas las reuniones diarias, pero mientras más involucrado esté el Dueño del Producto, habrá más probabilidades de éxito.
5. El Dueño del Producto también es respnsable en parte por definir el criterio de pruebas de aceptación y, en este aspecto, es también responsable por la calidad del producto - especialmente porque este criterio de pruebas de aceptación le permite al equipo de desarrollo construir con calidad desde el principio.

Por lo tanto, como Dueño del Producto, hay que estar preparado para estar más involucrado en el día-a-día y ensuciarse las manos.

Gerente General

Como los equipos Ágiles son auto-gestionados, ¿en dónde queda el gerente general, y cuál es su rol? 

1. Los gerentes tienen que estar disponibles para actuar como apoyo al equipo, especialmente si el Gerente tiene la experiencia apropiada - no hay igual para su experiencia. Es por esto que Toyota usa al Jefe de Ingenieros como su Dueño del Producto. Este apoyo puede hacer que los equipos eviten errores y por lo tanto ahorren tiempo.
2. Los gerentes tienen que estar presentes para ayudar con las tareas difíciles. Por ejemplo, tienen que asistir al Scrum Master a elimitar GRANDES impedimentos que requieren que la gerencia se involucre (como ser, aprobar un presupuesto para seguir avanzando).
3. Especialmente los equipos nuevos necesitan apoyo y dirección de la gerente para que el proceso Ágil pueda avanzar en la organización. Los gerentes tienen que estar con el equipo para mantener el rumbo hacia Ágil. Es muy facil que los equipos vuelvan a los viejos hábitos.
4. Los gerentes tienen que acutar como "coach", asistiendo a los miembros del equipo con su plan de carrera, revisiones de rendimiento, capacitaciones y organización de capacitaciones.
5. Los gerenetes deben enfocarse en iniciativas estratégicas de largo plazo para la organización (cómo gestionar amenazas competitivas, incrementar las ventas, reducir costos, etc.)
6. Basándose en estas iniciativas estratégicas, los gerentes tienen que trabajar de cerca con el Dueño del Producto para definir y priorizar las historias "Épicas" y crear mapas de ruta de proyecto a largo plazo.

Gerente de Proyecto

Scrum directamente se quita de encima el rol tradicional de "Gerente del Proyecto". Entonces, ¿a dónde van estos empleados? Lo más frecuente y natural es que los Gerentes de Proyecto hagan una transición hacia Scrum Masters. Sin embargo, muchos buenos Scrum Masters provienen de Desarrollo y QA. Créanme, el rol del Scrum Master no es ni remotamente parecido al del Gerente de Proyecto. Por lo tanto, es importante que el candidato a Scrum Master adquiera capacitación.

1. Para empezar, el Scrum Master tiene que aceptar el el equipo es dueño de la agenda, así que no más actualizar los viejos Gantts del MS Project. En cambio, hay que sentarse e inicialmente alentar al equipo para que mantenga actualizadas sus estimaciones diarias.
2. El Scrum Master se asegura que se siga el proceso de Scrum, que todos entienden Scrum y cómo funciona.
3. El Scrum Master debe quitar impedimentos, o asistir en quitar impedimentos, lo más rápido posible.
4. Se asegura que el equipo se mantiene en rumbo, recor´dandole al equipo el objetivo del Sprint en cada reunión.
5. Organiza los Scrums diarios (una reunión diaria en donde todos dicen lo que hicieron ayer, lo que van a hacer hoy qué impedimentos tienen), y se asegura que se realice en el mismo lugar a la misma hora.
6. Se asegura que todos los detalles de Scrum, y en particular los puntos de inspección y adaptación, se tomen seriamente y sean usados de la manera para la cual fueron diseñados. Esto es lo que le permite al equipo mejorar Sprint a Sprint.

Desarrolladores

A los desarrolladores les encanta hacer las cosas bien, no les gusta tomar atajos. No les gusta que los fuercen a deplegar código que saben que no es del todo bueno. El cambio más grande que un desarrollador puede esperar de un cambio hacia Ágil (Scrum + XP) es que se incrementa al máximo la disciplina técnica.

1. No se estiman más las tareas de forma individual. Esta actividad, quizás la más dificil, se hace en equipo usando, preferentemente, planificación de poker. Como resultado, obtendremos mejores estimaciones. Además, tenemos una responsabilidad compartida por una mala estimación.
2. Debemos aprendremos a programar en parejas. Asumiendo que se estén implementando las prácticas de XP (muy recomendable), van a estar haciendo esto muy seguido. Es un cambio mental enorme que los desarrolladores tienen que hacer porque, por primera vez, están abriendo su código para ser revisado por un par. Esto signifca ser criticado cada a paso. Al principio resulta dificil, pero los beneficios son enormes; está garantizado que uno será mejor programador. Se produce código de más calidad y más mantenible.
3. Ya no se tira código para que después los testers encuentren bugs. Ágil se basa en la premisa de salida sustentable, y para lograrlo es imperativo que la calidad se construya desde el principio. Deberá aprenderse a escribir pruebas unitarias y aprender un montón sobre TDD. Aquí es donde aparece el desafio técnico para producir el mejor código posible, con la mejor calidad. Y los beneficios son enormes.
4. Los desarrolladores participan en el proceso completo. Esto genera una nueva perspectiva de las cosas, ya que se forma parte de las historias inicial. En consecuencia, podremos escuchar problemas directamente del Cliente/Dueño del Producto, ya que están allí para dar detalles durante las reuniones de planificación del Sprint. También se participa de la retrospectiva para reflexionar sobre lo que ocurrió, lo que salió bien y mal, y así implementar mejoras sprint a sprint.
5. No hay que realizar esfuerzos desmedidos continuamente. De hecho, si seguimos Scrum, nunca debemos esforzarnos desmedidamente. La velocidad mantiene el ritmo sustentable del equipo, que gobierna cuánto trabajo en progreso hay en un momento dado. Los equipos pueden desplegar a producción cada dos semanas, sin error. Esto se logra optimizando la velocidad y el trabajo realizado. Podemos aprender un montón del pensamiento Lean y del Sistema de Producción de Toyota (TPS).
6. Si se sigue el proceso, no habrá que preocuparse por trabajar fines de semana continuamente, o código malo. En cambio, al final de cada Sprint, podremos sentirnos orgullosos de lo producido, y nunca más querremos trabajar de otra forma. Esto requiere que todos los interesados estén involucrados en este nuevo proceso desde el principio (un pre-requisito para una implementación Ágil exitosa).
7. Al finalizar cada Sprint, tenemos la oportunidad de demostrar lo que realizamos. Este es el momento de brillar (en vez de ocultar), a diferencia de proyectos en cascada donde nunca sabemos dónde puede aparecer el próximo bug.
8. Trabajamos en equipo y alcanzamos cada hito en equipo. No hay "yo", sino "nosotros". Buscamos oportunidades para ayudar a los miembros del equipo en lo que necesiten.

Testers de QA

Los proyectos en Cascada, al atrasarse, suelen recortar tiempo de QA. Este escensario cambio con las metodologías ágiles.

1. QA participa desde el inicio de cada Sprint. ¿Qué valor puede dar un tester en estas fases tempranas del proyecto? Al participar en las reuniones de planificación del sprint, vamos a informarnos sobre las historias planificadas. De hecho, QA está involucrado en elaborar las historias de usuario. Por ejemplo, ayuda a definir el criterio de pruebas de aceptación para las historias. Esto ayuda a los Desarrolladores a entender lo que se necesita para pasar las pruebas. Como resultado, se mejora la calidad del código y también la "utilidad" del código (qué tan cerca está del requerimiento del usuario).
2.  Estaremos involucrados en la creación de pruebas unitarias. Este es una forma importante por la cual los testers pueden mejorar sus habilidades. Esta es un área en donde los testers pueden agregar mucho valor al proceso con su marco de pensamiento estilo "cómo puedo romper esto".
3. Deberemos automatizar la mayor cantidad de pruebas funcionales. Como resultado, contribuiremos con la efectividad general del equipo y su productividad. El pensamiento Lean sugiere que los equipos necesitan estar enfocados en construir con calidad y minimizar los desperdicios, ya que esto es lo que más afecta a los ciclos de tiempo. Entonces, al escribir pruebas automatizadas, estamos contribuyendo a la calidad general del código y como resultado reducimos el tiempo de ciclo total.
4. Seremos un miembro respetado del equipo en vez de un ciudadano de segunda que "detiene la línea de producción". Por ejemplo, cualquier bug que se encuentra incluso en etapas tempranas del producto debería resolverse ni bien se encuentra.  Ágil resuleve los problemas de la gestión de proyectos tradicionales construyendo un equipo cohesivo y tratando a cada área funcional como desarrollo. De hecho, Scrum sólo hace referencia a "Desarrolladores" del proyecto (por ejemplo, si sos un tester dentro de un proyecto Scrum, sos otro Desarrollador que tiene entregables en el backlog del sprint).
5. Como los Desarrolladores escriben pruebas unitarias, no se recibirán más código con muchos errores. Ahora podemos enfocarnos en aspectos más importantes de las pruebas, como ser pruebas de frontera, y en la automatización de las pruebas.
6. Las prácticas de Scrum/XP y Lean confian en que todo el código que se entrega al final del Sprint está TERMINADO (con pruebas unitarias, funcionales, e integrado). Entonces tendremos tiempo para completar cada una de estas pruebas en cada Sprint ya que todo el trabajo (incluyendo el testing) está contando dentro de la planificación del Sprint (a diferencia de tener, por ejemplo, las últimos 3 semanas dedicadas al testing de un proyecto).

El testing maduró mucho desde las metodologías Ágiles, y ahora son miembros mucho más respestados en la industria del software. Ahora el testing es esencial para el desarrollo de buen software qeu asegure que funcione como se espera. Con conceptos como TDD y BDD, los esfuerzos de testing cambian de un enfoque tradicional "al final" del proyecto hacia un enfoque desde "el inicio" del proceso, y como resultado, se construye la calidad desde el comienzo.

Conclusión

Ágil adapta el entorno de desarrollo para sacar a relucir todo el potencial de los equipos y trasladarlo hacia ciclos de desarrollo increíblemente eficientes. También alienta la colaboración efectiva y productiva de las personas, eliminando las jerarquías corporativas en favor de equipos funcionales. Una migración a Ágil requiere un esfuerzo coordinado y el deseo de adoptar cambios a través de todos los aspectos en los equipos de desarrollo. Al principio, los cambios asociados a implementar Scrum parecen épicos. También es facil distraerse con los aspectos técnicos del cambio, en vez de hacer foco en las bases: una reestructuración del proceso de desarrollo de software para hacerlo más eficiente.

Traducido de Coping with change on Scrum projects, por Jack Milunksy.