Desarrollo ágil utilizando métodos ágiles

El desarrollo ágil (desarrollo ágil) es un método de desarrollo paso a paso, iterativo y orientado a las personas. En el desarrollo ágil, la construcción de un proyecto de software se divide en múltiples subproyectos, y los resultados de cada subproyecto deben integrarse y ejecutarse funcionalmente probados. En resumen, un proyecto grande se divide en proyectos más pequeños, interrelacionados pero ejecutados de forma independiente, y se completan por separado, mientras que el software siempre está disponible para su uso.

¿Es el desarrollo ágil una nueva teoría? La respuesta es mixta. Las personas cuidadosas pueden descubrir que el desarrollo ágil en realidad se basa en muchos métodos de ingeniería de software. El desarrollo iterativo y el desarrollo incremental, dos métodos que se mencionan en cualquier libro de texto de ingeniería de software, juegan un papel importante en el modelo de desarrollo ágil. Volviendo más atrás, también podemos ver la sombra del método en cascada y del método de creación rápida de prototipos, y quizás haya más.

Mejora, no innovación. El desarrollo ágil puede entenderse como la integración de los métodos de desarrollo de software existentes: tomando lo mejor y descartando lo sobrante. Por tanto, el desarrollo ágil hereda muchas de las ventajas de los métodos originales. "En el desarrollo de software ágil, recibimos un software funcional cada dos semanas", describe Fowler. "Este ciclo extremadamente corto le brinda al cliente final una visión rápida y oportuna de lo que gastó en la creación del software. Qué resultados se obtuvieron". /p>

Quizás debido a limitaciones de tiempo, Fowler enumeró sólo algunas de las ventajas. Permitir que los requisitos se cambien durante el proceso de desarrollo, identificar los riesgos de antemano mediante iteraciones tempranas, hacer factible la reutilización del código, reducir el retrabajo del proyecto... El desarrollo ágil se basa en muchos métodos avanzados y una rica experiencia y tiene muchas ventajas Las ventajas hacen que el desarrollo ágil parezca. haberse convertido en la respuesta estándar para resolver la crisis del software.

Preguntas y Pensamientos Sin embargo, la realidad a la que debemos enfrentarnos es que la optimización de modelos y métodos no significa el fin del problema. Como modelo de desarrollo, el desarrollo ágil enfrenta muchos desafíos.

La división de proyectos grandes significa que habrá más subproyectos y será más complejo coordinar estos subproyectos de forma sincrónica o asincrónica y asignar recursos de manera razonable. Además, con la actual "ampliación" general de proyectos y equipos de proyectos, los problemas encontrados también se han multiplicado. La importancia de las personas se ha elevado a un nivel superior. En ausencia de medios de coordinación eficaces, cómo minimizar el impacto de los flujos de personal y los cambios del proyecto en todo el proyecto se ha convertido en un gran desafío. …El nuevo enfoque trajo gran comodidad, pero también causó casi la misma cantidad de problemas.

Desde principios de 2004, el concepto de desarrollo ágil se ha ido popularizando gradualmente. Bailar apoya mucho esta teoría, por lo que también adopta métodos ágiles en la formación de equipos: el equipo ágil de Capital One está formado por tres empresarios. , dos empleados de operaciones y de cinco a siete empleados de TI, incluido un director de información empresarial (en realidad, el traductor entre los departamentos empresarial y de TI, además, hay un equipo de directores de proyectos y al menos 80 desarrolladores); Bailar envió a estos desarrolladores para participar en una capacitación de desarrollo ágil y dominaron las habilidades relevantes.

Cada equipo tiene su propio coach ágil (Bailar emplea a 20 coaches ágiles) cuyo trabajo es seguir todo el proceso y proporcionar asesoramiento y apoyo. Los requisitos iniciales se redujeron a un objetivo, una pila de tarjetas que detallaban lo que se necesitaba y algunos prototipos y plantillas como referencia. Los miembros del equipo trabajaron en estrecha colaboración durante toda la fase del proyecto, y el desarrollo se detuvo periódicamente (tres o cuatro veces durante el proceso de desarrollo de nueve semanas) para evaluar el proceso y decidir si eran necesarias modificaciones a los requisitos. En Capital One, los grandes proyectos de TI se dividen en subproyectos y se asignan a equipos ágiles en lo que se conoce como enjambre en desarrollo ágil, con todos los procesos controlados por un único director de proyecto.

