Patrón de pensamiento Lean en el marco de trabajo de Scrum

Por David Starr. David Starr es responsable de la creación de software para Scrum.org, donde se centra en la mejora de la profesión de desarrollo de software. También fundó la comunidad técnica en línea, ElegantCode.com.

Julio de 2012

Inspeccione las cualidades Lean del marco de trabajo de Scrum junto con distintas maneras de ayudar a los equipos de Scrum a mejorar usando el patrón de pensamiento Lean.

Se aplica a

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

Las conversaciones actuales sobre el desarrollo de Software Agile incluyen de forma invariable las herramientas Scrum, Lean y Kanban (tres herramientas para planear, supervisar y ejecutar las actividades de desarrollo de software). A menudo, algunos usuarios de Agile comparan y contrastan estas herramientas y proclaman que el marco de trabajo de Scrum y el patrón de pensamiento Lean funcionan bien juntos, mientras que otros ven estas herramientas fundamentalmente como maneras diferentes de crear software.

Información general

Scrum es terriblemente popular; de todos los equipos que dicen utilizar métodos ágiles de desarrollo, el 92% declara utilizar Scrum[1]. Tras muestrear los buenos resultados que se obtienen con Scrum, muchos equipos tienden a madurar sus procedimientos e ir más allá del marco de trabajo básico de Scrum. En este artículo se explora el modo de extender el marco de trabajo de Scrum con las técnicas Lean y Kanban, con el patrón de pensamiento de Kaizen, o de mejora continua.

Scrum

El marco de trabajo de Scrum, introducido en 1995 por Ken Schwaber y Jeff Sutherland, permite a los equipos trabajar conjuntamente en la entrega de software iterativa e incrementalmente. Los equipos Scrum organizan el trabajo en espacios de tiempo limitado denominados Sprint, que duran un máximo de un mes, lo que produce un conjunto de funcionalidad completa y activa en cada Sprint.

El marco de trabajo de Scrum es fácil de entender, y se ha vuelto muy popular entre los equipos de desarrollo de software y sus clientes. Scrum promueve los equipos multidisciplinares y autogestionados que se centran en el Sprint para entregar un incremento de trabajo y software que se puede liberar.

Scrum está codificado en la Guía de Scrum, que documenta los roles, los artefactos y los eventos de Scrum. La Guía de Scrum la mantienen los creadores de Scrum y está disponible en línea en Scrum.org.

Lean

El patrón de pensamiento Lean es una manera de abordar la optimización del sistema centrándose en la reducción de los desperdicios y mejorando el flujo global en todo un sistema. Lean tiene un historial muy completo en fabricación y ha ganado popularidad en los círculos de desarrollo de software en años recientes.

Cuando se aplica al desarrollo de software, Lean Thinking se plasma en los siete principios siguientes, primero publicados en el libro, Lean Software Development: un kit de herramientas Agile[2].

1. Eliminar desechos

2. Amplificar el aprendizaje

3. Decidir lo más tarde posible

4. Entregar tan pronto como sea posible

5. Autoriza al equipo

6. Compilar integridad en

7. Consulte todo

Al aplicar estos principios al trabajo de entrega de un producto de software no es un objetivo final. Se trata de usar los principios de Lean como orientación en la toma de decisiones y de elegir las técnicas que mejorarán la globalidad del sistema. Por ejemplo, la práctica de TDD (Desarrollo basado en pruebas) fomenta la integridad en el software revisándolo en el momento de la creación, de forma que se respeta el principio de Lean de fomentar la integridad en durante el proceso de creación.

Kanban

Una técnica con orígenes en el pensamiento Lean es Kanban[3], que usa el pensamiento Lean en un método formal que se centra en reducir la entrega desechos, entregar a su debido tiempo y evitar la sobrecarga de aquellos que realizan el trabajo. A diferencia de Scrum, Kanban no es un método iterativo e incremental; en lugar de basarse en iteraciones, Kanban se basa en cinco actividades básicas.

1. Visualizar el flujo de trabajo

2. Limitar el trabajo en curso (WIP)

3. Administrar el flujo

4. Haga las directivas de proceso explícitas

5. Mejora en colaboración

Equipos diferentes que usan Kanban tienen a menudo procesos muy diferentes. El método Kanban es simplemente un conjunto de técnicas para administrar un proceso y, a continuación, optimizarlo deliberadamente. Kanban se aplica fácilmente a los procesos ya en marcha, incluido Scrum.

Scrum y Kaizen

Una vez se entreguen de forma sistemática los incrementos del software que funciona con cada Sprint, los equipos de Scrum buscarán nuevas formas para mejorar sus procedimientos. El núcleo del Scrum efectivo es Kaizen, el patrón de pensamiento de mejora continua. Los equipos de Scrum que funcionan bien usan casi con toda seguridad una miríada de procedimientos cuando se centran en los principios de Kaizen. Las herramientas y técnicas como la estimación relativa, el desarrollo de pruebas en primer lugar, la automatización de compilación y la programación entre iguales son algo natural en los equipos de Scrum.

No solo las otras herramientas, técnicas y procedimientos funcionan bien para la finalización del Scrum, sino que también existe un modelo de extensión del Scrum que se describe y administra en scrum.org. Este modelo de extensión de Scrum fomenta la implicación de la comunidad en documentar los procedimientos que complementan a Scrum y funcionan bien con el marco de trabajo. En el momento de escribir esto, se propusieron varias extensiones con aplicación específica a prácticas Lean dentro de Scrum.

Las ventajas de aplicar Lean Thinking a Scrum son innegables. Naturalmente, muchos usuarios de Scrum han logrado un rendimiento y calidad mucho mayores al aplicar el patrón de pensamiento Lean en sus procedimientos de Scrum.

