¿Cómo hicimos SCRUM?

Un sueño terrible de un equipo de desarrollo es cuando necesita "sumergirse" en un área temática desconocida y "estimar" una idea poco elaborada antes de comenzar el desarrollo. En este caso, debe literalmente " firmar sangre " para obtener el resultado en el momento señalado por una cantidad fija de dinero.

De hecho, dar una evaluación precisa de los requisitos inexactos no es realista. Una forma típica en la gestión de proyectos es elaborar un TOR detallado antes de comenzar el desarrollo. Y luego implemente toda la funcionalidad en una gran pieza. Pero este enfoque de " cascada " amenaza con otros riesgos: lanzar un proyecto al estilo de un " big bang ", cuando obtienes el primer resultado al final del proyecto. Y puede estar muy lejos de los objetivos comerciales reales y las necesidades del usuario.

¿Por qué arriesgarse tanto si puede tomar un camino completamente diferente?

Por qué SCRUM

Al familiarizarnos con el proyecto, hay un entendimiento de "sabemos que no sabemos esto" e incluso "no sabemos dónde los límites de lo que no sabemos" ayudan a SCRUM



Los detalles de SCRUM pueden asustar, si nunca ha trabajado con este marco, por el hecho de que al principio no se conoce la longitud del camino que debe seguir para obtener un proyecto que funcione y una satisfacción del 100%.

Es difícil para el cliente: NO puede preparar un plan estratégico para el desarrollo del proyecto con fechas de lanzamiento confiables. Lo desconocido da miedo, especialmente cuando tienes que pagar de esta manera ahora.

Pero hay ventajas : al principio, el cliente no debe describir en detalle y escrupulosamente todas las funciones y características de un gran sistema futuro. Y también puede cambiar las prioridades en cualquier momento y adaptarse a un mercado externo competitivo.

Por cierto, fue lo mismo en este caso , pero pronto verán cómo salimos de una situación difícil, cuando junto con el cliente descubrimos qué y cómo implementarlo en el proceso.

SCRUM se basa en el concepto de pequeños pasos: lanzar versiones de software en ejecución regularmente, tan a menudo como sea posible y antes. Cada iteración es una micro etapa de desarrollo, verificada inmediatamente por la práctica.

Esto significa que después de la primera iteración, el cliente recibe una funcionalidad bastante útil, aunque pequeña, pero que funciona, la comprueba en la práctica e inmediatamente proporciona comentarios.



Vea cómo organizamos todo el trabajo: decisiones clave importantes (cuál es el próximo valor que le dará al negocio) que el equipo toma antes de cada nueva iteración, como resultado, el sistema se desarrolla a lo largo de un camino crítico óptimo hasta que se convierte en el más apropiado para el negocio. El cliente aquí es parte del equipo. Tanto el contratista como el cliente son responsables del éxito del desarrollo. Están a un lado de las barricadas.

Ese fue el caso con nosotros, ¿vamos a ver?

Queremos hablar sobre nuestra forma de adaptar el marco clásico SCRUM al trabajar en un sistema de control automatizado para la "Academia A + de Educación Moderna": este es un centro educativo moderno en Kiev, que incluye una escuela, un jardín de infantes, un centro de desarrollo temprano, música, danza y deportes. escuelas, estudios de arte y un centro para el estudio de lenguas extranjeras. En total, más de mil niños asisten a casi 150 cursos diferentes en la Academia.

SCRUM es un marco que ayuda a resolver tareas que cambian durante el proceso de trabajo, con el fin de entregar productos de manera eficiente y creativa a los clientes con el mayor valor posible

La ventaja de SCRUM y, para algunos, la desventaja es que es un marco muy ligero. No contiene respuestas a todas las preguntas e instrucciones detalladas para los miembros del equipo. Scrum - "intencionalmente incompleto", y debido a esto universal.

SCRUM debe adaptarse a cada proyecto específico

¿Cómo comienzan a trabajar los clientes y contratistas en SCRUM?

Para trabajar en un paradigma desconocido, a veces el cliente tiene que cambiar el pensamiento habitual. Estar en el mismo contexto con el artista. Por lo tanto, antes de desarrollar el sistema para la Academia, organizamos una capacitación conjunta con los muchachos de Scrum Ucrania . Sus objetivos principales: conocerse, comprender la terminología, desarrollar todas las técnicas en forma de juego, simular las actividades principales, comprender por dónde empezar, distribuir roles y registrar responsabilidades.









