Sustituto flexible
La palabra "Scrum" se refiere al menos a dos entidades: la filosofía y el marco.
La filosofía, o enfoque del trabajo, se describe en un libro de Jeff Sutherland.
Marco, es decir un algoritmo de acciones descrito en un documento llamado la Guía Scrum.
La filosofía se convirtió en un marco porque los autores de la filosofía querían ganar dinero con ella (en sus propias palabras).
El marco se simplifica enormemente en comparación con la filosofía. Lo principal es que el objetivo se ha simplificado, o más bien se ha eliminado.
El propósito de la filosofía: acelerar el logro de resultados. Por otra parte, a veces. Hay 8 veces ejemplos de aceleración en el libro.
El objetivo del marco es tener Scrum. Lo dice: hazlo de acuerdo con las instrucciones: tienes Scrum, infringe las instrucciones, no tienes Scrum.
El marco no implica acelerar el logro del resultado, en general.
Las personas que enseñan o implementan Scrum trabajan con el marco. Hablan e implementan un algoritmo que no conduce a ningún resultado que no sea "ahora tenemos Scrum".
El punto está claro. La filosofía es muy difícil de vender. El marco es más simple.
Un marco es un producto. Él, como se esperaba, pasó el "empaque". Es simple, comprensible, hay soporte y muchos especialistas. ¿No se parece a nada?
Todo es bueno, excepto el resultado, no lo es.
Si el cliente no está familiarizado con la filosofía de Scrum, entonces la implementación del marco lo satisfará perfectamente.
Si el cliente está familiarizado con la filosofía Scrum, se sentirá decepcionado con la implementación del marco; no habrá aceleración para lograr el resultado.
Será genial, moderno, moderno, pero no se lograrán objetivos comerciales (excepto el desarrollo del presupuesto para "algo nuevo").
Como ser Aprende la filosofía de Scrum. Se basa en la filosofía japonesa de gestión de calidad, cuya esencia es: mediciones y mejoras infinitas.
Desafortunadamente, hay que pensar, experimentar, observar y, por desgracia, trabajar mucho. Si esto no le conviene, tome el marco.
habr.com/en/post/345540Entorno variable
Para aumentar la eficiencia de un equipo de programadores, se necesita un entorno variable. Ya existe algún tipo de entorno en el equipo, necesitamos que sea cambiante.
Un entorno mutable es la falta de algoritmos de trabajo formales y aprobados.
A los programadores les gusta trabajar en el algoritmo, porque ellos mismos participan en la creación de algoritmos.
Un entorno mutable es un tipo de depuración, no es el algoritmo del programa el que está depurando, sino el trabajo del equipo.
Simplemente acuerde con el equipo que la era del cambio ha comenzado. Hoy, algunas reglas, mañana, diferentes. No porque las riendas cayeron debajo de la cola, sino porque el equipo necesita ser depurado.
La depuración es el lanzamiento de un algoritmo, que rastrea su funcionamiento y realiza ajustes si algo sale mal según lo previsto o como se desea.
La mayoría de los proyectos de cambio fracasan debido a la falta de un entorno cambiante. Es aterrador hacer cambios en piezas, es aterrador introducir nuevas reglas todos los días. Es mucho más simple, sin cambiar nada, desarrollar un documento grande, en el que todo está prescrito, y entregarlo para su ejecución.
Esto es, en términos generales, cómo escribir el código del programa de inmediato, sin un solo inicio. No, a veces es posible divertirse, pero en tareas decentes este enfoque no funciona: debes ser demasiado inteligente. Es mucho más fácil depurar en un entorno mutable.
habr.com/en/post/345830Scrum master
El scrum limpio descrito en el libro, cuando se aplica correctamente, aumenta la eficiencia del equipo en 2 veces. Esto se prueba en la práctica.
Pero la práctica de otras personas muestra que no ocurre aceleración alguna. Porque la metodología descrita en el libro se simplificó para la venta. Es ella la que se usa, simplificada.
Book Scrum implica tres niveles:
- El estado de Xiu ("cumplir") es la primera etapa, entrenar, repetir, sin desviarse de las reglas;
- Estado Ha ("romper") - comenzamos a cambiar las reglas, improvisar;
- El estado de Ri ("separado"): estamos libres de las reglas y comenzamos a construir.
Como regla general, el primer nivel está a la venta: instrucción e implementación de su implementación. Para obtener un aumento real en la eficiencia, debe pasar al segundo y tercer nivel. Piensa con tu propia cabeza, busca formas de optimizar, implementarlas y monitorear el resultado.
El scrum master debe lidiar con la aceleración, esta es su responsabilidad. Así que está escrito en el libro, cito: La principal preocupación del Scrum-master es llevar al equipo a una mejora continua y buscar regularmente la respuesta a la pregunta "¿Cómo podemos hacer aún mejor lo que ya estamos haciendo bien?".
Pero este es el segundo y tercer nivel. Y el primero se está vendiendo y presentando.
En el primer nivel, el scrum master tiene responsabilidades completamente diferentes. Verifique en Internet, la lista será algo como esto:
Oh
- organiza y celebra manifestaciones;
- Supervisa el cumplimiento de los principios de scrum;
- Crea una atmósfera de cooperación;
- Resuelve conflictos y protege al equipo.
Ni una palabra sobre mejorar la eficiencia. Solo siguiendo las instrucciones.
Si piensas lógicamente, ¿cómo puede aumentar la eficiencia si el equipo trabaja constantemente de acuerdo con las mismas reglas? Para que algo cambie, necesitas cambiar algo. Pero no puede hacer esto; de acuerdo con las instrucciones, no está permitido. Por lo tanto, la eficiencia en el primer nivel no crece.
Un scrum master debe ser una persona interesada en aumentar la eficiencia. Este trabajo no se puede aprender si no es interesante. Tienes que pensar mucho, organizar experimentos, probar hipótesis, cometer errores constantemente y llenar conos.
Es mucho más fácil emitir instrucciones y monitorear su implementación. Bueno, a veces para facilitar (lo que sea que eso signifique).
Traté de poner a diferentes personas como maestros de scrum, pero pocas personas se interesaron. Esto es normal
Si está familiarizado con la prueba de Belbin, entonces el Generador de ideas, el Analista y el Diplomático (investigador de recursos) son los más adecuados.
El papel de un scrum master es muy similar al de un programador que optimiza el rendimiento de una aplicación. Solo aquí está vivo el sistema, sin personas.
habr.com/en/post/346158Envío del sistema
Resultado de la mayoría de los cambios organizacionales: fallido.
Subproducto: la técnica es una mierda.
La metodología que subyace a los cambios. En particular, Scrum.
La razón es muy simple: insubordinación sistémica.
Bueno, la solución es muy simple: envío del sistema.
No sistemático, sino sistémico. Sumisión como sistema, como principio.
En nuestro país, la desobediencia se eleva al culto, gracias a la historia centenaria de nuestro estado.
La desobediencia sistémica conduce a comentarios extraños: se crean nuevas reglas y leyes teniendo en cuenta el hecho de que nadie las cumplirá.
Esto es especialmente cierto para el cambio organizacional. Su autor ni siquiera considera la opción de que las personas trabajen de acuerdo con las reglas propuestas. Por lo tanto, no se preocupa por la exigibilidad y la adecuación de las reglas.
Sin embargo, hay ejemplos de cambios implementados con éxito. Tome las mismas cámaras de video en las intersecciones.
Formalmente, la sanción por conducir a la intersección en la que se alinea el atasco de tráfico ha existido durante mucho tiempo. Pero esta regla prácticamente no se observó.
Ahora se observa perfectamente en intersecciones separadas. En aquellos donde se instalan cámaras de captura de video.
Las cámaras solo proporcionaron la presentación del sistema. Tan pronto como la gente comenzó a obedecer la regla, quedó claro que la regla en sí era bastante efectiva. La misma regla que solía estar juntos se consideraba una especie de basura.
Además, cualquier otra regla, cambio, algoritmo, técnica o caso. Cualquier técnica es útil.
Si piensas lo contrario, si dices que "Scrum no funciona" o "TOS no funciona" o "Lean es una mierda", entonces eres una gran persona. Es solo que no implementó esta técnica porque no proporcionó el envío del sistema. Y su incapacidad para proporcionarlo se acumuló en la inoperancia del método.
Proporcionar el envío del sistema es muy simple. Tienes que empezar contigo mismo. Será una auto-sumisión sistémica.
¿Presentamos Scrum en tu equipo? Siga todas las reglas declaradas, sin excepciones. Todos los días, sin pases.
Inmediatamente verá las ventajas y desventajas de la metodología: esta y cualquier otra.
Si hay éxito, entonces tú serás la razón. Si hay una falla, entonces usted será la causa.
habr.com/en/post/346712