La industria de la computación está plagada de lenguaje ambiguo, jerga áspera e ideas complejas que son difíciles de entender y pueden llevar a su mente a un frenesí de almacenamiento en búfer computacional.
¿Cascada? ¿Melé? ¿Ágil?
Si estas frases te resultan completamente ajenas, no te preocupes; Su útil equipo de expertos en tecnología de HashDork está aquí para ayudarlo a comprender las distinciones entre estas etapas cruciales del proceso de desarrollo para que pueda adquirir conocimientos.
Las técnicas ágiles, scrum y en cascada se tratarán en esta publicación de blog, junto con cómo cada una puede ayudar a su equipo en su conjunto.
Comencemos con lo ágil y continuaremos con el resto.
¿Qué es Agile?
El desarrollo ágil de software sigue un enfoque iterativo e incremental. En lugar de una preparación extensa al comienzo de un proyecto, las técnicas ágiles son flexibles para adaptarse a las necesidades cambiantes con el tiempo y promueven la retroalimentación continua de los usuarios finales.
Los equipos multifuncionales trabajan en iteraciones de productos a lo largo del tiempo, y este trabajo se clasifica en un trabajo pendiente y se prioriza según el valor del negocio o del cliente. El propósito de cada iteración es crear un producto utilizable.
El liderazgo promueve la cooperación, la responsabilidad y la comunicación cara a cara en metodologías ágiles.
Las partes interesadas y los desarrolladores del negocio deben colaborar para garantizar que el producto satisfaga las demandas del consumidor y los objetivos de la empresa.
La frase "desarrollo ágil" se refiere a una variedad de métodos y marcos que se basan en los ideales y principios descritos en el Manifiesto Ágil.
Los expertos aconsejan adherirse a los principios y valores ágiles y usarlos como guía para decidir las acciones correctas a tomar en un entorno particular al abordar el desarrollo de software.
El equipo colaborativo y autoorganizado son las principales áreas de enfoque para la comunidad de desarrollo de software ágil.
Los equipos pueden decidir de forma autónoma cómo abordarán un proyecto en particular, pero eso no significa que los supervisores no existan. Por lo tanto, los equipos ágiles son multifuncionales.
En un paradigma ágil, los gerentes siguen siendo necesarios. Se aseguran de que cada miembro del equipo tenga o adquiera las habilidades necesarias para el proyecto.
Los gerentes en un marco ágil operan fomentando una atmósfera que saca lo mejor del equipo. Pero en lugar de tomar la iniciativa, con frecuencia pasan a un segundo plano y dejan que el equipo decida cómo entregarán las cosas.
Los gerentes solo se involucran cuando los equipos intentan repetidamente resolver problemas sin éxito.
Ciclo de desarrollo ágil
Las etapas del ciclo de desarrollo Agile se enumeran a continuación. Es crucial recordar que estas fases no deben ocurrir en orden porque son flexibles y cambian constantemente. Muchas de estas etapas tienen lugar simultáneamente.
- Planificación: Después de que un equipo de proyecto ha decidido que una idea es práctica y factible, comienzan a buscar características. Esta fase tiene como objetivo priorizar cada característica y asignarla a una iteración después de dividir la idea en piezas de trabajo más pequeñas (las características).
- Análisis de requerimientos: Para determinar los requisitos comerciales, este paso implica varias discusiones con los gerentes, las partes interesadas y los usuarios. Quién utilizará el producto y cómo lo utilizarán se encuentran entre los detalles que el equipo debe recopilar. Estas normas deben ser específicas, aplicables y cuantitativas.
- Diseño: Los requisitos encontrados en la etapa anterior se utilizan para preparar el diseño del sistema y software. El equipo debe considerar la apariencia del producto o la solución. El equipo de prueba también desarrolla una estrategia o plan para la prueba.
- Implementación, codificación o desarrollo.: El enfoque de esta etapa es construir y evaluar características y planificar el despliegue de iteraciones (siguiendo el enfoque de desarrollo iterativo e incremental [IID]). Debido a que no se proporcionan características, comienza la iteración 0 del período de desarrollo. Al completar actividades como la contratación, la configuración de entornos y la financiación, esta iteración proporciona la base para el crecimiento futuro.
- Pruebas : Una vez que se ha creado el código, se prueba con los requisitos para garantizar que el producto realmente satisfaga las demandas del usuario y cumpla con los objetivos comerciales. En esta etapa se realizan pruebas unitarias, de integración, de sistema y de aceptabilidad.
- Despliegue: Después de las pruebas, el producto se envía a los clientes para que puedan utilizarlo. Sin embargo, el proyecto no finaliza después de la implementación. Los clientes pueden encontrar problemas adicionales después de comenzar a usar el producto, lo que requerirá que el equipo del proyecto encuentre una solución.
Ventajas
- Entrega más rápida y de mayor calidad: al dividir el proyecto en iteraciones (unidades manejables), el equipo puede concentrarse en la colaboración, el desarrollo y las pruebas de mayor calidad. Cuando se realizan pruebas con cada iteración, los problemas se encuentran y solucionan más rápidamente. Además, con constantes revisiones posteriores, este software de alta calidad se puede suministrar más rápidamente.
- El cambio es bienvenido: Aunque los ciclos de planificación son más cortos, es sencillo aceptar y adaptarse a los cambios en cualquier punto del proyecto. El backlog siempre se puede mejorar y volver a priorizar, lo que permite a los equipos realizar cambios en el proyecto en un par de semanas.
- Es posible que no se conozca el objetivo final: Agile es excelente para proyectos en los que el objetivo final no está claramente definido. A medida que el proyecto avance, los objetivos se aclararán y el desarrollo podrá adaptarse fácilmente a estas necesidades cambiantes.
- Mejora continua: Los programas ágiles promueven las aportaciones de los usuarios y del equipo en todas las etapas del proyecto, lo que permite la aplicación de lo aprendido para mejorar la próxima iteración.
- Se valoran las opiniones de los clientes: Hay varias oportunidades para que los clientes vean cómo se completa el trabajo, ofrezcan comentarios y realmente afecten el resultado final. Al interactuar tan íntimamente con el equipo del proyecto, pueden desarrollar un sentido de propiedad.
- fuerte trabajo en equipo: Agile enfatiza la importancia de la comunicación regular y los encuentros en persona. Las personas pueden asumir la responsabilidad y poseer ciertos componentes del proyecto cuando trabajan en equipo.
Desventajas
- Los miembros del equipo deben tener conocimientose: Los equipos ágiles suelen ser pequeños. Por lo tanto, los miembros del equipo deben tener una amplia gama de habilidades. Además, deben comprender y sentirse cómodos con la técnica Agile seleccionada.
- La planificación podría ser menos precisa: Ocasionalmente puede ser difícil determinar una fecha de entrega exacta. Agile se basa en la entrega en un plazo determinado, y los gerentes de proyecto con frecuencia reorganizan las prioridades de las tareas. Por lo tanto, es probable que algunos de los entregables que inicialmente estaban programados para entrega no se terminen a tiempo. Además, se pueden agregar más sprints en cualquier punto del proyecto, alargando todo el cronograma.
- La documentación puede ser ignorada: Algunos miembros del equipo pueden creer que concentrarse en la documentación es menos crucial, ya que el Manifiesto Ágil favorece el software en funcionamiento por encima de la documentación completa. Los equipos ágiles deben lograr el equilibrio ideal entre la documentación y el diálogo, incluso cuando la documentación exhaustiva no puede garantizar el éxito del proyecto por sí sola.
- El resultado final puede diferir muchoNota: Es posible que no haya habido una estrategia clara para el proyecto Agile inicial y, por lo tanto, el resultado final puede variar mucho de lo que se anticipó inicialmente. Un resultado final sustancialmente diferente puede resultar de agregar nuevas iteraciones basadas en cambios en la entrada del cliente, ya que Agile es muy adaptable.
- Compromiso de tiempo de los desarrolladores: El equipo de desarrollo debe estar completamente comprometido con el proyecto para que Agile sea efectivo. El método Agile, que lleva más tiempo que un enfoque convencional, requiere una participación y cooperación activa constante. Además, implica que los desarrolladores deben comprometerse con la duración total del proyecto.
¿Qué es Cascada?
La iteración más popular del ciclo de vida de desarrollo del sistema (SDLC) para proyectos de ingeniería de software y TI se conoce como el "enfoque en cascada", que sigue un procedimiento secuencial y lineal.
Ocasionalmente, se utiliza un gráfico de Gantt, una forma de gráfico de barras que muestra las fechas de inicio y finalización de cada trabajo, para planificarlo.
El equipo de desarrollo avanza al siguiente nivel después de terminar una de las ocho fases. El equipo no puede volver a una etapa anterior sin tener que reiniciar todo el procedimiento.
Además, es posible que el cliente deba evaluar y aceptar los requisitos antes de que el equipo pueda pasar al siguiente nivel.
El modelo en cascada se desarrolló en los entornos altamente organizados de los sectores de fabricación y construcción, donde los ajustes pueden ser prohibitivamente costosos o incluso imposibles.
La técnica de la cascada se llama así porque está destinada a fluir en una sola dirección, hacia abajo, como una cascada. Sus fases incluyen análisis, inicio, prueba, diseño, construcción, implementación, mantenimiento y prueba.
La técnica de la cascada tiene varias ventajas, como cualquier otra estrategia. Una es que las fases de planificación y diseño de proyectos están mejor establecidas.
Los clientes y el equipo de desarrollo están más alineados en lo que respecta a los resultados del proyecto al utilizar el desarrollo de software en cascada. Debido a que conoce el alcance del proyecto desde el principio, el desarrollo en cascada también simplifica el seguimiento del progreso.
El proceso en cascada utiliza especialistas, desarrolladores, analistas y evaluadores para concentrarse en sus trabajos en el proyecto en lugar de que todo el equipo se centre en un solo paso.
Etapas de Cascada
Los seis pasos de la Cascada deben ocurrir todos uno tras otro:
- Recopilación y almacenamiento de requisitos.: Debes acumular un conocimiento profundo sobre lo que demanda este proyecto en este momento. Existen varias técnicas para recopilar estos datos, incluidas entrevistas, encuestas y lluvia de ideas colaborativa. Las necesidades del proyecto deberían ser evidentes para cuando termine esta fase, y su equipo debería haber recibido una copia del documento de requisitos.
- El diseño de un sistema: El sistema está diseñado por su equipo utilizando especificaciones predeterminadas. Durante esta etapa, no se realiza codificación, pero el equipo establece requisitos para el hardware o el lenguaje de programación.
- Implementación: Esta etapa implica la codificación. Los programadores utilizan los datos de la etapa anterior para crear un producto utilizable. El código a menudo se implementa en pequeños fragmentos que se combinan al final de una fase o al comienzo de otra.
- Pruebas : El producto puede comenzar a probarse una vez que se completa el código. Cualquier problema es encontrado e informado meticulosamente por los evaluadores. Es posible que su proyecto deba volver a la fase uno para una reevaluación si surgen problemas importantes.
- Entrega/implementación: el producto está terminado en este punto y su equipo envía los entregables para su implementación o lanzamiento.
- Mantenimiento: El cliente ha recibido el producto y lo está utilizando. Es posible que su equipo necesite desarrollar correcciones y actualizaciones cuando surjan problemas para solucionarlos. Una vez más, los problemas significativos pueden requerir un regreso al paso uno.
Ventajas
- Simple de operar y administrar: El enfoque Waterfall es fácil de usar y comprender, ya que cada proyecto se maneja de la misma manera secuencial. Antes de comenzar un proyecto Waterfall, no se requiere que el equipo tenga experiencia o capacitación previa. El enfoque en cascada es muy estricto; cada etapa tiene un conjunto de entregables y una revisión, lo que facilita su administración y mantenimiento.
- Se requiere una metodología bien documentada: La documentación que requiere la metodología de cascada ayuda a aclarar el razonamiento detrás de las pruebas y el código. Además, crea un registro en papel en caso de que las partes interesadas deseen información adicional sobre una determinada fase o para cualquier iniciativa futura.
- Aplicación de la disciplina: Cada paso en un proyecto en cascada tiene un comienzo y un final, lo que simplifica la comunicación del progreso a las partes interesadas y los clientes. El equipo puede reducir la posibilidad de no cumplir con una fecha límite al priorizar los requisitos y el diseño antes de producir el código.
Desventajas
- Puede ser difícil recopilar requisitos precisos: Hablar con los consumidores y las partes interesadas para determinar sus necesidades es una de las etapas iniciales de un proyecto Waterfall. En esta etapa temprana del proyecto, podría ser un desafío determinar sus requisitos particulares. Con frecuencia, los clientes conocen sus requisitos a medida que se desarrolla el proyecto en lugar de expresarlos por adelantado.
- Los cambios son difíciles de acomodar: La tripulación no puede reanudar el trabajo después de terminar una fase. Es muy difícil y costoso regresar y repararlo si descubren durante la fase de prueba que faltaba la funcionalidad durante el proceso de requisitos.
- El software se proporciona después de su fecha de vencimiento: Se deben terminar de dos a cuatro fases del proyecto antes de que pueda comenzar la codificación real. Como resultado, las partes interesadas no verán el software funcional hasta el final del ciclo de vida.
¿Qué es Scrum?
Uno de los marcos de procesos más apreciados para poner en práctica Agile es Scrum, que es un subconjunto de Agile.
Es un paradigma iterativo para gestionar la creación de software y productos complejos. Los sprints, que son iteraciones de duración fija que duran de una a dos semanas, permiten al equipo lanzar software en un horario regular.
Las partes interesadas y los miembros del equipo se reúnen para discutir los próximos pasos después de cada sprint. Los roles, responsabilidades y reuniones en Scrum se mantienen constantes.
Por ejemplo, Scrum especifica la planificación del sprint, el stand-up diario, la demostración del sprint y la retrospectiva del sprint como los cuatro rituales que proporcionan la estructura de cada sprint.
El equipo utilizará artefactos visuales como tableros de tareas o gráficos de trabajo pendiente durante cada sprint para demostrar el progreso y obtener retroalimentación incremental.
En scrum, el equipo y el propietario del producto trabajan en estrecha colaboración para identificar y priorizar la funcionalidad del sistema. Lo logran mediante la creación de una acumulación de productos, que contiene todas las tareas necesarias para producir software que funcione según lo previsto.
Los parches de errores, los requisitos no funcionales y las características deben incluirse en la cola. Los equipos multifuncionales deben estimar y registrarse para entregar incrementos de software a lo largo de Sprints continuos, que generalmente duran 30 días, una vez que se han establecido los objetivos.
Solo el equipo puede agregar funcionalidad al Sprint después de confirmar el backlog para ese Sprint.
En la siguiente entrega del Sprint, se evalúa la acumulación de productos y, si es necesario, se vuelve a priorizar, y se elige el siguiente conjunto de entregables para que forme parte del siguiente Sprint.
Proceso de Scrum
- Atrasamiento del producto: Para ordenar los elementos de la cartera de productos, el propietario del producto y el equipo Scrum se reúnen (el trabajo en la cartera de productos proviene de las historias de los usuarios y los requisitos). La cartera de pedidos del producto es una lista de todas las funciones deseadas para el producto en lugar de una lista de tareas que deben completarse. Después de eso, el equipo de desarrollo selecciona tareas del backlog del producto para ejecutarlas a lo largo de cada sprint.
- Planificación de Sprint: antes de cada sprint, el propietario del producto entrega al equipo los principales elementos de la cartera de pedidos en una reunión de planificación de sprint. Luego, el grupo selecciona elementos de la cartera de productos que pueden terminar durante el sprint y los mueve a la cartera de pedidos del sprint (que es una lista de tareas para completar en el sprint).
- Refinamiento/preparación del backlog: Con el fin de garantizar que la acumulación esté preparada para el siguiente sprint, el equipo y el propietario del producto se reúnen al final de un sprint. El equipo puede descartar historias de usuarios que ya no sean pertinentes, agregar nuevas, revisar el orden en el que deben abordarse o dividir las historias de usuarios en tareas más pequeñas. En esta reunión de “grooming” se verificará que el backlog sólo comprenda lo pertinente, profundo y acorde con los objetivos del proyecto.
- Reuniones Scrum todos los días: En una reunión de pie de 15 minutos llamada Daily Scrum, cada miembro del equipo discute sus objetivos y cualquier problema que haya surgido. Todos los días durante el sprint, el equipo participa en Daily Scrum, que mantiene a todos concentrados en la tarea.
- Reunión para evaluar la primaverat: El equipo presenta su trabajo en una reunión de revisión de sprint al final de cada sprint. En lugar de un informe o una presentación de PowerPoint, esta reunión debe incluir una demostración real.
- Reunión de sprint retrospectivo: El equipo analiza las modificaciones que deben realizarse en el siguiente sprint, así como qué tan bien Scrum está funcionando para ellos al final de cada sprint. El equipo puede discutir los aspectos positivos, los aspectos negativos y las áreas de mejora del sprint.
Ventajas
- Más responsabilidad del equipo: No hay un gerente de proyecto que instruya al equipo de scrum sobre qué hacer y cuándo. En cambio, el equipo en su conjunto decide el trabajo que se puede terminar en cada sprint. Todos cooperan y se dan una mano, potenciando el trabajo en equipo y fomentando la individualidad de cada miembro del equipo.
- Visibilidad y transparencia mejoradas del proyecto: Hay menos malentendidos e incertidumbres ya que todos en el equipo son conscientes de sus responsabilidades gracias a las frecuentes reuniones de pie. El equipo puede solucionar los problemas antes de que se salgan de control, ya que los problemas se detectan con antelación.
- Reducciones de costos mejoradas: La comunicación constante mantiene informado al equipo de cualquier problema o cambio tan pronto como ocurra, lo que ayuda a ahorrar costos y mejorar la calidad. Los fragmentos de características más pequeños brindan retroalimentación continua y permiten la corrección temprana de errores antes de que los errores más grandes se vuelvan demasiado costosos de remediar.
- Fácil de adaptar a los cambios.: Es más sencillo lidiar con los cambios y adaptarse a ellos cuando hay bucles de retroalimentación frecuentes y sprints cortos. A modo de ilustración, si el equipo se encuentra con una nueva historia de usuario durante un sprint, pueden agregar rápidamente esa función al siguiente sprint en la reunión de refinamiento del backlog.
Desventajas
- Peligro de arrastre del alcance: debido a la falta de una fecha de finalización establecida, ciertos proyectos de Scrum pueden enfrentar un aumento del alcance. Las partes interesadas podrían verse tentadas a seguir exigiendo más funciones si no hay una fecha límite para completarlas.
- Un Scrum Master malo puede descarrilar todo: No es lo mismo un project manager que un scrum master. El Scrum Master debe confiar en el equipo que está supervisando y nunca darle instrucciones. El Scrum Master no tiene poder sobre el equipo. El proyecto fallará si el Scrum Master intenta administrar el equipo.
- Los problemas de precisión pueden resultar de tareas mal establecidas: Si las tareas no están claramente especificadas, los gastos y los cronogramas del proyecto no serán precisos. La planificación se convierte en un desafío y los sprints pueden demorar más de lo previsto si no se definen los objetivos iniciales.
- La experiencia y la dedicación son necesarias para un equipo.: Para que el equipo tenga éxito, los roles y deberes deben estar claramente definidos. El Equipo Scrum requiere miembros del equipo con habilidades técnicas porque no hay roles claramente definidos (todos hacen todo). El equipo también debe comprometerse a participar en las sesiones diarias de Scrum y mantenerse unido durante la vida del proyecto.
Ágil contra Scrum
Aunque Agile y Scrum usan la misma metodología, existen algunas variaciones entre los dos. El Manifiesto Ágil describe un conjunto de principios para crear software a través del desarrollo iterativo.
Scrum, por otro lado, es un conjunto de pautas que deben cumplirse al realizar el desarrollo de software Agile. Agile es un concepto, mientras que Scrum es una técnica para ponerlo en práctica.
Scrum es un método para implementar Agile, por lo que ambos tienen muchas cosas en común. Ambos enfoques son iterativos, priorizan la entrega temprana y frecuente de software y aceptan cambios. También apoyan la apertura y el desarrollo continuo.
Ágil contra cascada
Rígido frente a flexible describe mejor las distinciones entre el proceso Waterfall y Agile. Si bien Agile es fluido y cambia constantemente, Waterfall es una metodología mucho más estricta y rígida.
Estas distinciones adicionales entre ellos son las siguientes:
- Agile no requiere un enfoque lineal, mientras que Waterfall es secuencial.
- Si bien las necesidades a menudo están predefinidas en los proyectos Waterfall, se anticipa que se modificarán y adaptarán en las iniciativas Agile.
- A diferencia de Agile, los proyectos Waterfall no permiten realizar modificaciones al trabajo que se completó en una etapa anterior.
- La cascada es un procedimiento organizado en el que debes terminar cada paso antes de pasar al siguiente. Sin embargo, Agile es una metodología flexible que le permite continuar con el proyecto a su propio ritmo.
Ágil Vs Cascada Vs Scrum
- La cascada aumenta la confianza en lo que se proporcionará muy pronto después de lo planificado. Agile se basa en las mejores prácticas de un entorno de desarrollo. Aquí, una serie de riesgos del proyecto se pueden gestionar bien, ya que los resultados se evalúan continuamente.
- Waterfall no prevé que el equipo y el proyecto se basen en la misma ubicación. Mientras que Scrum y Agile necesitan la ubicación conjunta de los empleados.
- Agile se enfoca en reducir el retrabajo del proyecto y fomenta que los cambios se incorporen mucho antes. A diferencia de la cascada, que responde de manera diferente, scrum también permite el descubrimiento temprano de cambios.
- Agile y Scrum proporcionan un modelo más compacto para el producto final. Esto crea un problema con las promesas hechas al comprador. Por el contrario, el gráfico en cascada ofrece a los clientes y desarrolladores una mejor impresión del resultado final.
- Cada una de estas técnicas cuenta con un conjunto de herramientas para organizar y simular las tareas involucradas en su creación.
Conclusión
Si ha seguido hasta ahora y confía en su conocimiento de las distinciones entre los procesos Waterfall, Agile y Scrum, ya debería saber qué estrategia funcionará mejor para usted y su equipo.
La técnica Waterfall, que es para proyectos con un alcance, un plazo y un presupuesto definidos, puede ser su mejor opción si le gustan las reglas y los procedimientos estrictos y descubre que aportan claridad.
Por otro lado, si la libertad y la adaptabilidad que ofrece Agile te inspiran, podría ser donde deberías poner tu atención.
Sin embargo, Scrum es el camino a seguir si desea un poco de disciplina dentro de un marco flexible.
Sin embargo, debe considerar estos enfoques a la luz del proyecto en el que está trabajando y su resultado final.
Deje un comentario