Scrum a través de la lente de Lean

El marco de trabajo de Scrum consta de los roles, artefactos y eventos siguientes. Si no está familiarizado con el marco de trabajo básico de Scrum, lea la Guía de Scrum antes de continuar.

Roles	Artefactos	Eventos
Propietario del producto ScrumMaster Equipo de desarrollo	Trabajo pendiente del producto Trabajo pendiente del sprint Increment	Sprint Planeación del sprint Scrum diario Revisión del sprint Retrospectiva de sprint

La Guía de Scrum muestra reglas sobre cómo funcionan conjuntamente estos componentes, pero Lean Thinking proporciona un marco de trabajo para optimizar aún más la interacción de los roles, los artefactos y los eventos de Scrum. Los equipos Scrum seleccionan un subconjunto del trabajo pendiente del producto para entregar cada Sprint, y se centran en la entrega de un incremento con calidad y funcionalidad adecuadas. El patrón de pensamiento Lean puede ayudar a agilizar el flujo de trabajo en todo el Sprint y a reducir los desperdicios de la secuencia de valor global.

Scrum y Lean se esfuerzan por mantener un alto nivel de calidad, que es necesario para el éxito del trabajo global que se realiza. Para ver en acción los principios compartidos por el Lean Software Development y por Scrum, basta con que analice los roles, artefactos y eventos de Scrum a través de la lente de Lean Thinking.

Eventos

Salvo el sprint, que es un contenedor para el resto de los eventos, los eventos de Scrum en realidad simplemente son reuniones. El patrón de pensamiento Lean por lo general contempla las reuniones como un desperdicio, algo que se debe eliminar diligentemente.

Esto podría hacernos llegar a la conclusión de que los eventos de Scrum son innecesarios. Sin embargo, cada evento en Scrum está diseñado con cuidado para eliminar otras reuniones que se producirían de otra manera y que ocasionarían interrupciones (o ad hoc). Los eventos de Scrum bien ejecutados dan lugar a menos reuniones y a menos tiempo gastado en responder a interrupciones imprevistas.

Cada evento de Scrum está diseñado para inspeccionar algo y para adaptar algo. La inspección admite los principios de Lean de ampliar el aprendizaje y fomentar la integridad en el proceso de creación. La adaptación de un plan, requisito u otro artefacto durante un evento Scrum admite los principios de Lean de aplazar decisiones y tener una visión de conjunto. La tabla siguiente muestra eventos de Scrum y qué se examina y adapta durante cada uno de ellos.

Evento	Inspeccionado	Adaptado
Preparar el trabajo pendiente	Trabajo pendiente del producto	Trabajo pendiente del producto
Planeación del sprint	Trabajo pendiente del producto Incrementos anteriores	Objetivo del sprint Trabajo pendiente del sprint
Scrum diario	Trabajo pendiente del sprint Progreso hacia el objetivo del Sprint	Trabajo pendiente del sprint Plan diario
Revisión del sprint	El incremento más reciente El sprint más reciente Trabajo pendiente del producto	Trabajo pendiente del producto Otros planes a largo plazo
Retrospectiva de sprint	El incremento más reciente El sprint más reciente El propio equipo Scrum Procedimientos técnicos	Comportamientos del equipo Scrum Procedimientos técnicos Procedimientos de administración del trabajo que se utilizan en Scrum

Artefactos

Los artefactos Scrum están diseñados para ser tan sencillos como sea posible, pero no más. Los requisitos, los planes e incluso el software entregado por un equipo de Scrum son más valiosos cuando solo incluyen los detalles necesarios para completar el trabajo.

Trabajo pendiente del producto

En un mundo perfecto, no habría necesidad de crear requisitos más allá de las charlas entre personas. Lo ideal sería que la persona que solicita el software sea comprendida inherentemente por los que lo crean, y que no fuese necesaria ninguna expresión intermedia de requisitos. Aunque es posible en equipos muy pequeños con relaciones con el cliente próximas, no escala simplemente. Crear requisitos antes de entregar características es necesario para el planeamiento. Lean contempla los requisitos como un inventario, un desperdicio habitual en el patrón de pensamiento de Lean y, por tanto, debe minimizarse.

En Scrum, los requisitos se administran en el trabajo pendiente del producto, que recomienda una forma o estructura muy pequeñas. No se requiere que los elementos de trabajo pendiente del producto estén detallados en gran medida o se expresen perfectamente.

Aunque el mantenimiento del trabajo pendiente y los requisitos del producto sea necesario para planear el trabajo, lo ideal es crear y perfeccionar los elementos de trabajo pendiente del producto un poco antes de que el equipo de desarrollo trabaje realmente en ellos. Los equipos de Scrum eficaces evitan crear requisitos en el trabajo pendiente del producto que probablemente nunca se aborden.

Trabajo pendiente del sprint

En un mundo perfecto, no habría necesidad de planear. Un equipo de desarrollo puede aceptar simplemente la solicitud de la siguiente característica de una cola, omitiendo el contexto y el coste del requisito. Aunque este modelo sencillo de procesar el trabajo es muy flexible, no tiene en cuenta que el desarrollo de software es una tarea inherentemente compleja. El desarrollo de productos de complejidad significativa se beneficia de tener un plan, aunque ese plan sea sencillo y no tenga muchos detalles.

La Guía de Scrum define el trabajo pendiente del sprint como el subconjunto de elementos de trabajo pendiente del producto seleccionados para un sprint, y un plan para entregarlos. El trabajo pendiente del sprint muestra el inventario (residuos) de trabajo proyectado para el sprint, que se perfecciona por lo menos diariamente. Este perfeccionamiento diario garantiza que el plan nunca es una promesa y permite al equipo de desarrollo posponer decisiones de implementación hasta el último momento en que pueden tomarlas de forma responsable.

