Se trata de Agile 1: mitos de la agenda popular

Las metodologías de desarrollo ágil se han arraigado tanto en TI como en otras, repletas de presagios, estereotipos, supersticiones y mitología. Los editores del blog Mail.Ru Cloud Solutions decidieron hablar sobre esta mitología con el entrenador Agile Vasily Savunov de ScrumTrek.

Agile es una filosofía de desarrollo ágil cuyos fundamentos se describen en el Manifiesto de desarrollo de software ágil . El concepto se basa en cuatro valores fundamentales:

• las personas y la interacción son más importantes que los procesos y las herramientas;
• un producto que funciona es más importante que la documentación completa;
• la cooperación con el cliente es más importante que el acuerdo sobre los términos del contrato;
• la preparación para el cambio es más importante que seguir el plan original.

Los principios del enfoque ágil han transformado el proceso de desarrollo y han ganado respeto. El mundo moderno se está acelerando mucho: cada día aparecen docenas de nuevos servicios y soluciones digitales. Agile permite que el negocio sea lo suficientemente rápido al desarrollar nuevos productos para mantenerse al día con este ritmo acelerado y lo antes posible para brindarles a los usuarios y clientes algo que resuelva sus problemas.

Junto con la popularidad en Agile vino su interpretación formal. Analizaremos los mitos y estereotipos que nos impiden ver la esencia de un enfoque flexible y sacar más provecho de él.

Mito 1. Ágil es solo TI

Ya no. Es suficiente mirar la lista de compañías en nombre de las cuales hablan los oradores en Agile Days y Agile Business Conference: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Estas y muchas otras organizaciones que no están relacionadas con la industria de TI están utilizando con éxito los enfoques ágiles.

Mito 2. Ágil: no para proyectos de presupuesto fijo

Dentro de un presupuesto fijo, puede trabajar de manera muy diferente. La pregunta es cuál es la relación entre el contratista y el cliente. Si usa Agile, debe centrarse en lo que resuelve el problema del cliente. En otras palabras, si al principio el cliente y el contratista llevan a cabo la planificación juntos e identifican las principales prioridades del producto, nada les impedirá determinar qué parte más útil del producto puede implementar el contratista dentro de un presupuesto limitado. Y si también estipula exhibiciones regulares hechas al cliente, es muy posible ajustar el proceso en segmentos cortos y, en consecuencia, ajustar los costos del proyecto.

Mito 3. Ágil: una panacea para los negocios y el desarrollo: implementar, dejar que algo mejore

Me parece que esta es una visión simplificada y muy perjudicial de las cosas. Todos los casos y negocios son diferentes, y debe elegir el enfoque correcto que lo ayude en este caso particular.

Definitivamente, Agile no es necesario donde la clave del éxito es seguir un algoritmo de acciones bien definido. Por ejemplo, en el trabajo de un centro de atención telefónica, donde para un mejor servicio los operadores deben mantener una conversación usando "scripts", es decir. escenarios de comunicación predefinidos. No hay campo para la experimentación, e incluso pueden ser dañinos aquí. Por lo tanto, Agile no es necesario en las actividades de los operadores de centros de llamadas.



Ágil será perjudicial cuando el costo de "procesamiento" o "refinamiento" del producto sea colosal, o incluso pueda implicar sacrificio humano. Digamos, durante la construcción de una planta de energía nuclear, es obvio que no podemos construir de forma iterativa e incremental, como nos lo dicta Agile.

Mito 4. Scrum, Lean, Kanban no se cruzan.

Las metodologías y herramientas deben estar separadas. La metodología es un algoritmo para construir un flujo de trabajo. Las herramientas son esos "ladrillos" que se utilizan en este algoritmo.

Diferentes metodologías pueden incluir las mismas herramientas, pero en un diseño diferente. A menudo puede ver cómo, al implementar Scrum, recurren a XP (programación extrema) o herramientas Kanban. Y esto es normal, ya que todos cumplen con los valores de Agile y le permiten flexibilizar el flujo de trabajo de creación de productos.

Si hablamos de los enfoques ágiles específicos que ahora son más frecuentes, entonces esto es ciertamente Scrum y Kanban. Otros: FDD, XP, RUP, etc., abandonaron el escenario o rara vez se usan como un todo, pero las herramientas individuales de su arsenal están involucradas en la implementación de Scrum o Kanban.

Mito 5. Scrum: cómo hacer un producto de forma rápida y económica.

En cuanto a "rápido", todo es cierto, pero en cuanto a "barato" - no. Juzga por ti mismo: debes formar un equipo completo, destacando las competencias necesarias en él al 100%. Estas personas solo estarán ocupadas con el desarrollo del producto que se les ha confiado y nada más, lo que significa que tendrán que contratar a tales especialistas o "arrancarlos" de algún departamento. Lo mismo se aplica a la parte comercial: si lo desea, si no lo desea, deberá asignar el propietario del producto, que dedicará el 50–80% de su tiempo solo a este equipo y su producto.

Además, deberá reunirlos a todos, en una habitación, proporcionarles su propio espacio, accesorios para las actividades del equipo, etc. Además, debe tener en cuenta que se dedicarán al menos ocho horas por sprint a la comunicación, ya que Scrum implica una serie de reuniones obligatorias que duran una o dos horas. En cualquier caso, tendrá que invertir, pero la ganancia final en velocidad y calidad que proporciona Scrum es muy grande.


