Alberto Méndez

Las metodologías ágiles surgen para proporcionar un mecanismo que facilite la adaptación al cambio en el proceso desarrollo y creación de proyectos. Todo cambia muy rápido en los tiempos que corren y es necesario estar preparados para reaccionar ante esos cambios para evitar mermar la calidad final del proyecto o producto. Es por ello que la implementación de una metodología ágil frente a una predictiva puede marcar la diferencia ante nuestros competidores.

Historia

Originariamente todo proyecto se organizaba utilizando metodologías predictivas, orientadas a procesos nos determinaban los pasos a seguir de principio a fin, su poca flexibilidad provocaba que cualquier pequeña alteración o imprevisto supusiese un problema enorme a la hora de lidiar con ello, además que la detección de errores o problemas solía ser bastante tardía cuando ya es mucho más complicado el poder solucionarlos. Las metodologías ágiles, orientadas a funcionalidades nos permiten detectar errores, integrar los cambios y reaccionar frente a los imprevistos de forma casi inmediata.

«Los habitantes del país de la Reina Roja deben correr lo más rápido que puedan, sólo para permanecer donde están, pues el país se mueve con ellos.» Alicia a través del espejo, Lewis Carrol

Allá por los años 80 aparece la primera referencia a la aplicación de SCRUM en el proceso de desarrollo de productos por parte de los japoneses Takeuchi Hirotaka y Nonaka Ikujiro, quienes aplicaron esta metodología en empresas como Epson, Honda, Hewlett Packard y otras. SCRUM se refiere a la formación en bloque empleada en Rugby conocida como melé en español. Y es que vieron que las estrategias aplicadas en ciertos deportes como el rugby en este caso, podían ser empleadas en las empresas (y otros ámbitos) para el desarrollo de productos.

Es allá por 1995 en la OOPSA (Object-Oriented Programming Systems And Applications conference, conferencia de Programación de sistemas y aplicaciones Orientadas a Objetos) cuando Ken Schwaber asocia por primera vez la aplicación de SCRUM al desarrollo de software.

En el año 2001 en Utah, 17 críticos convocados por Kent Beck acuñan el término Métodos ágiles como alternativa a las metodologías predictivas y se crea el Manifiesto Ágil que resume los principios sobre los que se sustentan los métodos alternativos conocidos como ágiles.

Manifiesto ágil

SCRUM se asienta en cuatro premisas extraídas del manifiesto ágil.

• Personas e iteraciones antes que procesos y herramientas. Centramos el foco en las personas e iteraciones, es el pilar principal de SCRUM y una de las claves de las metodologías ágiles.
• El software (o producto, resultado, etc) que funciona, por encima de la documentación exhaustiva. La documentación ha de ser nada más y nada menos que útil, aquella que realmente da valor al producto.
• Colaboración con el cliente, por encima de la negociación contractual. El cliente es pieza fundamental de las metodologías ágiles, la asiduidad de la comunicación con este permite detectar errores en fases más tempranas y actuar en consecuencia
• Responder al cambio antes que seguir un plan. Se busca la forma de ser ágiles y responder eficientemente ante los cambios e imprevistos que puedan surgir, tiene que haber periodos de estabilidad y periodos en los que se introducen nuevos cambios.

Nuestra principal prioridad es satisfacer al cliente a través de la entrega continua y temprana de software de valor. El responder a los requisitos cambiantes nos permite gestionar los cambios, lo que no significa minimizarlos, son parte del desarrollo de un producto y saber como actuar frente a ellos puede ofrecernos una ventaja competitiva. Entregando con frecuencia (de dos a ocho semanas, tres semanas como recomendable) un software que funciona conseguiremos detectar posibles errores y actuar frente a ellos de forma eficiente.

Tanto la gente de la parte de negocio como los desarrolladores deben trabajar mano a mano de forma cotidiana a través del proyecto y deben estar en consonancia para obtener estimaciones certeras, puede ser un gran problema si ambas partes están desalineadas pudiendo incluso conducir a la frustración de todas las partes deteriorando la calidad del proceso y el resultado del producto.

El proyecto ha de construirse en torno a individuos motivados y ha de facilitárseles todos los medios necesarios para que puedan realizar su trabajo y de esta forma cumplir los objetivos; el diálogo entre las partes ha de ser cara a cara, en persona, con el fin de evitar interferencias que puedan provocar problemas de comunicación. Se pueden utilizar herramientas de comunicación a distancia aunque no es lo recomendable y deben establecerse reuniones físicas en gran parte del proceso.

La medida principal es el software que funciona pero no puede ser a costa de lacrar otras de las partes involucradas, de poco sirve un software que funciona con un equipo quemado y exprimido hasta la médula, en el equilibrio está el éxito. Se promueve el desarrollo de trabajo sostenible, puede haber picos puntuales de trabajo pero no debe convertirse en costumbre. Cultivando el conocimiento técnico se consigue la excelencia y facilita la agilidad, mejorar técnicamente y a diario nos permitirá ser más ágiles. Lo simple es más eficaz, más fácil de mantener y con menos puntos de ruptura, lo básico ha de funcionar de forma correcta y robusta, sin errores.