Durante un entrenamiento conjunto de tres días, nosotros, utilizando la llamada vista de helicóptero , formamos el sistema futuro con grandes golpes y lo fijamos en una línea temporal en forma de Project RoadMap.

vista de helicóptero: una descripción general u opinión de una situación, en lugar de una detallada


Mapa global de productos

¿Cuáles son nuestras conclusiones después de esta etapa?

1. La capacitación conjunta ayuda a cambiar el pensamiento del cliente y el equipo.
2. Product RoadMap le permite visualizar un plan de desarrollo de alto nivel y planear versiones aproximadamente. Es importante comprender que esta es una "hoja de ruta en vivo" que cambiará a medida que se descubran nuevos detalles de desarrollo.
3. El acuerdo sobre las reglas globales del juego es necesario "en la costa": el propietario del producto después de cada sprint recibe valor, un sistema de trabajo que debe usarse de inmediato y luego dar retroalimentación.

El tercer párrafo es obligatorio, sin él nada funcionará. Dado que las esperanzas de lanzar después de la preparación total abstracta en la final conducen a decepciones, en ambos lados:

• Por parte del cliente: "Esto es lo que solicitamos, pero no es lo que necesitamos".
• Por parte del intérprete: “Claramente hicimos lo que pediste. Y ahora sus requisitos nos parecen completamente diferentes. Aceptamos rehacer todo, pero a su cargo. En general, hay tantos cambios que completarlos llevará otros seis meses ”.

Propietario del producto : el propietario del producto es responsable de lograr el valor máximo del producto como resultado del trabajo realizado por el Equipo de Desarrollo. La única persona responsable del desarrollo del producto.

Todos nuestros arreglos en una breve lista.

Paso 1: Análisis de negocio y adaptación metodológica

Comenzamos el desarrollo de cualquier proyecto con un análisis de negocio: debe comprender los detalles. Siempre hay muchos procesos en cualquier empresa, y nuestra tarea en el estudio es descubrir cómo los participantes en el sistema interactúan entre sí antes de construir el sistema.

Después de una ronda de entrevistas problemáticas y de procesar la información recibida, recibimos una descripción del área temática en forma de ejemplos de uso.



Aunque SCRUM no requiere una especificación de desarrollo, el hecho de que tuviéramos una descripción del área temática preparada fue una gran ventaja. Este documento formó la base de la acumulación de productos: la base para el lanzamiento de SCRUM. Producto acumulado: una lista de requisitos, historias, funcionalidades, que están ordenados por importancia. Con tal lista, todo comienza. Además, todos los requisitos se describen en un lenguaje que es comprensible para el cliente. Los elementos de esta lista son historias de usuarios , "historias de usuarios".

La historia del usuario es una descripción de los escenarios de usuario más simples para usar el sistema, cuya esencia se puede formular de la siguiente manera: "quién, qué, para qué, cuáles son las características y limitaciones".









Nuestra cartera de productos de 203 historias, convenientemente agrupadas por segmento


Ejemplo de historia de usuario

¿Cuáles son nuestras conclusiones después de esta etapa?

1. Nuestros sprints durarán 2 semanas. Por qué Los sprints cortos son cómodos. Permiten que el equipo sea lo más "flexible" posible: listo para ajustar sus planes a menudo. Un sprint corto significa un ciclo de retroalimentación corto, que conduce a lanzamientos frecuentes. Lanzamientos frecuentes = revisiones rápidas de los clientes = menos tiempo para trabajar en la dirección incorrecta = capacitación rápida, mejora, etc.
2. Los sprints largos tienen sus ventajas: menos gastos generales, como planificación de sprints, demostraciones, etc. Pero elegimos los cortos para ser flexibles y tomar menos riesgos.

Sprint : el período de tiempo durante el cual se crea el "Listo", es decir, un producto adecuado para su uso y lanzamiento

Paso # 2: planificación del sprint. Cómo adaptamos la planificación de Sprint

