Hola Habr! Me llamo Zhenya Soy analista de sistemas en NORBIT y un principiante Scrum-master. He estado mirando Scrum durante mucho tiempo para estudiar, probar y evaluar sus capacidades en nuestro equipo de analistas. Y ahora, después de una
patada ligera de una conversación inspiradora con el RP, me di cuenta: deja de pensar, es hora de hacerlo.
En este artículo, hablaré sobre nuestra experiencia preparándonos para usar el Scrum limitado en nombre del Scrum master: lo que hicimos para comenzar. Al momento de escribir, se completa el 15 ° sprint. ¡El vuelo es normal!
A menudo escuché sobre el uso del marco Scrum en equipos cuyos miembros no son desarrolladores. Equipos de varios expertos se unen activamente a Agile. Pensé que Scrum se creó originalmente para equipos de desarrollo de ciclo completo y, por lo tanto, hay una serie de dificultades o puntos interesantes a los que debes prestar atención si el equipo difiere de la referencia en la que pensaron los creadores. Distingo equipos en la dirección de experiencia y grado de participación en el ciclo de desarrollo de productos. La dirección de la experiencia, en mi opinión, no limita el uso de Scrum. Pero el grado de participación en el desarrollo de productos puede ser limitado. Algunos de ellos pueden llevar a cabo el ciclo completo de trabajo en el producto, siendo responsables del resultado final disponible para el cliente, y en mi opinión, en dichos equipos puede usar un Scrum completo. Y otros solo hacen parte del ciclo completo, siendo parte de la cadena de trabajo. En este caso, puede haber preguntas y dificultades con un Scrum completo. Tal situación de diseño puede requerir un compromiso.
Este artículo se centrará en el equipo responsable de parte del ciclo de desarrollo del producto y la preparación para lanzar ScrumBut en él.
Nuestro plan de acción para el lanzamiento fue el siguiente:
- para estudiar y evaluar la situación actual y la deseada
- construir un tal cual y ser modelo en terminología ScrumBut,
- presentar e inspirar al equipo
Cómo aprendí qué es ScrumBut
Primero busqué en Google y obtuve:
Un ScrumBut tiene una sintaxis particular: (ScrumBut) (Motivo) (Solución). Ejemplos de ScrumBut: "(Usamos Scrum, pero) (tener un Scrum diario todos los días es demasiado caro) (por lo que solo tenemos uno por semana)" "(Usamos Scrum, pero) (Las retrospectivas son una pérdida de tiempo ,) (para que no los hagamos) "
Es decir ScrumBut es un Scrum limitado. Esta variación del marco le permite tomar todo lo que necesita de Scrum y no tomar lo que, en nuestra opinión, no es obligatorio. Por supuesto, este es un camino resbaladizo, porque Para comprender qué es necesario y qué no se requiere, era importante tener una idea del Scrum clásico, era importante para mí entender por qué esto se incluye en la versión completa.
Útil para mí en el material fueron:
- estudio de literatura: manifiesto ágil de desarrollo de software , "método revolucionario de gestión de proyectos SCRUM" (Joseph Sutherland), "coaching de equipos ágiles" (Lissa Adkins);
- Una serie de largas e interesantes consultas con un scrum master certificado y activo que practica los clásicos.
¿Cómo evalué la situación actual?
Para empezar, aproveché mi visión y presenté varios puntos para evaluación por parte de los gerentes.
Recolectó las opiniones de los miembros del equipo y las grabó.
Tenemos dos listas: lo que tenemos en la entrada y lo que queremos obtener.
Aquí haré listas consolidadas y generalizadas.
Lo que tenían en la entrada
- Un gran proyecto para el desarrollo de un sistema interpraise.
- Equipos separados de desarrolladores, soporte y analistas.
- Un equipo genial de analistas (alrededor de 14 personas).
- La capacidad de actuar solo en el marco de un equipo de analistas.
- Lanzamiento lanzamiento de versiones del sistema.
- Modelo de gestión del ciclo de vida del software Waterfall.
- La imposibilidad de una planificación dura, ya que las tareas del cliente llegan en cualquier momento.
- Carga de trabajo desigual de los analistas.
- Distribución funcional de las zonas de examen de analistas.
Que queremos conseguir
- Poder responder rápidamente a los cambios comerciales.
- Tener en cuenta y priorizar las tareas en el trabajo.
- Tener previsiones de crecimiento de producto factibles.
- Los sprints cortos pueden permitirle rastrear, registrar y completar tareas, y predecir con mayor precisión cuándo se lanzarán las tareas.
- Cree una acumulación de tareas para analistas.
- En cualquier momento, el analista sabe qué hacer.
- Intercambie experiencias en la resolución de problemas complejos.
- Establecer el trabajo en equipo de manera que se compartiera el conocimiento fue agradable, cómodo y mutuamente beneficioso.
- Organiza tu Scrum con Black Jack, etc. :)
- Pruebe cosas nuevas, mejore el espíritu de equipo. Chicos geniales. Por que no
Modelado
En la etapa de modelado, asignamos roles de equipo: identificamos a los propietarios de los productos, a los miembros del equipo y a mí como maestros de scrum, la duración del sprint, el proceso de llenar y priorizar el trabajo atrasado.
Se determinaron los atributos obligatorios de las tareas, un flujo de trabajo para el seguimiento, una herramienta de seguimiento, la asignación de una estimación en horas humanas para cada tipo de tarea y el número total de horas por semana para cada analista, teniendo en cuenta el cumplimiento del plan del equipo de sprint, el tiempo y la regularidad de las reuniones diarias y retrospectivas.
El propietario del producto y la persona que establece la cartera de pedidos es el jefe de un grupo de analistas. Se decidió formar equipos de 2-7 personas, satisfaciendo el requisito de la cantidad de 7 ± 2. Estos eran dos equipos, divididos condicionalmente de acuerdo con el atributo funcional de las tareas a resolver, que estaba más cerca del modelo original, pero más lejos del objetivo previsto: la funcionalidad cruzada.
Para el seguimiento, decidimos utilizar el TFS existente, en el cual es conveniente colocar las tareas en los estados de "Nuevo", "En el trabajo", "Completado" en el tablero y es posible recopilar pequeñas estadísticas sobre los resultados para su discusión en una reunión retrospectiva al final del sprint. La placa TFS imita una placa Scrum física, pero también tuvimos una física.
Presentación
La etapa de planificación finalizó con una demostración al equipo de la presentación sobre los resultados del modelado, el debate y la corrección de “Lo que comenzamos juntos juntos” de lo que no encontró respuesta de los muchachos.
Scrum y ScrumBut en particular son trabajo en equipo, coherencia, transparencia y aceptación general. Fue un momento importante a partir del cual comenzamos con inspiración.
FuenteConclusiones de los preparativos de lanzamiento.
Cuando trabajas en un proyecto grande, no hay forma de entrar en la piscina con la cabeza, por lo que no puedes hacerlo sin planificación. Es importante comprender cómo será y qué resultados traerá, pero nos encontramos con la necesidad de estar preparados para el hecho de que el plan en algunos aspectos seguirá siendo el plan. Al planificar, pintamos con grandes trazos, y ya en la etapa de implementación pudimos agregar los detalles que trajo el equipo y la situación del diseño.
Nuestro equipo solo es responsable de una parte del ciclo de desarrollo de software, por lo que hubo dificultades con respecto a qué llamar un producto y qué recibir como un aumento. Sabíamos que debería ser holístico y completo. Acordamos que, por parte del equipo de analistas, estamos preparando varios tipos de documentos para la interacción con el cliente y creando tareas para que los desarrolladores los acumulen. Por lo tanto, las tareas caen en los sprints para los desarrolladores. En mi opinión, este camino de compromiso puede ser adecuado tanto para proyectos en los que equipos individuales de analistas, desarrolladores, probadores, soporte, como para proyectos donde el número de personas requiere la separación en varios equipos. También hay una desventaja en esta decisión: los miembros de nuestro equipo no pueden afectar el momento de la disponibilidad de la funcionalidad del producto, solo podemos afectar el rendimiento de su parte del trabajo. Hay ventajas: la continuidad de las tareas de los analistas para desarrolladores. Esta decisión nos permitió evitar los intentos de convertirnos en un equipo multifuncional (analistas = desarrolladores = evaluadores, etc.), lo que en nuestro caso en esta etapa sería imposible, mientras se mantiene el ciclo de desarrollo del producto con una refracción comprometida en la unión de la interacción del equipo.
En la etapa de presentación, nuestros muchachos de
NORBIT reaccionaron con
entusiasmo e interés. Pero supongo que la respuesta emocional positiva del equipo es el mérito de elaborar los objetivos y su conexión con problemas urgentes y obvios.
Los pasos descritos anteriormente (estudio teórico, modelado y presentación) funcionaron: comenzamos con éxito.
Pero comenzar es solo el primer paso. Te contaré lo que sucedió después del lanzamiento y qué resultados se lograron en mi próximo artículo.