ScrumBut en el equipo de an谩lisis: antes del despegue

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

  1. Un gran proyecto para el desarrollo de un sistema interpraise.
  2. Equipos separados de desarrolladores, soporte y analistas.
  3. Un equipo genial de analistas (alrededor de 14 personas).
  4. La capacidad de actuar solo en el marco de un equipo de analistas.
  5. Lanzamiento lanzamiento de versiones del sistema.
  6. Modelo de gesti贸n del ciclo de vida del software Waterfall.
  7. La imposibilidad de una planificaci贸n dura, ya que las tareas del cliente llegan en cualquier momento.
  8. Carga de trabajo desigual de los analistas.
  9. Distribuci贸n funcional de las zonas de examen de analistas.

Que queremos conseguir

  1. Poder responder r谩pidamente a los cambios comerciales.
  2. Tener en cuenta y priorizar las tareas en el trabajo.
  3. Tener previsiones de crecimiento de producto factibles.
  4. Los sprints cortos pueden permitirle rastrear, registrar y completar tareas, y predecir con mayor precisi贸n cu谩ndo se lanzar谩n las tareas.
  5. Cree una acumulaci贸n de tareas para analistas.
  6. En cualquier momento, el analista sabe qu茅 hacer.
  7. Intercambie experiencias en la resoluci贸n de problemas complejos.
  8. Establecer el trabajo en equipo de manera que se compartiera el conocimiento fue agradable, c贸modo y mutuamente beneficioso.
  9. Organiza tu Scrum con Black Jack, etc. :)
  10. 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 鈥淟o 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.

Fuente

Conclusiones 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.

Source: https://habr.com/ru/post/437800/


All Articles