Si desaparece la figura del líder el equipo debe ser capaz de continuar trabajando, la auto organización del equipo debe ser trabajada desde el primer momento y un equipo polivalente, multifuncional y multidisciplinar ayudará a la auto organización del mismo, de ahí es de donde emergen las mejores arquitecturas, diseños y requisitos.

Scrum técnico

Se apoya en tres pilares básicos:

• Roles
• Eventos
• Artefactos

El ciclo básico de SCRUM lo componen la Pila de producto que organiza las funcionalidades ordenadas de forma descendente según su prioridad, es aquí dónde se introducen los cambios haciéndola por tanto, mutable. La Pila de sprint organiza las tareas del sprint actual y es inmutable, un sprint nunca puede modificarse ni detenerse. Las funcionalidades seleccionadas para el sprint pasan de una a otra pila a través del proceso conocido como grooming o preparación, una vez terminado el sprint se realiza lo que denominamos incremento, que viene a ser la entrega de las funcionalidades implementadas.

Valores y principios

La agilidad no la proporciona el cumplimiento de prácticas sino de valores

• Respeto entre las personas.
• Responsabilidad y autodisciplina.
• Trabajo enfocado y orientado en el valor para el cliente.
• Compromiso.

Diferenciamos 3 principios básicos

• Delegación de atribuciones (empowerment) al equipo para que pueda auto organizarse  y tomar las decisiones sobre el desarrollo.
• Información, transparencia y visibilidad del proceso de desarrollo.
• Inspección y adaptación frecuente para detectar posibles desviaciones y realizar los ajustes necesarios.

Roles

SCRUM diferencia tres roles principales

• Product Owner o Propietario de Producto: Debe conocer perfectamente el entorno de negocio del cliente y es el que tiene la visión del producto y establece el objetivo, «sabe» lo que quiere y determina el valor del producto a través del incremento. Sólo puede existir un único propietario de producto, proporciona la pila de producto con todas las funcionalidades bien definidas, establece las prioridades de cada una y actua sobre ella. Lo ideal es que sea el cliente o todavía mejor, el usuario final.
• SCRUM master: No forma parte del equipo, debe garantizar que éste disponga de las herramientas necesarias para realizar su trabajo, actúa como facilitador y proporciona liderazgo servil, garantizando que el equipo cumpla sus objetivos y lo asesora para que pueda trabajar de forma auto organizada. Se encarga de también de explicar las reglas, proporcionar información y asesorar al propietario de producto, revisar y validar la pila de producto y actuar como moderador en las reuniones.
• Equipo de desarrollo: No debe constar de menos de 3 ni más de 9 integrantes, ha de ser multifuncional, multidisciplinar y polivalente permitiendo así que cualquier miembro pueda realizar la tarea de otro de los integrantes, responden por el conjunto y trabajan de forma cohesionada y auto organizada. Todos y cada uno de los miembros participan en la toma de decisiones respetando las opiniones y aportes de cada uno.

Faltaría por mencionar la parte de los interesados o stakeholders, que no se suele integrar como rol en sí, vendrían a ser todas aquellas terceras partes involucradas en el proyecto que no forman parte de las anteriores. Cabe distinguir dentro de estos roles a dos grupos:

• Comprometidos: Son aquellos que se comprometen con el proceso de desarrollo del producto y de este forman parte el product owner y el equipo
• Involucrados: No forman parte del proceso pero intervienen de forma indirecta en él y a él pertenecen el SCRUM master y los interesados (dirección, gerencia, comerciales, marketing, etc).

Eventos

• Sprint: Nombre que recibe cada iteración del proceso de desarrollo. Es el núcleo central que genera el pulso de avance a ritmo de tiempos prefijados de un mínimo de 2 semanas, 3 como recomendable, 4 semanas como máximo recomendable y 6 como máximo, en el manifiesto se habla de hasta 8 semanas pero no es real en la práctica.
• Reunión de planificación del sprint: Marca el inicio de cada sprint y en ella se determina el objetivo y las tareas necesarias para cumplirlo, la conduce el SCRUM Master y a ella asisten tanto el equipo como el propietario de producto además de los interesados si es que hubiere. Se subdivide en tres partes
  • Precondiciones: Se estudian los recursos disponibles para llevar al cabo el sprint, están preparadas las historias de usuario y ya se conocen las tecnologías empleadas
  • Entradas: La pila de producto, lo desarrollado en incrementos anteriores, datos de velocidad o rendimiento del equipo en el último sprint como criterio para estimar la cantidad de trabajo que es razonable a integrar y las circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.
  • Resultado: La pila de sprint, su duración y fecha de la reunión de revisión además del objetivo del mismo.
• SCRUM diario: No debe constar de más de 15-20 minutos y en ella los miembros del equipo han de indicar qué es lo que han realizado durante el día anterior, qué tareas realizarán durante el día actual y los problemas o impedimentos encontrados, solucionados o no, deben explicarse los problemas para que todo el equipo se nutra de ese conocimiento y la duración de la explicación de los mismos no debe ser superior a dos minutos. Es ideal hacerlo con el tablero SCRUM presente, la conduce el equipo y en ella se establecen dos subgrupos:
  • Entradas: Pila de sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior además de la información del avance de cada uno de los miembros del equipo.
  • Resultados: Pila de sprint y gráfico de avance actualizados y la identificación de posibles necesidades e impedimentos.