Para probar la efectividad de este sistema, Bailar dividió el proyecto del desarrollo en cascada anterior al desarrollo paralelo, formó un equipo de desarrollo ágil y ágil defendido por el desarrollo ágil y dividió las etapas de desarrollo en Sprints en Ciclos de 30 días: cada sprint comienza con una reunión inicial y finaliza antes del siguiente sprint.

Después de que Bailar lo comparó con los métodos de desarrollo tradicionales, quedó muy emocionado: el desarrollo ágil redujo el tiempo de desarrollo entre un 30 y un 40 %, a veces incluso cerca del 50 %, y mejoró la calidad de los productos entregados. Sin embargo, existen algunas necesidades que el desarrollo ágil no puede satisfacer. Bailar reconoce que el desarrollo ágil tiene sus limitaciones, como requisitos que no están claramente definidos y priorizados, o aquellos que caen en el triángulo más rápido, más barato y mejor, pero no pueden priorizar los tres juntos. Además, cree que los proyectos a gran escala o proyectos con reglas especiales que requieren reglas especiales son más adecuados para el desarrollo tradicional. Si bien describir los requisitos siempre ha sido un desafío, los CIO pueden beneficiarse enormemente del proceso.

El desarrollo ágil fue propuesto por un grupo de expertos de la industria en respuesta a la situación actual de algunas organizaciones, propusieron algunos valores y principios para permitir que los equipos de desarrollo de software trabajen rápidamente y respondan a los cambios, y lo establecieron. la Agile Alliance a principios de 2001. Revelan mejores formas de desarrollar software haciéndolo ellos mismos y ayudando a otros a hacerlo. A través de este trabajo, creen que las personas y las interacciones son mejores que los procesos y las herramientas, que el software funcional es mejor que la documentación exhaustiva, la colaboración con el cliente es mejor que la negociación de contratos y que responder al cambio es mejor que ceñirse a un plan. También desarrollaron lo siguiente. Principio de insistencia: Nuestra primera prioridad es entregar software valioso lo antes posible para satisfacer al cliente. Incluso en las últimas etapas de desarrollo, damos la bienvenida a los cambios en los requisitos. Los procesos ágiles aprovechan el cambio para crear una ventaja competitiva para los clientes. Los intervalos entre entregas frecuentes de software funcional pueden variar de semanas a meses, siendo mejores los intervalos más cortos. Los empresarios y los desarrolladores deben trabajar juntos todos los días durante todo el proceso de desarrollo del proyecto. Construya proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan y confíe en ellos para hacer el trabajo. La forma más efectiva y eficiente de transferir información dentro de un equipo es mediante conversaciones cara a cara. El software funcional es la principal medida del progreso. Los procesos ágiles promueven la velocidad del desarrollo sostenible. Las personas responsables, los desarrolladores y los usuarios deberían poder mantener un ritmo de desarrollo estable y a largo plazo. Un enfoque continuo en las buenas habilidades y el buen diseño mejorará las capacidades ágiles. La simplicidad es fundamental. La mejor arquitectura, requisitos y diseños provienen de equipos autoorganizados. De vez en cuando, el equipo reflexiona sobre cómo pueden trabajar de forma más eficaz y ajusta su comportamiento en consecuencia. 1. Métodos de desarrollo ágil

(1) Descripción Este artículo se basa en algunas notas e ideas después de leer "Desarrollo de software ágil" de Alistair Cockburn y "El desarrollo de software ágil de XP es un conjunto" de William C. Wake. de software Término general para métodos de desarrollo, incluidos (Crystal, programación extrema, desarrollo de software adaptativo, etc.). Los métodos de desarrollo ágiles también se conocen como métodos de desarrollo "ligeros".

Lo siguiente es un extracto de un artículo de Martin Fowler:

De cero, de pesado a ágil La mayor parte del desarrollo de software sigue siendo una actividad desordenada, generalmente código y correcciones. El proceso de diseño está lleno de decisiones ad hoc a corto plazo y sin una planificación completa. Este patrón funciona bien para sistemas pequeños, pero a medida que los sistemas se vuelven más grandes y complejos, resulta cada vez más difícil agregar nuevas funciones. Al mismo tiempo, los errores y fallas técnicas son cada vez más difíciles de solucionar. Una manifestación típica es que una vez completado el sistema, habrá una larga fase de prueba y, a veces, incluso se tiene la sensación de que el tiempo se acaba, lo que afecta gravemente la finalización del proyecto. Llevamos mucho tiempo utilizando este modelo de desarrollo, pero en realidad tenemos una alternativa, la "metodología". Basándose en prácticas de otros campos de la ingeniería, estos métodos son reglas estrictas y detalladas para el proceso de desarrollo, con el objetivo de hacer que el desarrollo de software sea más predecible y eficiente. Estos métodos formales existen desde hace mucho tiempo, pero no tuvieron un éxito espectacular ni atrajeron siquiera una atención generalizada. La crítica más común a estos métodos es que son burocráticos y engorrosos, y si se siguen, habrá demasiado que hacer, lo que ralentizará el proceso de desarrollo.

