Agile Metodologias

Las diferentes metodologías ágiles comparten gran parte de la misma filosofía, así como muchas de las mismas características y prácticas (como se discute por separado). Pero desde un punto de vista de la aplicación, cada uno tiene su propia receta de las prácticas, la terminología y las tácticas. Aquí hemos resumido algunos de los principales contendientes:
Scrum
Scrum es un marco de gestión de peso ligero con una amplia aplicabilidad para la gestión y el control iterativo e incremental de proyectos de todo tipo. Ken Schwaber, Mike Beedle, Jeff Sutherland y otros, han contribuido significativamente a la evolución de Scrum en la última década. Durante el último par de años, en particular, Scrum se ha ganado mayor popularidad en la comunidad de software debido a su simplicidad, la productividad probada y capacidad de actuar como un contenedor para las prácticas de ingeniería promovidos por otras metodologías ágiles.
En Scrum, el "dueño del producto" trabaja en estrecha colaboración con el equipo para identificar y dar prioridad a la funcionalidad del sistema en forma de "Product Backlog". Los pedidos de productos se compone de características, correcciones de errores, los requisitos no funcionales, etc - todo lo que hay que hacer con el fin de entregar con éxito un sistema de software de trabajo. Con las prioridades impulsadas por el propietario del producto, equipos multi-funcionales y estimación de inscripción para entregar "incrementos potencialmente productivo" de software durante sprints sucesivos, por lo general una duración de 30 días. Una vez que una reserva de pedidos de productos de Sprint está comprometida, no una funcionalidad adicional se puede agregar a la Sprint, excepto por el equipo. Una vez que el Sprint ha sido entregado, la reserva de pedidos de productos se analiza y repriorizados, si es necesario, y el siguiente conjunto de funcionalidades es seleccionado para el siguiente Sprint.
Scrum se ha demostrado a escala de varios equipos a través de organizaciones muy grandes (800 + personas).
Extreme Programming (XP)
XP, originalmente descrito por Kent Beck, se ha convertido en uno de los métodos ágiles más populares y controvertidos. XP es un enfoque disciplinado para la entrega de software de alta calidad de forma rápida y continua. Se promueve la participación de los clientes de alto, bucles de retroalimentación rápida, prueba continua, planificación continua, y cerca de trabajo en equipo para ofrecer software de trabajo a intervalos muy frecuentes, por lo general cada 1-3 semanas.
La receta original de XP se basa en cuatro valores simples - la simplicidad, la comunicación, la retroalimentación, y el valor - y doce prácticas de apoyo:
La planificación del juego
Comunicados de pequeños
Las pruebas de aceptación del cliente
Diseño sencillo
Par de programación
Desarrollo basado en pruebas
Refactoring
La integración continua
Propiedad colectiva del Código
Normas de codificación
Metáfora
Pace sostenible
Don Wells ha representado el proceso de XP en un diagrama popular.
En XP, el "Cliente" trabaja muy estrechamente con el equipo de desarrollo para definir y priorizar las unidades granulares de las funciones a que se refiere como "historias de los usuarios". Las estimaciones del equipo de desarrollo, planes y entrega de las historias más alta prioridad de usuario en la forma de trabajar, probar el software en una iteración por iteración base. Con el fin de maximizar la productividad, las prácticas de proporcionar un marco de apoyo y ligero para guiar a un equipo y garantizar la calidad de software.
De cristal
La metodología de Cristal es uno de los más ligeros, los enfoques adaptables al desarrollo de software. El cristal es en realidad compuesto por una familia de metodologías (Crystal Clear, de cristal amarillo, Crystal Orange, etc), cuyas características son únicas debido a diversos factores tales como el tamaño del equipo, la criticidad del sistema y las prioridades del proyecto. Esta familia de cristal se refiere a la comprensión de que cada proyecto puede requerir un poco adaptado conjunto de políticas, prácticas y procesos con el fin de cumplir con las características únicas del proyecto.
Varios de los principios clave de Crystal incluyen el trabajo en equipo, comunicación, y la sencillez, así como la reflexión para ajustar con frecuencia y mejorar el proceso. Al igual que otras metodologías ágiles, Crystal promueve la entrega temprana y frecuente de los programas de trabajo, la participación de los usuarios, la capacidad de adaptación, y la eliminación de la burocracia o las distracciones. Alistair Cockburn, el creador de cristal, ha publicado un libro, "Crystal Clear: una metodología de tracción humana para los equipos pequeños".
Sistemas Dinámicos Método para el Desarrollo (DSDM)
DSDM, que data de 1994, surgió de la necesidad de proporcionar un marco estándar de la industria ejecución de proyectos para lo que se conoce como desarrollo rápido de aplicaciones (RAD) en el momento. Mientras RAD era muy popular en la década de 1990, el enfoque de RAD para la entrega de software evolucionado de una manera muy estructurada. Como resultado de ello, el Consorcio DSDM fue creado y convocado en 1994 con el objetivo de crear y promover un marco común en la industria para la entrega de software rápida. Desde 1994, la metodología de DSDM ha evolucionado y madurado para proporcionar una base integral para la planificación, gestión, ejecución y ampliación ágil e iterativa de proyectos de desarrollo de software.
DSDM se basa en nueve principios fundamentales que principalmente giran en torno a las necesidades del negocio / valor, los usuarios participen activamente, los equipos de la facultad, entregas frecuentes, pruebas de integración y colaboración de los interesados. DSDM se pide expresamente a "aptitud para el uso de negocios" como el principal criterio para la entrega y aceptación de un sistema, centrándose en la utilidad del 80% del sistema que se puede implementar en un 20% de las veces.
Los requisitos son la línea base a un alto nivel al principio del proyecto. Reproceso se construye en el proceso, y todos los cambios de desarrollo debe ser reversible. Los requisitos se planifica y se ejecuta en definitiva, de longitud fija de tiempo de las cajas, también conocida como iteraciones, y los requisitos para los proyectos de DSDM se priorizan con reglas MOSCÚ:
M - Debe tener requisitos
S - En caso de que, si es posible
C - ¿Podría haber, pero no crítica
W - No tendrá esta vez, pero potencialmente más tarde
Todo el trabajo crítico debe ser completada en un proyecto de DSDM. También es importante que no todas las necesidades en un proyecto o una caja de tiempo se considera crítico. Dentro de cada caja de tiempo, los elementos menos importantes se incluyen de manera que si es necesario, pueden ser retirados para evitar impactar mayores requisitos de prioridad en la agenda.
El marco del proyecto DSDM es independiente de, y puede ser implementado en conjunto con otros métodos iterativos como la programación extrema y el Rational Unified Process.
Característica-Driven Development (FDD)
FDD fue originalmente desarrollado y articulado por Jeff De Luca, con contribuciones de MA Rajashima, Lim Wee Bak, Szego Paul, Jon Kern y Stephen Palmer. La primeras encarnaciones de la FDD se produjo como resultado de la colaboración entre De Luca y OOD líder de pensamiento Peter Coad. FDD es un modelo impulsado por corto iteración del proceso. Se inicia con el establecimiento de una forma general del modelo. Luego continúa con una serie de dos semanas "por la característica de diseño, construcción por la función" iteraciones. Las características son pequeños ", útil a los ojos del cliente" los resultados. FDD diseños del resto del proceso de desarrollo en torno a la prestación característica con los siguientes ocho prácticas:
Dominio de modelado de objetos
En desarrollo de funciones
Componente / Clase Propiedad
Los equipos cuentan con
Inspecciones
Gestión de la Configuración
Construye regulares
Visibilidad de los avances y resultados
FDD recomienda las prácticas específicas del programador como "Construye regular" y "Componente / clase de propietarios". Proponentes FDD afirmación de que las escalas de forma más directa que otros enfoques, y se adapta mejor a grandes equipos. A diferencia de otros métodos ágiles, FDD describe las fases específicas, muy corto de trabajo que vayan a llevarse a cabo por separado por cada función. Estos incluyen Tutorial de dominio, diseño, inspección de diseño, código, código de Inspección, y promover para construir.
La noción de "modelado de objetos de dominio" es cada vez más interesante fuera de la comunidad FDD, tras el éxito del libro de Eric Evans Domain-Driven Design.
Lean Software Development
Lean Software Development es una metodología iterativa desarrollado originalmente por Mary y Tom Poppendieck. Lean Software Development debe gran parte de sus principios y prácticas para el movimiento de Lean Enterprise, y las prácticas de compañías como Toyota. Lean Software Development se centra el equipo en la entrega de valor al cliente, y en la eficiencia de la "Cadena de Valor", los mecanismos que ofrecen ese valor. Los principios fundamentales de Lean son:
La eliminación de residuos
Amplificación de aprendizaje
Decidir lo más tarde posible
Entregar lo más rápido posible
Autorizar al equipo
En la construcción de integridad
Seeing the Whole '
Delgado elimina los residuos a través de prácticas tales como la selección sólo las características verdaderamente valioso para un sistema, dando prioridad a los seleccionados, y su entrega en pequeñas cantidades. Se hace hincapié en la velocidad y la eficiencia de flujo de trabajo de desarrollo, y se basa en la información rápida y confiable entre los programadores y clientes. Magra utiliza la idea de producto de trabajo que se "retiró" a través de la petición del cliente. Se centra autoridad para tomar decisiones y la capacidad de los individuos y grupos pequeños, ya que la investigación muestra que esto es más rápido y más eficiente que el flujo jerárquico de control. Lean también se concentra en la eficiencia de la utilización de los recursos del equipo, tratando de asegurarse de que todo el mundo es productivo tanto del tiempo como sea posible. Se concentra en el trabajo simultáneo y el menor número posible de equipo dentro de las dependencias de flujo de trabajo. Lean también recomienda que las pruebas automatizadas unidad puede escribir al mismo tiempo que se escribe el código.

