SCRUM: un poema sobre el amor y el dolor.



Si es tan bueno, ¿por qué no todos trabajan solo de acuerdo con esta metodología? Y aquellos que supuestamente lo implementaron a menudo muestran un monstruoso ScrumBut. Un verdadero SCRUM deja cicatrices, heridas y marcas en tu corazón, y ahora contaré sobre el mío.

Dolor de scrum


Cuando lo intenté por primera vez, ya era joven y entendí esto. Me enamoré del libro Jeff Sutherland SCRUM: The Art of Doing Twice the Work in Half the Time. Es cierto que hacia el final me pareció un poco fanático cuando comenzó a contar cómo la metodología ayuda en la escuela y en la medicina. Pero realmente aprendí mucho de Sutherland e inmediatamente decidí probar esta técnica en mi equipo. Los escasos dolores comenzaron.

Demoras y demoras en las reuniones.


¿Qué sucede si desea cumplir con los stand-ups de 10 minutos y alguien llega 15 minutos tarde? Primero, todos lo están esperando, y luego quiero entrar en detalles, y la espera se retrasa por una hora. Y si alguien no ha llegado a ninguna reunión, ahora está fuera de contacto con los eventos y vuelve a preguntar todo. Todo esto lleva al hecho de que nadie ha comenzado a trabajar, pero todos ya están cansados ​​de una reunión viscosa. En primer lugar, tuve que trabajar en la disciplina: sin demora, sin argumentos, sin entrar en detalles. Para ser honesto durante 5-10 minutos, el scrum revitaliza, pero ¿en qué se diferencia de las reuniones soviéticas tradicionales de la mañana?

Disputas, discusiones detalladas y objetivos.


Le dices al equipo "tenemos 5-10 minutos", y ellos te dicen que si no resolvemos este pequeño garabato, no podremos seguir adelante, y nos bloqueará a todos. O peor aún: necesitamos ver un concepto y una estrategia generales, no podemos trabajar sin él, así que aplastemos los excrementos en un mortero. Se necesita una estrategia y un concepto general, deben ser atendidos antes del comienzo, si no están allí, entonces no debe ir en ciclos y ralentizar el trabajo de las disputas.

Nos enfrentamos al hecho de que es muy difícil comenzar un sprint sin comprender el objetivo global de la empresa como un equipo completo:

Scrum master: "¡Formulemos el objetivo del sprint: medible, comprensible, alcanzable!"
Escéptico: “¿Y por qué este objetivo debería ser solo eso? ¿Dónde la conseguiste?
... y hubo una discusión durante una hora.

Scrum master: “El objetivo de nuestro producto es eliminar a las personas de las mediciones. ¡Expongamos el objetivo del sprint!
Peppy: "Hagamos un mini módulo que tomará los contadores y los colocará en el plato".
Escéptico: “Bueno, no, pero de repente resulta que este es un trabajo extra, debes entender el proyecto en su conjunto. ¡Quiero tener todo el proyecto en mente! ”
Scrum Master se dispara en la boca con una escopeta ...

Escribiré nuevamente brevemente las condiciones para comenzar el sprint:

  1. Sin demoras
  2. Sin pases
  3. Sin demorar la reunión
  4. Sin argumento
  5. No partes pequeñas
  6. El objetivo global es claro, con lo que todo el equipo está de acuerdo.
  7. Existe la voluntad de que el mini sprint sea erróneo y que el objetivo del sprint se elija incorrectamente.

¡Todo duele mucho, mucho dolor!

¡Tenga todo el proyecto en mente!


... el maestro Scrum que acaba de volver a sus cabales en cuidados intensivos vuelve a caer en coma ...

No hay ningún proyecto y no puede estar en la cabeza, ya que el mundo a su alrededor cambia constantemente. Todo en mi cabeza es solo una ilusión. No hay que tener miedo de hacer demasiadas cosas innecesarias e incorrectas como parte del sprint. Nos movemos en pequeños pasos, por lo que siempre existe la oportunidad de corregir errores. Que discutir durante dos semanas, ¡tomemos dos sprints durante este tiempo, cometamos un error, probamos hipótesis y ganemos la pelea!

Es por eso que dejamos todas las disputas y la democracia a toda velocidad. Cuando comenzó el sprint, no discutamos: los resultados nos juzgarán muy pronto. ¡Listo para el cambio es parte del Manifiesto Ágil!

¡No me digas lo que hiciste ayer!


Cuando tú y tu equipo corren un sprint en el scrum, ¡entonces tienes un lado que lo que queda detrás de ti! Además, a menudo en stand-ups todos se sienten atraídos por decir quién hizo qué ayer. ¿Porqué es eso? Sí, porque es mucho más difícil decir qué quieres hacer hoy, cómo te acercará a la meta del sprint y qué te bloqueará.

