Análisis ágil. Mitos y realidad

I Introducción

¡La cabina debe ser movida! No hay temporada, por lo que un par de personas no hacen shandarah.
Ahora confundido con el baño, luego con una cabaña de playa ...
(x / f Características de la pesca nacional)

En fin de año, resumiendo, rellenando cuestionarios y otras mallas de funcionarios de TI antes de las vacaciones. Por enésima vez estoy captando la atención de los cuestionarios finales de las empresas de TI, diseñados para identificar tendencias en los enfoques para el desarrollo de productos. Y cada vez que hay una sensación de algún tipo de truco cuando respondes preguntas como: "Todavía usas el método Cascada (modelo de cascada), o aún (como toda la humanidad avanzada) practicas Agile (metodologías flexibles)". Cuando comienzas a descubrir por el autor de esta encuesta, y lo que entiende por Agile, sus explicaciones de alguna manera no encajan mucho en el bosquejo del manifiesto (Manifiesto Ágil). Realmente piensa en muchos principios por primera vez y estos mismos principios lo detienen directamente. Pero después de un poco de confusión, se utiliza artillería pesada con hormigón reforzado para confirmar nuestra posición: "No estamos trabajando en la Cascada, así que Ágil".

La tesis de la Metodología Flexible en sí misma es tan gutapercha en su sonido que muchos intentan exprimirle algo, o más bien, lo que es más beneficioso para ellos. Poco a poco, se convirtió en una pantalla de moda, que puede cubrir todo tipo de fallas e incluso descuidos, en el proceso de fabricación de productos de TI y, al mismo tiempo, como si estuviera en la cresta de la ola, en una tendencia. Como si no fuéramos así, pero tal técnica.

Juntos, una vez más "atacamos con el análisis" sobre el tema de las metodologías flexibles, intentemos clasificar los principales artefactos y principios en los estantes y separemos el significado sagrado que originalmente se estableció en este concepto de lo que los populistas negligentes individuales lo convierten. También comparamos los enfoques de Agile con otros métodos para una comprensión más precisa de la línea que los separa, o viceversa, los combina. Al mismo tiempo, tratemos de descubrir dónde es más apropiado el uso de los principios ágiles y dónde no es del todo apropiado.

II Antecedentes de la aparición de técnicas de desarrollo de productos de software.

La historia es como una pasta de carne: es mejor no mirar cómo se cocina.
Aldous Huxley

En aras de la objetividad, vamos a sumergirnos en la historia y sentir las circunstancias que formaron la base sobre la cual han madurado varios principios y métodos para desarrollar productos de software, incluidos los flexibles.

1. Mitos y realidad sobre la cascada

Como ya se mencionó en la introducción, el Antagonismo (ofrenda de sacrificio) para Agile (1) fue la técnica Waterfall elegida, que en su forma pura fue relevante en el siglo pasado, en el momento de las tarjetas perforadas y las unidades de cinta y fue presentada al mundo por primera vez en un artículo de W.W. Royce ( WW Royce), publicado en 1970.

Tal comparación indudablemente ayuda a cualquier otra metodología a parecer fresca e innovadora en comparación con ella. Algunos oradores, para mayor convicción, presentan el modelo Waterfall no como un flujo de trabajo monolítico, iterativo, sino único, de una fase sucesiva: análisis de requisitos, diseño, implementación, prueba, integración y soporte. Me conmovió especialmente la frase sobre métodos de desarrollo, que se observó en el artículo, hasta el período de Ajail: “Anteriormente, los productos se fabricaban de inmediato en su conjunto. Para hacer esto, recorrimos la cadena: idea → términos de referencia → diseño → programación → prueba → lanzamiento ”. Disculpe, pero Royce utilizó un modelo de desarrollo iterativo en su enfoque. Simplificar la idea de una manera cínica simplemente ya no es ético, especialmente considerando que no había vacío entre Waterfall y Agile, sino una cadena evolutiva bastante larga.

Aunque para ser justos, debo admitir que la mayoría de lo que se dijo sobre Waterfall, en general, no está lejos de la verdad. Si el equipo se dio cuenta en algún momento de que el resultado no cumplía con las expectativas, entonces o bien "terminaron" el producto que no era del todo correcto, o arrojaron la mayor parte del trabajo a la canasta, y comenzaron el proceso casi desde el principio, creando realmente un nuevo producto. ¿Por qué, a pesar de lo absurdo de los estándares actuales de tal enfoque, la técnica ha permanecido durante mucho tiempo como un buque insignia popular en el mundo del desarrollo de software?