Nuestro primer valor comercial fue una revista electrónica. Para los desarrolladores más experimentados, esto parecerá una utopía: tenemos una hoja en blanco, no hay un solo directorio, interfaz de usuario, sistema de autorización o una sola entidad comercial, y estamos comprometidos a proporcionar una de las funciones más complejas del sistema.



Como fue eso Para nosotros, fue necesario obtener 2 cosas: el objetivo declarado del sprint y el backlog aprobado del sprint.

Nuestro propietario del producto siempre comenzó la planificación del sprint con una descripción de lo que debe hacerse primero, las historias más importantes. Después de eso, el equipo evaluó los costos laborales para todas las historias de usuarios, comenzando por la más importante. En el proceso, el equipo tenía muchas preguntas sobre cómo debería funcionar esto.

La planificación de Sprint es una actividad SCRUM muy importante. Todos son conscientes de la responsabilidad de una evaluación correcta, porque:

• Esto le permite a la empresa comprender qué funcionalidad puede esperar al final del sprint. Seamos un equipo predecible y estemos "en la misma página" con el cliente
• el valor de una media historia realizada es cero, por lo tanto, todas las historias planificadas en el marco de un sprint deben decidirse.
• cualquier cambio en la puntuación durante el sprint se ignora;

El propósito del sprint es para qué sirve el sprint. Lo más importante, el objetivo debe indicarse en términos de negocio, no técnico. Es decir, en un lenguaje que es comprensible incluso para personas ajenas al equipo, y la reserva de Sprint es una selección de historias de la cartera de productos . Es una lista de historias que el equipo identificó como las más importantes en esta etapa y se comprometió a completar durante el sprint.


Ejemplo de reserva de Sprint

Revista electrónica después del primer sprint

Simplificaciones y suposiciones para el primer sprint . En el sistema - 2 usuarios: maestro y padre; una clase - 5 "A"; la composición real de la clase, ingresada manualmente directamente a través de consultas SQL; El horario actual para 5 "A", también formado directamente a través de la entrada en la tabla.

Historia de usuario # 1 : el maestro inicia sesión en el sistema y otorga calificaciones para cualquier materia del horario de clases del día. Un sistema con una función simple pero que ya funciona. Ya en la demostración de sprint, el maestro dijo qué usar convenientemente y qué no, para que en los próximos sprints el equipo pueda planificar las correcciones y proporcionar una herramienta actualizada.

Qué da el valor real: rendimiento digitalizado de la clase real, evaluaciones actuales, la perspectiva para la preparación automática de informes mensuales, semestrales y trimestrales.

Historia de usuario # 2 : Un informe semanal a los padres sobre el desempeño en el correo.

Qué valor agrega: informar a los padres sobre el desempeño actual; comentarios del maestro sobre la tarea; Analítica mínima pero real.

Después de varios sprints, decidí que había suficiente funcionalidad para que los maestros trabajaran con un diario electrónico. Por lo tanto, detuvimos el desarrollo de esta herramienta y cambiamos el enfoque al diseñador del cronograma. Esto es normal para SCRUM. Regresé a la revista electrónica el enfoque de desarrollo después de una docena de sprints, y, después de descartar parcialmente la funcionalidad simplificada, llevamos la revista electrónica al estado necesario para el análisis del rendimiento anual. Necesitábamos esta funcionalidad en ese momento. Hemos ganado suficiente valor y hemos cambiado el desarrollo activo a partes de mayor prioridad del sistema.

Svyatoslav, dueño del producto

Como referencia : para arreglar la versión final (ideal), tuvimos que volver al diario electrónico para varios sprints.


Así era la revista después del primer sprint, pero ya era posible trabajar con ella.


Esta versión de la revista electrónica fue recibida después de 12 sprints y podría mostrarse a los padres.

Otro ejemplo vívido de un enfoque SCRUM iterativo es el constructor de programación.

El cliente recibió el primer diseñador de cronograma 2 meses después del inicio del proyecto. Era un "editor brutal" para un usuario muy avanzado. Pero nos permitió presentar un horario para todos los quintos grados y probar el sistema en un horario real en vivo.

Se necesitaron tres sprints para refinarlo al "editor visual". El enfoque de desarrollo se ha cambiado varias veces, pero al comienzo del año escolar, el cliente recibió un diseñador de horarios completamente funcional, con la ayuda de la cual introdujo el horario desde el primero (A, B, C, D) hasta los estudiantes de octavo grado en solo una hora.

