Soy un nuevo maestro de scrum y estoy comprometido a entregar nuestro sprint a producción (¡en vivo!) Al final de cada sprint. ¿Cuáles son los desafíos y cómo podemos superarlos?

Supongo que descubrirá rápidamente cuáles serán sus desafíos en su organización particular, su equipo particular, su cultura particular y su pila de tecnología particular.

Mi punto es que cada tienda opera con un conjunto diferente de restricciones, por lo que es difícil responder a su pregunta en específico.

Sin embargo, en general, si desea lograr una entrega continua (y es un gran objetivo), me aseguraría de que:

  1. Todos están en la misma página (por lo que todos están comprometidos con la misma visión de una implementación de producción cada sprint). Haga que los desarrolladores, el propietario del producto, cualquier persona de control de calidad y cualquier otra persona directamente involucrada compren esta idea (significará que a veces es necesario sacar algunas noches tarde, por lo que deben estar preparados)
  2. Haga que el equipo invierta en infraestructura, es decir, asegúrese de que haya buenas herramientas para automatizar muchas tareas repetitivas. Cosas como: repositorio de código (ej. Git, SVN), servidor de integración continua (ej. Jenkins), automatización de pruebas (ej. Mocha, Selenium), automatización de implementación (ej. Puppet o Chef), herramientas de compilación (ej. Ant, make ) Estas herramientas se pueden agregar con el tiempo, así que comience con lo básico, pero aliente al equipo a pasar un poco de tiempo cada sprint automatizando tareas repetitivas. Idealmente, lanzar una nueva versión debería ser un 95% automatizado y podría suceder diariamente.
  3. Invierta en automatización de pruebas. Esta es una bestia difícil de seguro y no todo se puede automatizar (aún necesitará buenas personas de control de calidad), pero haga que el equipo comience con pruebas unitarias (especialmente para el código de la biblioteca), continúe con las pruebas de integración y posiblemente algunas pruebas amplias En mi experiencia, la automatización de pruebas es, con mucho, el mayor desafío para los lanzamientos frecuentes y requiere disciplina y coraje para mantenerse. También tenga en cuenta que las pruebas deben integrarse en el producto; Es una ilusión pensar que se puede atornillar después. Los desarrolladores deben pensar en las pruebas de automatización como parte de cada historia y el código de prueba debe escribirse con el mismo estándar de calidad que el resto del producto. No relegue la automatización de pruebas a desarrolladores junior; todos necesitan estar escribiendo y manteniéndolos todo el tiempo y defendiendo su continua existencia. Si las pruebas se vuelven obsoletas y comienzan a ser ignoradas, pronto perderá la capacidad de liberarse rápidamente.

Con suerte, como una nota de aliento, es muy posible tener lanzamientos muy rápidos. En mi equipo de desarrollo actual, podemos enviar el código a producción en aproximadamente 5 minutos desde el principio . Y como un ejemplo fantástico, lea este Despliegue continuo en Quora por Martin Michelsen en Ingeniería en Quora sobre cómo Quara realiza sus lanzamientos y cómo logran docenas de lanzamientos por día.

Gestión de proyectos – The Kanban Way ™
Lea “Teoría de restricciones” y entrega ágil de software. Para una mejor canción o música, la orquesta y todo debe estar sincronizado.