En un modelo de gestión represivo, un líder, por regla general, seleccionará a los empleados más estúpidamente que él mismo, o aquellos a quienes pueda "hipnotizar" o chantajear de una forma u otra. Están buscando "perros" que sean fáciles de manejar y fáciles de envenenar. Las instrucciones idiotas que bajan desde arriba se enviarán sin cambios, y aquellos que puedan representarlas a continuación sobrevivirán, el resto estallará. habr.com/post/124716
¿Es todo tan malo con el liderazgo del equipo? Ya sea para imponer un scrum formalmente cuando nadie comprende su necesidad, y realmente no se siente, o introducir sus elementos gradualmente, para que el equipo sienta su efectividad.
Los conflictos de intereses son una situación frecuente en los colectivos laborales y no solo en los programadores. Y a menudo no hay derecho y culpa, hay un choque de experiencias y visiones. Cómo liberar el potencial de todos los empleados y obtener sinergia cuando 1 + 1 = 11, no 2.
Inspirado después del mundial de fútbol. La historia de la retirada de Scrum. Todos los eventos son ficticios, todas las coincidencias son aleatorias. Una situación generalizada y muy simplificada.
Entonces, el equipo está formado, analista, front-end, full-stack-back-end. No scrum. El equipo está formado por un líder de equipo bastante competente, diversificado y experimentado que tiene amplios poderes. La gerencia de la empresa le delega plena autoridad.
Para una analogía, imagine que un proyecto es una liga de fútbol. todo el equipo con una falla, es decir, un proyecto fallido o prolongado. El éxito se considera un producto de alta calidad y entregado a tiempo, es decir, la posición más alta del equipo en el campeonato de acuerdo con los resultados de todos los juegos. Los juegos son sprints. Sprint: una iteración en el scrum, durante la cual se crea el crecimiento del software. Está rígidamente fijado en el tiempo, como un partido de fútbol. Descripción general del primer partido (sprint), la situación es bastante real.
Inicio del trabajo en el proyecto (primer semestre, todo va bien, gol 1 - 0)
Por lo tanto, el silbato y los jugadores con experiencia suficiente individualmente, pero que no juegan juntos, hacen su trabajo muy bien. El analista establece las tareas, el front-end realiza la aplicación en el backend mok. Al principio, todo va bien, el diseño, la arquitectura del proyecto, las páginas se crean rápidamente, el cliente recibe resultados rápidamente, el equipo recibe comentarios de él. Todos son felices
El backend se desarrolla por separado, se está construyendo la arquitectura, se está creando una base de datos, se están lanzando métodos aproximados.
Back-end no orientado al cliente (momento peligroso, objetivo, ayuda deficiente en la zona media, 1 - 1)
El analista, que muestra muy buenas cualidades individuales, transfiere la tarea al equipo, la pantalla y la descripción.
El front-end, recibe un pase, escribe el formulario, escribe el código del cliente, pasa el pase al fullstack-bekender. Y espera algo como:
Obtener / algún / método
Fullstek-backender (capitán del equipo, también conocido como líder del equipo) tomó un pase y da:
Como regla, las pilas completas tienen un conocimiento superficial en áreas (simplemente porque físicamente no pueden cubrir todo profundamente), pero ven todo el proyecto como un todo. Son buenos en proyectos pequeños donde hacen todo por sí mismos y no son efectivos en el desarrollo del equipo.
Hubo una pausa y desconcierto, cuando se le preguntó por qué, silencio e ignorar, el líder del equipo sabe lo que está haciendo. Con transmisiones repetidas y preguntas posteriores, ¿por qué? Respuesta: "Confía en mí, sé lo que estoy haciendo, no tienes una visión del sistema en su conjunto". Mientras que el empate es 1-1. Y aquí no se puede hacer nada, ni para el favorito ni para el liderazgo.
Trabajo en equipo débil (información, objetivo, 2-1 leads de fakap)
Frontender piensa y se esfuerza. ¿Qué necesitas lanzar en la pantalla? Pregunta de nuevo, pero la interacción no se pega. Tim-leader-full-stack-beckender está nervioso, arrojó respuestas. "¡Piensa!" "Es más fácil para mí hacerlo yo mismo", "Kicker". El juego no se pega, el equipo pierde el segundo gol.
Fortalecimiento mediante el desarrollo del equipo (el tiempo no es a favor del equipo, el puntaje de 2-1 es el mismo)
El delantero no adivinó los parámetros, aprendió a predecir la dirección del pase, pero aún así hubo un matrimonio en el juego. El proveedor front-end no percibe todo de oído y solicita herramientas de desarrollo de equipo (Redmine, Jira, Trello). El liderazgo se va a encontrar. Comenzó con tareas, como:
Saludo -> ??? (qué campo tomar de los datos)
Parámetro 1-> ??? (qué campo tomar de los datos)
Parámetro2 -> ??? (qué campo tomar de los datos)
En aras de la claridad, los datos se limpian directamente a la llegada desde el backend y en una forma comprensible se arrojan en html. El juego se ha estabilizado, pero el tiempo se acaba, la cuenta es la misma a favor del fakap.
Lesión, refactorizando el código, (El equipo recupera, pero pierde el gol 3-2)
El front-end se lesiona y abandona el campo por un tiempo (vacaciones planificadas), en este momento el back-end, se arrastra al código frontal, pasa tiempo refactorizándolo y desenreda heroicamente los datos del back-end directamente en html. Objetivo rápido, genial! Pero en respuesta, recibe errores del analista y tareas pendientes para el sprint actual. Sí ... el equipo recibió rápidamente un gol de regreso. Beckender cae en la lista de los mejores anotadores. Frontender se recuperó rápidamente y volvió al juego. Pero dado que los pases no salen y el líder del equipo se las arregla solo, el frente aún no está muy involucrado. El silbato final, el partido ha terminado. 3-2 el equipo perdió, pero antes del próximo juego (sprints).
Retrospectiva de Sprint (Análisis del primer juego, front-end en el banco)
En scrum, para identificar problemas en las primeras etapas y un autoajuste flexible del equipo, el maestro scrum (entrenador del equipo) realiza los sprints de forma retrospectiva, pero dado que no está en el club. Frontender lo inicia. Reúne a todos los participantes y explica la falacia de negarse a jugar el pase, ya que un momento no puede mejorar el juego del equipo durante todo el campeonato (final del proyecto), y pide a todos los miembros del equipo que hablen. En respuesta, el capitán del equipo - líder del equipo - full stack, ofrece transferir el front-end a otro proyecto, ya que las opiniones de los jugadores no molestan a nadie. El equipo está en silencio, la dirección del club también. La transferencia se retrasó, el front-end flotando en el banco.
¿Cómo operar la gestión del club? ¿Líder de Tim o maestro de scrum? Discusiones abiertas, expresión de opiniones u órdenes únicas del líder del equipo. De hecho, no hay una respuesta correcta. Para aclarar la situación, debes ingresar a un probador y ver el juego en algunos sprints más. Todo depende del tamaño del proyecto.
Epílogo (ha pasado el tiempo):
Muchas gracias por los comentarios!
Cual es nuestra vida El juego ...
Buenas tardes, en el club intelectual. Donde Cuando El único lugar donde cada espectador puede ganar dinero con su propia mente ...
Entonces silencio en el pasillo.
Estimados expertos (scrama). Una vez más, llamo la atención sobre el hecho de que el artículo al principio enfatizaba claramente que lo que el equipo estaba haciendo no era un scrum, sino que solo se describía un intento de mostrar una lucha.
Scrum es como el póker, tiene reglas muy simples pero muy estrictas. Pero al mismo tiempo, el póker y el scrum son juegos muy difíciles.
Ahora, la atención es la respuesta correcta.
En el proceso, se violó una regla de scrum muy simple y básica. Hay pocos roles en scrum y están claramente explicados. No hay un rol llamado líder de equipo. La tarea del scrum master es monitorear claramente la implementación de esta regla. Y detener cualquier intento de violarlo. En pocas palabras, el caos del backend fue al frente y el proyecto tropezó.
Scrum es un marco de desarrollo de software flexible. El marco se basa en un método empírico (basado en la experiencia) y está destinado al desarrollo de productos de ALTO valor en un entorno complejo. en.wikipedia.org/wiki/Scrum
Ronda. 1-0 - a favor de los espectadores. Los entendidos van a un descanso musical ... y se preparan para la próxima ronda.