Sigamos la ruta "editor brutal para un administrador real" - "editor visual" - "diseñador de horarios"

¿Y cómo hiciste el horario antes?

El cronograma se dibujó en hojas pegadas de papel Whatman A1 manualmente: pintado, resaltado con marcadores de colores, pegado. El director tomó semanas y meses para hacer esto.


La primera versión del editor: "Brutal editor for the admin", que hizo el calendario para 2018


La segunda versión mejorada, con la ayuda de la cual se realizó el calendario 2018/2019


Schedule Designer - Versión final

¿Cuáles son nuestras conclusiones después de esta etapa?

1. Cada sprint debe tener un objetivo claramente definido.
2. Simplificar la funcionalidad y luego desarrollarla es normal. Por qué SCRUM es tan bueno: no hay una sola forma correcta en el desarrollo de productos. Este no es un tutorial con tareas y respuestas correctas al final. Siempre puede considerar muchas opciones alternativas y ejecutarlas en diferentes secuencias. Si al final del sprint el cliente recibe un valor completo con el que puede trabajar, probar, ingresar nuevos datos, y esto avanza a la tarea final global, esta es la forma correcta.
3. La filosofía principal de SCRUM: no perseguir un código hermoso al principio, sino concentrarse en darle al cliente una herramienta de trabajo. Por lo tanto, puede soportar errores en el curso del trabajo, pero debe comprender: la mejor manera de identificar estos errores es dejar de pensar en el código ideal a nivel de arquitectura y diseño, y primero darle al negocio un prototipo que funcione.
4. Es importante durante la discusión realizar cambios en la historia del usuario y guardar y adjuntar todos los artefactos a las tarjetas.

Cómo hacer que un equipo evalúe la historia del usuario de manera realista

El equipo siempre evaluará adecuadamente la historia del usuario si se cumplen las condiciones: se describe en detalle el comportamiento del usuario real , se indican los límites de uso y los supuestos, se enumeran los criterios de aceptación . Es decir, el equipo comprende el "qué" debe hacerse y sugiere aproximadamente el "cómo".

Por qué es importante formular "criterios de aceptación" y "límites de uso": esto proporciona la misma comprensión del alcance del trabajo para las historias tanto del propietario del producto como del equipo.

Escala de calificación, o SCRUM-poker

En SCRUM, la evaluación de la historia se lleva a cabo no en horas o días, sino en puntos de la historia. Esta es una mezcla de complejidad, riesgo y esfuerzo que un equipo debe gastar para completar una historia. Para cada equipo, 1 punto de historia es un valor empírico individual, pero cada miembro del equipo lo siente.

Tenga en cuenta que la secuencia de valores en las tarjetas no es lineal. Por ejemplo, no hay nada entre 13 y 21. Por qué



En primer lugar, esto es necesario para evitar la apariencia de una falsa sensación de precisión para grandes clasificaciones. Si la historia se estima en aproximadamente 17 puntos de la historia, entonces no tiene sentido discutir si debería ser 15, 18 o 21. Todo lo que necesitamos saber es que la historia es difícil de evaluar. Por lo tanto, le asignamos una calificación de 21. Aproximadamente.

En segundo lugar, las personas tienden a exagerar sus capacidades, y la escala no permite que haya mucho error con la evaluación del tiempo y los recursos. Por ejemplo, el equipo acordó que 6 puntos de historia son suficientes para una de las tareas. Pero si no está seguro de que 5 es suficiente, entonces es mejor elegir 8. Esto le permite establecer términos reales en los que el equipo encajará exactamente. Además, ayuda a iniciar un diálogo entre los participantes, compartir su visión de la implementación de la historia , expresar los riesgos y llegar a un consenso.

Muy importante : cada miembro del equipo debe dar una evaluación. Por qué

• Para una evaluación razonada, cada participante debe comprender perfectamente cuál es la esencia de esta historia. Al recibir una evaluación de cada miembro del equipo, nos aseguramos de que todos sepan lo que está en juego. Esto aumenta la probabilidad de asistencia mutua durante el sprint. Y lo más importante: las preguntas más importantes de esta historia surgirán lo antes posible.
• Una visión integral del problema conduce a una amplia variedad de evaluaciones. Tales desacuerdos se identifican y discuten mejor lo antes posible. Después de discutir los desacuerdos: reevaluación, votación. Por lo general, un par de ciclos de evaluación son suficientes para aclarar los puntos principales y crear una comprensión común.

