En Scrum, es obvio que podríamos producir una demostración después de cada sprint.¿Cómo liberar con Kanban?
No sé cómo producir demos en Kanban ya que no tiene el concepto de sprint (puedo estar equivocado).
¿Podría por favor aclararme sobre cómo hacer lanzamientos en Kanban?
Gracias por su ayuda y tiempo.
Cuando estábamos implementando Kanban en mi último trabajo, las emisiones fueron una de tres maneras:
Era bastante abierto, realmente.
Hacemos que una demostración sea una condición para mover una función de "Prueba" a "Lista para versión". Por lo tanto, es característica por característica en lugar de sprint por sprint, y la naturaleza de la característica determinará la naturaleza de la demostración. Mientras mayor sea la participación de las empresas durante el desarrollo, de todas maneras, esto se convierte en un problema menor.
No hay una definición única. Por lo general, en Kanban agregamos MMF (características mínimas comercializables) que, por definición, significa que cada función debe agregar valor al cliente, por lo que debería poder liberar cada característica de manera independiente.
Esto no significa que tenga que liberar cada característica por separado, por lo que encontrará toda una gama de enfoques (David menciona algunos de ellos). Encuentro que es un caso común que el equipo de Kanban lo publique más a menudo de lo que lo haría si siguiera uno de los enfoques de tiempo.
Las demostraciones en Kanban son opcionales, pero si el cliente está dispuesto a tenerlas, puede hacer una demostración de las características a medida que implementa, incluso si libera cada característica de forma independiente. En teoría, cada característica debería agregar valor, por lo que este enfoque debería funcionar bien.
Kanban dice cómo administrar el flujo de trabajo y limitar el trabajo en progreso, no dice nada acerca de la frecuencia de las versiones como tales. Sin embargo, es bastante exigente porque exige que se mantenga siempre una versión integrada del producto que funcione, con nuevas funciones añadidas tan pronto como se consideren completas (lista de finalizadas, última columna del panel).
Un concepto que se utiliza con frecuencia es que hay una "cadencia": un intervalo regular cuando se toma este "producto listo" y se implementa en realidad en el sistema en vivo/enviado.
Sin embargo, creo que un concepto que es muy claro en Scrum también puede ayudar aquí. En Scrum, se dice claramente que Scrum exige un "incremento del producto enviable" (que confirma la definición de DONE) al final de cada sprint. Si realmente enviarlo/implementarlo está fuera del alcance del proceso de desarrollo, porque en última instancia es una decisión comercial. Lo mismo creo que se aplica a Kanban, un producto listo e integrado está disponible en todo momento, ya sea para usarlo como una decisión comercial que está fuera del alcance del proceso de desarrollo y su gestión.
Puede intentar agregar un paso de aprobación a su DOD, donde puede organizar una demostración rápida. Pero la diferencia sería que será una demo uno a uno, mientras que en scrum sprint, la demo es para todos los asistentes.
En cuanto al ciclo de publicación, ya se mencionó en las respuestas anteriores. Me gustaría agregar un punto más, es posible que tenga un límite para publicar elementos. Por ejemplo, si tiene 10 FMM en el tablero listos para ser liberados, entonces el proceso de lanzamiento se puede iniciar en ese momento.
Este método puede ayudarlo a rastrear el rendimiento de una manera.
Como nota al margen, considere mi propuesta de Área 51 (http://area51.stackexchange.com/proposals/9543/development-methodologies) como un futuro hogar para Kanban y otras preguntas y respuestas relacionadas con el método. Invita a todo tu equipo, técnico y no técnico :) – David
¿Cómo saber si las tarjetas actuales en "Hecho" forman una versión válida? ¿No es posible que formen una funcionalidad no relacionada? – Chiron
Eso depende mucho del proceso de QA. Para nosotros, "hecho" significaba que la característica fue probada por QA en el entorno de QA y aprobada por el usuario comercial que la solicitó en el entorno Model (clon de producción). Existía el riesgo de que las funciones afectaran negativamente a otras funciones, ya que la prueba de regresión era prohibitiva en términos de costos: probaba todo el sistema en el Modelo, por lo que tuvimos que ser diligentes en nuestro trabajo. Las funciones pueden no estar relacionadas, pero una vez que se aprueban, se aprueban. Las funciones grandes se pueden dividir y soltar en piezas, caso por caso. – David