Trabajo como propietario de un producto en una empresa de software basada en fintech. Mi equipo de desarrollo sigue la metodología scrum y sprint de 2 semanas. Intentaron seguir la ceremonia de scrum, pero no hacer una estimación de la historia.
Mi parte interesada establece 1 lanzamiento de producción cada mes (digamos, el 25 de cada mes) y algún tiempo extra de lanzamiento de revisión. Nuestro ciclo de lanzamiento es mucho más complejo. Primera prueba de control de calidad de la función en el entorno SIT. Después de obtener la aprobación de SIT qa, el equipo de desarrollo crea el paquete y lo envía a los dispositivos para la implementación de UAT. Después de la implementación de UAT, el probador de UAT prueba los elementos de compilación (una cosa para mencionar, la implementación de UAT solo ocurre en el momento del lanzamiento del producto, no después de cada entrega de sprint). Si el probador de UAT encuentra un problema, vuelve al equipo de desarrollo, pero están en medio del sprint y están haciendo otro trabajo. Luego, el equipo de desarrollo soluciona los problemas planteados por el probador de UAT y se los envía nuevamente. Finalmente despedido de la UAT se va a producción.
Ahora mi pregunta ¿cómo podría agilizar el proceso? , ya que el equipo de desarrollo se sintió frustrado porque a veces necesitan trabajar en medio del sprint para corregir errores o priorizar. Necesito una guía/opinión de un experto para administrar correctamente el lanzamiento de la producción que sigue al sprint.
Segundo ctrl-atl-delor (+1!) - deberías invertir en automatización.
La metodología ágil ayuda a organizar el trabajo, pero independientemente de la metodología, debe automatizar su trabajo tanto como sea posible.
Tenemos un escenario similar en nuestro proyecto, y supongo que es bastante común en las aplicaciones heredadas.
Tienes dos frentes principales de trabajo:
En función de su escenario, deberá evaluar en qué áreas dentro de SDLC o la automatización de pruebas puede obtener beneficios más rápido (las frutas al alcance de la mano).
Necesitará el apoyo del nivel C y/o de las partes interesadas, ya que definitivamente necesitará invertir tiempo y esfuerzo en ello.
Bien hecho, estás haciendo un gran trabajo. Scrum lo ha llevado a diagnosticar varios problemas con su proceso.
Recomendaría la fusión de devops, desarrolladores y operaciones. Luego se despliegan completamente a prueba (es lo mismo que operativo). Después de la prueba, presiona un botón para implementarlo y ponerlo en funcionamiento. Dockeres una buena herramienta para ayudar con esto.
La otra cosa (y la más importante) es realizar una retrospectiva, cada vez que detecte un problema (retroalimentación de la prueba: ¿Por qué sucedió esto? ¿Especificación incompleta/secreta? ¿Prueba de desarrollador incompleta?)
En una retrospectiva haz preguntas, sin reproches. Cuando pregunte use 5-por qué. Eso es preguntar por qué, luego preguntar por qué (5 veces). Por ejemplo, ¿Por qué se rompió? Se rompió porque sobrecargamos el burro. ¿Por qué sobrecargamos el burro? Porque no sabíamos cuánta carga le estábamos poniendo. ¿Por qué? porque faltaban las escamas. ¿Por qué? porque estaban siendo prestados por factura. ¿Por qué? Porque Bill no tiene su propia balanza. ¿Por qué? por el ahorro presupuestario. ¿Por qué? porque …
lalala
Tufiq Mahmud
Tiago Cardoso
Bart van Ingen Schenau
lalala
Bart van Ingen Schenau