Mostramos esto con el ejemplo de una amplia variación en la estimación de una de las historias. La historia se llamaba Buzz .

Importante : durante la planificación, generalmente no sabemos quién realizará esta o aquella parte. La implementación de la historia del usuario requiere la participación de especialistas para diferentes tipos de trabajo: arquitectura, front-end, back-end, pruebas, preparación de datos reales. Por separado, existe un grupo de trabajos como diseño y diseño de interfaz de usuario.

Estuche brillante: zumbido

En el sistema de gestión escolar, surgen muchos eventos de diversos grados de importancia. Por ejemplo, un estudiante recibió una calificación; se ha producido un reemplazo, y en lugar de matemáticas habrá biología con otro maestro; Se ha producido un incidente molesto con el estudiante y los padres deben ser informados de inmediato; El profesor escribió un comentario importante sobre el DZ.

Es inconveniente para los usuarios enviar estos datos por métodos estándar a mensajeros instantáneos o por correo, y de hecho ayer. Además, los mensajes pueden relacionarse con varias personas a la vez: el maestro debe enviar a los padres que el alumno dejó la escuela durante la lección. En el documento original, estas reglas se recopilan en 10 páginas.


Zumbido en la implementación final

Estuche brillante: zumbido

Estamos discutiendo entre los desarrolladores cuánto estimamos la cantidad de trabajo en la historia de Buzz.



Todos hablan cuántos puntos de la historia se requieren. Resultó que tenemos grandes diferencias de opinión, y llamamos la atención sobre opiniones extremas: por qué alguien calificó 50 y su colega confía en 5 puntos de historia. Así que de inmediato descubrimos requisitos no detectados que fueron notados por un desarrollador más cauteloso. Además, se han revelado tareas globales relacionadas con la personalización. Este es un gran ejemplo de cómo un equipo puede anticipar dificultades.

¿Qué conclusiones hemos llegado con respecto a la metodología de evaluación?

1. Sí, es normal que el diseñador de control de calidad y UX haga una evaluación del historial técnico.
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

La reunión diaria de SCRUM, o stand-up, y todo el SCRUM es una historia sobre comunicaciones efectivas que ayudan a ahorrar tiempo y esfuerzo al equipo. Estas no son solo "reuniones" y "conversaciones". No toman el tiempo que se podría dedicar al trabajo, pero ayudan a optimizar los esfuerzos. Uno de los principios de SCRUM es: "Las personas y la interacción son más importantes que los procesos y las herramientas".



Cada miembro del equipo informa brevemente, de acuerdo con una lista de verificación especialmente diseñada, qué hizo, qué problemas enfrentó, qué hará a continuación. Una persona no se queda sola con un problema, se le ayuda rápidamente a resolverlo de la manera más efectiva. Por lo tanto, un ingeniero no pasa tiempo en intentos fallidos, después de lo cual es posible que tenga que rehacerlo desde cero, ahorrando así los recursos de todo el equipo.

Funcionalidad cruzada: el equipo está listo para realizar cualquier tarea de lanzamiento del producto.

Al formar el equipo, seleccionamos especialistas en T que están versados ​​en muchas áreas y al menos uno es un experto. Gracias a esta versatilidad, todos los ingenieros conocen el sistema bastante bien.

La experiencia de todos es valiosa para encontrar la solución más efectiva.

En un equipo, una persona puede no tener la experiencia necesaria para una tarea específica, pero con una alta probabilidad tendrá sus colegas. Lo mismo por parte del cliente: una persona puede no conocer algunos detalles, pero otra persona los conoce.

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. Es necesario cambiar el énfasis y comprender que un SCRUM diario es necesario para la comunicación y no para la administración.
3. Cada sprint posterior debe tener en cuenta la experiencia de los anteriores.

Cómo llevar a cabo una reunión diaria de SCRUM

Paso número 4: cómo realizamos una demostración de los resultados. Nuestra adaptación de sprint demo