Los equipos Scrum compilan requisitos y planes que apenas son suficientes, para minimizar el costo. Este enfoque Lean de minimizar el inventario permite la toma de decisiones diferida y permite al equipo organizarse por su cuenta dentro del sprint. En lugar de centrarse en los requisitos o en el plan, los equipos de Scrum se centran en el valor que se proporcionará en cada incremento.

Increment

Cada Sprint incluye la entrega al menos de un incremento de software que funciona. El incremento del producto es el único artefacto de Scrum que Lean Thinking no considera residuos. Sin embargo, el incremento del producto puede tener desechos. Los residuos pueden estar presentes en forma de características no utilizadas, defectos, funcionalidad incompleta, código difícil de mantener o diseños mal incorporados.

Los equipos de Scrum con alto rendimiento eliminan los desechos con determinación del propio producto. A menudo, esto se hace inspeccionando los incrementos con frecuencia en todo el Sprint y manteniendo un alto nivel de calidad en todo momento. Esto hace realidad la propia esencia del principio de Lean de incluir la integridad.

Los equipos Scrum también se benefician de tener en cuenta los principios de eficiencia al entregar el incremento. El propio marco de trabajo de Scrum garantiza que el incremento está abierto para la inspección en la revisión del sprint. Recibir información sobre el incremento en la revisión del sprint es fundamental para ampliar el aprendizaje.

Roles

Los roles prescritos por Scrum se equilibran cuidadosamente para conceder autonomía al equipo de Scrum y equilibrar las tensiones dentro de él. Los expertos en Scrum, los equipos de desarrollo y los propietarios del producto trabajan en colaboración para tener éxito, lo que requiere que todos los implicados vean las perspectivas de los otros. Esta colaboración garantiza que los miembros del equipo Scrum vean el sistema Scrum en su totalidad, y hace transparente cualquier decisión de suboptimización del equipo Scrum que favorezca a cualquier rol sobre los demás.

El cocreador de Scrum, Jeff Sutherland, opina que la base para una implementación correcta de Lean es inteligencia ascendente y trabajadores con autonomía junto con directores comprensivos. Los equipos de desarrollo autogestionados de Scrum incluyen a los empleados con autonomía de Lean Thinking que pueden controlar el aprendizaje en la organización en lugar de seguir el que se les ha impuesto.

Una característica única de Scrum es el rol de experto en Scrum, que la Guía de Scrum describe como sigue:

El experto en Scrum es responsable de garantizar que el Scrum se entiende y se activa. Los expertos en Scrum lo consiguen asegurándose de que el equipo Scrum cumple la teoría, los procedimientos y las reglas de Scrum. El experto en Scrum es un subordinado líder del equipo Scrum.Guía de Scrum - octubre de 2011

Uno de las principales habilidades y actividades de los buenos Scrum Masters es saber simplificar. En la mayoría de los casos, los ScrumMasters facilitan eventos de Scrum. Los expertos en Scrum son administradores, aunque de la adopción y el cumplimiento de Scrum, no de personas.

Hacia un Scrum que sea más Lean

El uso de Lean Thinking para considerar y resolver problemas expuestos por Scrum a menudo genera grandes beneficios y es una buena manera de sustentar una cultura Kaizen. Los equipos Scrum siguen aprendiendo a aplicar Lean a Scrum, pero muchos procedimientos están ganando popularidad porque han demostrado conseguir equipos Scrum más eficaces.

En el trabajo del conocimiento se utilizan muchos procedimientos y técnicas comunes que se ajustan directamente los principios de la metodología Lean. Algunas de estas técnicas se exploran a continuación, prestando mayor atención a cómo pueden llevarse a cabo en un equipo Scrum.

Lo siguiente no es una lista exhaustiva de técnicas, sino simplemente ejemplos de cómo algunos equipos de Scrum podrían mejorar utilizando técnicas comunes de los usuarios de Lean. Además, cada técnica se puede aplicar de varias maneras. Solo algunas técnicas de Lean se describen aquí. Los equipos Scrum pueden enfocar los siguientes escenarios de manera diferente a lo descrito en este documento.

Eliminar desechos

Quizás el ejercicio más básico de los procedimientos Lean es la eliminación de los desechos. La metodología Lean considera que un desecho es aquello que no es en absoluto necesario para generar el resultado deseado. Los desechos comunes de desarrollo de software incluyen:

1. Código o características no utilizados

2. Defectos que conllevan que se tenga que repetir el trabajo

3. Retrasos o tiempo invertido esperando por algo

4. Entregas de una persona, equipo o proceso de negocio a otros

5. Requisitos detallados

6. Requisitos insuficientes

7. Comunicación lenta o deficiente

Parte de los residuos no se pueden evitar e incluso son necesarios. En términos estrictos, por ejemplo, los documentos de requisitos son irrelevantes. Una tarjeta de índice que representa un requisito no se envía al cliente, después de todo. Por consiguiente, las tarjetas de índice son residuos. La tarjeta de requisito no es propiamente la característica del producto; representa el trabajo que se debe realizar para crear la característica. La tarjeta de requisito existe para ayudar a los desarrolladores a planear detenidamente el trabajo y a realizar el seguimiento de este. Aunque la mayoría de los equipos vean esto como una práctica necesaria, es fácil identificarlo como residuos.

Si bien son necesarios algunos residuos, la mayor parte se pueden reducir, optimizar o incluso quitar. Ciertos residuos en el flujo de valor del desarrollo de software, como tardar demasiado en proteger el código, se reconocen y eliminan fácilmente. Otro desecho encontrado en los equipos de desarrollo de software, como crear documentos grandes de requisitos antes de que el desarrollo pueda iniciarse, se considera una referencia cultural y requiere un esfuerzo significativo y tiempo para cambiar desde los fundamentos.