• Revisión del sprint: Se analiza el incremento generado y se adapta a la pila de producto si fuera necesario, se analiza qué se está construyendo. Es una reunión informativa y su misión no es la toma de decisiones ni la crítica del incremento, a ella asisten el propietario de producto, el SCRUM Master, todo el equipo de desarrollo y aquellas personas involucradas que así lo deseen. Se proporciona el incremento terminado y como resultado ha de proporcionarse el feedback necesario para el propietario de producto y no al contrario, se convoca también la reunión del siguiente sprint. El propietario de producto debe proporcionar información para mejorar el valor de la visión del producto.
• Retrospectiva del sprint: Se revisa lo sucedido durante el sprint, equipo y SCRUM Master analizan cómo se está trabajando y crean un plan de mejoras para el próximo sprint. Debe realizarse de forma constructiva y positiva, es vital compartir información y recopilar datos que puedan ayudar a la mejora del proceso.

Artefactos

Dentro de los artefactos podemos distinguir varios elementos

• Pila de producto o backlog: Se compone de historias de usuario, que definen los requisitos en una metodología ágil y son imprescindibles para describir una funcionalidad. Como dijimos anteriormente está en continuo crecimiento y evolución, nunca se da por completada y el propietario del producto la mantiene ordenada por prioridad.
  • Historias de usuario: Forman la pila de producto, deben establecer una descripción, la prioridad y la preestimación del esfuerzo y debe ser una por cada funcionalidad, también indican las pruebas de aceptación que luego se convertirán en tests.
• Pila de sprint: Es responsabilidad del equipo y contiene las tareas resultado del proceso de grooming aplicado sobre la pila de producto. Nace y muere cuando se termina el sprint y es inmutable excepto para establecer las prioridades de las tareas. Es visible para todo el equipo en un tablero o pared en el mismo espacio físico dónde el equipo realiza su trabajo. Cada tarea ha de indicar quién es el responsable de la misma, el estado en el que se encuentra y el tiempo restante para completarla.
• Incremento: Es la parte del producto realizada en un sprint potencialmente entregable, debe estar suficientemente probada y por supuesto terminada.
• Epopeya o EPIC: Viene siendo la expectativa del cliente, la idea sin procesar y agrupa las historias de usuario que la conforman.

Medición y estimación ágil

El proceso requiere de la obtención de información de valores y números medibles que determinen el rendimiento, la satisfacción del cliente y la eficiencia. Además hay todo tipo de indicadores, del propio proyecto, esfuerzo, coste, tamaño, desarrollo, densidad de fallos complejidad del diseño y disponibilidad.

Los indicadores tienen que ser pocos y útiles, todos aquellos que no nos sean útiles para el proceso deben ser descartados, muchas veces el propietario de producto nos pide indicadores que le proporcionan la información necesaria para conocer el estado y la evolución del proyecto.

Uno de los indicadores más importantes es el del tiempo estimado frente al del tiempo efectivo, lo que viene a ser el tiempo estimado de duración de la tarea frente al tiempo que realmente se tarda en realizarla.

Velocidad, trabajo y tiempo

• Velocidad (trabajo/tiempo): Muestra la cantidad de trabajo realizada por unidad de tiempo. Es la cantidad de trabajo realizada por el equipo en un sprint (incremento iterativo). Lo normal es que la velocidad aumente tras cada sprint.
• Tiempo
  • Incremento iterativo (SCRUM): En iteraciones, indica el número de tareas que hemos sido capaces de realizar en un sprint.
  • Incremento continuo (sin sprints, propiedad de las metodologías predictivas, propio de Kanban): Muestra el flujo de avance constante, se mide en días, semanas o meses de forma que la velocidad se expresa en puntos que vienen a indicar la cantidad de trabajo.
• Trabajo o esfuerzo: Se determina el grado de avance del proyecto que queda pendiente por realizar, aunque se mencione lo que se ha realizado no se registra. El tiempo pendiente restante puede ser superior al del día anterior si surgen imprevistos en la propia tarea y se descubre que requiere más tiempo del estimado. Dos tareas similares realizadas por la misma persona en diferentes escenarios pueden tener distintas estimaciones de tiempo. No es realista hablar de la cantidad o calidad del trabajo realizado por una persona por unidad de tiempo. No es posible estimar con precisión la cantidad ni el tiempo necesario para llevar a cabo una tarea, con el fin de aumentar esta precisión las tareas se suelen descomponer en subtareas más pequeñas con la técnica del juicio de expertos.

Relacionado:

• SCRUM:  Wikipedia, curso SCRUM Manager, Manifiesto ágil
• Algunos de los textos aquí mencionados son originales de Josefina Alonso Nocelo: Twitter, LinkedIn
• Imagen cabecera: PluralSight