Los desarrolladores se turnan para demostrar la nueva funcionalidad en vivo con datos reales. La atención se centra en lo que hemos hecho y no en cómo lo hicimos. En general, nos esforzamos constantemente por hacer que nuestra demostración esté orientada a los negocios, sin mencionar los detalles técnicos.

Cómo averiguar si una solución se adapta al cliente

Aquí nuevamente el objetivo del sprint se destaca . A nuestras demostraciones asistieron a menudo maestros y directores especialmente invitados que no estaban planeando. Conocían el producto solo en términos generales. Siempre agradecemos que después de cada historia demostrada, los propios clientes intentaran hacer algo en el sistema. Luego, el usuario final verifica cada elemento del criterio de aceptación. Él dice qué se adapta y qué no, qué aspectos se pueden mejorar. Y así, para cada historia de usuario que se planeó para este sprint.





¿Qué conclusiones hemos sacado sobre la metodología para demostrar los resultados?

1. Composición obligatoria para la demostración: propietario del producto, scrum master, representantes de clientes y usuarios finales que trabajarán con la herramienta, equipo.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

Para nosotros, la retrospectiva es un evento importante justo después de la demostración de Sprint. Las retrospectivas son útiles, especialmente cuando algo sale mal. Sin retrospectivas, puede resultar que el equipo pise el mismo rastrillo una y otra vez.



Cómo asegurarse contra la repetición de errores

El rastrillo más común es cuando el rendimiento real del equipo es muy diferente del previsto. El rendimiento real se calcula en función de una evaluación inicial de cada historia. Y cuando en medio del sprint nos damos cuenta de que la historia, estimada en 5 puntos de historia, se realiza tanto como la tarea generalmente toma 13 puntos de historia y está lejos de completarse, y si también es una historia de bloqueo, otras no pueden comenzar porque imprudencia problemática. Cuando los objetivos del sprint están en juego, la retrospectiva es inevitable.

Nuestras retrospectivas tienen una estructura y objetivos absolutamente claros: el equipo se une. Scrum Master lee el retraso del sprint, le pide a cada miembro del equipo que hable y evalúe los resultados del sprint desde su punto de vista. Cada miembro del equipo expresa su opinión de que fue posible hacerlo bien, qué salió mal y, lo más importante, por qué. Qué seguir haciendo y qué rechazar. Sin embargo, nadie lo interrumpe. Coloca sus conclusiones registradas en la etiqueta en una de las columnas:

• esta bien
• podría ser mejor
• necesita arreglar

Un ejemplo de nuestras mejoras basado en una retrospectiva.

• Cuando un desarrollador hace un front-end y comenzamos a implementarlo, es necesario que los diseñadores sean 100% accesibles.
• Discuta con PO la inclusión de horas metodológicas.
• En ergonomía, es importante obtener la mayor cantidad de documentación.
• La deuda técnica no se debe acumular. Alinee el 10% para historias técnicas con PO.
• Debe haber un especialista que resolverá los problemas técnicos a medida que surjan.
• Antes de cada planificación de sprint, es imprescindible llevar a cabo la preparación del sprint.

“Después de que el equipo haga una lluvia de ideas sobre todas las calcomanías problemáticas, llevaré a cabo una“ votación al azar ”: cada miembro del equipo tiene tres votos (tres puntos de marcador en las calcomanías). Puede emitir todos sus votos a la vez a un problema, o puede distribuir de manera diferente. Según este voto del equipo, seleccionamos 2-3 mejoras en las que nos enfocaremos en el próximo sprint. Y al comienzo de la próxima retrospectiva, comprobaremos qué sucedió. Por decir, "revisando la tarea" :) "

Pavel Kamyshov , entrenador ágil

Sí, SCRUM requiere la inclusión activa de todos los miembros del equipo. Para actividades como aseo, planificación, SCRUM diario, nos llevó alrededor del 12% del tiempo pagado; este es un tipo de precio por transparencia, previsibilidad y reducción de riesgos.

Una semana de trabajo puede ahorrar una hora de planificación.

Pavel Kamyshov , entrenador ágil de Scrum Ucrania

El 12% es mucho, pero vale la pena, ya que en la clásica "cascada" el precio del uso de la metodología es una función separada para el gerente del proyecto. En promedio, aproximadamente el 15% del costo de desarrollo se gasta en administración en nuestro segmento de mercado.

