Share
Si bien el objetivo principal de Scrum es la organización y la gestión de proyectos., Apoyarse es más sobre la optimización de procesos para producir rápidamente productos de calidad. Puede ser su primer paso hacia la adopción de principios ágiles, o puede ser algo en lo que su equipo evolucione, cuando Scrum no es suficiente. Los invito a leer la historia de mi equipo y cómo evolucionamos de Scrum a un proceso de desarrollo más simple..
Lean es un conjunto de principios definidos por la industria japonesa de fabricación de automóviles en los años ochenta. El ingeniero de calidad de Toyota, John Krafcik, acuñó el término, mientras observaba los procesos y herramientas utilizados para eliminar residuos En la producción masiva de automóviles. No fue hasta 2003 que Mary y Tom Poppendieck introdujeron Lean como un proceso de desarrollo de software en su libro, Lean Software Development: An Agile Toolkit..
Mientras que Scrum es un conjunto de reglas y roles, Lean es un conjunto de principios y conceptos con un puñado de herramientas. Ambas se consideran técnicas ágiles y comparten la misma ideología de entrega rápida, al tiempo que reducen defectos y errores. Siempre enfatizo la adaptabilidad de Agile, pero no puedo ignorar el hecho de que Scrum se presenta como un conjunto obligatorio de reglas. De hecho, los fanáticos religiosos de Scrum gritaban blasfemia por no seguir las reglas de Scrum a la letra.
Lean, por otro lado, es más abierto; Sus seguidores presentan el proceso como un conjunto de recomendaciones altamente adaptables..
Alienta al equipo o compañía a tomar decisiones y se adapta a las decisiones y sorpresas diarias que enfrentan su equipo y compañía..
A medida que mi equipo maduraba y explotaba Scrum, sentimos que algunos aspectos nos frenaban. Nos convertimos en un equipo bastante disciplinado y homogéneo. Algunas reuniones ya no eran apropiadas para nosotros y comenzamos a darnos cuenta de que las reuniones diarias no eran eficientes. Aprendimos que los problemas deben resolverse más rápido y sentimos la necesidad de evitar estos procedimientos que nos frenaron..
Seguimos adelante.
Lean expone dos conceptos principales, pero las ideas centrales son: eliminar el desperdicio y mejorar el flujo de trabajo.
Si algo se va a romper, se romperá el viernes..
Cualquier cosa que se interponga en el camino de la producción es un desperdicio. Esto incluye tiempo perdido, materiales sobrantes y una fuerza de trabajo no utilizada. Los defectos en el producto final son residuos; desperdicia el tiempo para solucionarlos, desperdicia dinero para reemplazarlos y desperdicia recursos para encontrar otras soluciones.
El concepto de desperdicio se traduce muy bien en el mundo del desarrollo de software. Los desperdicios pueden ser descritos por entregas tardías, errores y programadores que no tienen nada que hacer (no confunda esto con "los programadores deben programar ocho horas al día sin pausa y youtube").
El concepto Lean de Toyota se concentra en el flujo de producción. En una planta de producción, el flujo es una cadena de procedimientos que transforman las materias primas en sus productos finales. Estos procedimientos pueden ser muy diferentes entre sí y tomar diferentes cantidades de tiempo para completarse, pero cada uno puede mejorarse para hacerlos más eficientes. Es una batalla constante para encontrar y mejorar los cuellos de botella en el proceso..
Un flujo ideal es aquel en el que cada paso requiere la misma cantidad de tiempo y esfuerzo para producir la misma cantidad de productos..
Esto no significa que cada proceso deba costar la misma cantidad de dinero, sino que cada proceso debe poder completarse con la misma facilidad..
Irónicamente, Scrum fue la herramienta que finalmente nos llevó a darnos cuenta de los residuos en nuestro proyecto. Si bien nos adherimos a Scrum puro en algunas áreas de nuestra producción, comenzamos a identificar errores y / o demoras que podríamos evitar fácilmente al adoptar un enfoque diferente..
Sabíamos poco sobre Lean en ese momento. Leímos algunos artículos sobre el tema, pero hicimos lo incorrecto y los ignoramos, porque estábamos muy concentrados en nuestro proceso Scrum. Estábamos casi convencidos de que Scrum era el Santo Grial, pero nuestra "ametralladora Scrum" comenzó a fallar. Necesitábamos abrir nuestras mentes.
Para el desarrollo de software, los principios de Lean se adaptaron a los siguientes siete.
El cambio de Scrum a Lean fue realmente liberador..
En el desarrollo de software, puede encontrar y eliminar el desperdicio al reconocer las cosas que deben mejorarse. En un sentido pragmático, todo lo que no sea un valor directo para el cliente es un desperdicio. Para proporcionar algunos ejemplos: el desperdicio es un error, un comentario en el código, una función no utilizada (o que se usa raramente), equipos que esperan en otros equipos, reciben una llamada personal ... entienden la idea. Todo lo que lo retenga a usted, a su equipo o a su producto es un desperdicio, y debe tomar las medidas adecuadas para eliminarlo..
Recuerdo que uno de nuestros problemas era la necesidad frecuente de reaccionar más rápido que dos sprints. Desarrollar en los sprints y respetar las reglas de Scrum le prohíbe cambiar las historias asignadas al sprint actual. Un equipo necesita adaptarse cuando un usuario encuentra un error y necesita una solución, o cuando el cliente más importante desea una característica que se pueda completar fácilmente en dos días. Scrum no es lo suficientemente flexible en estos casos.
Dar un alto valor a la educación..
Tienes residuos y, naturalmente, quieres menos residuos en el futuro. Pero ¿por qué hay residuos? Es más que probable que provenga de un miembro del equipo que no sepa cómo abordar un problema en particular. Está bien; nadie lo sabe todo Dar un alto valor a la educación..
Identifique las áreas que necesitan la mayor mejora (en cuanto al conocimiento) y comience a entrenar. Cuanto más sepa usted y su equipo, más fácil será reducir el desperdicio..
Por ejemplo, el aprendizaje de Test Driven Development (TDD) puede reducir la cantidad de errores en su código. Si tiene problemas con la integración de módulos de diferentes equipos, puede aprender qué Integración continua Medios e implementar una solución adecuada..
También puede aprender de los comentarios de los usuarios; Esto le permite aprender cómo los usuarios usan su producto. Una función de uso frecuente solo puede ser accesible navegando a través de cinco menús. Eso es un signo de desperdicio! Inicialmente, puede culpar a los programadores y diseñadores (y puede que tenga razón), pero los usuarios tienden a usar su software de una forma que nunca pretendió. Aprender de sus usuarios ayuda a eliminar este tipo de desperdicio. También le ayuda a eliminar los requisitos incorrectos o incompletos. Los comentarios de los usuarios pueden conducir un producto en rutas que nunca hubieras considerado.
En algún momento, mi equipo identificó que ciertos módulos podrían haberse escrito mejor si hubiéramos sabido más sobre el dominio al principio. Por supuesto, no hay manera de retroceder el tiempo, y reescribir una gran parte del código no es práctico. Decidimos invertir tiempo para aprender sobre el dominio cuando se le asignó una función más compleja. Esto puede requerir algunas horas o incluso semanas, dependiendo de la complejidad del problema.
Cada decisión tiene un costo. Puede que no sea inmediato y material, pero el costo está ahí. La postergación de decisiones lo ayuda a prepararse por completo para los problemas que debe enfrentar. Probablemente el ejemplo más común de decisión demorada es con el diseño de la base de datos.
Las decisiones no tienen que ser de naturaleza técnica; la comunicación con los clientes lo ayuda a tomar decisiones que afectan la forma en que aborda las características de sus productos.
Pero los usuarios no siempre saben lo que quieren. Al aplazar las decisiones de funciones hasta que los usuarios realmente necesiten la función, tendrá más información sobre el problema y podrá proporcionar la funcionalidad necesaria..
Elija la metodología Agile que mejor se adapte a usted y a su equipo..
Hace catorce años, el equipo tomó la decisión de almacenar la configuración de la aplicación en una base de datos MySQL. Tomaron esta decisión al comienzo del proyecto, y ahora el equipo actual (mi equipo) tiene una carga difícil de llevar. Afortunadamente, ese producto ya no está en desarrollo activo, pero aún tenemos que mantenerlo de vez en cuando. Lo que debería ser una tarea sencilla termina siendo un monumento monumental..
En el lado positivo, aprendimos de los errores de nuestros predecesores. Tomamos decisiones de programación, arquitectura y proyectos lo más tarde posible. De hecho, aprendimos esta dura lección antes de adoptar Lean. Escriba código abierto y desacoplado, y escriba un diseño que sea persistente y de configuración independiente. Sin duda, es más difícil de hacer, pero al final te ahorra mucho tiempo en el futuro..
Hace algún tiempo, agregamos una característica a nuestro producto que comprime los datos en el disco. Sabíamos que sería útil y queríamos agregarlo a nuestro producto lo más rápido posible. Comenzamos con una funcionalidad simple, evitando decisiones sobre opciones y configuración hasta un momento posterior. Los usuarios comenzaron a proporcionar comentarios después de unos meses, y tomamos esa información para tomar nuestras decisiones sobre las opciones y la configuración de la función. Modificamos la función en menos de un día, y ni un solo usuario se ha quejado o solicitado más funcionalidad. Fue una modificación fácil de hacer; Escribimos el código sabiendo que haríamos una modificación en el futuro..
Vivimos en un mundo en constante cambio. Los programas que escribimos hoy son para computadoras que estarán obsoletas en dos años. La ley de Moore sigue siendo válida, y seguirá siéndolo..
La velocidad de entrega es todo en este mundo acelerado.
La entrega de un producto en tres años lo pone detrás del paquete, por lo que es muy importante dar valor a sus clientes tan pronto como sea posible. La historia demostró que un producto incompleto con una cantidad aceptable de errores es mejor que nada. Además, tienes un valioso comentario de los usuarios..
Nuestra empresa tuvo un sueño: entregar después de cada sprint. Naturalmente, eso es poco práctico en la mayoría de los casos. Nuestros usuarios no querían un producto actualizado cada semana o mes. Entonces, mientras nos esforzamos por lanzar cada versión de nuestro código, no lo hacemos. Aprendimos que "rápido" es lo que el usuario percibe, no lo que somos físicamente capaces de hacer. En la industria de nuestros productos, rápido significa actualizaciones regulares cada pocos meses y correcciones de errores críticos en cuestión de días. Así es como nuestros usuarios perciben "rápido"; Otros tipos de productos e industrias tienen diferentes definiciones de "rápido".
Los programadores solían ser recursos encerrados en cubículos, realizando silenciosamente sus tareas para su empresa. Esta fue la imagen prominente de un programador a fines de la década de 1990, pero ciertamente ya no es el caso..
La historia demuestra que ese enfoque y la gestión tradicional de proyectos en cascada no son adecuados para el software.
Fue tan malo en un momento que solo alrededor del 5% de todos los proyectos de software fueron entregados. Los negocios y productos de millones de dólares fallaron el 95% del tiempo, lo que provocó enormes pérdidas.
Lean identificó que los programadores desmotivados causaron ese desperdicio. Pero ¿por qué la falta de motivación? Bueno, los programadores y los equipos de desarrollo no fueron escuchados. La empresa estableció tareas y microgestionó a los empleados que solo eran vistos como recursos que producen código fuente..
Lean alienta a los gerentes a escuchar a los programadores, y los alienta a enseñar a sus gerentes el proceso de producción de software. También alienta a los programadores a trabajar directamente con clientes y usuarios. Esto no significa que los desarrolladores hagan todo, pero sí les da el poder de influir en la evolución de la producción. Sorprendentemente, teniendo ese sentimiento de "¿Sabes esa gran característica que les encanta a los usuarios? Fue mi idea!"es un gran factor motivacional.
Pero no creas que esto solo funciona para equipos grandes; nuestro equipo es pequeño Nuestra empresa tiene solo unos pocos desarrolladores, por lo que siempre hemos estado cerca de nuestros usuarios. Esa relación nos ha permitido influir en nuestro producto más allá de lo que nuestros gerentes pudieron haber previsto inicialmente.
Todo lo que se interpone en el camino de la producción es un desperdicio..
La integridad tiene que ver con la solidez de su producto, y es cómo los clientes ven su producto como un todo. La integridad tiene que ver con la uniformidad de la interfaz de usuario, la confiabilidad y la seguridad, y el usuario se siente seguro con su producto. La integridad es la imagen completa que el usuario crea para su producto. Por ejemplo, la integridad de la interfaz de usuario implica la apariencia entre páginas, pantallas, módulos o incluso entre la interfaz de usuario de su sistema y el sitio web de la empresa..
Pero la integridad también se puede observar y practicar en el nivel del código fuente. La integridad puede significar que sus módulos, clases y otras piezas están escritas de manera similar. Utiliza los mismos principios, patrones y técnicas en toda su base de código, incluso entre diferentes equipos. La integridad significa que tienes que refactorizar tu código con frecuencia. Es un trabajo continuo e interminable, y debes esforzarte por conseguirlo, pero nunca alcanzarlo..
Mantener la integridad en nuestro código fuente es una tarea difícil. Nos dimos cuenta de que encontrar el código duplicado es lo más difícil y, por duplicado, no me refiero a un par de líneas de código duplicado en el mismo método o clase..
Ni siquiera se trata de buscar en diferentes módulos exactamente el mismo código; se trata de encontrar esas piezas de lógica común, extraerlas en sus propias clases y usarlas en varios lugares.
Encontrar la duplicación lógica es muy difícil y requiere un conocimiento íntimo del código fuente.
He estado en el mismo proyecto durante más de un año y todavía me sorprende cuando encuentro un código duplicado. Pero eso es algo bueno; llegamos a un punto en el que realmente vemos estas cosas y tomamos medidas sobre ellas. Desde que comenzamos a eliminar activamente la lógica duplicada de alto nivel, la calidad de nuestro código aumentó. Estamos un paso más cerca de lograr la integridad..
Los usuarios no siempre saben lo que quieren..
Al crear su aplicación, debe pensar en los componentes de terceros en los que confía para desarrollar su producto, así como en los otros terceros con los que su producto se comunica. Su aplicación necesita integrarse con el diseño de un dispositivo o el sistema operativo en una PC de escritorio. ¿No es más fácil usar una aplicación que se integra con el sistema de notificación de su teléfono inteligente, y la interfaz de usuario refleja la interfaz de usuario del sistema operativo??
Sí, ver el todo no es tan fácil. Tienes que separarte de los pequeños detalles y mirar tu producto desde lejos. Uno de los momentos memorables en el desarrollo de nuestro producto fue cuando nos dimos cuenta de que tenemos que confiar en lo que otros programadores producen en otros proyectos. Nos dimos cuenta de que el núcleo del sistema, programado por otros, es uno de estos componentes de terceros en los que confiamos..
En un momento dado, ese componente de terceros cambió. Podríamos haber aplicado curitas a nuestra aplicación, o podríamos haber tomado la ruta fácil y culpar a los programadores que escribieron ese componente. En su lugar, tomamos el problema por los cuernos y reparamos el problema en el núcleo de terceros. Ver todo y trabajar con él puede ser complicado, pero puede marcar la diferencia entre un producto y un gran producto..
Existen varias herramientas y técnicas para hacer que Lean funcione. Prefiero Kanban, una herramienta basada en tablero que es similar al tablero de planificación de Scrum. Imagina una tabla Kanban como un doble embudo..
A la izquierda está la lista interminable de historias que debemos abordar. Todas las historias terminadas se acumulan a la derecha, y el gerente o el propietario del producto determina cuándo publicar una nueva versión, según esta lista.
En el medio está nuestro proceso Kanban efectivo. El producto debe estar en un estado estable y listo para su lanzamiento cuando completemos una historia. Esto no significa necesariamente que se haya completado una característica; El producto puede tener algunas características parcialmente implementadas. Pero la estabilidad, seguridad y robustez del producto deben ser de calidad de producción..
Lo estábamos haciendo bastante bien con nuestro sprint actual. Era un lunes habitual, un día tranquilo con poca emoción, pero comenzamos a ver algunos problemas el miércoles. Eso está bien, sucede todo el tiempo. Superar estas dificultades, sin embargo, requirió un tiempo extra. El propietario de nuestro producto estuvo de acuerdo con nosotros para continuar trabajando en la función actual y extender el sprint actual unos tres o cuatro días adicionales.
El viernes llegó con una sorpresa. Ya sabes la regla: si algo se va a romper, se romperá el viernes. Un cliente importante y potencial requería cierta característica antes de firmar un contrato con la compañía. Tuvimos que reaccionar (y rápido!). Un nuevo lanzamiento era obligatorio ... ¡Pero espera! Estamos en medio de un sprint. El producto debe estar listo para su lanzamiento al final del sprint. qué hacemos? Scrum diría que hacer la nueva función en el próximo sprint, ¡pero ya estamos retrasados con el sprint actual! Ese fue el momento, cuando empezamos a darnos cuenta de que tenemos que pensar más pequeño que un sprint individual. Necesitamos poder adaptarnos más rápido, y debemos lanzar antes si es necesario.
Un tablero Kanban se parece bastante a un tablero de planificación Scrum, pero con algunas adiciones para adaptarse mejor al proceso Lean.
La primera columna de la izquierda es el registro completo: todo lo que necesitamos hacer en algún momento. En el extremo derecho, tiene el otro embudo, que contiene todas las historias completadas (pero no publicadas).
En el medio está nuestro proceso. Estas columnas pueden diferir dependiendo de cada equipo y proceso. Por lo general, se recomienda tener al menos una columna para las siguientes tareas y otra columna para las historias actualmente en desarrollo. La imagen anterior muestra varias columnas más para presentar mejor el proceso de desarrollo..
los Que hacer La columna enumera las tareas que debemos completar. Entonces nosotros tenemos Diseño, Donde los desarrolladores trabajan en el diseño de las historias actuales. La cuarta columna es Desarrollo, la codificación real. Finalmente, el Pruebas La columna enumera las tareas que esperan ser revisadas por otro compañero de equipo..
Nadie lo sabe todo.
Si compara este tablero Kanban con un tablero de planificación scrum, notará inmediatamente las diferencias obvias. Primero, cada columna tiene un número, que representa el número máximo de historias que pueden residir en esa columna. Tenemos cuatro tareas pendientes, cuatro en diseño, tres en desarrollo y dos en pruebas. El backlog y las tareas completadas no tienen dicho límite..
El valor de cada columna debe ser definido por el equipo. En la imagen de arriba, asigné números arbitrarios a las columnas; sus números pueden diferir significativamente Además, los números no son definitivos. Adapta los números cuando identifiques y elimines cuellos de botella..
Una de las cualidades más sorprendentes de Kanban y Lean es la importancia de la colaboración y la reasignación de esfuerzos. Como puede ver en la pizarra, cada columna de nuestro proceso contiene tarjetas con personas en ellas. Hay ocho desarrolladores en el panel de ejemplo, ¡un equipo bastante grande! La junta siempre presenta el estado actual de quién está haciendo qué en un momento dado.
Según nuestro consejo, hay tres personas que trabajan en diseño, dos pares que trabajan en desarrollo y una prueba de desarrollador. Las historias se mueven a la siguiente columna, su trabajo en la columna actual está completo y, dependiendo del tipo de desarrollo y organización del equipo, el mismo desarrollador puede continuar trabajando en la misma historia a medida que avanza el proceso..
Supongamos que tenemos personas especializadas. Por lo tanto, la función principal de los tres diseñadores es el diseño, los cuatro desarrolladores escriben el código y el probador solitario principalmente prueba el producto / característica. Si un diseñador termina una historia, la historia pasa al desarrollo y otra historia de la lista de tareas pendientes se pone en el diseño..
Este es un proceso normal. Se trasladó una historia del diseño al desarrollo, y ahora el desarrollo está en su máxima expresión. Pero ¿y si otro diseñador termina otra historia? Eso le da al equipo de desarrolladores cuatro historias: una situación no deseada.
Lean quiere evitar la congestión. Está prohibido mover una historia a la siguiente columna si excede el máximo de la columna. En este caso, los recursos deben ser reasignados; El diseñador que terminó su tarea debe elegir qué hacer a continuación. Su primera opción es sacar otra tarea de la columna de tareas pendientes, pero no puede hacerlo porque necesita pasar su tarea recién terminada al equipo de desarrollo (lo que no puede hacer). Su única otra opción es comenzar a trabajar en una historia de desarrollo. Puede que no sea el mejor desarrollador, pero sus esfuerzos ayudarán a mantener el flujo del proceso.
Si el probador termina la última historia en su columna, podría ayudar al diseñador en su tarea de desarrollo.
¡Esto es genial! El equipo puede reorganizarse sobre la marcha! ¿Ves un desperdicio? ¿Ves un cuello de botella en el flujo? Tomar acción inmediata!
Una vez que se completa una historia en la columna de desarrollo, el probador vuelve a probar, el diseñador a diseñar y los desarrolladores recogen la historia en la que estaban trabajando el diseñador y el probador. Pero tenga en cuenta que no tiene que seguir esa receta exacta; el desarrollador podría comenzar a diseñar a medida que el diseñador y el probador terminaron de desarrollar su historia. Tu decides!
Nuestra tabla ha vuelto a la normalidad..
Está prohibido mover una historia a la siguiente columna si excede el máximo de la columna..
Vi con nostalgia como nuestro maestro de scrum desmontó nuestro tablero. Pieza a pieza, derribó nuestra amada tabla, que luego se convirtió en una montaña de papel arrugado..
Otro colega entró en la habitación, con unas enormes hojas de papel blanco fresco en sus manos. Nuestra junta directiva estaba a punto de renacer en algo diferente, algo mejor adaptado a nuestras necesidades. Después de que las hojas de papel estuvieran en la pared, comenzamos una reunión ad hoc para definir las columnas que necesitábamos para definir nuestro proceso. Luego debatimos la cantidad de historias que deberían estar en cada columna. Después de que todo estuviera cuidadosamente pintado y dispuesto en la pared, experimentamos esa sensación extraña ... tristeza por lo viejo pero felicidad por lo nuevo..
Hicimos algo que mucha gente llama, Scrum-Ban. Mantuvimos algunos conceptos de scrum, como los roles de scrum master y de propietario de producto, y aún estimamos y evaluamos las historias. Pero ahora nos centramos en Lean y Kanban, preservando el flujo y descubriendo y solucionando desperdicios y cuellos de botella..
El cambio de Scrum a Lean fue en realidad liberador. Los miembros del equipo se volvieron mucho más amistosos entre sí, y comprendimos que deberíamos ofrecer ayuda tan pronto como no haya nada en nuestra columna. Esta sensación de que los desarrolladores son importantes nos hizo pensar en el proyecto en su conjunto; Nos preocupamos más por el proyecto que nunca antes..
Lean no siempre fue considerado ágil. Incluso hoy, algunos agilistas se niegan a reconocerlo como una metodología ágil. Pero cada vez más, los programadores aceptan Lean como una de las mejores metodologías ágiles..
Como señaló uno de mis sabios colegas, Lean y Kanban le permiten seguir esta metodología por su cuenta. Entonces, si eres un desarrollador solitario y necesitas algunas herramientas para hacer tu vida más fácil, prueba algunas herramientas Kanban gratuitas.
El sitio web de AgileZen ofrece una cuenta gratuita, que le permite rastrear un solo proyecto.
Encontré que es una de las mejores herramientas de Kanban en línea gratuitas; Incluso lo uso todos los días para rastrear y planificar el progreso de los artículos y cursos que ofrezco para Tuts +. Por supuesto, siempre puede actualizar su cuenta de AgileZen, si necesita realizar un seguimiento de más proyectos.
En este artículo, revisamos Lean y Kanban como una evolución de Scrum. ¿Significa esto que Lean es mejor que Scrum? ¡Absolutamente no! Depende de los proyectos y de las personas con las que trabajes. Como siempre, elija la metodología Agile que funcione mejor para usted y su equipo..
Accentsconagua