¿Cómo se lanza a menudo con Lean/Kanban?

Question

Soy bastante nuevo en Lean/Kanban, pero he recurrido a recursos en línea durante las últimas semanas y he planteado una pregunta para la que no he encontrado una buena respuesta. Lean/Kanban parece ser una buena opción para nuestra empresa, que ya está usando Scrum, pero ha alcanzado algunas limitaciones dentro de esa metodología. Espero que alguien aquí pueda darme una buena idea.

Como yo lo veo, una de las mayores ventajas de Scrum over Waterfall es el uso de sprints. Al tener todo listo cada 14 días, obtiene ciclos de retroalimentación cortos y puede lanzar a menudo. Sin embargo, como he entendido por leer sobre Lean, hay algunos costos asociados con esto (por ejemplo, tiempo dedicado a reuniones de planificación de sprints, reuniones de compromiso del equipo & algunos problemas para encontrar algo útil para todos al final de los sprints).

Lean/Kanban eliminará estos residuos, pero solo a costa de no poder liberar cada 14 días. ¿O me he perdido un punto importante? Porque, en Kanban, ¿cómo puedes trabajar en nuevas tareas de desarrollo y lanzar al mismo tiempo? ¿Cómo se asegura de que no envíe algo que está a mitad de camino? ¿Y cómo puedes probarlo correctamente?

Mis mejores "soluciones/ideas" hasta el momento son:

• No suelte a menudo y permitir que los residuos asociados con el funcionamiento de las nuevas tareas de desarrollo. Sin embargo, en realidad no es una solución a la pregunta planteada.
• Desarrollar en ramas y luego combinar en el tronco principal. Hace que tengas que admitir al menos dos ramas continuamente internamente.
• Utilice un sistema inteligente de etiquetado automático para compilar automáticamente solo ciertas tareas terminadas y otras no.

A modo de resumen, mi pregunta es: Cuando se utiliza Kanban Lean /, se puede liberar a menudo sin la introducción de los residuos? ¿O es la versión a menudo que no forma parte de Lean/Kanban?

Otros detalles específicos de mi compañía: Usamos el sistema de control de la fundación del equipo & Fuente y hemos tenido algunas malas experiencias con anterioridad en lo que respecta a la ramificación y fusión. ¿Podría resolverse esto simplemente aportando cierta experiencia en esta área?

Answer 1

El problema que describe parece más un programa de control de código fuente: cómo separar las funciones realizadas de las características en progreso que sobre Kanban. Parece que aplica una gran penalización en la ejecución de muchas ramas, que es el caso de los sistemas de control de origen que no se basan en la idea de múltiples ramas. En los sistemas de control de fuente distribuida, como GIT y Mercury, todo es una sucursal, y tenerlos y trabajar con ellos es liviano.

Supongo que leyó this blog sobre Kanban vs SCRUM, y la guía práctica asociada?

Y, en respuesta a su pregunta, sí, puede soltar a menudo con Kanban.

Answer 2

El equipo que administro utiliza Kanban y lanzamos cada dos semanas. Si eres estricto con respecto a lo que se integra en la rama de código de la línea principal (pruebas aprobadas, aprobadas por el cliente, etc.), Kanban te permite publicar cada vez que quieras.Debe asegurarse de que las historias que se mueven a través de su sistema no sean co-dependientes para hacerlo, pero en mi equipo eso generalmente no es un problema. Una gran parte de nuestro trabajo implica mantenimiento, que consiste en varias correcciones de errores no relacionadas./características por lanzamiento.

Answer 3

Para control de fuente recomiendo Perforce. Hace que la bifurcación e integración de cambios desde otras ramas sea relativamente simple, y proporciona la mejor interfaz para el control de fuente que he visto hasta ahora.

La integración continua también ayuda, es decir, una gran cantidad de compromisos pequeños, más que diarios, en lugar de fusiones enormes y potencialmente desafiantes. Herramientas como CruiseControl pueden ayudar a resaltar cuando la fuente se rompe por una mala confirmación. Además, si todos hacen muchos pequeños cambios, los cambios conflictivos serán raros.

También recomendaría no tratar de seguir cosas como Lean, scrum, kanban & co. muy de cerca. Solo resuelva los problemas usted mismo, busque estas ideas en lugar de instrucción. Es muy probable que los detalles de sus problemas requieran cierta flexibilidad para la mejor administración.

Answer 4

La forma en que manejamos los lanzamientos semanales en un proyecto de ingeniería sostenido que utilizó Kanban fue para implementar una estrategia de ramificación. Los desarrolladores trabajaron en una rama de sandbox e hicieron un checkin por artículo de trabajo. Nuestros probadores probarían el elemento de trabajo en la caja de arena; si superaba las pruebas de regresión, el checkin se migraría a nuestra rama de publicación. Bloqueamos la rama de publicación desde el mediodía del lunes hasta que se publicó el lanzamiento (generalmente el miércoles, ocasionalmente el jueves, la fecha de vencimiento fue el viernes) y volvimos a ejecutar las pruebas de regresión para todas las comprobaciones migradas, así como las pruebas de integración del producto. soltando un lanzamiento una vez que pasaron todas las pruebas.

Esta estrategia permite a los desarrolladores trabajar continuamente en problemas sin ser excluidos de sus sucursales durante el proceso de lanzamiento. También les permitió trabajar en problemas que tardaron más de una semana en resolverse; si no fue registrado y probado/aprobado, no se migró.

