Cómo usar Scrum con más productividad y menos dolor

Lidiar con el desarrollo de software no es lo más limpio y fácil. Abarca una miríada de cuestiones, técnicas y no técnicas. El aspecto técnico seguramente es mucho más complejo y necesita habilidades duras, pero al mismo tiempo se puede manejar de alguna manera, usando las tácticas y herramientas adecuadas. El mundo no técnico, por otro lado, tiene muchos más grados de libertad. Tiene la misma variabilidad e imprevisibilidad que la naturaleza humana.

Al igual que con cualquier otro proceso de fabricación de productos, se han implementado y probado varias mejores prácticas desde los primeros años de la aventura del desarrollo de software. Las metodologías ágiles son un conjunto de diferentes formas de hacer frente principalmente a la extrema variabilidad de los requisitos, y también a la falta de enfoque en los objetivos más importantes para entregar el producto final.

A veces, tales metodologías van más allá de su propósito original y el resultado neto está lejos de ser ideal. Scrum es una de estas metodologías. Se describe más como un marco. Se basa en un conjunto básico de principios, reglas, eventos y roles. Discutimos en este artículo cómo se puede usar este marco con juicio y flexibilidad y evitar algunas interpretaciones estrictas que podrían estar lejos de ser ideales.

Muy Breve Introducción a Scrum

Las metodologías Ágiles se basan en los siguientes principios generales, definidos en el llamado “Manifiesto Ágil”:

• "Individuos e interacciones sobre procesos y herramientas"
• "Software de trabajo sobre documentación completa"
• "Colaboración con el cliente sobre negociación de contratos"
• "Responder al cambio siguiendo un plan"

(Fuente: Manifiesto Ágil )

Según el Manifiesto Ágil, en las declaraciones anteriores, mientras que los elementos de la derecha son importantes, los de la izquierda lo son más.

Desde el punto de vista del proceso de desarrollo, todas las metodologías ágiles implican un proceso iterativo e incremental en lugar del modelo Waterfall clásico: todo el desarrollo se compone de una serie de pasos incrementales, y cada paso se compone de las mismas fases que caracterizan todo un proyecto en cascada: una recopilación de requisitos, análisis, diseño y codificación. Es decir, cada paso representa un incremento en todo el desarrollo y puede verse como un proyecto completo en sí mismo.

La metodología Scrum puede verse como una declinación particular de los principios anteriores. Scrum es un marco dentro del cual un equipo puede usar sus propios procesos para desarrollar algún producto de software específico. Se caracteriza básicamente por Roles , Eventos y Artefactos .

Los roles son:

• El Equipo : puede incluir analistas, desarrolladores, testers, y en general todo tipo de profesionales involucrados en el proyecto. Se supone que debe funcionar de manera autoorganizada dentro de los límites de las sesiones de planificación de Scrum.

• El Scrum Master : coordina todos los procesos Scrum, organiza las reuniones, etc.

• El propietario del producto : tiene la responsabilidad del producto. Gestiona el llamado Product Backlog , que contiene todas las características requeridas expresadas de forma clara. Puede discutirlos con el equipo y recibir ayuda de este, pero él es el único responsable.

  
  

Los eventos son:

• El Sprint : representa un solo incremento en el desarrollo iterativo. Suele tener una duración de dos semanas a un mes.

• Sprint Planning : es una reunión con una duración máxima de 4 horas para Sprints de dos semanas y de ocho horas para Sprints de un mes. Está organizado y programado por el Scrum Master e incluye el Equipo y el Dueño del Producto. En esta reunión, se seleccionan, evalúan y discuten una serie de características del Product Backlog para desarrollarlas en el Sprint actual. Las funciones se seleccionan en función de su prioridad.

• Daily Scrum Meetings : son reuniones diarias de no más de quince minutos. Son programados por el Scrum Master. En estas reuniones, cada miembro del equipo describe lo que ha hecho para implementar las tareas actuales, cualquier problema que haya ocurrido y cómo superar las posibles dificultades. El Scrum master se encarga de la programación y coordinación de estas reuniones y su correcta ejecución.