Escenario

Scrum tiene seis meses de vida. Los equipos de desarrollo están produciendo incrementos operativos de software con cada sprint de dos semanas y todos los indicadores de calidad medidos indican una tendencia positiva.

Método Lean

Los expertos en Scrum se reúnen para discutir cómo preparar a sus equipos para conseguir una productividad y una calidad más altas. Un ScrumMaster sugiere eliminar desechos según lo indicado en Lean Thinking. Los maestros del Scrum acordaron probar la idea y buscar ejemplos de desechos para categorizarlos en dos listas: los que pueden ser eliminados inmediatamente y los que requieren tiempo para administrar.

La primera lista contiene residuos que eliminarán los propios expertos en Scrum o los equipos de desarrollo, y no requiere ningún permiso ni espera. El otro se etiqueta “Trabajo pendiente de residuos” e identifica los residuos presentes reconocidos por todos pero que llevará mucho tiempo o esfuerzo cambiar. Los ejemplos de las dos listas se muestran a continuación:

Tratar inmediatamente

Trabajo pendiente de residuos

Algunas compilaciones se realizan manualmente en un equipo de compilación que debe mantenerse especialmente para este fin. El empaquetado del sitio web es un proceso ZIP manual. Automatice esto. Los desarrolladores usan todos una base de datos de desarrollo compartida y los cambios en los datos con frecuencia interrumpen la evolución del desarrollo. Desplácese a un modelo donde cada desarrollador tenga una base de datos dedicada de desarrollo. Las pruebas no se escriben hasta que exista una característica. Fomentar y mostrar prácticas de pruebas iniciales a los especialistas en pruebas.

Los modelos UML creados antes de codificar todas las características. Comunicación dificultada por el diseño de la oficina que requiere que los miembros del mismo equipo de desarrollo vayan de una oficina a otra para mantener pequeñas reuniones. Incorpore instaladores donde sea posible de modo que la implementación no sea manual en las operaciones. Muchos campos en el sistema de informes de seguimiento de errores son necesarios y se usan en raras ocasiones. Se puede ahorrar el tiempo empleado creando datos para estos campos haciéndolos opcionales.

Con estas listas, los expertos en Scrum se dirigen a sus respectivos equipos de Scrum con sugerencias procesables para obtener mejoras inmediatas. Aunque los expertos en Scrum entrenen a los equipos para alcanzar niveles de calidad más altos, la naturaleza de organización propia de los equipos de Scrum exige a los equipos valorar los cambios y crear un plan para que surtan efecto.

La reunión retrospectiva del sprint es un foro dedicado a compartir ideas de mejora y a obtener apoyos para ponerlas en práctica. Las reuniones retrospectivas de Sprint a menudo resultan en planes instaurar mejoras, según Kaizen. Eliminar o mejorar los desechos detectados en el trabajo pendiente puede requerir trabajo adicional fuera del equipo de Scrum. Esto es responsabilidad del experto en Scrum, cuyo trabajo incluye la mejora del uso de Scrum y fomentar la agilidad en toda la organización.

Limitar el trabajo en curso

Escenario

Un equipo de desarrollo con cinco miembros ha estado usando Scrum por 12 semanas, completando tres Sprints cuatrisemanales con resultados mixtos. Si bien los incrementos que se generan tienen más calidad que el software creado antes de implementar Scrum, parece que se hace menos trabajo y que los miembros del equipo de desarrollo todavía no colaboran en su trabajo. El Scrum diario proporciona un recordatorio diario de que cada persona del equipo está trabajando de forma aislada en sus propias tareas, aunque la situación no parece mejorar.

Durante la planeación del Sprint, el equipo de desarrollo crea una lista de tareas pendientes necesarias para entregar cada elemento de trabajo pendiente del producto seleccionado para el Sprint. Esta técnica crea una lista de trabajo pendiente del Sprint durante la planeación del Sprint, y un mecanismo para seguir el progreso del equipo de desarrollo en el Sprint.

El equipo de desarrollo utiliza un panel de tareas visible en el muro del área de trabajo del equipo de desarrollo para seguir su progreso en el sprint. Durante el anterior Sprint, el ScrumMaster tomó fotografías del comité cada día antes del Daily Scrum. Algunas de las fotografías se muestran debajo.

Día 1	Día 4
Día 9	Día 14
Día 17	Día 20

El experto en Scrum compartió estas fotografías con el equipo de desarrollo. Algunas cosas eran obvias, como:

• Hay más tareas periódicamente en progreso que miembros hay en el equipo de desarrollo.

• El día dos, un desarrollador extrajo todas las tareas para la Característica C en el estado “En curso” y las dejó allí durante todo el Sprint.

• La característica B no se trabajó hasta que finalizó el Sprint y no se completó.

• La característica C se trabajó durante el Sprint pero no se completó. El desarrollador que trabaja en la característica C se frustró por falta de ayuda cuando surgieron problemas desconocidos. A pesar de su sugerir sutilmente en el Daily Scrums que agradecería alguna ayuda, nunca se materializó, porque los otros miembros del equipo estaban centrados en su propio trabajo y no se sentían responsables por la Característica C.

• Las características se colocaron en el trabajo pendiente del Sprint ordenadas según prioridad durante la planeación del Sprint y el propietario del producto estaba muy decepcionado porque no se había completado la características B en el Sprint, ya que estaba clasificada delante de otras características que se entregaron.

• Había varias características en curso al mismo tiempo, haciendo que partes muy diferentes del código cambiasen al mismo tiempo. Durante el Sprint, esto condujo a varios errores de compilación y a una revisión del trabajo ya que los desarrolladores, sin saberlo, se afectaron entre sí.