Si yo estuviera a cargo de Kanban para una nueva versión de un proyecto, que haría uso de una estrategia similar, pero todas relacionadas grupo confirmaciones como 'característica', migrando una característica en masa a la rama de lanzamiento una vez que la característica fue hecho y luego realizar pruebas adicionales de unidad/integración/aceptación/regresión en la rama de publicación antes de descartar una publicación con esa característica. Tenga en cuenta que un concepto clave de Kanban es limitar el trabajo en progreso, por lo que podría restringir a mi equipo para que trabaje en una característica a la vez (esto probablemente sería en varios artículos de trabajo/historias de usuario).

Answer 5

Hay más en esto que solo el control de fuente, pero su elección de TFS lo va a limitar. Cuando se concibió el proyecto Burton en 2004, Microsoft no estaba prestando atención a Agile, y mucho menos a Lean. Va a ser su enlace mecánico más débil por algún tiempo. Sus ataques deberían haber sido provocados por la adopción de Mercurial por parte de CodePlex después de haber sido ofrecidos a la comunidad de Microsoft como el poster de la implementación de TFS.

Un problema más destacado aquí es Work Design. Incluye el orden que elige para implementar las características (programa de trabajo), así como la priorización y el costo de la demora, y la forma y el tamaño de los elementos de trabajo.

Scrum se interpreta comúnmente para decir que los "Propietarios de productos" no técnicos pueden determinar el horario de trabajo basándose únicamente en sus propias preocupaciones. Si sigues este camino, vas a incurrir en un gran desperdicio al no aprovechar las oportunidades para trabajar juntos que pertenezcan juntos. El trabajo que pertenece en conjunto no puede ser determinado solo por los deseos del Dueño del Producto. Las oportunidades técnicas y de la fuerza de trabajo (habilidades) también deben tomarse en consideración.

Para que el trabajo se realice de la manera más productiva, el trabajo en sí tiene que diseñarse de esa manera. Esto significa que en un equipo de Desarrollo de Producto Lan, las decisiones no son tomadas por un trabajador no técnico, sino por lo que Toyota llama "Competencia Técnica Elevada", que está cerca del producto, cerca de los clientes y cerca del equipo .

Este papel es un marcado contraste con la proposición de Scrum. Un ingeniero jefe en un equipo Lean es él mismo la voz del cliente, y la función del propietario del producto es innecesaria.

El "propietario del producto" de Scrum es un reconocimiento de un rol subdesarrollado en las organizaciones de desarrollo de software, pero está lejos de ser una solución sostenible que evite sistemáticamente el desperdicio. El papel de "Arquitecto de software" a menudo es insuficiente, ya que en algunas subculturas de desarrolladores, el arquitecto se ha alejado demasiado del trabajo.

Sus problemas de despliegue continuo solo se tratan parcialmente con tecnología y herramientas. Observe también los problemas organizativos, y tal vez reflexione sobre el propósito de Scrum como un enfoque de transición de la cascada en lugar de uno que pueda servir a su organización indefinidamente.

Answer 6

Necesita comprender los sistemas de extracción, que es lo que Kanban está diseñado para administrar.

Una solicitud del cliente (o del propietario del producto o similar) para una función en el sistema en ejecución es lo que desencadena el proceso.

La solicitud es una señal que se envía al despliegue. Despliegue busca un elemento probado con propiedades que coincidan con la solicitud. Si no hay ninguno, escriba las pruebas y observe el desarrollo si hay un espacio de desarrollo que pueda usarse para implementar algo que cumpla con la prueba. Cuando el desarrollo ha hecho su desarrollo (tal vez buscando primero un análisis adecuado, etc.), la prueba hace su prueba y se despliega la implementación.

Las solicitudes que retroceden a través del sistema son permisos para comenzar a trabajar. Tan pronto como ha llegado la solicitud, esto genera una gran actividad, donde cada actividad debe completarse lo más rápido posible. Ahí tienes tu despliegue turbo.

Al igual que la solicitud de un automóvil va al distribuidor que mira en el barco que señala a la fábrica de automóviles, que señala a los proveedores.

Kanban no se trata de solicitudes de empuje a través de un sistema. Se trata de extraer la funcionalidad del sistema a cambio de una solicitud que ingresa en el último paso.

Answer 7

cómo lo hacemos:

Tenemos una tubería con las siguientes etapas

1. Cartera
2. TODO
3. en curso (Desarrollar y prueba rápida)
4. revisión de código
5. Prueba (pruebas rigurosas)
6. Integrat prueba de iones y pruebas de aceptación general
7. Implementar

Cada historia se desarrolló como una rama en base a la última versión para dejar la etapa de despliegue. Luego se integran como parte de la preparación de la prueba de integración.

QA extrae de la etapa de revisión de código y puede preparar lanzamientos al ritmo que desee. Creo que tenemos un ritmo de aproximadamente un lanzamiento cada semana.

Al eliminar la rama "principal" de git y no realizar ninguna fusión antes de la etapa de revisión del código, nos hemos asegurado de que no haya posibilidad de "escabullir" código en las versiones. Lo cual, como un subproducto interesante, nos ha obligado a visualizar gran parte del trabajo que solía estar oculto.