Se trata de Agile - 2: características de implementación ágil

Continuamos sobre los matices del desarrollo ágil que suceden en la práctica. ¿Cómo entender si Agile se implementa correctamente? ¿Qué práctica es adecuada para cada tarea e industria? ¿Quién en la empresa debería transferir el trabajo a “Railes ágiles”? Vasile Savunov, entrenador ágil ScrumTrek, continúa compartiendo su experiencia con los editores del blog Mail.Ru Cloud Solutions .

La última vez, Vasily habló sobre qué es Agile, qué metodologías incluye y qué estereotipos se han formado a su alrededor. Ahora hablemos de su implementación.

Acerca de las empresas ágiles

- ¿Existen "preferencias de la industria" en metodologías flexibles?

Como el estudio Agile Russia , que llevamos a cabo por segundo año consecutivo, muestra que Scrum se utiliza principalmente en el desarrollo de software, Kanban en organizaciones financieras y ambos en la industria de las telecomunicaciones.

Como persona que analizó directamente los datos recopilados y trabajó con muchos de los encuestados, creo que este estado de cosas se debe a dos razones:

• La tasa de cambio en TI es significativamente más alta que en finanzas. Por lo tanto, Scrum es preferible allí como un enfoque que permite, debido a experimentos rápidos, controlar de manera flexible las prioridades y cambiar la dirección según los cambios en el entorno externo y las condiciones en la entrada. Las finanzas son más conservadoras.
• El costo de un error en las finanzas es mucho mayor que en el desarrollo de TI. Por lo tanto, son Kanban más valorados, basados ​​en las matemáticas, en lugar de la experimentación, y permitiendo cambios pequeños pero constantes para mejorar el flujo de trabajo en su conjunto.

Telecom Kanban también es adecuado. Aunque solo sea porque el vector de desarrollo de la industria es la digitalización. Sin embargo, pocas personas entienden cómo debería ser exactamente. Además, en telecomunicaciones, la parte "rápida" del trabajo (desarrollo de software) es adyacente a la parte "lenta" (soporte y desarrollo de infraestructura de hardware). Por lo tanto, junto con los experimentos realizados en Scrum, tiene sentido acelerar evolutivamente los procesos actuales utilizando Kanban.


Prácticas de desarrollo ágil adoptadas en diversas industrias. Las cantidades no son iguales al 100% porque se puede seleccionar más de un artículo. Image / ScrumTrek

- ¿Y qué hay de los desarrolladores móviles? ¿Agile tiene detalles específicos sobre el desarrollo móvil?

Desde mi punto de vista, la principal dificultad para desarrollar aplicaciones móviles es identificar los requisitos de la aplicación, ya que puede ser difícil identificar a los interesados. Estas dificultades se pueden superar utilizando el desarrollo del cliente para investigar las necesidades del cliente y Scrum para probar rápidamente las hipótesis de los productos.


En general, Agile va bien con el desarrollo móvil: requiere una reacción rápida, participación y trabajo coordinado de diferentes especialistas, la capacidad de proporcionar rápidamente el resultado y, si es necesario, cambiarlo.

Además de Scrum, aquí puede usar directamente enfocado en enfoques de desarrollo móvil. Por ejemplo, Mobile-D se basa en XP, Crystal y RUP: los enfoques son bastante antiguos y están bien establecidos. La principal diferencia entre Mobile-D y Scrum: la presencia de fases claras y el enfoque principal en el lado de ingeniería del desarrollo de productos. Si bien Scrum presta más atención a la administración y entrega del producto, Mobile-D se enfoca en el proceso de fabricación e incluye prácticas XP que mejoran significativamente la calidad del producto final. Al mismo tiempo, la influencia de RUP afecta, por lo que el proceso está bastante formalizado.

Otro enfoque más moderno para el desarrollo móvil es SLeSS , que combina Scrum y Lean Six Sigma . Primero, implementa la configuración del flujo de trabajo de Scrum y luego aplica los enfoques Lean Six Sigma para la gestión de la calidad estadística. Me parece que SLeSS combina la flexibilidad necesaria con los mecanismos de toma de decisiones informadas basadas en estadísticas.

Al mismo tiempo, la Guía Scrum no prohíbe inicialmente la inclusión de otros enfoques y herramientas en el flujo de trabajo de Scrum que puedan ser útiles para el desarrollo de productos. Por lo tanto, todo lo anterior se puede implementar en el marco del Scrum "clásico".