• The Sprint Review : es una reunión al final de la primavera actual. Se necesitan dos horas para Sprints de dos semanas y cuatro para Sprints de un mes. Está organizado por el Scrum Master y los participantes son el equipo Scrum, el Scrum Master, el propietario del producto y todas las partes interesadas requeridas según la decisión del propietario del producto. Se discute el incremento actual. Se describe lo que salió bien y lo que salió mal y, al final, se actualiza el Product Backlog si es necesario.

• The Sprint Retrospective : es una reunión de una hora para Sprints de dos semanas y de dos horas para Sprints de un mes. Tiene lugar justo después de la revisión del Sprint y antes de la planificación del próximo Sprint. Durante esta reunión, en base a la experiencia de la última iteración, se discuten y planifican todas las acciones para mejorar y agregar calidad al producto final para el próximo Sprint.

  
  

Los artefactos son:

• Product Backlog : es un documento en evolución que contiene todos los requisitos del producto. Cada elemento se denomina Historia de usuario y tiene atributos como descripción, pedido, estimación y valor. Los elementos con el orden más alto son más claros y detallados.
• Sprint Backlog : contiene los elementos del Product Backlog seleccionados para el próximo Sprint combinados con la planificación necesaria.
• User Story : como dijimos anteriormente, una User Story es un elemento del Product Backlog. Una historia de usuario sigue una estructura textual común: " Como <tipo de usuario>, quiero <hacer alguna tarea>, para que <pueda lograr algún objetivo>. También debe tener una serie de criterios de aceptación, cada uno con el siguiente esquema: dada <alguna condición previa>, cuando <el usuario realiza alguna tarea> entonces <ocurre algún cambio de estado del sistema>.
• Burn-Down Chart : es un gráfico en el que el eje horizontal representa el tiempo y el eje vertical la cantidad de trabajo que queda por hacer para cada paso en el tiempo. La cantidad de trabajo se puede medir por los llamados Story Points . El Story Point es una unidad de medida de trabajo que tiene en cuenta todas las variables que pueden influir en el desarrollo del trabajo, como habilidades, complejidad, herramientas, etc.
• Incremento : es el incremento total hasta el momento, es decir, la suma de los elementos del Product Backlog completados hasta el momento más todos los demás elementos ya completados en las iteraciones pasadas.

No confunda Scrum con alguna forma de doctrina

Puede considerar los elementos enumerados anteriormente como una base sobre la cual puede operar un conjunto de profesionales. Pueden verse como una herramienta útil pero lo que realmente aporta cohesión, intercomunicación y eficacia en un proyecto son las propias personas. El hecho es que, incluso con todas esas prescripciones estrictamente seguidas y todo el compromiso del Scrum Master, un proyecto puede derivar en el caos y fracasar miserablemente.

Esto se debe a que las personas a menudo confunden las reglas, las metodologías y los marcos con algún tipo de motor divino que supuestamente lleva a los humanos por el camino correcto. Es un defecto psicológico común. Una consideración muy importante es que la realidad es diferente de las teorías, y es un animal muy complejo y salvaje. Si cree que puede domarlo con una lista de reglas y patrones, está condenado al fracaso.

El verdadero propósito de Scrum es minimizar la cantidad de "ruido de fondo" en el proceso de desarrollo y mejorar el enfoque en las cosas más importantes. Si se usa con la flexibilidad y la modestia adecuadas, puede ser eficaz para hacerlo.

En la siguiente sección, describo un caso de uso real, en el que hice un viaje al mundo de Scrum. Fue un viaje de personas sin experiencia, incluyéndome a mí, dispuestos a adoptar los principios ágiles de manera consistente por primera vez. Muchos proyectos en los que trabajé antes se realizaron de manera iterativa pero sin toda la ceremonia de un marco ágil real.

Un caso de uso real

Hablamos aquí de un caso de uso real, en el que se había hecho una adopción del marco Scrum que distaba mucho de ser estricta. El proyecto consistía en un sistema de software destinado a rastrear todas las actividades involucradas en un laboratorio de patología anatómica, desde la recolección de muestras de tejido y su tratamiento en varios pasos hasta la distribución final de los portaobjetos de tejido. También se suponía que el sistema se integraría en fases específicas con maquinaria de automatización externa, mediante controladores de software específicos.