Para comprender este fenómeno, nos sumergiremos en la atmósfera de los entonces Centros de Computación (CC). Permítanme recordarles que en aquellos tiempos lejanos, el camino desde el diseño de los desarrolladores hasta la ejecución de su computadora fue largo y espinoso. Repasó los dispositivos de preparación de datos ya olvidados que realizan perforaciones mecánicas de tarjetas perforadas y afectuosamente llamadas "barmales". Esta operación fue realizada no por los propios desarrolladores, sino por personas especialmente capacitadas. Habiendo recibido el preciado paquete de cajas de cartón perforadas, en el orden de prioridad, teniendo en cuenta la operatividad de la computadora, estas tarjetas perforadas se colocaron en un dispositivo especial (nuevamente, personas especialmente entrenadas) que leyeron el código y solo después de eso, tuvo la oportunidad de ser ejecutado por el procesador. Pero si una de las tarjetas perforadas en el mazo se atascó durante la lectura, debe repetir el procedimiento para leer todo el mazo nuevamente. Y Dios no lo quiera, se manifestó un error en el código, fue necesario recurrir nuevamente a la ayuda de "barmaley", interrumpir parte de las tarjetas perforadas y, sin confundirlas con lugares en el mazo, repetir todo el procedimiento una vez más desde el principio. Con tales encantos, el trabajo de los programadores de entonces estaba salpicado todo el tiempo. Naturalmente, los cambios rápidos en los requisitos para el producto desarrollado en el curso de su implementación, con tal enfoque, estaban fuera de discusión. Los requisitos de alta calidad para el producto que se desarrolla y el proceso estrictamente regulado de su producción eran para todos los equipos.

2. ¿Qué pasa si no es una cascada?

Pero el tiempo pasó y todo cambió. Las computadoras personales se convirtieron gradualmente en la cápsula para el mundo digital, desplazando enormes monstruos en el patio trasero. El número de operaciones realizadas por los procesadores por unidad de tiempo ha aumentado en varios órdenes de magnitud, y la velocidad de la operación de entrada / salida de información simplemente parece ser "cósmica". Los programadores obtuvieron acceso directo e instantáneo a la ejecución del código que se acaba de escribir desde el teclado, recursos informáticos, sin abandonar el lugar. Ahora es mucho más fácil hacer cambios en el software, y ya imagino que alguien más continúa trabajando de acuerdo con el método Waterfall en su forma pura es simplemente ridículo.

La selección natural y la necesidad de adaptación obligaron a las técnicas a mutar. Además, la mayoría de ellos tomaron prestado un modelo de desarrollo iterativo de sus predecesores. Simplemente, los ciclos de ejecución se han reducido y mejorado significativamente.

Pero entonces surgió otra desgracia. Oportunidades sin precedentes hasta ahora han permitido desde la automatización de secciones individuales de producción pasar a la automatización de empresas enteras e incluso barrer completamente en la industria. Con tales volúmenes de operaciones y cantidades de recursos involucrados, no fue posible simplemente simplificar los métodos de desarrollo de software. Por el contrario, se han vuelto aún más radicales y formalizados.

Una de las técnicas más conocidas que utilizan un modelo de desarrollo iterativo es Rational Unified Process (RUP). Fue desarrollado e implementado en la segunda mitad de la década de 1990 en Rational Software.

El término RUP oculta no solo una metodología de desarrollo de software, sino también un conjunto de herramientas que le permiten administrar los procesos de desarrollo. En el marco de este tema, es especialmente interesante observar que la metodología RUP (2) describe un proceso general abstracto en base al cual una organización o un equipo de proyecto puede crear su propio proceso de desarrollo de software único, enfocado en sus propias necesidades. ¿Cómo dice que este enfoque no es flexible?

Con análisis y comparaciones adicionales, se puede observar que algunas de las características clave de RUP también se heredan en parte de la técnica de la cascada.

1. Enfoque cíclico para la producción de software . El ciclo de vida del proyecto RUP se divide en 4 fases y 9 procesos de trabajo.
2. Proceso de desarrollo iterativo . El proyecto RUP consiste en una secuencia de iteraciones con una duración recomendada de 2 a 6 semanas.
3. Desarrollo obligatorio de requisitos . RUP usa casos de uso o casos de uso para describir requisitos. Cada caso de uso es una descripción del escenario de interacción del usuario con el sistema que realiza completamente una tarea específica del usuario.
4. Un enfoque incremental dirigido a incrementar gradualmente la funcionalidad del producto. La unidad principal de la planificación de la iteración es el caso de uso, que le permite realizar los cambios necesarios en los requisitos, las decisiones de diseño y la implementación durante el proyecto.