Por cierto, si discutimos solo los planes para hoy, entonces prácticamente no hay nada de qué hablar. El futuro tiene muchas menos personas cargadas de emociones que el pasado. Sprint está mirando hacia el futuro. Si sigue este principio, las paradas no tomarán más de 10 minutos.

Dificultades de aseo


Cuando los monos comieron lo suficiente y se sexaron, se sientan para peinar los insectos de la lana del otro. Los miembros del equipo, como ellos, peinan pequeñas tareas con piernas de la corriente general, tratando de hacerlas lo más cortas posible.

A menudo resulta que la tarea no está programada correctamente cuando el trabajo ya ha comenzado. Nadie quiere peinar nada. Como resultado, todos lloran con lágrimas de sangre debido a que son demasiado flojos al principio. Cuanto más pequeña es la tarea, más comprensible y más difícil es cometer un error.

Por lo general, me siento con desarrolladores fuera del sprint y leo cada historia de usuario en voz alta en coro.

¡El propio equipo elige las tareas!


Pero esto es un verdadero dolor para las primicias. ¿Cómo es eso? Después de todo, es mucho más fácil asignar tareas directamente. Como saben, el soviet, es decir, el pueblo ruso no está listo para la democracia, ¡habrá caos!

Y luego resulta que hay tareas sabrosas e interesantes, pero hay tareas aburridas y rutinarias. Y también sucede: ahí está tu tarea, te especializas en esto. Y de repente, alguien que no es el núcleo lo agarra de debajo de la nariz, porque es muy sabroso e interesante.

Deje que duela mucho para los gerentes, pero cuando los miembros del equipo eligen sus propias tareas, obtenemos un mejor rendimiento y una mejor calidad.

... Scrum Master sonríe sin dejar un coma ...

Funcionalidad cruzada


El comando de las fuerzas especiales puede ser un médico, operador de radio, comandante, mecánico. ¿Pero qué pasa si alguien es asesinado? Entonces sus funciones serán recogidas por otros luchadores. Este principio se utiliza en el equipo SCRUM para que no haya "cuellos de botella". Si todo está atascado en uno u otro, entonces el resto del equipo debería renunciar a su trabajo y asumir tareas inusuales para ellos.

Scrum trae mucho dolor a su orgullo profesional: "He estudiado durante tantos años para no atornillar la barra de la cortina".

Fallas


Por supuesto, mi primer sprint terminó en fracaso. Y casi cada primer sprint con un nuevo equipo termina en fracaso. La mayoría de las veces, la razón es que el objetivo del sprint se formuló incorrectamente. Resulta que era inalcanzable e incomprensible, el equipo sobreestimó su fuerza y ​​el cliente bloqueó la mayor parte del trabajo.

Lo más interesante es una retrospectiva de un sprint fallido cuando se acaba el tiempo y no se alcanzan los objetivos. No, no, no vamos a extender el sprint por el día, no, ¡no trabajaremos de noche! Reconocemos la falla y analizaremos con qué nos equivocamos, qué sucedió con éxito y qué podría mejorarse.

Por lo general, después de tal informe, todos se reúnen y el próximo sprint es súper exitoso. En la segunda retrospectiva, todo el equipo comienza a tener un verdadero revuelo del trabajo y, por lo tanto, de la vida en general. Te propones metas medibles, alcanzables, comprensibles, pero complejas, y ahora estás satisfecho por su logro.

El hecho de que el sprint se complete con cualquier resultado reduce la ansiedad y le permite concentrarse en las tareas locales, y esto mejora la calidad de la ejecución.

... wow, nuestros maestros Scrum ya se están transfiriendo de cuidados intensivos a terapia, coma detrás ...

SCRUM es como una llama, te quema cuando hace calor


Burnout profesional! ¡Scrum es la mejor manera de acelerarlo! Si no toma un descanso después de cada sprint, todos se cansarán rápidamente, las paradas se convertirán en una rutina y el trabajo se deslizará a la basura completa.

La satisfacción con la vida se produce cuando establece objetivos audaces, lucha, experimenta el fracaso, se pone de pie y logra resultados. No puedes vivir en este modo para siempre. Completaron el sprint, se tomaron un descanso de una semana: realizaron tareas rutinarias, se fueron de vacaciones, cambiaron a otros proyectos y recuperaron fuerzas para una nueva batalla. Para volver a enamorarte, debes lamer un poco las heridas de la experiencia anterior, y estás listo. Aunque muchos se sienten atraídos por el poliamor, ¡y esto es polibola!

Conectamos al cliente a SCRUM


Incluso si el cliente no es un programador, se drogará, ¡lo prometo! Solo todo debe ser honesto. Un verdadero SCRUM: no puedes tirar partes importantes, convirtiendo todo en el ScrumBut impío. Objetivo del proyecto, trabajo atrasado, objetivo de sprint, el equipo selecciona tareas y ofrece una evaluación, stand-ups diarios, retrospectivas, pausas entre sprints. Si al menos se saca algo de esto, entonces todo deja de funcionar, y el cliente está decepcionado con una metodología flexible.