- ¿Qué tan flexibles son las metodologías para modificar bajo condiciones particulares?

Debe considerarse por separado Scrum y Kanban.

Scrum es un marco, es decir, un marco, cuyos elementos son necesarios: eventos, roles y artefactos. Ninguno puede ser desechado. Pero no hay requisitos estrictos sobre cómo implementar exactamente estos elementos: haga lo que desee. Y Scrum no prohíbe agregar nuevos elementos: reuniones, artefactos, roles que necesita para trabajar y ayudar a acelerar el proceso.

Kanban es un conjunto de herramientas y métricas. No proporciona ajustes rigurosos sobre exactamente qué herramientas y en qué combinación usar, ya que está diseñado para un cambio evolutivo prolongado en el sistema existente. Pero al mismo tiempo, el éxito de Kanban está determinado por la recopilación de datos sobre el proceso de trabajo y su análisis periódico. Si esto no se hace, con el tiempo todo se extinguirá y no habrá más mejoras. Pero está bien: como dijo Edward Deming, no tienes que cambiar; la supervivencia es voluntaria.

- ¿Cuáles son los errores típicos en la adaptación que Scrum hace un negocio?

El principal error en la implementación de metodologías flexibles es el uso de herramientas sin comprender por qué deberían usarse específicamente.

Por ejemplo, en organizaciones grandes, cuando implementan Scrum, a menudo simplemente cambian el nombre del gerente del proyecto como propietario del producto, y el equipo del proyecto en el equipo Scrum y comienzan a exigir dar el resultado final en dos semanas. Pero esto no funciona, y por una razón muy simple: no se cumplen las condiciones bajo las cuales Scrum puede funcionar .

• Aunque el gerente del proyecto ha sido denominado Propietario del producto, no ha recibido la autoridad necesaria y, por lo tanto, no tiene derecho a formular una visión del producto o cambiar las prioridades de implementación. Como antes, se ve obligado a coordinar cada paso con el liderazgo y está sujeto al marco de los requisitos de tiempo y volumen de trabajo. Entonces, la velocidad de la toma de decisiones se ha mantenido igual. Sin aceleración o adaptación a condiciones cambiantes.
• Aunque el equipo del proyecto se llamaba Scrum-team, las personas incluidas en él todavía pueden figurar en cada departamento e informar directamente a sus gerentes de línea. En consecuencia, cada miembro del equipo, en primer lugar, hace lo que su gerente de línea, y no el propietario del producto, le confiará. Como resultado, las tareas del producto siempre serán de menor prioridad, lo que significa que la velocidad de implementación del producto, para lo cual el equipo Scrum fue "reunido", no aumentará en absoluto.
• Lo más probable, como antes, los miembros del equipo estarán ocupados en otros proyectos. Si bien Scrum declara directamente: los miembros del equipo deben asignarse al equipo Scrum el 100% de su tiempo de trabajo, y tratar solo con el producto que lidera su Dueño de Producto. Si las personas están "divididas por porcentajes" entre proyectos / productos, entonces cambiarán entre ellos, lo que reducirá drásticamente tanto la participación como la eficiencia del trabajo en cada proyecto / producto específico.

Tal "implementación" inepta tiene muchas consecuencias negativas, pero comienzan con un intento de reproducir la mecánica, pero no la esencia de Scrum. Los principales errores en la implementación de Scrum se describieron en detalle en mi informe " Stop Signals for Agile " en la conferencia CodeFest 2017.

- ¿Cómo evaluar cómo se implementan metodologías competente y flexible en la empresa?

Hay una prueba Scrum Open , pero sirve más como una prueba de conocimiento teórico. Lo que sucede en la práctica, no permite entender. Dado que la base de Scrum es el trabajo en equipo, y su prioridad es la velocidad de entrega del producto y el valor para el consumidor, 360 encuestas son las más apropiadas. Por lo tanto, es más confiable establecer el grado de madurez del equipo y la satisfacción del cliente.

Utilizamos nuestra propia metodología, que se implementó en el servicio ScrumTrek Diagnostic Tool . Ella trabaja asi. A un equipo y a las partes interesadas externas se les formula una serie de preguntas sobre cómo evalúan el nivel de interacción del equipo, la planificación de su trabajo, el valor del resultado entregado al cliente, la interacción con otros equipos, etc. Para cada parámetro, se calcula la mediana de las opiniones y se crea un gráfico circular complejo: Radar, que muestra el aspecto tanto desde el interior del equipo como desde el exterior.


