¿Qué hace que el desarrollo de software Agile sea tan atractivo?

El desarrollo ágil de software se está convirtiendo en una palabra de moda bastante divertida en estos días.

Como desarrollador, entiendo el valor pragmático del desarrollo iterativo, pero (la mayoría de las veces) no es una elección de los desarrolladores adoptar un enfoque ágil para el desarrollo de software. ¡Es una opción de gestión de arriba hacia abajo! Ya sea cristal, métodos ágiles, dsdm, rup, xp, scrum, fdd, tdd, lo que sea. No es una elección del desarrollador.

Para todos los gerentes, ¿cuáles son las principales razones para elegir hacer un desarrollo ágil cuando (en mi experiencia) la mayoría de los gerentes ni siquiera han tocado un código en su vida!

Requisitos de cambio, entrega más rápida

Agile es atractivo porque brinda la posibilidad de adaptarse a las necesidades cambiantes más rápidamente (o en absoluto), y entregar esos cambios al cliente más rápidamente.

Esta es la razón por la cual muchas compañías fallan cuando usan Agile / Scrum: los gerentes no entienden que con un gran poder (establecer fechas de lanzamiento más rápidas y cambiar los requisitos a menudo) viene la responsabilidad de confiar en los desarrolladores para las estimaciones . Para que el trabajo sea ágil, el gerente debe estar dispuesto a reducir el alcance.

Quieren el poder de ambos.

Siguiendo tendencias

A veces las personas hacen cosas, no por el mérito de lo que se están embarcando (ágilmente), sino simplemente porque es popular y otras personas están tratando de hacer lo mismo.

"¿Qué? ¿Macrojam está haciendo Agile? ¿Por qué no lo hacemos? ¡No somos lentos, somos Agile, maldita sea!"

A algunas personas no les importa lo que realmente implica ser ágil. Es simplemente un medio para justificar su existencia. Sheeple, presión de grupo, etc.

La codificación en sí no es la razón principal por la que los gerentes pueden estar convencidos de seleccionar un método ágil. El hecho de que pueda reaccionar más rápido a los requisitos y prioridades cambiantes es atractivo. El 'gerente' al final necesita entregar una solución al usuario final / cliente / su gerente.

Si la funcionalidad que parecía clave al comenzar el proyecto puede ser abolida a mitad del proyecto y reemplazada por requisitos nuevos y más relevantes, esa es una gran ventaja.

También es importante que la mayoría (por ejemplo, como en scrum) cada entrega intermedia esté casi lista para ser puesta en producción. Al mismo tiempo, las funciones más urgentes se desarrollaron primero. Por lo tanto, en caso de que el proyecto se cancele debido a alguna decisión corporativa, la gerencia está segura de que terminará con algo que funcionará y se puede poner en producción.

Espero que esto ayude.

Aumente la visibilidad de lo que está sucediendo y aumente la productividad.

1. Los gerentes suelen estar interesados ​​en la visibilidad que aporta ágil, especialmente con scrum. Es uno de los puntos de venta más utilizados en los seminarios que se dirige a los gerentes.

2. También se usa comúnmente una mayor productividad para atraerlos, ya que es fácil de demostrar (gracias a la visibilidad). Algunos evangelistas ágiles les prometen una productividad sobresaliente de sus empleados existentes. "¿Qué? Ya los estoy presionando como limones y me dices que puedo obtener aún más " ?

Muchos gerentes usan agile para aplastar a sus empleados un poco más y los he visto usar la tabla de quemado como una máquina de caza más floja en una gran empresa.

¿Resultado? Muchos equipos en distress. Pensaban que ágil resolvería todos sus problemas, pero hizo exactamente lo contrario. El problema estaba en otra parte.

Estoy luchando activamente contra eso. Es por eso que, a veces, cuando existe una alta probabilidad de que la pervertedadministración emplee una metodología ágil , sugiero no mencionarla dentro de la empresa.

La respuesta a esa pregunta podría llenar un libro.

Creo que una de las razones principales es que el desarrollo ágil se centra en lo que se puede entregar. Siempre se enfoca en entregar exactamente lo que es más urgente aquí y ahora.

Otra razón es que las prácticas de planificación y estimación basadas en la historia que siguen los procesos ágiles brindan una estimación mucho mejor de lo que se puede entregar y cuándo.

Un buen ejemplo de cuán efectiva es la planificación basada en historias es un proyecto en el que trabajé. Durante un par de meses (antes de adoptar un desarrollo ágil), el líder del proyecto creía que podíamos entregar a tiempo, y eso era aproximadamente 18 meses desde la fecha límite. Todos los desarrolladores tenían la sensación de que eso probablemente no era realista. Después de comenzar una planificación ágil, el líder del proyecto todavía tenía una evaluación optimista de la situación. Pero solo después de algunos sprints, el líder del proyecto se dio cuenta de que el equipo simplemente no tenía la capacidad de cumplir con todos los requisitos en el tiempo esperado. Y eso aún estaba a más de 12 meses de la fecha límite.

Por lo tanto, las prácticas ágiles también aclaran la realidad mucho antes.

Y, por último, los equipos ágiles tienden a adoptar con mayor frecuencia prácticas que crean una mejor calidad de código, por ejemplo, desarrollo basado en pruebas, refactorización frecuente, integración continua, revisión de código de pares / programación de pares, etc. No es que los proyectos de software tradicionales prohíban estas prácticas, solo tienden a No estar tan enfocado.

¡La mayoría de los gerentes ni siquiera han tocado un código en su vida!