Todas estas observaciones nos llevan de nuevo a la práctica del equipo de desarrollo de trabajar en muchas cosas a la vez. Cambiar de una tarea a otra e intentar concentrase en muchos elementos al mismo tiempo dio como resultado que los miembros del equipo de desarrollo se sintieran sobrecargados y desbordados por el trabajo en el trabajo pendiente del sprint. Por consiguiente, cada miembro del equipo se pudo centrar en su propio trabajo y actuar como individuo más que como un miembro de un equipo.

Método Lean

Durante la reunión retrospectiva del Sprint, el ScrumMaster explicó la idea de limitar WIP al equipo de desarrollo que decidió probar la técnica. El equipo de desarrollo decidió aplicar tres nuevas reglas diseñadas para reducir WIP en el sprint siguiente:

1. Las características del trabajo pendiente del Sprint se implementaron en orden descendente.

2. No puede haber más de 3 elementos en curso al mismo tiempo. Si un cuarto elemento se pone en marcha, el equipo hará una pausa para determinar por qué hay un cuello de botella en el sistema.

El experto en Scrum tomó imágenes de nuevo en el transcurso del siguiente sprint. Algunas de las fotografías se representan a continuación.

Día 2	Día 8
Día 12	Día 20

Durante la reunión retrospectiva del Sprint, las fotografías se compartieron de nuevo con el equipo de desarrollo que hizo las observaciones siguientes sobre cómo las cosas habían cambiado para ellos durante este último Sprint:

1. Los miembros del equipo de desarrollo colaboraron en elementos más complejos. Aunque las opiniones sobre cómo hacer el trabajo en ocasiones so distintas, las diferencias se resolvieron y el equipo progresó más rápido globalmente.

2. Los miembros del equipo de desarrollo comenzaron a aprender a cerca de la funcionalidad, en la que no se habían centrado previamente. Cada uno registró un sentimiento de propiedad colectiva respecto al producto en su conjunto. Esto se puso claramente de relieve frente a las prácticas anteriores de las personas que solo se concentraban en características que entendían.

3. La complejidad de la coordinación de cambios en varias áreas diferentes del código al mismo tiempo se redujo drásticamente. Tanto es así que, de hecho, la productividad del equipo de desarrollo aumentó notablemente.

4. Aunque la característica E no se completa en el Sprint, todas las características que se entregaron tenían una prioridad mayor que la característica E. El propietario del producto estaba encantado y decidió enviar el incremento al cliente incluso sin esta característica de prioridad baja.

Aunque crear un trabajo pendiente del Sprint durante la planeación del Sprint limite el tamaño de lote de trabajo seleccionado para el Sprint, una limitación del WIP adicional dentro del Sprint puede provocar un rendimiento más rápido y una productividad mayor. La limitación del WIP durante el Sprint también aumenta la colaboración y reduce el riesgo de tener a especialistas técnicos cuyo trabajo otros no comprenden.

Reducir los tiempos de espera

Se invierte mucho tiempo en esperar a que pasen cosas en el desarrollo de software. Este tipo de residuos se encuentra fácilmente en la mayoría de los equipos de desarrollo. Los nuevos equipos de Scrum esperan a que pasen muchas cosas durante un Sprint, incluso:

• Permiso para hacer algo

• Proceso largo a completar

• Entrega de otro equipo o individuo

• Las pruebas que se ejecutarán o la validación que se completará

• Obtener acceso a un recurso necesario

• La cooperación de una persona no perteneciente al equipo

Peor que las ineficiencias de esperar a los equipos Scrum es el tiempo que los clientes y las empresas pasan esperando a que se integre, empaquete y envíe el software. Este problema aumenta con el tamaño de la organización de desarrollo. Cuantos más desarrolladores o equipos se agreguen a un proyecto, el costo de integrar su trabajo en mejoras individuales de un producto aumenta.

El tiempo de espera más largo compilado en Scrum es el sprint. Al ser el contenedor para todos los eventos de Scrum, el único requisito de la duración del Sprint es que sea un mes o menos. Esto limita a no más de un mes el tiempo que se espera para obtener un incremento de software que funcione. La mayoría de los equipos de Scrum entregan incrementos que funcionan con más frecuencia.

Escenario

Una compañía tiene seis equipos Scrum que trabajan en un producto de software grande y complejo. Cada equipo de Scrum se centra en un área de la característica específica y el trabajo se coordina a través de un trabajo pendiente del producto principal. Los sprints duran tres semanas e incluyen la integración del trabajo de todos los equipos de desarrollo.

Previamente, los Sprints duraban dos semanas, pero cuando el producto creció también creció la complejidad para crearlo. Se agregaron nuevos equipos de Scrum, que necesitaron más tiempo para integrar su trabajo, por lo que la longitud del Sprint se incrementó para alojar las actividades de integración.

La semana tres ahora se conoce coloquialmente como semana de integración. La integración de nuevas características en la línea de código principal es la actividad principal durante este tiempo. Un equipo de integración se establece cada semana de integración con representantes de cada equipo de desarrollo. Dirigen el trabajo de las actividades de integración.

El equipo de integración no acepta nuevas características durante la semana de integración, aunque sí solicita pequeños cambios en los problemas de integración de direcciones. Esto produce una oleada de cambios ad hoc en el código durante la semana de integración en respuesta a las necesidades del equipo de integración.

El gráfico siguiente muestra la administración de configuración típica durante un sprint. Los equipos de desarrollo crean sus propias bifurcaciones de desarrollo al principio de cada Sprint. Combinan el código al final de la semana 2. Durante la semana 3, el equipo de desarrollo se ocupa de las solicitudes del equipo de integración según se necesita.

