“Todo es veneno, todo es medicina; ambos están determinados por la dosis ".
Paracelso
Es habitual contar la historia de
Agile desde febrero de 2001, cuando nació un documento bastante extraño: el
Manifiesto Ágil . En general, el texto del documento se compone de evidencia filosófica (por ejemplo, "simplicidad: el arte de no hacer demasiado trabajo") y declaraciones controvertidas (por ejemplo, "los mejores requisitos técnicos, diseño y arquitectura se obtienen de un equipo autoorganizado"). Pero este documento es extraño no tanto en su contenido (nunca se sabe lo que se le ocurre en una estación de esquí), sino en la naturaleza épica de los cambios posteriores en la industria del desarrollo de software. En el menor tiempo, aparecieron muchas técnicas que implementan la metodología de desarrollo "flexible", que marcha solemnemente alrededor del mundo, capturando las mentes de los Contratistas y las billeteras de los Clientes. Los adeptos presentan este movimiento como una especie de píldora mágica que decide todo. Llegó al punto de que un
donante noble, un programador honesto, ya se ha vuelto indecente para admitir su participación en el desarrollo de software de acuerdo con la
orientación tradicional
de la metodología. Intentemos comprender las causas y consecuencias del fenómeno, utilizando
Scrum como la manifestación más común de Agile.
Primero, intentemos comprender qué es realmente nuevo tenemos en el contenedor Agile en general y en Scrum en particular.
Scrum en el antiguo Egipto
Me tomaré la libertad de afirmar que siempre ha existido una metodología flexible en general, y la metodología Scrum en particular, aunque no se llamaron. No fueron llamados en absoluto, sino que fueron simplemente la forma más natural y efectiva de llevar a cabo sus proyectos internos (la palabra clave aquí es "interna").
Por ejemplo, el antiguo faraón egipcio planeó construir una pirámide y ... comenzó. Discutió la idea con los sacerdotes (partes interesadas) y asignó a su mayordomo para ser responsable del proyecto (propietario del producto). El empleado encontró un albañil competente (scrum master). El albañil contrató asistentes (equipo scrum), y fueron al mercado de esclavos y anotaron esclavos (herramientas de trabajo: PC, servidor, software para desarrollo, etc.).
Dado que el faraón le ordenó un informe mensual sobre el progreso de la construcción, el albañil (con asistentes) comenzó a realizar una demostración mensual de construcción (demo) para el mayordomo. Durante el espectáculo, no solo se discutió lo que ya se hizo (retrospectiva), sino que también se elaboró un plan para el próximo mes (sprint). Para no perderse nada, el copero pasó todo el mes discutiendo sus historias con los sacerdotes (historias de usuarios) y grabándolas en un pergamino especial (cartera de pedidos), desde el cual la lista de deseos cayó en el plan para el próximo mes. Bueno y así sucesivamente. No sé cómo eran entonces las pegatinas, el tablero de scrum y los diagramas de burndown. Cualquier líder competente selecciona las herramientas más convenientes para administrar y monitorear el proyecto. Los detalles no son importantes aquí, lo principal es que la técnica funciona.
Es decir Creo que todos los gerentes en todo momento utilizaron una técnica flexible para crear su producto interno (bajo su propio riesgo y riesgo) porque:
- suficientemente competente para diseñar el resultado final;
- suficientemente competente para controlar el proceso;
- tener suficiente poder sobre los participantes del proceso subordinado;
- la relación entre el término, el costo y la calidad del trabajo no es un dogma para ellos y puede revisarse si es necesario (ya que "él es su propio maestro");
- y lo más importante, tanto el resultado final como el proceso para lograrlo están en las mismas manos y persiguen un interés comercial.
Pero para el Cliente externo, ninguno de los elementos de esta lista es aplicable; por lo tanto, para proyectos externos (personalizados), nunca se ha utilizado una técnica flexible (las excepciones solo confirman la regla). Después de todo, la gente era simple e intolerante, por un exceso flagrante de plazos y estimaciones, podrían haber acortado sus cabezas.
Scrum hoy en día
La única novedad del Scrum moderno es el hecho de su uso para la implementación de proyectos externos (personalizados). Tratando de no sobresalir de este lado del problema, porque tirar de una cuerda puede atraer la verdadera motivación de los participantes del mercado. De hecho, el manifiesto Ágil y todos los argumentos de Scrum son pura propaganda de los intereses del Contratista, en aras de la decencia, velados en la lucha por todo lo bueno contra todo lo malo. ¡Ese es el genio de la solución, que nos permite convencer al Cliente de sacrificar el resultado por el bien del proceso!
Entonces, ¿qué cambia si el propietario del producto es un empleado de otra empresa y no la suya propia? La principal diferencia es que el resultado final y el proceso de su logro están ahora en diferentes lados de la "barricada" y cada una de las partes persigue solo su propio interés comercial. El resultado es importante para el cliente, y el proceso es importante para el Contratista. No puede ser de otra manera, después de todo, "nada personal, esto es solo negocios".
Agile es beneficioso para los jugadores del mercado de TI, ya que les brinda la oportunidad:
- ganar dinero en el proceso y no ser responsable por el resultado;
- reduzca el costo del personal de administración competente (son caros, pero no necesita diseñar nada ahora y no necesita escribir TK, y el proceso ahora controla al propietario del producto del cliente).
Y dado que esto es rentable, justo ante nuestros ojos, los equipos de programación con la columna vertebral de profesionales altamente calificados y orientados al sistema pueden convertirse en granjas de codificadores alquilados de la mano media.
Trate de ponerse en el lugar de una persona que contrata a un equipo de constructores para reparar su departamento e intenta obtener los términos y el costo de las reparaciones del líder del equipo, y en respuesta escucha:
- somos personas creativas, por lo que trabajaremos "a medida que avanza", pero usted paga por cada hora de trabajo del equipo y los materiales;
- no haremos un proyecto y plan comunes, lo resolveremos en el camino (si hacemos algo mal, lo volveremos a hacer por el tiempo que pagó y materiales adicionales);
- mostraremos los resultados de nuestro trabajo cada dos semanas y hablaremos sobre nuestros problemas, y juntos planearemos las próximas dos semanas.
¡Es poco probable que alguien esté de acuerdo con dicha oferta, y los clientes de los empleados de TI están de acuerdo! ¡Eso es lo que hace la propaganda que da vida!
Los clientes no solo están convencidos de aceptar fechas y costos impredecibles, sino que también transfieren toda responsabilidad por fallas. Como regla general, la calificación del Cliente no permite formalizar los requisitos para el resultado final y controlar profesionalmente el proceso. Por lo tanto, siempre se puede confundir y distraer (en ausencia de un TK general) para resolver muchos problemas secundarios (que surgen con mayor frecuencia debido a la falta de planificación a largo plazo).
Las consecuencias de la adoración ágil
¿No cree que la calidad de los productos de software cae en proporción a la distribución generalizada de Agile en la industria? ¿De dónde viene la calidad si todo el proceso se agudiza resolviendo problemas de la manera más simple y rápida posible? ¡Y pensar en el futuro está oficialmente prohibido por la metodología!
¿No cree que los productos de software se están convirtiendo cada vez más en "colchas de retazos" cuando se sorprende al notar que diferentes secciones del mismo software parecen estar hechas por personas completamente diferentes? E incluso en una pantalla de programa, se pueden mezclar diferentes estilos de diseño, diferentes enfoques ergonómicos y diferentes algoritmos para el funcionamiento de controles similares. Pero no hay TK y Guía de estilo para el producto, por lo que quien esté más familiarizado lo hará. Y el personal de control de calidad, como todos los demás, está sujeto a los plazos de sprint.
¿De qué se trata todo esto?
De todo lo anterior, puede parecer que soy un ardiente enemigo de Agile. Pero esto no es en absoluto! ¡Y no intenté ofender a nadie! Él solo trató de ilustrar más claramente las palabras del gran Paracelso que aparecen en el epígrafe.
Una metodología flexible es bastante adecuada para proyectos internos pequeños e incluso medianos. El tamaño del proyecto está limitado solo por la capacidad de un líder particular de "no perder el bosque detrás de los árboles", es decir. la capacidad de tener en cuenta todos los detalles y el resultado deseado sin sistematizarlo "en papel".
Una metodología flexible es muy adecuada para proyectos externos. En este caso, se aplican los mismos requisitos al propietario del producto del Cliente que al gerente interno del proyecto, es decir, esta persona debe ser un verdadero profesional de TI y no una secretaria que ejerza una carga temporal a tiempo parcial. Debe poder verificar las calificaciones del equipo contratado y monitorear constantemente la calidad del producto que se está desarrollando. Además, el producto que se está desarrollando debe permitir (en caso de fuerza mayor) el reemplazo del equipo de desarrollo. Solo en este caso podemos esperar que no sea "insultante y doloroso por años vividos sin rumbo".
Como puede ver, Agile tiene su lugar en el sol, pero es muy limitado en el campo del desarrollo de TI por contrato. ¿Qué hacer si su proyecto no entra en la categoría de Agile-adecuado?
¿No le parece sospechoso que una metodología flexible no haya echado raíces en ningún otro lugar que no sea el desarrollo de software por contrato? Bueno, no hacen submarinos, aviones o automóviles en Scrum. La sabiduría de nuestros antepasados nos enseña que incluso una caseta de perro normal no se puede armar sin una etapa de diseño (dibujo a lápiz con dimensiones) y la preparación de un ToR (lista de materiales y herramientas). Todo lo que ves a tu alrededor (desde el taburete hasta la nave espacial) se creó de acuerdo con la buena y antigua
"cascada" . ¿Por qué no haces lo mismo? Y recuerda: ¡todo estará bien!
PS
Todo lo dicho se basa en mi experiencia personal considerable (19 años) en el desarrollo web por contrato utilizando enfoques tradicionales (cascada) y progresivos (Scrum). El motivo para escribir el artículo fue la angustia moral de contemplar el próximo "milagro de la tecnología hostil", improvisado bajo los convenios del gran Frankenstein para una empresa occidental respetada.