Fui desarrollador durante 12 años y ahora gerente durante 5. Durante los 5 años pasé gradualmente de un administrador que todavía codificaba a ser principalmente un administrador puro (todavía ocasionalmente reparo errores o hago ejercicios de creación de prototipos).

¿Cuáles son las principales razones para elegir hacer un desarrollo ágil?

• Visibilidad o éxito rápido / Fallo rápido: somos una tienda de desarrollo de productos con ciclos de 6 a 24 meses. El desarrollo iterativo con funciones probadas y de trabajo hizo un mejor trabajo al reflejar el estado del proyecto.
• Cambio: en nuestro entorno, los requisitos y el tiempo tienden a ser fijos. Pero, el negocio con demasiada frecuencia pasa por cambios rápidos y discordantes en la dirección. El desarrollo iterativo y visible facilitó que los proyectos cambiaran de dirección.
• Los requisitos basados ​​en la historia con desarrollo iterativo facilitaron el trabajo con la empresa que no siempre entendía los aspectos técnicos de los requisitos o entendía completamente los impulsores comerciales de algunos de los detalles. En nuestros esfuerzos anteriores, las especificaciones de alto nivel o los documentos de requisitos de comercialización no siempre fueron suficientes. Ahora, a medida que los proyectos evolucionan, puede haber una investigación paralela de mercado y de clientes.
• El cambio de proceso vino con muchos otros atributos de desarrollo como TDD, pruebas automáticas versus pruebas manuales, ciclos de prueba más estrictos (ya no tenemos un grupo de control de calidad, solo un grupo de control de calidad) y una mayor apreciación y esfuerzo relacionado con la calidad (utilizamos un muchas más herramientas y métricas).

Podríamos haber logrado esto de otras maneras, pero aprovechar metodologías e ideas ágiles nos ha ayudado enormemente.

También continuamos refinando nuestro proceso. Por ejemplo, el equilibrio entre el trabajo de diseño inicial frente al diseño justo antes de la implementación. Revisamos todas nuestras decisiones regularmente para determinar si podríamos haber diferido decisiones de diseño pasadas. Y, cuando las cosas salen mal, cuánto más trabajo inicial habría sido necesario hasta que se hubiera identificado el error. A menudo, las fallas son casos de esquina que requieren un análisis profundo. El esfuerzo para obtener ese detalle a menudo es el mismo que el costo de resolverlo en el camino y refactorizarlo. Los equipos no son penalizados por este tipo de errores y se les anima a ser más agresivos.

He visto a varias compañías "hacer" ágilmente. Desafortunadamente, muy pocos de ellos adoptan ágil. Lo que quiero decir es que solo haciendo desarrollo iterativo y standups diarios (donde la mayoría del equipo se sienta) no hace que el equipo sea ágil. TDD, refactorización, integración continua, presencia del cliente, prácticas SOLIDAS hacen que un equipo sea ágil. Sin esos, solo estás dando vueltas en círculos.

Hay mucho atractivo que trae el mensaje de Agile. La adaptabilidad al cambio es la más grande. Desafortunadamente, su código no se vuelve más adaptable solo porque cambia la forma en que administra el proyecto. Hasta que más compañías se den cuenta de esto, solo escucharemos sobre más y más proyectos ágiles fallidos.

No sé sobre la parte de la palabra de moda. Realmente he estado haciendo esto todo el tiempo en un proceso no tan formalizado o identificado. He tenido clientes que literalmente miran por encima de mi hombro mientras construía su sitio web. Guarde unos 50 correos electrónicos y el cliente aprendió algo sobre este proceso; no es fácil.

Toda la noción de que tomaremos un largo período de tiempo para escribir todo lo que el usuario quiere que haga el software, luego tomaremos un período de tiempo más largo para construir lo que creemos que quieren descubrir solo dentro de los 2 segundos posteriores a la prueba de la aplicación. no es lo que esperaban es nauseabundo. ¿Qué tan difícil es dividir cualquier proyecto o aplicación en algunas piezas razonables para construir y obtener algunos comentarios antes de construir otra pieza?

Sé que esto es una simplificación excesiva y no aborda las prácticas reales del desarrollador, pero no es difícil de vender incluso al gerente o cliente más no técnico. ¿Qué otro enfoque es más atractivo? ¿A los clientes realmente les encanta el hecho de que los programadores están fuera de su alcance durante 6-12 meses mientras se desarrollan durante algún proyecto en cascada? ¿Contratarías a alguien para construir una casa de esta manera?

La gerencia no presiona estas cosas sobre los desarrolladores. Los desarrolladores y los equipos deben tomar la iniciativa y esforzarse hacia ellos para hacer mejor su trabajo. El trabajo de la gerencia es brindar apoyo para estas iniciativas.

Como gerente que ha escrito una buena cantidad de código en mi carrera, puede que no sea a quien buscas para responder esto. En cualquier caso, creo que el atractivo de Agile en estos días tiene más que ver con responder a las necesidades del cliente más rápidamente, así como acortar el ciclo de retroalimentación entre la especificación, la codificación, las pruebas y el cliente. Estamos avanzando hacia un desarrollo más ágil por estas mismas razones.

Creo que no deberías estropear el proceso ágil y las prácticas de codificación / desarrollo. Por ejemplo, Scrum no le dice cómo debe desarrollar su código: se trata del proceso que acepta los cambios.

Al final del día, se trata de empoderar al desarrollador; se trata de reconocer el hecho de que esos tipos que están en la parte inferior de la jerarquía son los únicos que realmente entienden el alcance de lo que hay que hacer y cómo hacerlo, así que si ya los contrataste por su experiencia, ¿por qué? no dejarlos tomar el control total o, mejor dicho, ¿por qué distanciarlos de la toma de decisiones real?