Si bien la integración durante el Sprint es necesaria, actualmente se está usando un tercio de la capacidad de los seis equipos Scrum para realizar la integración. Durante ese tiempo, gran parte de la capacidad de los equipos se emplea en actividades fuera del Sprint. Observe que en el ejemplo anterior, el equipo 5 no tiene ningún trabajo en absoluto durante la semana de integración.

Aumentar el costo de la semana de integración sería la interrupción de flujo en los equipos de Scrum que deben cambiar a menudo de contexto. Algunos equipos están bifurcando líneas de código de forma privada en un intento de ser productivos durante toda la semana, aumentando la complejidad total y sacrificando la transparencia necesaria para tomar buenas decisiones.

Método Lean

Los expertos en Scrum de los equipos se reúnen para discutir las opciones. Un ScrumMaster indica que su equipo le han salido muy bien las cosas a la hora de restringir WIP durante las primeras dos semanas de cada Sprint. Los expertos en Scrum observan que si cada equipo limita WIP a una característica al mismo tiempo, este podría integrar su trabajo a medida que se completa cada característica.

Si esta práctica se usase en todos los equipos de desarrollo, ningún equipo esperaría hasta el final de la semana dos para mostrarse desagradecido con su trabajo. En lugar de esperar para integrar características nuevas, cada equipo podría ahora considerar la integración en la parte principal de la línea de código de la definición de Finalizado1 para cada característica en la que funciona.

La definición de "terminado" es un concepto de Scrum en el que los equipos de desarrollo acuerdan lo que debe cumplirse para que cada elemento de trabajo pendiente del producto seleccionado se considere “terminado”. Para obtener más información sobre la definición de "terminado", vea el artículo de MSDN Tareas realizadas y no realizadas.

Durante la siguiente reunión retrospectiva del Sprint, los equipos de desarrollo acordaron la integración de su trabajo según se completaba cada característica. Establecen y se comprometen a cumplir las nuevas reglas siguientes:

1. Cada equipo de desarrollo limita WIP a una característica de cada vez.

2. Una característica no se completa hasta que se integra en la línea de código principal.

3. Antes de empezar a trabajar en una nueva característica, los equipos de desarrollo actualizarán las líneas de código con una nueva copia de la línea principal.

La actividad resultante se representa en el gráfico siguiente:

Las nuevas reglas han provocado que los equipos experimenten un flujo más uniforme en la entrega de características. Los equipos de desarrollo ya no tienen que estar inactivos e interrumpir su labor en la semana tres del Sprint ya que no hay semana de integración.

El tiempo que se tarda en integrar los cambios durante el sprint es mayor al principio, pero a medida que aumenta la familiarización con el modelo de integración continua, aumenta la productividad de cada equipo de desarrollo. Con el tiempo, las características agregadas por Sprint aumentan.

Ya que cuando se finaliza una tarea con una característica ahora indica que esa característica esta integrada en la línea de código primario, ya no existe duda alguna si una característica se ha completado realmente. La definición de "terminado" ahora incluye integración con el código principal para cada característica individual. El riesgo de no poder realizar la integración se reduce considerablemente.

Finalmente, la decisión de reducir el tiempo que un equipo de desarrollo debe esperar para integrar código ha aumentado la productividad total de los equipos de desarrollo y ha hecho que la semana de integración no se use. Así, los equipos Scrum pueden volver a realizar sprints más cortos, lo que permite al propietario del producto hacer entregas incluso más a menudo si es necesario.

Compromiso de aplazamiento

El compromiso de aplazamiento es uno de los principios iniciales de Lean expresado como valor de Lean Software Development. Este principio a menudo se describe como “esperar hasta el último momento responsable” para tomar una decisión.

Tomar una decisión que nos compromete prematuramente a una línea de acción tiene poco o ningún valor, por lo que la reflexión continúa. ¿Por qué no esperar hasta que la decisión deba tomarse, de forma que se conozca la mayor cantidad de información posible sobre el problema? Esto limita el riesgo de tomar la decisión incorrecta y da tiempo para que surjan incluso más opciones o rutas de acción.

Escenario

Durante la planeación del Sprint, el equipo de desarrollo crea planes detallados sobre cómo implementar los PBI seleccionados para el Sprint. A menudo, el plan cambia durante el Sprint según se va obteniendo más información. Observan que, cuando el trabajo está menos claro, el plan cambia aún más. Sabiendo que los requisitos no usados son irrelevantes, el equipo desearía evitar tener que revisar esta planeación.

Confirmar un curso de acción requiere descartar otras opciones. A menudo, esto hace que quienes son conscientes del compromiso descarten las ideas. Puede haber varias maneras de implementar una característica determinada, pero cuando se ha elegido una línea de acción, los desarrolladores pueden dejar de considerar otras maneras de abordar a un problema, y las posibilidades de innovación disminuyen.

Método Lean

El equipo de desarrollo decide permitir elementos más grandes y menos definidos en el trabajo pendiente del sprint. De hecho, deciden si un elemento de trabajo pendiente del producto se aceptará en el Sprint sin un plan detallado en absoluto.

El equipo de desarrollo espera ahora para crear el plan detallado más adelante cuando se sepa más. Para ellos, esto significa desglosar el elemento grande del trabajo pendiente del Sprint en pequeños fragmentos cuando el trabajo realmente comenzando o en curso. Esto aplaza la planeación detallada hasta que sea realmente necesaria y permite que el equipo cambie de opinión sobre la implementación en un momento más cercano al punto del trabajo. También garantiza que se usa el plan mejor en lugar de ejecutar un plan que es posible que ya no sea válido.

