Una de las primeras decisiones que nos enfrentamos para cada una de nuestras implementaciones del proyecto a Continuación es «Que la metodología de desarrollo deberíamos utilizar?»Este es un tema que recibe mucha discusión (y a menudo acalorado debate)., Si esto no es algo con lo que haya trabajado antes, una definición de metodología de desarrollo está en orden; en pocas palabras, es una forma de organizar el trabajo de desarrollo de software. Esto no se trata de un estilo de gestión de proyectos o un enfoque técnico específico, aunque a menudo escuchará estos Términos todos juntos o utilizados indistintamente.

las dos metodologías básicas, más populares son:

1. cascada: (ugh, nombre terrible!,), que podría llamarse más correctamente el enfoque «tradicional», y
2. Agile: un tipo específico de desarrollo rápido de aplicaciones y más nuevo que Waterfall, pero no tan nuevo, que a menudo se implementa utilizando Scrum.

ambas son metodologías utilizables y maduras. Habiendo estado involucrado en proyectos de desarrollo de software durante mucho tiempo, Aquí están mis pensamientos sobre las fortalezas y debilidades de cada uno.

La metodología de Cascada

cascada es un enfoque lineal para el desarrollo de software., En esta metodología, la secuencia de eventos es algo así como:

1. recopilar y documentar requisitos
2. Diseñar
3. código y prueba unitaria
4. Realizar pruebas del sistema
5. Realizar pruebas de aceptación del usuario (UAT)
6. solucionar cualquier problema
7. entregar el producto terminado

en un verdadero proyecto de desarrollo en cascada, cada uno de estos representa una etapa distinta de desarrollo de software, y el siguiente puede comenzar., También hay típicamente una puerta de etapa entre cada uno; por ejemplo, los requisitos deben ser revisados y aprobados por el cliente antes de que el diseño pueda comenzar.

Hay cosas buenas y malas sobre el enfoque de Cascada. En el lado positivo:

• Los desarrolladores y los clientes están de acuerdo en lo que se entregará al principio del ciclo de vida del desarrollo. Esto hace que la planificación y el diseño sean más sencillos.
• El Progreso es más fácil de medir, ya que el alcance completo del trabajo se conoce de antemano.,
• a lo largo del esfuerzo de desarrollo, es posible que varios miembros del equipo se involucren o continúen con otro trabajo, dependiendo de la fase activa del proyecto. Por ejemplo, los analistas de negocios pueden aprender y documentar lo que se necesita hacer, mientras que los desarrolladores están trabajando en otros proyectos. Los evaluadores pueden preparar scripts de prueba a partir de la documentación de requisitos mientras la codificación está en curso.
• excepto para revisiones, aprobaciones, reuniones de estado, etc., una presencia del cliente no es estrictamente necesaria después de la fase de requisitos.,
• debido a que el diseño se completa al principio del ciclo de vida de desarrollo, este enfoque se presta a proyectos donde se deben diseñar Múltiples componentes de software (a veces en paralelo) para la integración con sistemas externos.
• Finalmente, el software se puede diseñar completamente y más cuidadosamente, basado en una comprensión más completa de todos los entregables de software., Esto proporciona un mejor diseño de software con menos probabilidad del» efecto fragmentario», un fenómeno de desarrollo que puede ocurrir a medida que se definen piezas de código y posteriormente se agregan a una aplicación donde pueden o no encajar bien.

estos son algunos problemas que hemos encontrado usando un enfoque de Cascada pura:

• Un área que casi siempre se queda corta es la efectividad de los requisitos. Reunir y documentar los requisitos de una manera que sea significativa para un cliente es a menudo la parte más difícil del desarrollo de software, en mi opinión., Los clientes a veces se sienten intimidados por los detalles, y los detalles específicos, proporcionados al principio del proyecto, se requieren con este enfoque. Además, los clientes no siempre pueden visualizar una aplicación desde un documento de requisitos. Wireframes y Maquetas pueden ayudar, pero no hay duda de que la mayoría de los usuarios finales tienen alguna dificultad para poner estos elementos junto con los requisitos escritos para llegar a una buena imagen de lo que van a obtener.,
• otro inconveniente potencial del desarrollo de Pure Waterfall es la posibilidad de que el cliente no esté satisfecho con su producto de software entregado. Como todos los entregables se basan en requisitos documentados, es posible que un cliente no vea lo que se entregará hasta que esté casi terminado. Para entonces, los cambios pueden ser difíciles (y costosos) de implementar.

la metodología ágil

Agile es un enfoque iterativo, basado en el equipo para el desarrollo. Este enfoque enfatiza la entrega rápida de una aplicación en componentes funcionales completos., En lugar de crear tareas y horarios, todo el tiempo está «en caja de tiempo» en fases llamadas «sprints».»Cada sprint tiene una duración definida (generalmente en semanas) con una lista de entregables, planificada al inicio del sprint. Los entregables se priorizan según el valor del negocio determinado por el cliente. Si todo el trabajo planificado para el sprint no se puede completar, el trabajo se vuelve a priorizar y la información se usa para la planificación futura del sprint.

