Los usuarios / clientes participan activamente #
Cada ciclo de gestión cíclica de proyectos implica el desarrollo de requisitos, diseño, ejecución y pruebas. Esto implica que se deben tomar muchas decisiones a lo largo de un ciclo. Si el programa va a representar con precisión los deseos del cliente, el cliente debe ser un miembro activo del equipo del proyecto.
Los clientes deben comunicar sus requisitos a los programadores y diseñadores de la manera más sencilla posible. Esto a menudo implica la participación semanal (o al menos quincenal) en el equipo del proyecto.
Dentro de un proyecto, los consumidores contribuyen a la definición de las características requeridas y la planificación del ciclo. Cooperan en las pruebas de aceptación, aprueban o rechazan los hallazgos provisionales y contribuyen a la dirección general del proyecto. Además, la participación activa del cliente da como resultado mejores resultados cuando se utiliza el método en cascada.
El equipo tiene la autoridad para tomar decisiones. #
Dentro de un ciclo, el equipo del proyecto debe estar facultado para tomar sus propias decisiones. Si el equipo del proyecto carece de esta autoridad, el modelo cíclico de gestión del proyecto no funcionará. Si se requiere la aprobación constante de los superiores a lo largo de un ciclo, esto puede resultar en un estancamiento. Además, los forasteros con frecuencia no se dan cuenta de lo que está sucediendo porque no participan activamente en el equipo del proyecto; esto les dificulta tomar decisiones racionales.
La salida del proyecto (software) se puede descomponer en componentes más pequeños. #
La gestión cíclica de proyectos es un método de gestión de proyectos en el que partes del proyecto se completan en una serie de ciclos. Esto solo es posible si el software que se está desarrollando se puede descomponer en varios componentes más o menos distintos.
Los requisitos de la gerencia para el software de gestión de proyectos son principalmente globales; la dirección no impone requisitos directos, concretos o específicos. Una de las ventajas de la gestión cíclica de proyectos es la estrecha colaboración entre el cliente, los diseñadores, los programadores y los probadores durante los ciclos. Si se establecen requisitos específicos y concretos al inicio de un proyecto, esto limita la capacidad del equipo del proyecto para usar su mejor criterio al tomar decisiones de diseño. Se revela que numerosos requisitos de un proyecto necesitan adaptación durante el proceso y, por lo tanto, no deberían establecerse (demasiado) firmemente al principio.
El cliente comprende las actividades. #
Si un trabajo técnico significativo que es difícil de comprender para el cliente debe ocurrir dentro de un ciclo, existe el riesgo de que el cliente no pueda contribuir de manera efectiva al equipo. En tal situación, el cliente tiene muy poco que decir en las decisiones de diseño que deben tomarse.
Existe un riesgo similar cuando el cliente desconoce el progreso. Por ejemplo, gran parte del trabajo se puede dedicar a la codificación, prestando poca atención a la interfaz de usuario. Es fundamental que los clientes tengan suficiente conocimiento de la esencia y la progresión de un ciclo para evitar ser empujados al margen.
Debería ser posible volver sobre los propios pasos. #
Incluso en la gestión cíclica de proyectos, los equipos ocasionalmente siguen caminos que resultan incorrectos. En tal caso, debería ser posible dar un paso atrás. Si un nuevo módulo creado durante un ciclo resulta insuficiente, debe ser posible reanudar el trabajo con el módulo anterior. Esto impone requisitos, sobre todo para el archivo y la documentación de los materiales del proyecto. CVS y Subversion son dos herramientas útiles para estas tareas (consulte el Apéndice 3 para obtener una lista completa de herramientas).
Junto con las habilidades de programación, los programadores deberían poder interactuar de manera efectiva con los clientes y viceversa. Los miembros del equipo deben ser pensadores intelectuales. Se requiere disciplina para continuar con el trabajo.
La organización en la que se lleva a cabo el proyecto también debe proporcionar suficiente apoyo para este modo de operación. Se requieren sistemas de seguimiento, archivo y programación del tiempo para respaldar los proyectos. Estos sistemas de registro brindan la apertura esencial para garantizar una asignación equitativa de recursos entre proyectos y períodos de tiempo.
Priorización #
Los proyectos deben recibir la importancia adecuada y los miembros del equipo deben estar disponibles para ellos. Requerir que los miembros del equipo trabajen en demasiadas tareas al mismo tiempo es ineficaz. Si una organización no se adapta adecuadamente al trabajo basado en proyectos, es probable que la flexibilidad cíclica de la gestión de proyectos genere un caos. Además, la técnica de la cascada se beneficia de un enfoque organizado de la gestión de proyectos (ver Wijnen, 2004, p. 111).
El director de una empresa de desarrollo de software, que era más visionario que gerente, tenía una gran idea casi todos los meses y constantemente iniciaba nuevas iniciativas en su empresa. Como resultado, los proyectos más antiguos nunca se completaron y los trabajadores trabajaron en hasta cinco proyectos al mismo tiempo. El carismático director acababa de terminar de leer un libro sobre el desarrollo rápido de aplicaciones (RAD) y estaba muy entusiasmado con él, especialmente el elemento «rápido». Grabó las ideas fundamentales de RAD en la fotocopiadora y luego esperaba que todos comenzaran a trabajar con estas nociones. Después de todo, era una técnica excelente.
Riesgos de la gestión cíclica de proyectos #
Las técnicas de gestión cíclica de proyectos a veces dejan un tiempo inadecuado para ejecutar las funciones necesarias. Debido a que la duración del proyecto es fija, es casi seguro que se agregarán menos funciones de las inicialmente previstas.
Si bien esta es una preocupación legítima, también es inherente al enfoque en cascada . El paso definitorio del enfoque en cascada implica un examen en profundidad de los requisitos. Es probable que este análisis dé como resultado una mejor gestión del tiempo. A menudo, este no es el caso en la realidad, por las razones expuestas anteriormente.
Además, las funcionalidades se omiten en este enfoque debido a la falta de fondos para desarrollarlas.
Los requisitos se tratan de forma pragmática en enfoques cíclicos. Por ejemplo, las necesidades en ciclos pueden clasificarse utilizando los criterios de MoSCoW (Stapleton, 2003) de la siguiente manera:
- Debe tener: requisitos críticos del sistema
- Debería tener: necesidades críticas que los usuarios realmente desean
- Podría tener: necesidades deseables que se pueden ignorar fácilmente
- Quiere tener: requisitos que no se cumplirán esta vez: requisitos que pueden esperar hasta más tarde
Independientemente de si ciertas capacidades ya no están disponibles, los gerentes de proyecto de DANS creen que el trabajo cíclico da como resultado una mayor satisfacción del cliente que el enfoque en cascada. En cualquier caso, las expectativas se controlan regularmente de manera más eficaz y los proyectos producen resultados que funcionan de manera rutinaria, incluso si son menos complejos de lo previsto inicialmente.
Comprender los posibles inconvenientes #
Un inconveniente comúnmente citado de XP es que se transfiere una potencia significativa a los programadores. Si abusan de esta autoridad, pueden aprovechar la falta de experiencia técnica del cliente en su beneficio. Para evitar este escenario, se necesita un líder de proyecto que pueda velar por los intereses de los programadores y del cliente. Estos líderes de proyecto ayudan a sus clientes a seleccionar y planificar ciclos, a hacer comprensibles los fundamentos técnicos de sus selecciones y a proporcionar administración e informes.
Finalmente, otro inconveniente de XP es que la implementación del método requiere una curva de aprendizaje alta para programadores, gerentes y consumidores.