Radar ScrumTrek. Nos fijamos en la dispersión de las calificaciones.


Radar ScrumTrek. Nos fijamos en las medianas

El diagrama contiene mucha información útil.

• Las estimaciones atómicas de los individuos y sus promedios son interesantes en sí mismas, y aquí no se necesitan explicaciones.
• La dispersión de calificaciones en un equipo es algo interesante. Cuando es muy grande, hay razones para acordar lo que nosotros como equipo entendemos por uno u otro aspecto de nuestro trabajo. ¿Qué queremos decir con "valor para el cliente", por ejemplo? ¿Y qué hay de la "velocidad de entrega"? Una gran extensión indica que el equipo no ha formado una sola posición en una serie de cuestiones.

Una pequeña extensión indica consenso y buen trabajo en equipo.

• Las clasificaciones están clasificadas. Puedes ver que todo está bien con la cultura, pero la productividad se está hundiendo en algunos lugares. Está claro dónde "cavar".
• La diferencia entre la evaluación dentro y fuera del equipo es uno de los indicadores más importantes, muestra las diferencias entre las expectativas de los clientes y otras partes interesadas del equipo y cómo se percibe el equipo. Agile se trata de la estrecha interacción entre las empresas y quienes venden el producto, por lo que estas discrepancias son una excelente razón para "verificar el reloj" entre estas dos áreas y acordar cómo reestructurar el equipo.

Después de recopilar los datos, se realiza necesariamente un análisis del cuadro con la participación de todo el equipo y las partes interesadas. Todo para mostrarles cómo se ve el trabajo del equipo desde diferentes ángulos y para procesar los resultados del análisis en pasos concretos para mejorar el trabajo.

Acerca de los equipos de implementación de Scrum

- ¿De quién debe iniciar la empresa la implementación de metodologías de desarrollo ágil?

La implementación de Scrum siempre proviene de un objetivo comercial. Por lo tanto, el cliente debe ser el primero en pensar en la aceleración, ya sea interna o externa. Luego debe resolver el concepto del producto para que se pueda hacer de forma iterativa. Y solo entonces formar un equipo. Scrum por el bien de Scrum no funciona. Además, puede ser demasiado costoso resolver problemas específicos.

¿Quién será la "guía ágil" en la empresa es una pregunta sin la única respuesta correcta. Vi al director técnico convertirse en el "instigador" del cambio. Hubo casos en que la iniciativa provino de negocios, e incluso vio cómo surgió dicha iniciativa "desde abajo". Todo depende de la energía y la motivación de la persona, de si podrá integrar su visión de desarrollo utilizando enfoques flexibles en el contexto comercial del producto o unidad.

Ideal cuando la iniciativa proviene de la alta dirección. Los avances en esta dirección son notables en el mercado ruso.

- ¿Qué nuevos roles y funciones surgen en una organización o equipo con la introducción de metodologías flexibles? ¿Cuáles de ellos son obligatorios, cuáles son opcionales?

En el caso de Scrum, estos son los roles del maestro Scrum, propietario del producto y equipo de desarrollo. Todos ellos son obligatorios. El equipo de desarrollo también se considera un "rol", ya que combina no solo desarrolladores, sino también a todos los que necesitan que el producto aparezca en principio: analistas, diseñadores, etc.

El Scrum-master y el propietario del producto pueden tener asistentes que asuman parte de sus funciones, mientras que la responsabilidad del resultado recae en el Scrum-master o el propietario del producto.

El propietario del producto suele ser una persona del negocio. Pero no necesariamente: digamos que si creamos algún tipo de solución de ingeniería para la producción, el ingeniero jefe puede desempeñar este papel. En última instancia, esta es la persona que comprende lo mejor de todo para qué consumidor estamos haciendo el producto, qué problemas resuelve en primer lugar, cómo se deben construir las prioridades al crearlo. Es muy importante que el propietario del producto tenga la autoridad para determinar de forma independiente la composición del producto en función de los datos del mercado y del consumidor. Debería tener derecho a decir no a las partes interesadas con las que interactúa. Esto es necesario para que las prioridades se acuerden y las decisiones se tomen con prontitud.