Como resultado, estos métodos a menudo se consideran métodos "engorrosos, rezagados y pesados", o lo que Jim Highsmith llama métodos "monumentales". Para contrarrestar estos métodos, en los últimos años ha surgido una nueva clase de métodos. Aunque aún no tienen un nombre oficial, generalmente se les conoce como métodos "ágiles". Para muchos, el atractivo de estos enfoques radica en su rebelión contra la burocracia y los procesos burocráticos. Logran un equilibrio entre ningún proceso y procesos demasiado engorrosos, lo que da como resultado resultados más satisfactorios con menos pasos del proceso. Existen algunas diferencias significativas entre los enfoques ágiles y los de mucho retraso. Una diferencia obvia está en la documentación. Los métodos ágiles no están muy orientados a los documentos; generalmente requieren la menor documentación posible de las tareas. En muchos sentidos, están más centrados en el código. De hecho, creen que la documentación más básica debería ser el código fuente. Sin embargo, no creo que el aspecto de la documentación sea una parte esencial de los métodos ágiles. La documentación reducida es sólo un síntoma, refleja una característica más profunda: los métodos ágiles son "adaptativos" en lugar de "prescriptivos". El enfoque pesado intenta planificar un proyecto de desarrollo de software durante un período de tiempo más largo y luego desarrollarlo de acuerdo con ese plan. Este enfoque rechaza los cambios una vez desarrollado el plan. Los métodos ágiles, por otro lado, agradecen el cambio. De hecho, están diseñados para adaptarse a procesos cambiantes e incluso pueden permitirse cambiar para adaptarse al cambio. Los métodos ágiles están "orientados al cambio". Los métodos ágiles están "orientados a las personas" en lugar de "orientados a los procesos". Intentan hacer que el desarrollo de software funcione con la naturaleza humana, no en contra de ella. Destacan que el desarrollo de software debe ser una actividad agradable. Creo que las dos características anteriores resumen bien las ideas centrales de los métodos de desarrollo ágiles: adaptarse a los cambios y estar orientado a las personas

(2) La idea detrás del método

Alistair Cockburn en " Desarrollo ágil de software" "El libro habla sobre las ideas detrás de los métodos de desarrollo ágiles

Los procesos que las personas dominan se pueden dividir en tres categorías. (Dominar el proceso se puede dividir en tres etapas: 1. Seguir un proceso definido 2. Salir del alcance de conocer diferentes procesos y utilizar diferentes procesos en diferentes situaciones 3. Fluidez No preocuparse por seguir un proceso específico, sino saber qué hacer hacer bajo qué circunstancias Acción

El desarrollo de software es un juego colaborativo de inversión y comunicación. El objetivo principal del desarrollo de software es producir software siguiendo procesos y modelos específicos es sólo un medio para un fin, siempre y cuando. hay suficiente comunicación de información. Los medios son secundarios. El efecto de la comunicación es más importante que la forma de comunicación. Generalmente, hay dos objetivos en el desarrollo de software: 1. Crear software lo antes posible. o proyecto. A veces estos dos objetivos son contradictorios. Encontrar un equilibrio entre estos dos objetivos.

En el desarrollo de software, el factor humano es mucho mayor que el proceso y la tecnología.

Las personas tienen defectos: 1. Son propensas a cometer errores y, por lo tanto, deben detectarlos y corregirlos antes de que se propaguen. 2. No están dispuestos a correr riesgos cuando sienten que tienen más que perder. 3. Prefieren reconstruir en lugar de reutilizar lo que tienen. ya lo tienen. 4. Les resulta difícil mantener un hábito.

Algunas sugerencias para los factores humanos: 1. Los modelos concretos son más fáciles de entender que los modelos abstractos. 2. Es fácil empezar con ellos. ejemplos 3. Aprender de los resultados de los demás. Más fácil 3 Es más fácil aprender del trabajo de los demás 4 Es más fácil aprender del trabajo de los demás 5 Es más fácil aprender del trabajo de los demás Es más fácil aprender observando el trabajo de los demás 4 Hay suficiente tiempo ininterrumpido 5 Asignación e intención personal Trabajo que coincide con la capacidad 6 Las recompensas incorrectas pueden traer daño A la larga, los intereses personales son más importantes que las recompensas: 1) Siéntete orgulloso de. su trabajo. Siéntase orgulloso de participar en el trabajo, generalmente participando en un proyecto importante. Habrá una sensación de orgullo en el trabajo. 2) Siéntete orgulloso de los logros. Siéntete orgulloso de no completar el trabajo durante mucho tiempo. Daña la moral. 3) Siéntete orgulloso de la contribución. Siéntete orgulloso de contribuir a los demás. 7. Fomenta el interés por el trabajo de los demás y por todo el trabajo.