Esto da lugar a una mejor comprensión de las opciones de implementación cuando llega el momento de implementar la característica. El equipo de desarrollo ha aprendido más sobre el producto durante el tiempo que implementó características anteriores en el sprint, y ha especificado un plazo de tiempo para la investigación si fuera necesario.

Visualizar el flujo de trabajo

El primer paso del método Kanban requiere la visualización de flujo de trabajo real utilizado por un equipo. Esto hace realidad el principio “ver el todo” de Lean y requiere que se vea el flujo de trabajo, no una versión idealizada prescrita por un documento de proceso de negocio o algún otro modelo existente. Una visión útil representa lo que realmente ocurre.

Una vez haya visualización, se podrá llevar un seguimiento del trabajo con ella. Un modelo de ejemplo de un proceso de desarrollo de fases controladas o en cascada se muestra a continuación con varias características en curso.

Los equipos Scrum han estado utilizando la visualización del flujo de trabajo durante años para ver el trabajo del Sprint. La forma más común de visualización del flujo de trabajo en equipos de desarrollo de Scrum es el "panel de tareas" de Scrum, o simplemente "panel Scrum". Esta visualización normalmente es más sencilla que el modelo anterior, y puede parecer similar al modelo siguiente.

Este formato típico de visualización del flujo de trabajo se ve influenciado fuertemente por la prescripción Scrum de los equipos de desarrollo multidisciplinares. El foco en los equipos de desarrollo multidisciplinares es una característica de definición del marco de trabajo del Scrum. Un equipo multidisciplinar tiene todas las funciones que necesita para entregar un incremento completo de software que funcione en cada Sprint. Los miembros del equipo realizan muchas actividades de desarrollo de software al mismo tiempo.

Los equipos multidisciplinares pueden hacer un poco de todo en el acto mientras implementan una característica juntos. Esto es muy distinto del modelo controlado por el plan, en el que los especialistas se concentran en realizar todas las operaciones de una actividad al mismo tiempo. Además, los miembros de equipos multidisciplinares pueden tener especialidades, pero todos los miembros del equipo trabajan regularmente en todas las actividades necesarias para entregar el software, independientemente de si las actividades están dentro del área de especialidad de la persona. Los equipos multidisciplinares de desarrollo de software suelen superar en rendimiento a los equipos de especialistas dedicados.

Escenario

Un equipo de desarrollo está entregando incrementos de software que funciona, pero los miembros del equipo no colaboran bien. Los codificadores trabajan en problemas de aislamiento antes de entregar código a los evaluadores que deben acometer la validación hasta el final del Sprint.

Esto deja poco tiempo para realizar pruebas al final del sprint, por lo que el equipo de desarrollo a veces se las salta y entrega el incremento con las pruebas de regresión incompletas. Se encuentran errores en producción que deberían haberse detectado antes si se hubiera dejado que finalizar la regresión funcional.

Método Lean

El experto en Scrum trabaja junto con el equipo de desarrollo para modelar el flujo de trabajo real que aparece dentro de cada sprint. Aunque el equipo utiliza un comité de Scrum típico en el Daily Scrum, pronto se hace evidente que el flujo de trabajo real es un proceso de desarrollo en fases controladas. El equipo genera el modelo siguiente para reflejar el flujo de trabajo real:

El experto en Scrum ayuda al equipo a entender el aumento potencial de productividad conseguido trabajando de forma multidisciplinar. Aunque sea dudoso, los miembros del equipo acuerdan intentar mejorar el flujo de trabajo para ser más multidisciplinares.

El equipo de desarrollo deja intacta la visualización y la utiliza para controlar el trabajo en el sprint, pero está dispuesto a buscar cada oportunidad para contraer las fases. Es decir, el equipo busca oportunidades donde se puedan combinar dos fases en una, reemplazando así una entrega con colaboración. Lo hacen poco a poco, realizando cambios deliberados en el modo en que los individuos del equipo de desarrollo trabajan conjuntamente. En cada retrospectiva de Sprint revisan el modelo para reflejar las mejoras llevadas a cabo por el equipo.

Primero, Arnie y Kyle acuerdan colaborar en la combinación de diseñar y codificar fases. Prueban varias técnicas para mejorar su colaboración y pronto descubren que su flujo de trabajo ha cambiado al siguiente:

Este equipo de desarrollo conoce pronto la creación de pruebas de regresión funcionales que no se superan antes de implementar el código, lo que provoca los cambios siguientes:

Durante los meses próximos, el equipo de desarrollo buscará oportunidades de reducir el número de fases en la canalización de la entrega. La cultura del equipo cambia realmente a medida que los especialistas comparten sus conocimientos y todo el mundo echa una mano para que el trabajo fluya sin problemas por el equipo. Los miembros del equipo empiezan a considerarse a sí mismos “generalistas especializados” a medida que aumenta la colaboración.

Cuando la colaboración en el equipo aumenta, también lo hace el conocimiento colectivo sobre el software que se está creando y la información detallada de los miembros del equipo en las responsabilidades de cada uno. Esta colaboración contrae naturalmente las fases de trabajo durante el sprint y se refleja en una visualización más simple del flujo de trabajo que se produce dentro del Sprint. El equipo de desarrollo es ahora multidisciplinar y ve su flujo de trabajo real en consecuencia, como se explica a continuación.

La reflexión iterativa del equipo sobre la eliminación de fases del proceso produjo finalmente las prescripciones del Scrum de flujo de trabajo en primer lugar, una sola fase de desarrollo de En curso. Esto muestra cómo un panel Kanban totalmente optimizado en última instancia se muestra como un panel Scrum tradicional.

Compilar integridad en