Scrum-master es una persona cuya tarea es crear un equipo fuerte, unido, responsable e idealmente autoorganizado. Lo importante no es un líder de equipo , es decir, no un líder. Scrum-master no puede dar orientación o intervenir directamente en el desarrollo de productos. Es el organizador, facilitador, entrenador y profesional ágil. En mi experiencia, los mejores maestros de Scrum provienen de gerentes de proyectos, siempre que hayan sido capacitados y hayan logrado pasar de un formato de directiva a uno de coaching.


Hablando de estilo de coaching de comunicación. También hay un entrenador ágil . Su tarea es configurar el flujo de trabajo, educar a las personas y darles herramientas para las actividades diarias dentro de Agile. Incluyendo herramientas de resolución de conflictos. Todo lo demás está más allá de su alcance. Idealmente, un entrenador ágil debería establecer un equipo o departamento para que todo funcione por sí solo y no se necesita un entrenador ágil.

El período de transición siempre se asocia con molestias. Agile-coach está diseñado para ayudar al equipo a atravesar este período con una fricción mínima y desarrollar nuevos métodos de trabajo, convenientes y efectivos.

Al escalar, se pueden introducir roles adicionales, como se describe, por ejemplo, en el marco SAFe , pero todavía se basan en los términos de referencia y los principios de trabajo del Scrum-master o del propietario del producto: simplemente aparecen niveles de jerarquía con respecto al producto.


- ¿Cómo se diferencian las funciones del propietario del producto y el Scrum-master "en un mundo ideal"?

Por un lado de la escala están los intereses del negocio que representa el propietario del producto, por el otro, la vitalidad y la eficacia del equipo del que es responsable el Scrum Master. Para que el equipo logre resultados rápidamente, el sistema debe estar en equilibrio. Si el propietario del producto "pellizca", el equipo trabajará de noche y los fines de semana, y pronto se enfrentará a un puñado de personas desmotivadas y no involucradas en lugar de un equipo bien coordinado. Si el Scrum-master pone la manta sobre sí mismo, el desarrollo no será inestable ni envolvente, con disputas constantes y mucho más de lo necesario.


- ¿Qué metodologías y modelos gerenciales vale la pena dominar para aquellos que van a asumir uno de los roles descritos anteriormente?

En términos de competencias comerciales, todo está “de acuerdo con los clásicos”, como con la administración ordinaria, excepto la necesidad de determinar las prioridades por etapas e interactuar más estrechamente con el equipo.

El propietario del producto debe aprender Lean Startup, desarrollo de clientes y otros enfoques modernos para crear productos.

Para el Scrum-master, el rango de competencias es más amplio: facilitación, manejo de conflictos, dinámica de grupo, coaching y, por supuesto, práctica ágil. Más bien, se trata de habilidades del campo de la psicología, por lo tanto, su falta se siente al entrenar a los gerentes.

- ¿La propiedad colectiva del código realmente reduce la dependencia de la compañía de los desarrolladores "estrella"? ¿Está cayendo su motivación?

La propiedad del código colectivo es factible sin metodologías flexibles. Suficientes acuerdos de revisión de código y otras reglas formales, y los desarrolladores pueden actuar atómicamente.

A menudo, la compañía en sí misma provoca el comportamiento "estelar" de los ingenieros: a primera vista, es más rentable que se convierta en un súper especialista y le confíe una dirección completa con total responsabilidad por el resultado que reunir un equipo de campesinos intermedios, reducir sistemáticamente los riesgos debidos a errores y aumentar su profesionalismo.

Este es un dilema: éxito a corto o largo plazo. Parece que contratar una "estrella" es bueno para los negocios. Pero, ¿qué sucederá en tres años, cinco, siete años después de que un profesional se haya unido a la empresa? Se volverá indispensable. Y con al menos tres consecuencias negativas.

En primer lugar, esa persona casi no tiene tiempo libre , y a la empresa, en general, no le importa. Su lógica: "No le pagamos un sueldo enorme para que pueda descansar". Entrando en una situación similar, las personas se agotan rápidamente, caen en cinismo y tratan de obtener los máximos beneficios de su posición.

-, . , , , . : , , , , . , .

-, «» . , : , «», «» . : , , .

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

, , . , « ». , , « » . , « . - ».

Mail.Ru Cloud Solutions .