Sprint incluye 4 reuniones obligatorias: planificación, implementación, lanzamiento, revisión de sprint con una retrospectiva. Además, las reuniones a corto plazo (reuniones de pie) se llevan a cabo todos los días en las que los miembros del equipo "controlan el reloj" en un solo formato y coordinan sus acciones. No puede agregar nuevas tareas al sprint abierto: esto acostumbra al equipo a planificar y protege contra la ocurrencia de caos gerencial.

Mito 6. Kanban es un tablero con tareas publicadas en ellos.

¡Para nada! Los tableros son solo el primer paso más fácil en Kanban. Pero el asunto no se limita a ellos . En el corazón de Kanban hay un complejo aparato matemático basado en datos estadísticos. Por lo tanto, equiparar Kanban con tablas significa no mirar más allá de su fachada.

En pocas palabras, el punto principal de Kanban es:

• Haga que el flujo de trabajo actual sea transparente y cubra todas las etapas, desde la ocurrencia de la tarea en la cabeza del negocio hasta su implementación y envío del producto al consumidor.
• Administre su flujo de trabajo identificando pérdidas de tiempo y eliminándolas. Por lo tanto, hacemos que nuestro flujo de trabajo sea predecible.
• Tome decisiones de gestión basadas en métricas, no en sentimientos.

Mito 7. Scrum y Kanban se pueden plantar en cualquier proyecto y empresa.

No me gusta la palabra "plantar", después de todo, Agile se trata de trabajar con personas. Sería más correcto hablar sobre "inculcar" una nueva filosofía de pensamiento en el equipo.

Al mismo tiempo, el algoritmo de injerto Scrum y Kanban son diferentes.

La tasa de éxito del uso de Scrum depende de la cultura corporativa dominante de la compañía. En una estructura jerárquica dura, donde todos necesitan una hoja de papel, ningún esfuerzo para "hacer crecer" a Scrum tendrá éxito sin el apoyo de la alta dirección. Tendremos que construir una nueva estructura paralela basada en un enfoque de equipo. Una especie de "reserva ágil", que protegerá a uno de los gerentes del escalón más alto. En tales condiciones, es posible mostrar un resultado rápido en tres o cuatro meses. Pero habrá una tarea más difícil por delante: difundir esta cultura en toda la organización. Cuánto durará esto es extremadamente difícil de evaluar. Pero, en mi experiencia, si el nuevo enfoque cubría el 30% de la compañía, entonces comienza a extenderse aún más y ya no necesita protección desde arriba.

La implementación de Scrum generalmente requiere grandes cambios, tanto en la estructura de la organización como en la contratación con contratistas (se necesita un contrato de tiempo y material ), y en el presupuesto (presupuesto por fases) y todo lo demás.



Kanban no requiere un cambio tan radical. Él ofrece: "Comience con lo que es y comience a mejorarlo evolutivamente". La tasa de cambio será significativamente menor que en Scrum, pero todos los cambios se basarán en estadísticas y tendrán una justificación clara.

Mito 8. Scrum está diseñado solo para proyectos hechos desde cero.

Existen diferentes casos, no existe una regla rígida de que Scrum esté destinado solo para el desarrollo desde cero. Transferir proyectos existentes a Scrum no solo es posible, sino que a menudo es apropiado. Todo depende de la voluntad de los artistas y los clientes de reestructurar su trabajo para acelerar el desarrollo. Si están listos, todo se puede lograr.

Por ejemplo, uno de los creadores de Scrum, Jeff Sutherland, en su libro Scrum: El arte de hacer dos veces el trabajo en la mitad del tiempo, habló sobre cómo usó Scrum para desarrollar un sistema automatizado de contabilidad del FBI. Cuando asumió el proyecto, el desarrollo continuó por cuarto año, ni una sola función fue presentada al lanzamiento y el proyecto no era visible ni al final ni al borde. Jeff pudo acelerar radicalmente el desarrollo y hacerlo transparente para los clientes. Seis meses después, se lanzó la primera versión funcional del producto, y en dos años el desarrollo se completó con éxito.

Mito 9. Al introducir metodologías flexibles, los conflictos con los representantes de la jerarquía tradicional son inevitables.

Si todo se hace correctamente: para separar al equipo de la jerarquía tradicional, entregar el presupuesto al propietario del producto y contratar a un Scrum-master verdaderamente hábil, entonces no habrá conflictos. Pero esto no siempre sucede. A menudo es imposible combinar estas dos estructuras, por lo tanto, solo hay una salida: construir una nueva estructura, afilada para una rápida toma de decisiones e implementación del producto.

Y sobre quién es un Scrum-master, aprenderás en la próxima serie. Espere en la segunda parte de la historia de Vasily sobre la implementación de metodologías de desarrollo flexibles: las dificultades, los beneficios, las trampas y las bombas de tiempo.

UPD Y aquí está la continuación: se trata de Agile - 2: características de implementación de desarrollo ágil

No hay tiempo para explicar, el material fue preparado desinteresada y amorosamente por el equipo de Mail.Ru Cloud Solutions .