Agile 101 - Introducion

¿Qué es el desarrollo ágil?
"Desarrollo ágil" es un término genérico para varias metodologías iterativo e incremental de desarrollo de software. Las metodologías ágiles más populares incluyen la Programación Extrema (XP), Scrum, Crystal, Método de Desarrollo De Sistemas Dinámicos (DSDM), el desarrollo Lean.

Aunque cada uno de los métodos ágiles es único en su enfoque específico, todos ellos comparten una visión común y los valores básicos (ver el Manifiesto Agile). Todos ellos incorporan fundamentalmente la iteración y la retroalimentación continua que ofrece para refinar sucesivamente y entregar un sistema de software. Todos ellos implican una planificación continua, pruebas continuas, integración continua, y otras formas de continua evolución tanto del proyecto y el software. Todos ellos son ligeros (especialmente en comparación con el estilo tradicional de los procesos de cascada), y adaptable sí. Tan importante, todos se centran en capacitar a las personas a colaborar y tomar decisiones de forma rápida y eficaz.

La evolución del desarrollo ágil
Muchos de los principios y prácticas individuales que son promovidos por el desarrollo ágil han existido por años, incluso décadas. A diferencia de la aplicación de estas mejores prácticas poco a poco, las metodologías ágiles se han "empaquetado" de los clientes diversos, gestión, y en algunos casos, las prácticas de ingeniería y principios de juntas de una manera que ayuda a los equipos de guía en el proceso de la rápida planificación y provisión de trabajo, software de prueba. Cada una de las metodologías ágiles combina viejas y nuevas ideas en mejoras que son sin duda mayor que la suma de sus partes.
Si bien es cierto que muchas de las prácticas asociadas con el desarrollo ágil han existido desde hace bastante tiempo, el equipo de desarrollo de software promedio aún tiene que adoptar muchos de los principios y prácticas. Incluso hoy en día, el equipo de software de medios no repetir, no entregar el software de forma incremental, y no practicar la planificación continua, ni automatizar las pruebas. Ahora que estas prácticas se han combinado de tal manera que pueden ser más fácilmente entendida y adoptada, la tendencia parece estar cambiando rápidamente para mejorar, especialmente durante los últimos años.
Como con cualquier nueva forma de hacer negocios, sin embargo, los métodos ágiles, han generado un poco de controversia dentro de la comunidad del software. Sin embargo, desde su aparición, en un proyecto tras otro, no han dejado de ofrecer una mayor calidad de los sistemas de software en menos tiempo que los procesos tradicionales. Si usted es un desarrollo de software profesional, que sin duda debemos a usted a familiarizarse con la teoría y práctica del desarrollo ágil. Esperamos que la información presentada en este sitio puede ayudar.