¿Qué conclusiones hemos sacado sobre la metodología retrospectiva?

1. Para nosotros, la retrospectiva es el segundo evento más importante en SCRUM después de la planificación del sprint.
2. Cada miembro del equipo habla para que todos estén en el mismo campo de información.
3. Cada cambio tiene un precio. Debe aceptar que PO incluya historias técnicas y horas metodológicas en el backlog de Sprint.
4. Las horas metodológicas son pagadas por el cliente.

La retrospectiva de Sprint es una oportunidad para que un equipo realice una inspección dirigida a ellos mismos y cree un plan para mejorar el trabajo en equipo en el próximo Sprint.

Paso número 6: cómo adaptamos el refinamiento de la cartera de productos

Muchos colegas que están familiarizados con los detalles específicos de TI dudan: cómo puede ser tan claro para un equipo durante la planificación del sprint que está listo para evaluar todas las historias de los usuarios.



Sí, de hecho, sin la preparación de tal coherencia no funcionará. Para que esto funcione de esta manera, hay una actividad SCRUM especial: refinamiento de la cartera de productos. Para llevarlo a cabo, debe pedirle al propietario del producto que le dé un horizonte de planificación: describa qué historias pueden ser candidatos para el próximo sprint. Si hay historias entre ellas que requieren un estudio en profundidad o competencias especiales que el equipo no tiene, se convoca una reunión: preparación / planificación previa.


Resultados de aseo

El propietario de nuestro producto era muy competente, por lo que siempre teníamos un horizonte de visión suficiente de cómo se desarrollaría el sistema y realizábamos mejoras de forma regular. De hecho, la transparencia es uno de los principios fundamentales de SCRUM.


Parece un plan de aseo

¿Qué conclusiones hemos sacado sobre la metodología de refinamiento?

1. Este es un evento importante que nos permite aclarar lo que no sabemos, qué competencias nos faltan. Entonces, una vez que se decidió atraer a un consultor desarrollador externo en temas específicos, cuya solución no teníamos en ese momento.
2. Estas discusiones fueron muy efectivas con nosotros, consideramos muchas alternativas y opciones, lo que nos permitió tener en cuenta el problema, y ​​para la planificación del sprint, la historia más complicada ya estaba "presentada".
3. Problemas complejos, aparentemente insolubles, encuentran soluciones claras. A veces es suficiente comprar una biblioteca que desarrollar un sitio complejo usted mismo.

El refinamiento es la base para estar listo para dar una evaluación de la complejidad de las historias en diferentes condiciones de implementación durante la planificación del sprint, porque necesitamos comprender su volumen y complejidad.

Falla

Sí, estamos sinceramente encantados con el desarrollo de la metodología SCRUM, pero esto no significa que todo haya salido bien. Aquí hay tres puntos donde pondríamos pajitas si supiéramos de antemano que iría de esa manera.

Trabaja en patrones familiares

En una de las retrospectivas, analizamos en detalle la razón de la desviación anormal de la "productividad real" del equipo en todas las historias que involucran a diseñadores. El rendimiento real generalmente se calcula utilizando la fórmula: rendimiento proyectado / rendimiento real.

Descubrimos por costumbre que se organizaron en la cascada secuencial familiar.

Como resultado: las tareas se llevaron a cabo secuencialmente, los desarrolladores pasaron tiempo en el encendido secuencial en diferentes etapas con retrasos causados ​​por la necesidad de completar las tareas ya iniciadas.

Conclusión: Quizás la historia más dolorosa para nosotros, que hizo el mayor daño y no fue revelada de inmediato. Es necesario verificar regularmente si todos los miembros del equipo han cambiado a trabajar de acuerdo con los nuevos estándares.

Trabajo extra en funcionalidades innecesarias

En el segundo sprint, el propietario del producto sucumbió a la opinión de uno de los directores, que creía que el "diario del curador" era una funcionalidad extremadamente importante. Tomamos esta historia en un sprint, gastamos el esfuerzo en ello.

Por qué un error: esta herramienta solo se pudo probar en las etapas posteriores, ya que necesitaba datos acumulados, que en ese momento no estaban allí.