Prestamos especial atención al último punto. Establece que es la presencia de requisitos detallados redactados en una forma específica que solo proporciona la capacidad de realizar cambios efectivos en las decisiones de diseño y la implementación del producto durante el proyecto. Incluido en las últimas etapas del proyecto.

RUP a menudo se considera erróneamente un proceso pesado con un alto nivel de formalismo. Pero esto no es del todo cierto, ya que el proceso RUP puede (y debe) personalizarse según los detalles de una organización y proyecto en particular. Incluso si el equipo adquiere un pequeño producto de software que necesitará desarrollarse, ampliarse o integrarse con otros sistemas, RUP le permitirá hacer frente con toda comodidad a todos los desafíos que surjan.

3. El derrocamiento de los cimientos.

Y luego más. Habiendo omitido el período del advenimiento de las computadoras personales en nuestro mundo, pasamos a la aparición de todo tipo de estudios de herramientas, herramientas de visualización y modelado, creadores de aplicaciones automáticas, etc. En toda esta variedad de ayudantes, que, por ejemplo, le permiten arrastrar y soltar un elemento en el diagrama con el mouse y cambiar automáticamente el código de la aplicación para el producto final, comenzó a devaluar el papel de las técnicas de desarrollo de software. Con herramientas tan avanzadas, con falta de tiempo o recursos, puede abandonar algunos flujos de trabajo de la metodología y, al mismo tiempo, no perder nada. Al menos a corto plazo. Estas libertades y, como resultó, la impunidad, con la debida profesionalidad de los artistas intérpretes o ejecutantes, llevaron a las cabezas más desesperadas a proclamar una nueva tendencia de TI: "Metodologías de desarrollo flexibles".

Aquí en este lugar desde la línea roja, enfatizo una vez más una tesis muy importante, quizás la clave: "¡con el debido profesionalismo"! Es decir, los especialistas de clase alta que tienen docenas de proyectos completados a gran escala detrás de sus cabezas, que son capaces de dibujar el diagrama de clase de un pequeño módulo en sus cabezas en 20 minutos, estiman de inmediato los procesos que cambian sus estados, sugieren dependencias críticas, etc. decidió que, en algunos casos, pueden prescindir de la aprobación obligatoria de los reglamentos adoptados. Al mismo tiempo, el proyecto seguirá obteniendo el resultado esperado con una calidad aceptable en un tiempo significativamente más corto. ¿Es bueno o malo? A primera vista, es simplemente maravilloso. En el segundo, no todo es tan simple. Analizaremos los pros y los contras un poco más tarde.

Definitivamente malo aquí es otro. Joven y audaz, mirándolo desde un lado, pregunta: "Pero, ¿qué fue eso posible?" Nunca vieron requisitos de calidad en sus ojos, no pueden leer diagramas, pero ahora no lo necesitan. Eso es todo! ¡los requisitos ahora están cancelados! Diagramas, proceso de modelado - allí en el horno. Solo código, código y comunicación. Como beneficio adicional, pueden dejar sus comentarios en el código para futuras generaciones del mismo insolente.

En esto, la excursión histórica se puede completar y mover, por así decirlo, más cerca del cuerpo ...

III Análisis del fenómeno de las metodologías flexibles.

Cada entidad debe analizarse en términos de lógica antes de meterla en la boca.
Woody Allen

1. Definiciones de metodologías flexibles

Como Adjayl ha existido durante muchos años, aprovechemos la información disponible y comencemos por revisar las definiciones y opiniones que encabezan la red. Y como ya nos hemos alejado de ellos, pasaremos al artefacto principal: el Manifiesto del desarrollo de software flexible.

Lo primero que se encontró en un motor de búsqueda con el término Agile:

La metodología de desarrollo flexible (desarrollo de software ágil, métodos ágiles) es una serie de enfoques para el desarrollo de software centrados en el uso del desarrollo iterativo, la formación dinámica de requisitos y garantizar su implementación como resultado de la interacción constante dentro de grupos de trabajo autoorganizados formados por especialistas de varios perfiles.