Participé en este proyecto como arquitecto de software. Tuve que cooperar con el director del proyecto para delinear los problemas principales y diseñar un anteproyecto básico de arquitectura. Si sigues los principios Agile al extremo, pensar en arquitectura de antemano no es lo mejor. Incluso el diseño arquitectónico se ve en un escenario iterativo. Sin embargo, en la mayoría de las situaciones, aún necesita una base desde la cual comenzar, y debe discutirla con todas las partes interesadas involucradas.

Me acerqué a este estudio arquitectónico preliminar tratando de tener una separación clara de los contextos, en un enfoque estructurado basado en vistas , puntos de vista y perspectivas . Seguir este enfoque es importante para tener una separación clara de los problemas y también para personalizar la discusión en función del tipo particular de partes interesadas.

Una parte de la arquitectura discutida fue de hecho la fase de desarrollo y su organización. La propia empresa aún no había adoptado ninguna metodología ágil. Sin embargo, de acuerdo con el gerente y las demás personas involucradas, queríamos llenar este vacío y elegimos inspirarnos en el marco de la metodología Scrum.

No estábamos entrenados en absoluto en Scrum, pero todos éramos conscientes de sus conceptos básicos. Las principales directrices que teníamos en mente para el proyecto, tanto metodológicas como técnicas, eran:

• Un conjunto básico de prácticas a seguir, para focalizarnos en el objetivo parcial y global en un enfoque iterativo (Scrum en nuestra decisión final).
• Seguimiento de actividades/fuentes por herramientas de automatización.
• Enfoque de desarrollo impulsado por el comportamiento junto con pruebas unitarias y de integración .

Prácticas Scrum

Motivados por la necesidad de hacer cumplir un marco metodológico sólido pero forzados por nuestra falta de habilidades profundas, elegimos tomar algunas de las reglas principales de Scrum sin ir demasiado lejos. En primer lugar, un enfoque iterativo era realmente importante en nuestra mente. Scrum cubre esto a través de los llamados Sprints, que podemos considerar las unidades iterativas de trabajo. Se supone que cada Sprint cubre un número elegido de características del backlog y tiene una duración de tiempo específica.

Elegimos dos semanas para el tiempo de duración de nuestros sprints. Antes de iniciar el trato real, establecimos un Sprint número cero convencional de una semana para hacer trabajos preliminares y tareas organizativas. En este Sprint preliminar, también escribimos la versión inicial del backlog, con todas las características enumeradas por prioridad. No adoptamos un método particular para evaluar los esfuerzos de la tarea, solo una discusión normal entre los miembros del equipo.

Al comienzo de cada Sprint , en cuanto a las reglas de Scrum, discutiríamos el trabajo ya realizado, evaluaríamos todos los problemas encontrados y elegiríamos las funciones que se implementarán en el próximo Sprint .

El director del proyecto desempeñó el papel del propietario del producto, respaldado por un experto en el dominio. Esto tenía sentido en la situación específica porque no había un gerente de producto real involucrado y el gerente de proyecto mismo tenía todo el conocimiento de los requisitos del cliente. En cuanto al Scrum Master, lo hice por un tiempo y luego le pasé el rol a otro colega, incluso si ninguno de nosotros estábamos completamente capacitados en eso.

Nuestro equipo era heterogéneo con personas que trabajaban en diferentes ciudades. Entonces nos vimos obligados a organizar una versión virtual de reuniones de pie programando llamadas de Skype todos los días a la misma hora. Las reuniones tenían una duración de unos 15 minutos. Algunos de los miembros del equipo han considerado esto como una forma de resistencia, tal vez porque lo interpretaron como una forma de control, lo cual no lo es.

Dedicamos un tiempo a hacerles conscientes del significado real de las reuniones diarias: una breve discusión entre compañeros de equipo para centrarse en los temas principales, mejorar la comunicación y encontrar formas de mejorar y facilitar el trabajo para todos. Durante un tiempo, siguieron diciendo que era una pérdida de tiempo y una fuente de distracción del trabajo real, pero al final logramos convencerlos.

