Saludos a toda la comunidad

Me alegra mucho volver a compartir contenido útil para ustedes, en esta oportunidad les traigo un tema bastante interesante, se trata del Desarrollo Ágil y sus metodologías, pasando por Scrum, desarrollo de software Lean y Kanban, sus principios básicos, metodología Cristal, Método de desarrollo de sistemas dinámicos (DSDM) y muchas cosas más, espero que sea de su agrado y sin más que añadir empecemos.

https://cdn.steemitimages.com/DQmcYSBnGZKqHboyLLtTAFamzZU3AkSZJtmmKFQ1gnjuuGz/workstation-336369_1920.jpg Imagen tomada de Pixabay (imágenes sin derechos de autor)

Introducción

Las diversas metodologías ágiles de Scrum comparten gran parte de la misma filosofía, así como muchas de las mismas características y prácticas. Pero desde el punto de vista de la implementación, cada uno tiene su propia receta de prácticas, terminología y tácticas. Aquí voy a resumir algunos de los principales candidatos de la metodología de desarrollo de software ágil.

Metodología Ágil Scrum

Scrum es un marco de administración de proyectos ágil y liviano con una amplia aplicabilidad para administrar y controlar proyectos iterativos e incrementales 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. Scrum ha ganado una creciente popularidad en la comunidad de desarrollo de software ágil debido a su simplicidad, productividad probada y capacidad para actuar como envoltorio para diversas prácticas de ingeniería promovidas por otras metodologías ágiles. Con la metodología Scrum, el "Propietario del producto" trabaja en estrecha colaboración con el equipo para identificar y priorizar la funcionalidad del sistema en forma de un "Product Backlog".

El Backlog del producto consta de características, correcciones de errores, requisitos no funcionales, etc, lo que sea necesario hacer para entregar con éxito un sistema de software que funcione. Con las prioridades impulsadas por el Propietario del producto, los equipos multifuncionales estiman y se inscriben para entregar "incrementos potencialmente enviables" de software durante sucesivos Sprints, que generalmente duran 30 días. Una vez que se haya comprometido la acumulación de productos de Sprint, no se puede agregar ninguna funcionalidad adicional a Sprint, excepto por el equipo. Una vez que se ha entregado un Sprint, el Product Backlog se analiza y se vuelve a ordenar, si es necesario, y se selecciona el siguiente conjunto de funciones para el próximo Sprint.

Desarrollo de Software Lean y Kanban

Lean Software Development es una metodología ágil iterativa desarrollada originalmente por Mary y Tom Poppendieck. Lean Software Development debe muchos de sus principios y prácticas al movimiento Lean Enterprise, y a las prácticas de compañías como Toyota. Lean Software Development enfoca al equipo en la entrega de Valor al cliente y en la eficiencia de la "Corriente de Valor", los mecanismos que ofrecen ese Valor. Los principios fundamentales de la metodología Lean incluyen:

Eliminar desechos.
Aprendizaje amplificador.
Entregar lo más rápido posible.
Empoderar al equipo.

La metodología Lean elimina el desperdicio a través de prácticas tales como seleccionar solo las características realmente valiosas para un sistema, priorizar las seleccionadas y entregarlas en pequeños lotes. Enfatiza la velocidad y la eficiencia del flujo de trabajo de desarrollo y se basa en una retroalimentación rápida y confiable entre los programadores y los clientes. Lean utiliza la idea de que el producto de trabajo se "extrae" a través de la solicitud del cliente. Enfoca la autoridad y la capacidad de toma de decisiones en individuos y pequeños equipos, ya que la investigación muestra que esto es más rápido y más eficiente que el flujo de control jerárquico. Lean también se concentra en la eficiencia del uso de los recursos del equipo, tratando de asegurar que todos sean productivos la mayor cantidad de tiempo posible. Se concentra en el trabajo simultáneo y la menor cantidad posible de dependencias de flujo de trabajo dentro del equipo. Lean también recomienda encarecidamente que las pruebas unitarias automatizadas se escriban al mismo tiempo que se escribe el código.

Método Kanban

El método Kanban es utilizado por las organizaciones para gestionar la creación de productos con un énfasis en la entrega continua sin sobrecargar al equipo de desarrollo. Al igual que Scrum, Kanban es un proceso diseñado para ayudar a los equipos a trabajar juntos de manera más efectiva.

Kanban se basa en 3 principios básicos

Visualice lo que hace hoy (flujo de trabajo): Ver todos los elementos en el contexto de cada uno puede ser muy informativo

