¿Deberían implementarse las correcciones de errores tan pronto como estén listas?

Independientemente del marco utilizado, la idea general es:

• Entregar valor al cliente lo más rápido posible
• Entregue valor al cliente con la menor cantidad de errores posible

Las metodologías orientadas a Agile se basan fuertemente en pruebas automatizadas, como mencionó, pero no debe limitar su proyecto solo porque Scrum / Agile lo dice.

En realidad, otras metodologías, como Kanban, podrían adaptarse mejor a su modelo actual: las correcciones se entregan tan pronto como se corrigen.

Sucede que parece que tiene otras preguntas secundarias aquí, como la calidad y la cobertura de las pruebas. Puede estar entregando rápido al cliente, pero a costa de aumentar la deuda tecnológica. Si ese es el caso, entonces ese es el punto clave en el que debe concentrarse en sus discusiones.

Solo evite discutir 'Agile lo dice' y 'Kanban lo dice'. Para los usuarios finales, simplemente no importa mucho.

En primer lugar, no existe una regla en Scrum (que yo sepa) sobre no publicar el trabajo terminado durante un Sprint; por lo tanto, si esos elementos están en el sprint, aún puede liberarlos potencialmente durante el sprint.

En segundo lugar, un sprint consiste en trabajar en los elementos del backlog del sprint para crear un incremento terminado. Si tiene errores que surgen y se solucionan durante el transcurso de un sprint, eso suena más como una sobrecarga, de la misma manera que, por ejemplo, lo sería actualizar las versiones de Rails. En ese caso, posiblemente tenga sentido excluir esos elementos del sprint.

Finalmente, dado que Scrum está orientado al desarrollo de productos, y usted no está haciendo mucho de eso en este momento, podría tener sentido enfocarse aún más en limpiar y probar este sistema, y ​​posponer la adopción de Scrum hasta que están listos para enfocarse en desarrollar su producto. Scrum no funciona bien en un entorno con prácticas de ingeniería menos que estelares.

Parece que es posible que desee ver Kanban.

Siguiendo estrictamente Scrum, no, no debe ignorar sus Sprints y publicar correcciones de errores diariamente. Pero no hay ninguna razón por la que tengas que usar Scrum específicamente; en mi experiencia, funciona mejor para nuevos desarrollos que para trabajos de mantenimiento.

Kanban, por otro lado, es un marco mucho más ligero, que involucra simplemente un tablero con columnas y límites de trabajo en progreso para cada columna (con la excepción de las columnas del primer 'problema descubierto' y el último 'terminado'). Funciona mucho mejor para el trabajo de mantenimiento en el que no está tan preocupado por la estimación y solo desea obtener correcciones de errores a un ritmo constante.

Sobre todo, analice tanto Scrum como Kanban , comprenda sus fortalezas y debilidades, y lleve la decisión a su equipo, para que ellos puedan decidir. El mejor proceso que se le impone a un equipo suele ser peor que un proceso mediocre que se entiende y acepta por completo.

Scrum tampoco dice que no puede liberar durante un Sprint, ni dice que debe liberar después de un Sprint.

Pero sí dice que debe haber un incremento liberable al final de un Sprint, y esto debe estar disponible para su inspección en la Revisión de Sprint, de modo que todas las partes interesadas puedan inspeccionar los cambios y proporcionar comentarios para planificar el próximo Sprint.

Un aspecto crucial de Scrum es la definición de "Terminado". El Equipo de desarrollo debe establecer una definición de "Terminado", que se puede utilizar para garantizar la calidad y garantizar la transparencia. Por estas razones, no se debe agregar nada al Incremento si no está "Terminado" (de lo contrario, no sería liberable).

Diría que es vital que se ayude al equipo de desarrollo a comprender los requisitos comerciales para lanzar regularmente (si aún no lo hacen), y se les debe habilitar y alentar a encontrar una forma de trabajo que sea adecuada para las necesidades del negocio. .

Sugeriría que todas las partes consideren los méritos relativos de lanzar solo después de un Sprint completo y lanzar más regularmente. El profesionalismo debería significar que es posible encontrar un sistema que optimice la calidad y el valor.

La decisión correcta dependerá de las circunstancias dentro de su organización, pero un principio fundamental de Scrum es que los lanzamientos regulares permiten una mayor inspección y adaptación, y oportunidades para recopilar comentarios de los clientes.

La duración del Sprint debe establecerse para que coincida con los requisitos comerciales, y aunque se pueden aprovechar las oportunidades de lanzamiento antes del final del Sprint, todos deben tener claro que la responsabilidad clave del Equipo de Desarrollo es producir ese incremento liberable al final del Sprint.

No tenga miedo de probar Sprints muy cortos (por ejemplo, 1 semana, o posiblemente incluso más cortos), pero tenga en cuenta que 2 semanas suele ser lo más común, y probablemente habrá algunos desafíos interesantes con Sprints muy cortos.

Sea valiente, experimente, inspeccione, adáptese. No decida de una forma u otra sobre la publicación regular, hasta que tenga suficiente información para tomar una buena decisión, y luego, cuando salgan a la luz nuevos conocimientos, prepárese para reevaluar y cambiar de opinión.

¡Adelante!

dado que apenas tenemos que lidiar con errores (1 o 2 errores por sprint), no vemos ningún daño en implementarlos junto con grandes cambios (como 4 o 6 historias de usuarios). Entonces, dado que ese no es el caso en esta empresa, ¿deberían implementarse las correcciones de errores tan pronto como se hayan hecho? ¿O deberíamos implementarlos al final del sprint junto con las nuevas funciones para mantener el compromiso?

No se trata de la proporción entre errores y características, se trata de pérdidas y beneficios. En términos generales, debe hacer lo que sea más beneficioso para la empresa.

Seleccione el período de iteración (tiempo de ciclo) que maximiza los ingresos de la empresa. Cuanto menores sean los riesgos y los costos de implementación, más rápido podrá realizar la entrega. (Amazon se implementa cada 11,6 segundos en producción).

Además, lo más probable es que usted no sea una persona que tome decisiones sobre qué arreglar y cuándo. Simplificando demasiado que está proporcionando:

• Precio y riesgos de cada corrección de errores.
• Etiqueta de precio y riesgos de la implementación en sí.

La mayoría de las veces no estás tomando decisiones sobre qué hacer desde el lado del desarrollo. Debe proporcionar las etiquetas de precios y los riesgos de la manera más clara y explícita posible para que las personas a cargo de las ganancias de la empresa tomen una decisión sobre qué pagar y qué cantidad de riesgo aceptar.