Muchas técnicas de creación de software se centran en compilar la integridad en el proceso de creación. Los modelos de diseño de software, técnicas de desarrollo de pruebas en primer lugar, la refactorización y la programación entre iguales buscan aumentar la calidad del software en el momento de su creación. El uso de técnicas que aumentan la calidad en las fases más tempranas del proceso de creación garantiza que los equipos no se basan en una comprobación de calidad tras la finalización de la tarea para "probar la calidad más tarde”.

Escenario

Un equipo de desarrollo ha experimentado con técnicas de desarrollo probadas por vez primera y usa correctamente expresión Given/When/Then de los criterios de aceptación en pruebas unitarias creadas por los desarrolladores durante el desarrollo.

Formato de los criterios de aceptación Given/When/Then
Dado <cierto contexto inicial> Cuando <sucede algo> Entonces <este es el resultado>

El equipo tiene una buena serie de conjuntos de pruebas unitarias legibles que los desarrolladores usan como guía de diseño y para comprobar el código con frecuencia mediante un agente de prueba automatizada.

Aunque este enfoque funciona en el nivel de prueba unitaria, los especialistas de pruebas en el equipo de desarrollo siguen usando documentos de Microsoft Word para crear criterios de aceptación para pruebas funcionales. Se validan manualmente después de escribir el código de las características y completarlas. Dado que estas pruebas no se ejecutan hasta que los codificadores piensen que una característica se ha completado, los especialistas de pruebas detectan un número significativo de defectos. Esto provoca que sea necesario repetir trabajo en el sprint y a veces da lugar a que no se completen características antes de la revisión del sprint.

Método Lean

Durante la discusión del flujo de trabajo de los criterios de aceptación en la reunión retrospectiva del sprint, el equipo de desarrollo decide probar lo siguiente:

1. Los especialistas de pruebas crearán criterios de aceptación no como documentos de Microsoft Word, sino como pruebas automatizadas no superadas que no tienen implementación interna.

2. Las nuevas pruebas automatizadas se ejecutarán a diario a las 5 a.m. y a las 3 p.m., generando un informe con las pruebas superadas y las no superadas. Las pruebas creadas recientemente siempre fracasan.

3. Cuando los programadores seleccionan una nueva característica para trabajar en ella, comienzan implementando la funcionalidad de la matriz de la prueba de aceptación.

4. El programador puede mejorar la prueba, pero en colaboración con el especialista de pruebas que la creó, con objeto de que se conserve el propósito original de la misma.

5. La característica no está completa hasta que se supera la prueba.

6. Todas las pruebas deben pasar al final del Sprint.

Después de que un par de Sprints con esta técnica, disminuyen los defectos y las repeticiones del trabajo. El equipo de desarrollo supervisa el informe actualizado por las series de pruebas automatizadas realizadas dos veces al día y se da cuenta de que superar o no superar las pruebas se puede mostrar como tendencia. El equipo crea un informe que se actualiza con cada serie de pruebas automatizadas. El informe muestra la tendencia de los resultados de las pruebas de aceptación superadas y no superadas a lo largo de las dos semanas del sprint. El gráfico se muestra a continuación.

El equipo de desarrollo descubre que encuentra más valor en revisar este informe en su Scrum diario que en el típico gráfico de evolución. El experto en Scrum confirma que este nuevo gráfico puede ser parte crucial del trabajo pendiente del sprint.

La Guía de Scrum especifica que el trabajo pendiente del sprint es el conjunto de elementos de trabajo pendiente del producto seleccionados para el sprint, más un plan para entregarlos. Para este equipo de desarrollo, el plan se compone ahora de pruebas de aceptación no superadas y el progreso hacia su finalización se sigue examinando la tendencia de la cantidad de pruebas superadas y no superadas. Como cuando se usan tareas en los trabajos pendientes del Sprint, se pueden agregar, eliminar o enmendar pruebas en el Sprint. La creación de una prueba determinada llevará a menudo a la implementación de la característica correspondiente en unos pocos días.

El uso de pruebas automatizadas reales como requisitos y como mecanismo de regresión funcional significa que las pruebas son los requisitos. Esto también permite ver el trabajo del sprint como una progresión de pasar pruebas automatizadas. Esta técnica de desarrollo de probar-primero ha vuelto a definir la manera en que el equipo piensa sobre el uso de Scrum y hace que la validación de requisitos se integre en el propio proceso de creación, lo que añade integridad al producto.

Muchos aspectos de los increíblemente famosos principios Lean con compatibilidad con el marco de trabajo Scrum. Según maduran y mejoran los equipos de Scrum, descubren a menudo que Lean Thinking es una herramienta eficaz para encontrar más valor en el desarrollo iterativo e incremental.

Aunque pueden surgir y desaparecer determinadas técnicas, la atención continua a las mejoras resulta crítica para mantener sanos los equipos de desarrollo de software. El marco de trabajo de Scrum es lo bastante flexible para adoptar métodos de mejora de Lean como los encontrados en Kanban. Ver Scrum a través de la lente de Lean Thinking a menudo permite conseguir una mayor calidad, una mayor productividad y menos residuos.

Optimizar deliberadamente la implementación de un Scrum de un equipo puede ser difícil. Al buscar maneras de mejorar, no deje que lo perfecto sea enemigo de lo bueno. La perfección de Scrum es mucho menos importante que aportar software con un funcionamiento de alta calidad que es valorado por los clientes, por lo que hay que centrarse primero en esas acciones que en mejorar realmente el producto.

Referencias

1. West, D. (2011). XXXXX. Forrester Research

2. Poppendieck, M. P. (2003). Lean Software Development: un kit de herramientas Agile. Addison-Wesley Professional.

3. Anderson, D. (2010). Kanban: un buen cambio evolutivo para su negocio tecnológico. Presione el hueco azul.