Seguimiento de actividades/fuentes por herramientas de automatización

Además de las prácticas metodológicas, también necesitábamos las herramientas para resolver estas preocupaciones principales:

• Versionar el código, rastrear sus cambios y compartirlos con todo el equipo.

• Seguimiento de las actividades y resolución de errores: qué se debe hacer, quién está asignado a qué y el estado del mismo.

• Hacer coincidir los cambios del código fuente con las actividades.

  
  

El flujo de información en un proyecto es demasiado complejo como para depender únicamente de prácticas metodológicas para controlarlo. Necesita una base sólida de herramientas para facilitar el trabajo. Cuantas más tareas automatices, más podrás concentrarte en cosas importantes y producir un mejor producto.

Para el control de versiones del código, usamos Git, ya que es la opción más natural. Git se puede usar de varias maneras y nosotros personalmente adoptamos Gitflow como patrón de flujo de trabajo.

Para realizar el seguimiento de las actividades utilizamos Redmine , que es una plataforma general destinada a la gestión de proyectos.

Para lidiar con la tercera preocupación, integramos nuestro repositorio de Git con Redmine de tal manera que las confirmaciones de Git pudieran relacionarse con tickets específicos de Redmine mediante el uso de un código de identificación de problema en el comentario de confirmación. De esta manera teníamos un mapeo completo entre actividades y unidades de trabajo de Git.

Enfoque de desarrollo impulsado por el comportamiento junto con pruebas unitarias y de integración

Estábamos muy dispuestos a basar nuestro proceso de desarrollo en un enfoque basado en el comportamiento. BDD encaja muy bien con Scrum y en general con los principios Agile, especialmente en la parte de comunicación. Permite escribir escenarios de prueba en un formato que puede ser entendido por personas sin conocimientos técnicos y, con las herramientas adecuadas, brinda un informe visual del estado actual. Traza los límites lógicos del producto y fuerza el trabajo de desarrollo dentro de esos límites.

Las pruebas funcionales de BDD eran solo la capa externa de toda la instrumentación de prueba. También utilizamos pruebas unitarias y de integración. Para no sentirnos abrumados por la complejidad de un entorno de desarrollo de este tipo, tuvimos que utilizar las herramientas y las funciones de automatización adecuadas.

Las principales tecnologías involucradas fueron:

• Cucumber : integrado en la aplicación Spring Boot con servicios REST

• Otras herramientas de prueba: bibliotecas JUnit , Mockito y Spring Boot para admitir pruebas de integración.

  
  

El siguiente mapa mental muestra un resumen de lo discutido anteriormente:

Consideraciones

¿Valió la pena la adopción de Scrum, aunque sea de una manera ligera y flexible? La respuesta es sí. Sin embargo, seamos claros, no podemos verlo como la solución a todos los problemas, y si se adopta sin comprender su espíritu mismo, podría ser incluso perjudicial. La esencia de una metodología es ofrecer un esquema mental colectivo para hacer que las personas trabajen juntas con el máximo intercambio de información y compromiso, pero si las personas se enfocan en seguir las reglas de una ceremonia exótica en lugar del trabajo real, el propósito original se desvanece.

Una analogía deportiva

Puedes entender mejor lo dicho anteriormente con una analogía deportiva. No a todas las personas les gusta el fútbol, pero casi todos tienen al menos una mínima idea de cómo funciona. En primer lugar, es un juego colectivo. Dos equipos se enfrentan en un campo de juego tratando de meter un balón dentro de una portería. Para realizar esta tarea aparentemente sencilla tienen que mezclar iniciativas individuales con estrategias y tácticas colectivas. Esas estrategias y tácticas son enseñadas de antemano por el entrenador y constituyen un gran porcentaje de todo el tiempo dedicado a las sesiones de entrenamiento.