Sé como Sutherland, sé fanático cuando te digan: "Oh, todo esto es muy inconveniente, SCRUM es bueno, trabajaremos en ello, pero no es necesario seguir todos sus principios".

A menudo, los miembros del equipo me dicen: "¿Cómo puedo hacerlo? Porque el cliente verá el trabajo inacabado y jurará". ¡Ese es todo el punto! Cuanto más rudo sea el prototipo, cuanto más fácil sea criticar, cuanto antes escuche las críticas, ¡menos tiempo y esfuerzo dedicará a las ediciones y mejoras!

Esto es exactamente lo que nos dice Agile Manifesto:

personas e interacción: ¡stand-ups diarios con el cliente y el equipo!
La colaboración con el cliente también se trata de esto.
Disposición a cambiar: ¡cuanto antes hagamos los cambios, mejor!

¿Tan rosado? ¿Y dónde está el dolor? ¡Decir ah! En todas partes: la administración tiene miedo y pospone el inicio del sprint con el cliente, teme que el cliente vea el trabajo no terminado. Hay clientes que desean comprar el producto terminado, como en una tienda, y piensan que los desarrolladores necesitan los standups, no ellos. Y una vez me dijeron: "Queremos que todo sea flexible y que el precio sea difícil".

El precio es difícil, las tareas son flexibles.


... en este lugar, el Scrum Master ya conduce el scrum desde el hospital de forma remota.
Espera, ¿es eso realmente posible? Los científicos todavía discuten sobre esto ...

Muéstrame un desarrollador que no tenga miedo de tal declaración. En su cabeza, las perspectivas de esclavitud de por vida nacen de inmediato. El Director General, con estas palabras, imagina la bancarrota de la empresa y el colapso del negocio. ¿Es este el dolor principal?

¡Resulta que puedes hacer que los precios del cliente sean difíciles con tareas flexibles! Arreglamos el dinero, evaluamos las tareas y entendemos cuáles encajan en el presupuesto y cuáles no. Aquí, por supuesto, caminas por la hoja de un cuchillo. El cliente discutirá con la evaluación de tareas individuales, y el gerente intentará dar una evaluación en lugar de los desarrolladores. Esto solo se puede hacer si todos están de acuerdo con el principio: quien lo evalúa. Para este principio, tienes que luchar duro con la gerencia y los clientes.

Proyectos a gran escala


Algunas personas piensan que la felicidad y la dicha están en grandes proyectos.
Algunos tontos se engañan a sí mismos, supongo
que no me están engañando.
Sé que no es verdad. Sé que no es verdad.
Los proyectos a gran escala son solo una mentira que termina en una cara azul. Según las estadísticas, la mayoría de los proyectos pequeños sobreviven.
Para cambiar el mundo, un pequeño equipo es suficiente.

Por lo general, un proyecto exitoso a gran escala es una serie de pequeños proyectos interesantes. Lo principal es un producto que funcione, como nos dice el manifiesto. No persigamos la escala, sino comencemos con una pequeña, pero rápida, flexible y que funcione.

Cuanto más grande es la empresa, más grande es el proyecto, menos flexibilidad tienen. Es por eso que SCRUM se enfoca en un pequeño proyecto que se puede hacer en un sprint de 1 a 3 semanas y un pequeño equipo de 2 a 7 personas.

Al mismo tiempo, se pueden realizar equipos muy grandes y tareas muy grandes de acuerdo con una metodología flexible, para esto debe dividir todo en tareas pequeñas y equipos pequeños.

En el residuo seco:


  1. El trabajo de scrum duele.
  2. Es necesario trabajar en Scrum, ya que ganar garantizado
  3. Debe seguir la metodología de manera clara y fanática sin caer en ScrumBut; esto es lo más difícil y doloroso.
  4. Involucramos a los clientes y a la gerencia en SCRUM al máximo; esto no es tan doloroso como parece.
  5. Cortamos todos los proyectos a gran escala en pequeños, aunque esto duele mucho.

Fuentes de placer:


  1. Manifiesto para el desarrollo de software ágil
  2. ¿Qué es ScrumBut?
  3. Canción de SCRUM HURTS

Una explicación para el dolor, especialmente para Masha:


El dolor generalmente es que tienes que cambiar todo a lo que estás acostumbrado. El dolor causa una sensación de pérdida de control y un proceso incontrolable cuando confías tus tareas favoritas a los miembros del equipo y temes que abrumarán el proyecto. El dolor llega cuando pisas la garganta de tu propia canción y terminas proyectos a gran escala.

El dolor pasa cuando las tareas son muy pequeñas, e incluso el feroz fakapa de los participantes no abruma todo el proyecto. Se hace más fácil cuando dejas de preocuparte y esparces la paja en todo el proyecto de inmediato, cuando te relajas y cortas una tarea a la vez.

All Articles