¡Hola! ¿Por aquí de nuevo?. ¡Gracias y bienvenido!
Anteriormente en el contador…
Voy a resumir, en los POST anteriores mostraba estadisticas de fracasos en la construcción de software, y extraía las conclusiones que se daban en algunos de estos estudios para sacar un factor común. Con este, reflexionaba como pueden ayudarnos las distintas metodologías para no caer en esas situaciones.
Así, resulta que los mayores problemas parecen venir de la gestión, la toma de requisitos y en la calidad técnica de lo que se construye.
Por ello, y tras el resumen de las metodologías y lo que pueden aportar sobre cada una de las conclusiones de fallo para impedir que se repitan, ahora aporta otra visión en forma de tabla, y finalmente doy mi opinión (que es eso, una opinion subjetiva).
Yo creo que…
| Gestión | KANBAN | SCRUM | XP | SCRUM+XP | RUP |
| Involucra a todos las partes | ?? | ??? | ?? | ??? | ??? |
| Define roles | – | ?? | ?? | ??? | ??? |
| Dispone de métricas | ? | ?? | ? | ?? | ?? |
| Las personas son lo más importantes | ? | ??? | ? | ??? | ? |
| Fomenta la comunicación y la motivación | ?? | ??? | ?? | ??? | ? |
| Reglas de consenso | ? | ?? | ? | ?? | ??? |
| Facilita la estimación de tiempo y costes | – | ? | ? | ? | ??? |
| Objetivos | |||||
| Definición y mantenimiento de requisitos | ? | ?? | ?? | ?? | ??? |
| Adaptación ante cambios | ??? | ?? | ?? | ?? | ? |
| Relación con el cliente | ?? | ??? | ??? | ??? | ??? |
| Visión final | ? | ? | ? | ? | ??? |
| Contrucción del software | |||||
| Calidad | – | – | ?? | ?? | ??? |
| Gestión de riesgos | – | – | ? | ? | ??? |
| Adaptación a la cantidad de trabajo | – | – | – | – | ??? |
| Documentación generada | – | ? | ? | ? | ??? |
| Otras | |||||
| Facilidad de aplicación y aprendizaje | ??? | ??? | ? | ?? | ? |
| Popularidad | ?? | ??? | ? | ?? | ? |
Mi opinión
SCRUM es genial en el día a día, mantiene el equipo motivado y bien en continua colaboración, pero no sirve por sí mismo para garantizar un software de calidad.
Si se combina con XP, se da por hecho que los componentes del equipo son fuera de serie o con una gran experiencia en el dominio con el que va a trabajar. ¡y esto es muy difícil! Y es muy peligroso dar por hecho que es así, primero hay que demostrarlo.
Según la teoría, en estas dos últimas exigen que el cliente trabaja mano a mano con el equipo de desarrollo, por eso, necesitan menos metodología en la recogida de requisitos, ya que cuando tienen una duda, te pones en contacto con el cliente, que está en la habitación de al lado y les resuelve las dudas. ¿Ciencia Ficción? ¿No? ?
Usar RUP, puede ser un poco pesado, especialmente cuando ya se trabaja sobre una arquitectura muy desarrollada y lo que se está haciendo es añadir funcionalidad a algo muy explotado. Además está muy centrada en los procesos y se echan de menos las reuniones típicas de Scrum, por lo que para el día a día puede ser duro.
Entonces… dependerá de muchas situaciones, pero generalizando:
- Si el cliente no sabe lo que quiere… Kanban hasta que se aclaren los objetivos, no hace falta que se definan los detalles de los requisitos, a partir de hay:
- Si estás diseñando una nueva Arquitectura Software (te vas a meter en un buen lío):
- Y estás en un equipo de analistas y diseñadores con demostrada experiencia, puedes irte a Scrum con XP.
- Pero si no es así, RUP es una gran opción, pondrás las bases, la documentación para su gobierno y garantizarás una buena arquitectura sobre la que añadir funcionalidad. Además, podrás estimar costes y tiempos de esta nueva arquitectura.
- Si estás añadiendo funcionalidad a una arquitectura más que conocida, pues es posible que solo con Scrum sea suficiente.
- Si necesitas apoyarte en algo más visual para hacer seguimientos en el equipo o ejecutivos o relacionarte con terceros o cuando una tarea en particular se atasca o es muy dura… te apoyas en Kanban que es muy agradecido y motivador, el equipo podrá ver los estados y cómo se van desatascando las tareas.
- Si el proyecto es increíblemente complejo y va a requerir colaboración entre empresas o naciones, donde es normal que el equipo crezca o merme según la situación y la documentación es un transmisor necesario. Pues no estarás leyendo esto y casi seguro que usarás algo similar a RUP.
- Si vas a hacer una prueba de concepto, pues en cascada, resuelve la tarea y no te lies.
¿La burbuja de la agilidad?
Bueno, pues hay quien dice, y ojo que son algunos de los peces gordos del desarrollo del software, algunos de ellos firmaron el manifiesto ágil, que la agilidad se ha vuelto un producto de marketing, que está asumida por los gerentes de proyecto y maestros scrum. Que ahora es más un argumento de venta y que se está olvidando la parte técnica, la más compleja, la que requiere de una maestría y de un arte cada vez mayor ante la complejidad hacia la que vamos. Esto es profundamente inquietante
Deberíamos escuchar a los mayores y reflexionar:
https://techbeacon.com/app-dev-testing/unc le-bob-martin-agile-manifesto-15-years-later https://techbeacon.com/app-dev-testing/agile-manifesto-dead
¡A darle caña! ?