Para que sean realmente efectivas, las reglas colectivas descritas anteriormente seguidas por los jugadores de fútbol deben ejecutarse sin esfuerzo y sin siquiera pensar que existen. Deben ser automáticos, como los gestos para conducir un coche por ejemplo. Un requisito básico para alcanzar este objetivo es que deben ser lo suficientemente simples como para que todos los jugadores los absorban por completo en el tiempo limitado que se requiere para prepararse para el campeonato.

Si te enfocas en seguir la ceremonia de Scrum en lugar del trabajo real, terminas trayendo caos en lugar de orden. Por otro lado, si sigues un enfoque más pragmático, siendo flexible e incluso deshaciéndote de todas las cosas que en nuestra experiencia específica no funcionan, puedes aprovecharlo al máximo. Incluso puede pensar en posponer algunos enfoques de Scrum si los encuentra difíciles de seguir y luego tratar de introducirlos en una fase posterior.

Manejo de los gerentes

Hagamos hincapié en un concepto: las metodologías ágiles y Scrum específicamente, solo pueden funcionar si las personas del equipo están dispuestas a adoptarlas o al menos son conscientes de sus ventajas. No puede funcionar si solo lo presentan los gerentes de una empresa para seguir el alboroto general y decirle al mundo exterior: "¿Ves? ¡Somos ágiles!". Seamos claros: si el propósito es solo marketing, sería mejor solo pretender seguir esas metodologías. No es necesario introducir en los procesos internos una carga que sólo tiene un fin promocional.

Moraleja de la historia: las metodologías ágiles pueden tener algún impacto positivo solo si son adoptadas por los ingenieros junto con los gerentes y no solo impuestas por los gerentes. La mayoría de los gerentes, especialmente aquellos sin formación técnica, no saben nada acerca de cómo una metodología podría afectar el ciclo de vida de un proyecto de software, mientras que los ingenieros sí lo saben, especialmente los ingenieros senior. Años de experiencia son mejores que los mejores libros y los mejores cursos.

Además, según mi extraña experiencia en empresas italianas, las organizaciones a menudo están dictadas por una cultura que parece provenir de algún tipo de herencia medieval. En este contexto, el Scrum Master e incluso los roles de Product Owner podrían verse simplemente como una fuente de autoridad en una trayectoria profesional, en lugar de roles operativos.

He experimentado con esta dura realidad recientemente, a decir verdad. Normalmente estas personas no tienen la menor idea de cuáles son los principios mismos de una metodología, y siguen acosando a la gente con reglas que ni siquiera entienden.

En estos entornos horribles, Extreme Programming y Scrum son solo títulos sin sentido. En estos contextos los directivos son fuentes de entropía a tratar, y para alcanzar un nivel digno de productividad el equipo debe gestionar su propio trabajo e incluso los directivos, para reducir su mala influencia. Eso explica el título de esta sección: "Gestión de los Gerentes".

Equilibrio entre metodología, prácticas de prueba, actividades de seguimiento y herramientas relacionadas

En el caso de uso descrito en este artículo, hemos hablado de metodología, pero también de estrategias de prueba, actividades de seguimiento y las herramientas utilizadas para respaldarlas. Los mejores marcos de metodología no pueden resolver por sí mismos todos los asuntos complejos involucrados en el desarrollo de software.

De hecho, BDD, que cubre las pruebas funcionales, es una forma muy efectiva de compartir el conocimiento de la lógica del sistema de software que se está desarrollando. Crea un fuerte vínculo entre todos los miembros del equipo y el propietario del producto, y mejora el enfoque en los aspectos más importantes del proyecto. Por lo tanto, cubre parte de los problemas que se supone que Scrum debe cubrir.

Las pruebas unitarias y de integración, por otro lado, están más involucradas en los procesos internos de los desarrolladores de software, pero indirectamente hacen que los cambios sean más fáciles de manejar y se acoplan bien con el enfoque iterativo de Scrum.

Conclusión

El desarrollo de software es un asunto complejo incluso en proyectos mínimos manejados por un solo desarrollador. Si un proyecto necesita un equipo para desarrollarse, surgen una serie de cuestiones organizativas. Las metodologías ágiles son un intento de resolver esos problemas, pero serían realmente útiles solo si se toman como un grano de sal y evitan cualquier forma de magnificación sin sentido.