¿Deben los equipos ágiles entregar nuevas características diariamente?

Mi empresa está en medio de una transición del desarrollo de estilo cascada a Agile / Scrum. Entre otras cosas, se nos dice que la expectativa es que tengamos nuevas características de trabajo comprobables (por QA) al final de cada día.

La mayoría de nuestros desarrolladores pierden alrededor de 2 horas al día en reuniones y otros gastos generales empresariales. Esto significa que en cualquier período de 6 horas (en el mejor de los casos), tenemos que diseñar, escribir, probar la unidad, construir e implementar (con notas de la versión) suficiente código para producir una función completa con la que pueda jugar el control de calidad. Entiendo que las notas de compilación / implementación / lanzamiento podrían automatizarse con una configuración de CI adecuada, pero aún no hemos llegado.

También tenemos un gran contingente offshore que escribe nuestro código del lado del servidor, y la diferencia horaria de 12 horas hace que esto sea aún más difícil.

Intentamos distribuir las historias en cortes verticales estrechos y profundos para completar las características de principio a fin lo más rápido posible, pero la mayoría de los días se sienten bastante frenéticos y a menudo encuentro personas tomando atajos estúpidos y frágiles para asegurar que el control de calidad tenga su estructura. Este problema se agrava después de que un sprint ha estado en progreso durante un par de días, cuando los defectos inevitables comienzan a aparecer y tienen que encajar en la misma ventana de 6 horas.

¿Es este un ritmo normal para los equipos ágiles? Incluso si logramos implementar una configuración de CI, no puedo ver cómo podremos mantener este ritmo y seguir creando software de calidad.

Editar: Hay varias buenas respuestas aquí. Me hizo darme cuenta de que lo que realmente estaba preguntando es si los equipos de Agile ofrecen nuevas funciones a diario. Actualicé el título en consecuencia.

Los crímenes que se cometen en nombre de Agile en estos días me ponen triste. Mucha gente está teniendo dificultades para hacer esta transición.

Manifiesto ágil: "Valoramos a las personas y las interacciones sobre el proceso y las herramientas". Cuando la gente está claramente herida, el proceso es incorrecto. No quiero decirte cómo hacerlo, pero compartiré cómo lo hago.

En mis equipos, lo importante es evitar comprometerme con un código de repositorio compartido que se rompa de manera que desperdicie el resto del tiempo del equipo. Solo en este sentido, me esfuerzo por 'entregar código de trabajo todos los días'. No rompas el control de calidad. No bloquees a otros desarrolladores. Idealmente, nunca reviso ningún error. (jaja).

La implicación no es que tienes que cometer algo todos los días. La implicación es que solo debe cometer cosas buenas, para que cada día pueda obtener una compilación de todas las cosas buenas que cualquiera cometió. De esta manera, el equipo sigue disparando en todos los cilindros.

En mis equipos, el control de calidad es constante. Construyo productos comerciales, por lo que el proyecto nunca termina hasta que el producto esté obsoleto. Los ingenieros de control de calidad prueban las características que están disponibles para probar. Los ingenieros de control de calidad siempre tienen un retraso. Nunca hay suficiente tiempo de control de calidad para probar o automatizar todo lo que idealmente desearíamos.

Si los desarrolladores necesitan varios días antes de fusionar los cambios para una función o corrección, está bien, se recomienda si les ayuda a obtener el código justo antes de arriesgar nuestro tiempo. Los desarrolladores pueden enviar código a su repositorio privado o sucursal sin afectar al equipo o al control de calidad. Los desarrolladores pueden ejecutar pruebas unitarias o automatización de regresión en el código creado a partir de un repositorio o una rama privada del desarrollador. En casos particularmente riesgosos, un ingeniero de control de calidad trabajará con el desarrollador para probar antes de fusionar, para proteger al equipo de demoras.

En este sentido, practico lo que quieren tus gerentes. Casi todos los días durante los últimos 12 años, mis equipos de desarrollo han tenido un código que funciona en el repositorio compartido. Siempre estamos casi listos para enviar. Ocasionalmente no logramos esto, pero no nos preocupamos demasiado por eso. A veces es intencional, adaptarse a cambios importantes de herramientas o fusiones difíciles.