Los siguientes puntos importantes se pueden distinguir de esta definición:

1. Usando un enfoque iterativo . No hay nada nuevo aquí, no he escuchado acerca de los métodos de desarrollo de software que niegan este principio;
2. La formación de requisitos se lleva a cabo en etapas, en el curso del desarrollo del producto . Esta es una diferencia clave de muchas otras técnicas. De alguna manera, da una ventaja, de alguna manera introduce limitaciones fundamentales. Discutiremos más adelante ambos;
3. Usando la interacción constante y cercana de todos los miembros del equipo , incluido el cliente. La mayoría de las otras metodologías, por supuesto, prestan atención al trabajo en equipo, incluso con los clientes, pero posicionar esta comunicación como un recurso adicional del proyecto que brinda una ventaja absoluta es más exclusivo;
4. Equipo autoorganizado . Se supone que cada iteración termina con un informe y un cambio constructivo en el proceso, lo que contribuye al desarrollo continuo del equipo. Lo más probable es que se tomen técnicas similares de técnicas anteriores. Por ejemplo, practica RUP.

En principio, no logramos encontrar mucho de esta descripción, así que pasemos a aclaraciones:

La mayoría de las metodologías flexibles apuntan a minimizar los riesgos al reducir el desarrollo a una serie de ciclos cortos llamados iteraciones, que generalmente duran de dos a tres semanas. Cada iteración en sí misma parece un proyecto de software en miniatura e incluye todas las tareas necesarias para producir una mini ganancia en funcionalidad: planificación, análisis de requisitos, diseño, programación, pruebas y documentación.

Pero ya consideramos el mismo enfoque en el viejo RUP. Es decir, tampoco hay nada fundamentalmente nuevo aquí.

La mayoría de las definiciones que he encontrado también son abstractas y vagas, hay muy poca información que le permita tomar de inmediato y comenzar a usar la flexibilidad. Pero aquí se abre otro aspecto igualmente importante del enfoque, que aporta claridad a la superficialidad a través de la cual se cruza todo el tema en consideración. Aquí hay un ejemplo:

Agile no incluye prácticas, pero define los valores y principios que guían a los equipos. Agile es una familia de procesos de desarrollo, no el único enfoque para el desarrollo de software, y está definido por Agile Manifesto.

Ágil es una forma de pensar con su propio sistema de valores. Es similar a la filosofía, religión o cultura: el mismo conjunto de actitudes en las que una persona cree y que influyen en su comportamiento.

Aparentemente por esta misma razón, hay innumerables disputas en torno a las Metodologías Flexibles. No hay mucho en la idea de lo que realmente puedes sentir. Aparentemente, debido a esto, puede llamar a algo propio (casi cualquiera), no convencional - metodologías flexibles y no quedar atrapado en la falta de profesionalismo. En mi opinión, esto es aceptable, si quieres estar en la tendencia, nombra tu enfoque de desarrollo lo más de moda posible, si solo el proceso de desarrollo y el producto final en sí no se vean afectados.

Recuerdo un caso de mi práctica cuando una gran empresa de TI, antes de un nuevo proyecto a gran escala, decidió mejorar sus procesos tecnológicos. Para esto (según las recomendaciones), se invitó a un especialista en metodologías flexibles, sobre cuyos hombros se encomendó esta misión responsable. Después de leer una conferencia muy breve sobre la forma de pensar y el sistema de valores de Agil, comenzó a descubrir cómo son realmente las cosas con la producción de software en la empresa. Al encontrar defectos e inconsistencias en los procesos existentes, junto con el equipo de la empresa, seleccionamos las formas y métodos más apropiados para resolverlos. Afortunadamente, estas deficiencias no fueron un secreto para nadie, y una serie de razones les impidieron superar. Por ejemplo: falta de tiempo, contradicciones entre equipos subordinados a diferentes niveles de gestión, miedo a asumir la responsabilidad, etc. Dado que todo el evento fue patrocinado por la alta dirección de la empresa, y el especialista invitado era un profesional de TI verdaderamente de primera clase, las innovaciones desarrolladas se implementaron casi a tiempo y con un efecto muy sensible y positivo. Eso es solo para el manifiesto de metodologías flexibles que no tenían nada que hacer. Como resultado, la mayoría de los empleados de la compañía seguían confiando en que ahora se habían cambiado completamente a Agile y habían abandonado todo lo demás. Todo esto se parece mucho a un cuento de hadas sobre cómo un soldado cocinó gachas de un hacha, sacando astutamente los ingredientes que necesitaba de los propietarios y mejorando el sabor del plato. Eso es solo que el hacha no se hierve.

