Scrum? ¿Qué SCRUM?
Por primera vez, Hirotaka Takeuchi e Ikujiro Nonaka describieron el enfoque SCRUM (
scrum inglés "pelea alrededor de la pelota"), quienes notaron que los equipos pequeños (5-9 personas), conformados por diversos especialistas, dan mejores resultados. La descripción más completa de SCRUM fue presentada por primera vez en su libro por Jeff Sutherland. El libro se llama SCRUM. Jeff comenzó su carrera como piloto militar, durante la Guerra de Vietnam completó más de cien salidas. Entonces Jeff se dedicó a la ciencia, pero el mundo lo recordará como uno de los fundadores de SCRUM. El libro comienza con una historia real de la vida del FBI, que gastó millones de dólares en el desarrollo de un sistema automatizado diseñado para buscar y rastrear criminales. El problema fue que después de que el proyecto expiró, los contratistas le mostraron al FBI un producto que no funcionaba. Esto solo significó una cosa: los contribuyentes estadounidenses han desperdiciado millones. La situación parecía desesperada hasta que el liderazgo del FBI recurrió al método de gestión de proyectos SCRUM, entonces naciente. Este método se describe en un lenguaje accesible en el libro mencionado, que, por cierto, se ha traducido al ruso. Además, el artículo analiza los principales conceptos erróneos y mitos que pueden ahuyentar a los altos directivos que han decidido implementar SCRUM en sus proyectos.
1. Control total que mata la creatividad.
En SCRUM, el equipo del proyecto, no la gerencia, decide cómo lograr el objetivo comercial. Este método motiva y estimula un enfoque creativo, en contraste con la gestión clásica, donde a los empleados se les delega la implementación de acciones específicas de bajo nivel, y quienes, a su vez, a menudo ni siquiera entienden por qué esto es así y cómo afectará al proyecto en su conjunto. Por lo tanto, en SCRUM, la administración no controla las acciones del equipo del proyecto y, a su vez, solo informa sobre los resultados al final de cada sprint (un período de tiempo preestablecido, por ejemplo, 2 semanas). La transparencia existe solo entre los miembros del equipo del proyecto. ¿En qué se manifiesta? En primer lugar, manifestaciones diarias de pie en las que cada miembro del equipo del proyecto cuenta lo que hizo ayer, lo que hará hoy, qué problemas tuvo. Esta práctica no pretende controlar la cantidad de trabajo realizado por cada empleado. Las manifestaciones stand-up están diseñadas para ayudar a cada miembro del equipo a eliminar obstáculos en su trabajo y dedicar a sus colegas a sus planes para que todos entiendan hacia dónde avanza el proyecto hoy y sean conscientes de su papel en el desarrollo de productos. Con el mismo propósito, por cierto, sirve un tablero SCRUM común con pegatinas, que todos pueden ver, y un espacio abierto, que elimina los obstáculos para la comunicación gratuita entre los miembros del equipo.
2. SCRUM priva los derechos de los ingenieros más experimentados, porque obedecen la decisión del equipo.
SCRUM crea un entorno en el que la autoridad se obtiene no por títulos y posiciones, sino por habilidades y experiencia. Un ejemplo sorprendente de la situación inversa es la jerarquía de los militares, donde el poder se basa en la posición y el rango. Un capitán puede ser mucho más talentoso y erudito que un coronel. A pesar de esto, el capitán debe obedecer estrictamente. Una estructura tan rígida es ideal para condiciones extremas, como las hostilidades, donde las decisiones deben tomarse rápidamente, y su discusión conduce a un retraso, lo que lleva a la muerte de personas. SCRUM no cancelará títulos. Cada empleado tiene su propia posición de acuerdo con su matriz de experiencia y competencia. Sin embargo, en el proceso de discutir una decisión particular, el factor dominante es una posición clara y razonable, respaldada por la experiencia personal del empleado en el área en discusión, y no su título. Contrariamente al mito, SCRUM otorga poder a aquellos miembros del equipo que articulan claramente ideas sólidas. Y como saben, el que piensa claramente, formula claramente.
3. SCRUM está dirigido a valores comerciales a corto plazo, y no al desarrollo a largo plazo del proyecto.
Este problema es, de hecho, relevante. Afortunadamente, la pregunta "¿Qué hacer?" hay respuestas Debería comenzar con el hecho de que si el proyecto no es de larga duración, con una duración de no más de seis meses, lo más probable es que este problema no surja. Otra cosa es cuando el software se desarrolla durante 2-3 años o más. Hay muchos artículos en los que los autores expresan su dolor con respecto a tales proyectos. El ejército de junio y medio (las sinergias, como saben, son caras y pocas en número) confía con confianza su trabajo para dominar, y el cliente sprint cosecha resultados brillantes para sprint SCRUM. Pero el problema es que después de 5-10 sprints, agregar nuevas funciones se vuelve problemático y, cuanto más lejos, más difícil. Por lo tanto, SCRUM es bueno, pero debes pensar en la estrategia y la arquitectura. Una situación similar se puede prevenir. En primer lugar, al
menos 1-2 ingenieros experimentados como sea posible trabajarán en el proyecto, quienes pasarán por sí mismos todos los compromisos al repositorio durante la revisión del código. En segundo lugar, dedicar mucho tiempo a la capacitación (al menos 3 horas a la semana) para ingenieros junior y medios en arquitectura de software, patrones de diseño y cómo se aplica esto a un proyecto existente. Dichas clases deben ir acompañadas de práctica y tareas mínimas para un mejor aprendizaje. Las tareas prácticas se pueden incrustar en la acumulación de sprints del proyecto. Esto no afectará mucho la rentabilidad del proyecto, pero acelerará el proceso de crecimiento de los empleados y evitará posibles problemas con la arquitectura del software. La celebración de reuniones periódicas permitirá a los equipos de proyecto aprender unos de otros, lo que no perjudica la calidad del software producido.
4. SCRUM impide que los ingenieros desarrollen
SCRUM asume que todas las decisiones con respecto a la forma de alcanzar los objetivos comerciales se delegan al equipo. El propietario del producto decide lo que debe hacerse y el equipo decide cómo. Se deduce que el equipo debe ser lo suficientemente competente como para tomar decisiones efectivas. Por lo tanto, la piedra angular de la metodología SCRUM es la capacitación. Es por eso que en todos los bancos más grandes y subcontratistas de TI se presta tanta atención al desarrollo: capacitaciones, seminarios, cursos. El crecimiento profesional de los empleados es una parte integral de SCRUM. Debido al hecho de que los equipos SCRUM son relativamente pequeños, los miembros del equipo tienen que dominar toda la pila de tecnología dentro del proyecto en el que están trabajando. Al final del proyecto, el ingeniero recibe nuevas habilidades, lo que aumenta su valor en el mercado laboral.
Subtotal
SCRUM, como cualquier otro método de gestión de proyectos, tiene sus propias características y asperezas que deben conocerse y tenerse en cuenta. A pesar de esto, da el mejor resultado entre los métodos conocidos hoy.
1. Jeff Sutherland // SCRUM 2017.