En equipo, está demostrado que cara a cara. La comunicación en tiempo real es la más eficaz, mientras que la comunicación retrasada puede provocar la pérdida de información. La pizarra es la mejor forma de comunicarse. El retraso provocará la pérdida de información. La pizarra es la mejor herramienta de comunicación. El avance de las herramientas de comunicación no puede mejorar el efecto de la comunicación. La función de los documentos es registrar y memorizar, no comunicar a través de documentos.

Los métodos de desarrollo ágiles deberían evitar varios errores comunes en el diseño de procesos 1. Usar el mismo proceso para todos los proyectos 2. Falta de flexibilidad 3. Demasiado oneroso 4. Agregar innecesarios "debería hacer" ¿Es realmente un deber? 5 No verificado

El diseño de procesos de los métodos de desarrollo ágiles tiene los siguientes principios: 1 La comunicación interactiva cara a cara es la forma más barata y rápida de intercambiar información. 2 Los procesos que exceden lo que realmente se necesita generan desperdicio. 3 Los equipos grandes requieren metodologías pesadas. 4 Los proyectos que abordan grandes problemas deben hacer hincapié en metodologías pesadas. 5 Una mayor retroalimentación y comunicación reduce la necesidad de documentación y productos intermedios. 6 Un enfoque más ligero es más eficaz para reducir la necesidad de documentación y productos intermedios. 5 Una mayor retroalimentación y comunicación puede reducir la necesidad de productos intermedios y documentación. 6 El enfoque liviano enfatiza la comprensión, la disciplina y las habilidades, mientras que el enfoque pesado enfatiza la documentación, el proceso y la comprensión formal se refiere al conocimiento total del proyecto por parte del equipo, incluido el comprensión del equipo de Todo el conocimiento del proyecto, incluido el conocimiento total del equipo sobre el proyecto, incluido todo el conocimiento del equipo sobre el proceso. La comprensión se refiere a la comprensión del proyecto por parte de todo el equipo, incluido el proceso de discusión. Los documentos solo pueden registrar una parte del mismo. La disciplina se refiere a las personas que toman la iniciativa para completar el trabajo. El proceso se refiere a las personas que completan el trabajo de acuerdo con las instrucciones. Buenas habilidades que pueden omitir productos intermedios. La forma significa que el trabajo debe completarse de acuerdo con los pasos prescritos. /p>

7 Determinar los cuellos de botella en medio del desarrollo y mejorar su eficiencia. El trabajo en los cuellos de botella debe acelerarse y reducirse tanto como sea posible (utilizar personas más capacitadas, más personas y mejores). herramientas), para hacer que la profundidad de trabajo en el cuello de botella sea lo más estable posible) El trabajo en los lugares que no son cuellos de botella se puede repetir con más frecuencia y se puede comenzar lo antes posible cuando la inversión aún es incierta.

Se pueden extraer algunas conclusiones de estos principios: 2 El tamaño del equipo a menudo aumenta a pasos agigantados, por ejemplo: se necesitan 6 programadores expertos, pero solo hay 4, por lo que es necesario programadores no cualificados. agregado, como resultado, gran parte del tiempo del equipo se dedica a capacitar a programadores no calificados y, finalmente, el equipo crece hasta tener una gran cantidad de programadores calificados. Por lo tanto, el equipo dedicó mucho tiempo a capacitar a programadores no calificados y finalmente llegó a tener 20 programadores no calificados. 3 Centrarse en mejorar las habilidades del equipo, no en hacer crecer el equipo 4 Usar diferentes procesos para diferentes proyectos 5 Cuando corresponda, los métodos ligeros son mejores que los métodos pesados ​​6 Cortar procesos para diferentes proyectos

El principio del desarrollo ágil El método es liviano y suficiente

El principio del método de desarrollo ágil es liviano y suficiente

El principio del método de desarrollo ágil es liviano y suficiente. adecuado.