Como resultado: no se probó, no se usó, no se desarrolló. Las funciones necesarias se resolvieron de manera diferente y no en la forma en que pensaba el director, a través de herramientas completamente diferentes. Conclusión: tome en el trabajo solo lo que comenzará a usar de inmediato.

Igual a usuarios avanzados

En una etapa, desarrollamos la historia con el "editor de reemplazo", en cuyo desarrollo participó un maestro, un usuario de computadoras muy experimentado. Como resultado, obtuvimos una gran herramienta, pero no podía ser utilizada por maestros de escuela ordinarios que no eran tan avanzados.

Conclusión: confirme la historia en clientes habituales.

Conclusiones generales

Conclusión número 1

Flexibilidad profesional: SCRUM te permite ser un equipo efectivo

Los resultados de cada sprint dependen de las tareas introductorias, la eficiencia, la coordinación, la responsabilidad del equipo y la retroalimentación de calidad.

La entrada es dada por el propietario del producto. También es responsable del contexto en el que se utilizará la funcionalidad, la calidad de la formulación de requisitos, proporciona una profundidad de detalle suficiente.

SCRUM requiere que el equipo complete un trabajo completamente tangible, lo que les permite obtener valor, es decir, una herramienta que se puede proporcionar al usuario al final de cada iteración. Esto ayuda a ver la solución en el trabajo y en las etapas iniciales para comprender qué se debe cambiar para seguir adelante.

Conclusión número 2

Sobre el uso más eficiente de los recursos

SCRUM: una forma de organización del trabajo que es beneficiosa para el cliente y el contratista. Que?
Trabajar con iteraciones que ya se encuentran en las primeras etapas le permite comprender qué está sucediendo mal, lo que significa que necesita hacer ajustes a tiempo. La preparación para cada sprint y los detalles de su organización ayudan cada vez a hacer solo lo que el cliente necesita y no irse a un lado. Y proporciona una EFICIENCIA tremenda de los recursos, el tiempo y los esfuerzos gastados.
En las etapas iniciales, el cliente recibe una sección de trabajo del sistema: después de los primeros sprints, toma la funcionalidad que ha hecho en el trabajo y la prueba en la práctica.

SCRUM - cuando ambas partes están aseguradas contra riesgos

Vea cómo se comparte la responsabilidad entre el cliente y el contratista
La barricada desaparece, en ambos lados de los cuales el contratista y el cliente están en la gestión clásica del proyecto. En principio, los puestos de clientes y contratistas desaparecen, el equipo permanece. Y no hay condiciones para una posible confrontación.

CLIENTE

El cliente paga solo si se han alcanzado todos los objetivos de sprint. Si no se desarrolla una herramienta que el cliente pueda ejecutar en la práctica mañana, el sprint no cuenta.

El cliente paga una cantidad fija por cada sprint y hace que su negocio sea un paso más eficiente

Artista intérprete o ejecutante

El contratista está interesado en preparar una nueva herramienta, un nuevo valor para el cliente durante cada sprint, ya que esto dará una nueva ronda de comentarios e información / experiencia. Que se puede utilizar para un mayor desarrollo del producto.

Cada sprint aumenta el nivel de competencia del ejecutante, lo acelera en la implementación del proyecto.

En total, en solo 7 meses, creamos un sistema que funcionó y fue completamente satisfactorio para el cliente, probado por él en la práctica y reflejó todos los deseos, y no proporcionó un sistema diseñado teóricamente de acuerdo con las especificaciones técnicas, que necesitaría completarse unos meses más, ya que la práctica inevitablemente haría sus propias correcciones.

A nivel mundial, este caso se trata de una técnica de gestión de proyectos seleccionada correctamente en condiciones de alto grado de incertidumbre y un tiempo limitado antes del lanzamiento.

Con un cliente tan exigente, con altos estándares de calidad, a veces fue muy difícil para nosotros, pero al mismo tiempo muy interesante. Esos desafíos que superamos, los errores cometidos, sin embargo, a tiempo, conscientes y corregidos, las conclusiones hechas, cambiaron para siempre la cultura de nuestro equipo.

Probablemente durante mucho tiempo todos estaban interesados ​​en conocer el producto en sí, que resultó.

El cliente recibió un excelente producto: un conjunto de herramientas para una escuela moderna que puede transformarlo rápidamente en una escuela del futuro