Pero dado que estamos aquí para analizar imparcialmente el fenómeno Ágil, continuaremos nuestro estudio. Pasemos a la fuente original: el Manifiesto Ajail:

2. Analicemos las ideas principales del Manifiesto Ágil

Ideas clave

1. Las personas y la interacción son más importantes que los procesos y las herramientas;
2. Un producto que funciona es más importante que la documentación completa;
3. La colaboración con el cliente es más importante que negociar los términos del contrato;
4. La disposición a cambiar es más importante que seguir el plan original.

Comencemos con una mosca en la pomada. Para mí personalmente, todos los puntos son controvertidos. Vayamos en orden:

punto 1 . En mi opinión, una de las razones clave para la aparición de Ajail, como escribí anteriormente, fue el rápido desarrollo de sistemas de automatización para procesos de desarrollo de software, lo que permitió descuidar las regulaciones. Es decir, es solo el desplazamiento del trabajo humano monótono mediante procesos robóticos lo que nos permite producir resultados más confiables y predecibles, incluido el mantenimiento de una interacción de alta calidad de los procesos mismos. Por lo tanto, sobre "Las personas: lo más importante", en mi opinión, esto es solo un eslogan que ayuda a divertir la vanidad humana de los miembros del equipo más sentimentales.

, , , ( ) . , , .

2 . – , , . - , ? , , , ? , , ? .

. , .

, , , , “” , . . , . . , , , , , .

3. Bueno, para empezar, el punto no comprende la oposición misma. ¿Pero el acuerdo de los términos del contrato no es una colaboración con el cliente? Si el cliente, como resultado de aclarar los términos del contrato con el equipo de desarrollo, puede comprender la cantidad de trabajo, darse cuenta aproximadamente del costo de su implementación y, lo más importante, imaginar el resultado que puede obtener, en algunos indicadores realmente tangibles (funciones comerciales automatizadas, modelos de diseño, etc.) .). Después de todo, será más fácil para él tomar una decisión: si necesita este producto en particular, si está listo para financiar su producción, etc. ¿No es eso una colaboración?

? - ? , , - . – . , , . , . , .

— , , . – .

4. , , , . , , , . , , . , , . , , , .

3. Agile Manifesto

, , Agile Manifesto:

• ;
• ( );
• ( );
• , ;
• , , ;
• — ( );
• — ;
• , ;
• ;
• — ;
• , ;
• . .

La mayoría de lo anterior no contradice otros métodos y es muy recomendable.

Pero no siempre estos principios pueden realmente usarse en la práctica. Por ejemplo, un cliente no siempre puede colaborar con un equipo para discutir soluciones. A menudo no tiene tiempo y, a veces, ningún deseo especial. Entonces necesita un profesional: un analista, capaz de líneas concisas, discretamente, que se haya basado en la confianza y use todas sus "pequeñas cosas" psicológicas, para extraer información útil de ella y ya peinarla sin problemas, transmitirla al equipo de desarrollo en la forma más adecuada para la implementación. ¿Es interesante si esto sucede, el trabajo del equipo ya no se considera flexible?

. , , () , . , , . .

, « , » , Agile, . “” , ( ).

, , — — « ( )». , , , -, .

IV

.
, .
, , , .
.

Si surgieron tantas evaluaciones críticas durante la revisión, ¿cómo funciona todo?
El éxito de Agile, aparentemente, contribuye a la efectividad de la metodología en pequeños proyectos y a la similitud del uso de todos los elementos anteriores.

1. Beneficios de usar Agile

. , , , .. , , , , , .

Debido a las entregas frecuentes de prototipos, es posible evitar grandes discrepancias entre las expectativas del cliente y las opciones ofrecidas por los ejecutantes de las soluciones. Con cada nuevo lanzamiento, acercándolos. Las reducciones en el tiempo de ejecución y, en consecuencia, las pérdidas financieras tampoco son grandes y predecibles, se pueden incluir directamente en el plan del proyecto.

: , . “ ”, , , . “ ”, . , , “”, . 3-6 , , .

, , – ( ), . , , , , -, , -, , .

2. – Agile

, , . , , . , . – , – .

, . .

Si este producto es de una sola vez y no está previsto desarrollarlo, entonces es suficiente.

