¬Ņ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

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


All Articles