El Manifiesto Ágil, para mí, resume lo mejor del nuevo pensamiento sobre el proceso de desarrollo que surgió en la década de 1990. Soy un verdadero creyente en esos principios, pero los detalles del proceso pueden variar. Desde mi punto de vista, el objetivo de Agile es adaptar su proceso a las necesidades de sus productos y clientes, no ser un esclavo del proceso.

Si ayer tuvieras un software operativo, ¿por qué no funcionaría hoy? Si no terminó ninguna tarea hoy, la compilación de hoy será la misma que ayer. Las construcciones diarias y el ritmo de desarrollo son cosas separadas. El hecho de que tenga compilaciones diarias no significa que tenga nuevas funciones en cada compilación.

Cuando finalmente alguna característica se termina y se registra en la sucursal principal, entonces debería tener un proceso automatizado que construya el software y ejecute pruebas. Si hay un problema con la creación o ejecución de pruebas, se notifica al equipo y se concentran en su esfuerzo para que funcione nuevamente. Así es como funciona CI y cómo lo ayuda a lanzar software de trabajo todo el tiempo.

Respuesta corta: no . Simplemente no se puede lograr a diario.

Sin embargo, el equipo ágil supone entregar piezas de software de trabajo o historias de usuarios en cada sprint . Por lo general, las reuniones de estado se llevan a cabo diariamente para ver el progreso y los impedimentos.

En lo que respecta al software de calidad , los procesos de integración continua (CI) establecidos garantizarán que el control de calidad se aplique a pequeños esfuerzos (check-ins) y se realice con la frecuencia que se haya configurado. También tiene como objetivo mejorar quality of softwarey reducir el tiempo necesario para entregarlo, al reemplazar la práctica tradicional de aplicar el control de calidad después de completar todo el desarrollo.

No, no debe haber expectativas de ofrecer nuevas funciones todos los días. No todas las características se pueden dividir en un tamaño tan pequeño como para que un desarrollador pueda finalizar la característica en ~ 6 horas de tiempo de desarrollo.

Si está haciendo scrum, debería estar haciendo al menos 2 semanas de sprints, con características dimensionadas para tomar aproximadamente de 0 a 8 días para finalizar. La promesa al propietario del producto es entregar un código de trabajo correcto nuevo, probado y verificado que pueda ponerse en producción al final del sprint. (NOTA: No tiene que ponerlo en producción, pero el objetivo es que pueda serlo si lo desea)

Una buena metodología le sugirió que configurara un servidor CI (integración continua) en el que automatizara la creación de al menos una compilación diaria de software de trabajo. La idea es que ingrese su código tan pronto como termine la función para que pueda estar en el próximo ciclo de compilación y luego en manos de QA para la prueba.

¡Recuerda que el objetivo es que las funciones se realicen y se prueben al final del sprint! No querrás tener que hacer que el control de calidad espere hasta el último día del sprint para que puedas hacer la compilación y luego hacer que prueben todas las características. No tendrán tiempo para probarlo todo y usted no tendrá tiempo para corregir ningún error ...

Si no puede configurar un servidor de CI, la práctica debería ser que necesita crear manualmente una nueva compilación para el control de calidad cada vez que un desarrollador verifica su código terminado y afirma que ha terminado con una función y está listo para entregarlo al control de calidad.

De hecho, depende del tamaño del proyecto; Si el proyecto es grande, no hay forma factible de lograrlo.

Las compilaciones diarias (o incluso más frecuentes) que surgen de herramientas de integración continua no significan software de trabajo; Apenas significa código compilable.

Existen muchos proyectos que ofrecen compilaciones diarias que, gracias a la integración continua, son software en funcionamiento. Al menos en teoría.

Significa que no necesariamente contiene nuevas características. Tal vez algunas correcciones de errores menores, o nada en absoluto.

En teoría, si no puede proporcionar más trabajo a su QA diariamente, debe aumentar el número de desarrolladores o reducir el número de probadores. Idea terrible!

Tu trabajo es hacer las cosas.

Dígale al control de calidad que obtendrán algo para probar cuando esté terminado. Tienes que explicarles por qué.

Creo que está confundido acerca de la idea de "CI". Puede visitar este excelente artículo de Martin Fowler sobre cómo funciona CI en la práctica. Eso debería responder a su pregunta correctamente.