3. ¿Cómo puedo usar Agile en proyectos medianos?

Usar Agile en proyectos medianos también puede ser muy efectivo.

En proyectos más grandes, se puede utilizar una variedad de plataformas de automatización, equipadas con plantillas listas para usar, mejores prácticas, herramientas de autodocumentación, etc. Esto simplifica enormemente los procesos formales, incluidos el diseño, el modelado y la documentación. Las soluciones presentadas en tales casos se duplican con mayor frecuencia, con un número limitado de mejoras y cambios.

El mayor efecto se puede obtener si se documentan decisiones similares anteriores. Sobre esta base, puede dedicar más tiempo no al diseño y modelado, sino a seleccionar, junto con el cliente, el prototipo deseado. “Pruébalo, póntelo y listo. No presionar? ". Es importante que las soluciones nuevas e implementadas también estén bien documentadas. En este caso, el equipo recibe un conjunto de bloques e instrucciones para ensamblar varios modelos de ellos, que se pueden ofrecer a los futuros clientes para elegir.

En este modelo de trabajo, es importante comprender que Agile no niega la importancia del proceso de documentación, simplemente le permite retrasar su formación, dando prioridad a la construcción del producto en sí (si es posible en la situación actual). La documentación se puede formar ya después de recibir un producto sostenible, consolidando los resultados logrados y, como se señaló anteriormente, ayudando a no perder en el futuro el hilo de la comprensión de las reglas del sistema.

4. Cómo usar efectivamente Agile en grandes proyectos de integración

En proyectos grandes y complejos, en los que se mantiene documentación de alta calidad, existe una idea arquitectónica del producto y el proceso de su producción, las "piezas" del producto se pueden subcontratar a pequeños equipos. Esta transferencia ocurre después de un estudio detallado de la arquitectura general y la preparación de requisitos de alto nivel para nuevos subsistemas. Y ahora estas partes relativamente pequeñas se pueden implementar de manera bastante efectiva usando Agile.

El mismo esquema es aplicable para pequeñas mejoras o desarrollo gradual de un sistema complejo grande, especialmente si necesita realizar algún trabajo de investigación.

Otra opción para usar Agile en grandes proyectos se puede aplicar de manera efectiva en caso de una entrega de emergencia del producto al cliente. En vista de la falta crítica de tiempo y recursos para su refinamiento y corrección, es precisamente la flexibilidad en el enfoque lo que puede ayudar a prevenir un fiasco. En tales situaciones, en mi opinión, esta metodología particular es óptima.

En esta sección, vale la pena mencionar los métodos existentes basados ​​en Agile, pero que gravitan hacia la resolución de problemas a gran escala.

El proceso unificado ágil (AUP) es una versión simplificada del proceso unificado (UP) desarrollado por Scott Ambler. Esta metodología de desarrollo de software combina elementos de metodologías flexibles y un proceso unificado. En particular, AUP implica el desarrollo a través de pruebas (TDD), el uso de modelado flexible (modelado ágil en inglés) y refactorización de bases de datos, gestión de cambio flexible.

OpenUP es un método de desarrollo de software iterativamente incremental. Posicionado como una versión ligera y flexible de RUP. OpenUP divide el ciclo de vida del proyecto en cuatro fases: la fase inicial, las fases de refinamiento, diseño y transferencia. El ciclo de vida del proyecto garantiza que las partes interesadas y los miembros del equipo reciban puntos de familiarización y toma de decisiones durante todo el proyecto. Esto le permite monitorear efectivamente la situación y tomar decisiones oportunas sobre la aceptabilidad de los resultados. El plan del proyecto define el ciclo de vida, y el resultado final es la aplicación final.

5. Cómo no usar Agile

Una sección igualmente importante, tal vez en aras de la cual se contempló todo el análisis.