Limite la cantidad de trabajo en progreso (WIP): Esto ayuda a equilibrar el enfoque basado en el flujo para que los equipos no comiencen y se comprometan a trabajar demasiado a la vez.

Mejora el flujo: Cuando algo termina, la siguiente cosa más alta del trabajo acumulado se pone en juego

https://cdn.steemitimages.com/DQmR4d5FuucaxMiqCqnNxjKcjHBDTfJWith7TdmUCiLaDsV/mark-516277_1920.jpg Imagen tomada de Pixabay (imágenes sin derechos de autor)

Metodología Crystal

La metodología Crystal es uno de los enfoques más livianos y adaptables para el desarrollo de software. En realidad, Crystal está compuesto por una familia de metodologías ágiles como Crystal Clear, Crystal Yellow, Crystal Orange y otras, cuyas características únicas están impulsadas por varios factores como el tamaño del equipo, la criticidad del sistema y las prioridades del proyecto. Esta familia Crystal aborda la idea de que cada proyecto puede requerir un conjunto de políticas, prácticas y procesos ligeramente adaptados para cumplir con las características únicas del proyecto. Varios de los principios clave de Crystal incluyen el trabajo en equipo, la comunicación y la simplicidad, así como la reflexión para ajustar y mejorar el proceso con frecuencia. Al igual que otras metodologías de procesos ágiles, Crystal promueve la entrega temprana y frecuente de software en funcionamiento, la alta participación de los usuarios, la adaptabilidad y la eliminación de la burocracia o las distracciones. Alistair Cockburn , el creador de Crystal, ha lanzado un libro, Crystal Clear: Una metodología basada en el ser humano para equipos pequeños.

Método de desarrollo de sistemas dinámicos (DSDM)

DSDM, que data de 1994, surgió de la necesidad de proporcionar un marco de entrega de proyectos estándar de la industria para lo que en ese momento se denominaba Desarrollo de aplicaciones rápidas (RAD). Si bien RAD fue extremadamente popular a principios de la década de 1990, el enfoque de RAD para la entrega de software evolucionó de una manera bastante desestructurada. Como resultado, el consorcio DSDM se creó y convocó en 1994 con el objetivo de diseñar y promover un marco industrial común para la entrega rápida de software. Desde 1994, la metodología DSDM ha evolucionado y madurado para proporcionar una base integral para la planificación, gestión, ejecución y escalado de procesos ágiles y proyectos de desarrollo de software iterativos. DSDM se basa en nueve principios clave que giran principalmente en torno a las necesidades y el valor de la empresa, la participación activa del usuario, los equipos habilitados, la entrega frecuente, las pruebas integradas y la colaboración de los interesados.

DSDM declara específicamente "aptitud para fines comerciales" como el criterio principal para la entrega y aceptación de un sistema, centrándose en el útil 80% del sistema que se puede implementar en el 20% del tiempo. Los requisitos se basan en un nivel alto al principio del proyecto. El proceso está integrado en el proceso, y todos los cambios de desarrollo deben ser reversibles. Los requisitos se planifican y se entregan en cajas de tiempo cortas y de longitud fija, también conocidas como iteraciones, y los requisitos para los proyectos de DSDM se priorizan mediante las Reglas de MoSCoW.

https://cdn.steemitimages.com/DQmTW2DmcyLV9TbMTNQFxzKcexX8Vbq1scFUZ5LE2Baec3d/block-chain-2850276_1920.jpg Imagen tomada de Pixabay (imágenes sin derechos de autor)

Conclusión

Todo el trabajo crítico debe completarse en un proyecto. También es importante que no todos los requisitos de un proyecto o cuadro de tiempo se consideren críticos. Dentro de cada casilla de tiempo, se incluyen los elementos menos críticos, de modo que, de ser necesario, se pueden eliminar para evitar que se afecten los requisitos de mayor prioridad en el cronograma. El marco del proyecto es independiente y puede implementarse junto con otras metodologías iterativas como la Programación Extrema y el Proceso Unificado. La receta original de muchas de estas metodologías se basa en cuatro valores simples: “simplicidad, comunicación, comentarios y valor” y distintas prácticas de apoyo para que el proyecto sea perfecto para el usuario.

Bibliografía

Libro: Ingeniería de software (Autor: Roger Pressman)

https://cdn.steemitimages.com/DQmSBaVcwtD1HCodppcJ4AqSjYt1iV6RpHEbmHBNzHgbtk3/Manta1animacion.gif