a medida que se completa el trabajo, puede ser revisado y evaluado por el equipo del proyecto y el cliente, a través de compilaciones diarias y demostraciones al final del sprint., Agile se basa en un nivel muy alto de participación del cliente durante todo el proyecto, pero especialmente durante estas revisiones.

algunas ventajas del enfoque ágil son fáciles de ver:

• El cliente tiene oportunidades frecuentes y tempranas para ver el trabajo que se entrega, y para tomar decisiones y cambios a lo largo del proyecto de desarrollo.
• El cliente gana un fuerte sentido de propiedad al trabajar extensa y directamente con el equipo del proyecto durante todo el proyecto.,
• si el tiempo de comercialización de una aplicación específica es una preocupación mayor que la liberación de un conjunto completo de características en el lanzamiento inicial, Agile puede producir más rápidamente una versión básica de software de trabajo que se puede construir en iteraciones sucesivas.
• El desarrollo es a menudo más centrado en el usuario, probablemente el resultado de una dirección más frecuente del cliente.,
• Para obtener más beneficios de desarrollo ágil, consulte 8 Beneficios de desarrollo de Software ágil

y, por supuesto, hay algunas desventajas:

• El muy alto grado de participación del cliente, si bien es ideal para el proyecto, puede presentar problemas para algunos clientes que simplemente no tienen el tiempo o el interés para este tipo de participación.
• Agile funciona mejor cuando los miembros del equipo de desarrollo están completamente dedicados al proyecto.,
• Debido a que Agile se centra en la entrega en caja de tiempo y la reordenación frecuente de las prioridades, es posible que algunos elementos establecidos para la entrega no se completen dentro del plazo asignado. Es posible que se necesiten sprints adicionales (más allá de los planificados inicialmente), lo que aumenta el costo del proyecto. Además, la participación del cliente a menudo conduce a características adicionales solicitadas a lo largo del proyecto. Una vez más, esto puede aumentar el tiempo y el costo generales de la implementación.,
• Las relaciones de trabajo estrechas en un proyecto ágil son más fáciles de gestionar cuando los miembros del equipo se encuentran en el mismo espacio físico, lo que no siempre es posible. Sin embargo, hay una variedad de formas de manejar este problema, como cámaras web, herramientas de colaboración, etc.
• la naturaleza iterativa del desarrollo ágil puede conducir a una refactorización frecuente si el alcance completo del sistema no se considera en la arquitectura y el diseño inicial. Sin esta refactorización, el sistema puede sufrir una reducción en la calidad general., Esto se hace más pronunciado en implementaciones a mayor escala, o con sistemas que incluyen un alto nivel de integración.

haciendo la elección entre Agile y Waterfall

entonces, ¿cómo elegimos? Primero, cambiamos un poco el juego (que es lo que hacen la mayoría de las organizaciones de desarrollo de software) definiendo nuestro propio proceso. En Segue, se llama nuestro marco de proceso, y es una variación de la metodología tradicional de Cascada., Nuestras modificaciones incluyen el uso de prototipos cuando sea posible para proporcionar al cliente una mejor visión de su producto terminado al principio del ciclo de diseño/desarrollo. Esto ayuda a mejorar la comprensión del equipo de los requisitos y la comunicación con el cliente. Después de completar el marco principal de la aplicación según los requisitos de alto nivel, continuamos desarrollando y también contactando con el cliente para el refinamiento de los requisitos. De esta manera, nos esforzamos por ser lo más iterativos posible sin comprometer nuestra arquitectura general del sistema.,

tenemos en cuenta los siguientes factores al considerar qué metodología utilizar:

Los factores anteriores no están igualmente ponderados; cada uno se evalúa dependiendo del proyecto individual y las circunstancias.

aunque estamos empezando a ver la adopción masiva de varias metodologías ágiles en la empresa (incluso DoD y agencias federales), todavía hay muchas organizaciones que son lentos para hacer el cambio., También es muy común que la organización realice la transición hacia un enfoque ágil híbrido que combine aspectos de Agile y Waterfall. La Guía de prácticas ágiles se desarrolló específicamente para ayudar a la organización a comprender y evaluar el uso de enfoques ágiles e híbridos. El Project Management Institute (PMI) que desarrolló la Guía Project Management Body of Knowledge (PMBOK) colaboró con Agile Alliance para agrupar las dos guías en una sola oferta para ayudar a las organizaciones, gerentes y líderes a aumentar la agilidad en el proceso de desarrollo.,

una vez que hemos decidido qué metodología básica utilizar, podemos refinar aún más el proceso para que se ajuste mejor a los objetivos de nuestro proyecto. En última instancia, aunque la forma en la que hacemos nuestro trabajo es importante, entregar un producto sólido y mantenible que satisfaga a nuestro cliente es lo que realmente cuenta.