1. El líder en mi anti-rating es la situación cuando intentan usar Agile, o más bien algunos de sus principios, no para lograr ningún objetivo específico que permitan garantizar, sino simplemente #CRAFTLY. Debido a que esta es una tendencia, está en boca de todos. Por ejemplo, alguien compartió críticas positivas en la fiesta de TI, un poco efímero e incluso arrogante, pero hubo un rumor, apareció un séquito. Y ahora ya se han llamado seguidores de Agile, se sienten en comunicación con el resto, pertenecientes a cierto club de élite. Todo esto contribuye a la aparente simplicidad de la metodología y los contornos borrosos de sus fronteras. Las implementaciones sobre este principio ocurren irreflexivamente y formalmente. Las personas implementan formalmente y sin principios principios diseñados para reducir el formalismo.
   
   Por ejemplo, uno de los casos más recientes. En una compañía, que realizaba Retrospectivas, los Timlids les prohibieron. Aquí hay tal chip. Inesperadamente Primer pensamiento: bueno, tal vez tengan razón para que las autoridades no presionen al equipo cuando discuten problemas, etc. Pero los Timlids están ofendidos, están perdidos y quieren descubrirlo. Traté de convencerme de que dicen que podría ser mejor, lo principal es que obtienes una lista de deseos, con una lista de lo que hay que cambiar, lo que hay que mejorar, etc. Y aquí se reveló un terrible secreto. Y no surgen resultados ni deseos de mejorar los procesos como resultado de estas reuniones. Señores IT_shniki, y ¿por qué entonces una retrospectiva? ¿Alabarse mutuamente y aumentar el espíritu de equipo? A, digamos, y B. dijeron. Después de todo, el objetivo principal de este proceso de metodología es que: "El equipo debe analizar sistemáticamente las posibles formas de mejorar la eficiencia y, en consecuencia, ajustar el estilo de su trabajo".
2. La segunda situación en mi clasificación es cuando los equipos deciden ahorrar en la preparación de requisitos en proyectos con algoritmos lógicos o de comportamiento complejos. Es decir, cuando la historia del usuario es solo una pequeña punta del iceberg del problema, y ​​su parte principal no es visible y requiere un análisis detallado y exhaustivo y un diseño para su implementación. ¿Qué pasa con esto?
   
   Antes de comenzar a trabajar, ni el cliente ni los desarrolladores entienden aproximadamente la cantidad de trabajo que deben hacer. Y en consecuencia: o bien el cliente pagará, pagará y pagará, cada vez que le expliquen que todo resultó ser mucho más difícil y ahora el trabajo aún no es visible y finaliza. Y después de todo, será una lástima dejar de fumar y gradualmente comenzará a roer a la severa comprensión de que este producto "dorado" nunca valdrá la pena. O bien, los desarrolladores, habiendo acordado completar el trabajo por una cierta cantidad de tiempo, terminarán y rehacerán el producto (sin cargo) a su propio costo hasta que el cliente se quede sin imaginación, o se apiade de las víctimas de un enfoque flexible.
3. La situación ocupa un tercer lugar honorable cuando en un gran proyecto multifuncional (y de repente también uno de integración) el equipo decide ahorrar en la elaboración de la arquitectura de la solución y comienza a implementar historias de usuarios individuales en iteraciones cortas. Con un alto grado de probabilidad sucederá que después de 3-5 iteraciones, al intentar crear un nuevo funcional, resulta que debe rehacer todo el anterior, ya que los principios fundamentales en los que debería haberse basado este funcional no se tuvieron en cuenta. Peor aún, si después de la décima iteración se descubre que las tecnologías seleccionadas no satisfacen todas las necesidades del cliente y es necesario comenzar de nuevo. Quizás cambiando el comando.
4. La situación en la que una correa aguda e increíblemente flexible irrumpe en las extensiones de un segmento de mercado lento no cayó entre los tres primeros. Una startup, también es una startup, que no tiene fundamentos, vínculos, apegos y, al mismo tiempo, estabilidad y estabilidad. Y simplemente, casi no hay documentación, el equipo no es armonioso y a menudo cambia. El mercado está literalmente destrozando al equipo, exigiendo más y más soluciones nuevas en el campo replanteado, y todos los proyectos posteriores simplemente se desmoronan ante nuestros ojos. Muy a menudo, esto se explica por el hecho de que el equipo no comprende los procesos de producción de software industrial , organización de entrega y soporte de productos.

Para resumir

Al preparar este artículo, traté de ayudar a los equipos interesados ​​en el enfoque ágil a resaltar y formalizar los desafíos que deben enfrentar de una forma u otra, así como a encontrar posibles soluciones para superarlos. Traté de considerar el tema lo más tolerante posible, tanto para los apologistas por la introducción de una o más metodologías de este grupo, como para los oponentes que quieren desacreditar el halo de flexibilidad y razonablemente rehusarse a usarlo.

Espero que el análisis ayude a los equipos que utilizan otras metodologías para aprovechar el enfoque ágil si es necesario.