Haciendo Software - Metodologías - 1 de 3

Espero que este sea un post vivo y que aprenda mucho desarrollándolo y compartiéndolo. Así que espero vuestros puntos de vista, experiencias, correcciones o amenazas de muerte. No dudéis en comentarme en el post o por privado cualquier punto que consideréis. ¡Mil gracias! ? ¡Y a divertirse!

A ver si estaremos de acuerdo en esto… hacer software es divertido, pero a nivel profesional, para resolver problemas complejos, con cientos de miles de líneas de código, es una de las labores más complicadas a las que se puede enfrentar un grupo de personas. Las posibilidades de fracaso son altas… ¿Cuantas veces se va de presupuesto? ¿Cuando veces no acaban en el tiempo esperado? ¿O se cancelan? ¿Cuando cumplen todos los objetivos? ¿Cuantas veces se convierte en algo difícil de mantener?…

¡Soy negativo!

Como parece que es más común la visión en negativo, centrarse en lo que ha salido mal, inicialmente, voy a poner en foco en los motivos de fracaso.

Hay muchas estadísticas que hablan de las tasas de fracaso y los motivos, alguna van desde el 14% hasta 68%, depende de lo que se considere fallo y del tamaño del proyecto. Me está costando encontrar estadísticas actuales, tampoco se suele cuantificar el impacto de cada motivo en el fracaso. ¿Conoces alguna?

Estas son algunas:

https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

https://www.wellingtone.co.uk/wp-content/uploads/2016/01/The-State-of-Project-Management-Survey-2016.pdf

https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en

https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

https://www.zdnet.com/article/study-68-percent-of-it-projects-fail/

¡En la Wikipedia hay incluso un listado de grandes fracasos!

https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

Parto de que quiero aprender de los demás para evitar sufrir los problemas que se reportan desde la comunidad. Y que es imposible predecir el futuro y menos cuando se presenta como algo totalmente inesperado, pero si es posible ver donde pueden existir riesgos y trabajar en minimizar sus efectos e incluso intentar convertirlos en ventajas.

Voy a hacer un análisis sobre estos estudios y ver como las distintas metodologías agiles nos pueden ayudar: SCRUM, KANBAN, XP, RUP,… Doy por hecho que a todos nos suena el concepto de agilidad y cascada. ¿No?

https://es.wikipedia.org/wiki/Desarrollo_en_cascada

https://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software

¡Vamos allá!

Sacando factor común, a las motivos de fracaso encontrados, saco la siguiente lista, seguro que hay más y que se pueden clasificar de mil formas más acertadas, cada proyecto es un mundo y esto está muy sesgado. ¡ya, ya! Son los datos que dispongo. Pero si lo lees creo que la mayoría de las puntos tienen su sentido, aunque desconozco el impacto de cada uno de ellos dentro del problema.

Problemas con la gestión
- Responsables de proyectos no involucrados
- Ausencia de un buen gestor del proyecto
- Sin el apoyo de los lideres ejecutivos
- Falta de comunicación. Trabajando en un silo.
- Falta de supervisión del proyecto. Falta de métricas
- Resistencia al cambio
- Seleccionar a las personas
- Fricción causada por roles indefinidos
- Estimación de costo y tiempo, tiempo insuficiente, presupuesto insuficiente. No invierte suficiente tiempo y dinero en tu equipo
- No conforme a los estándares de la industria
- Mala planificación
- Incapacidad para llegar a un consenso sobre las prioridades
- Falta de coordinación y planificación detallada
- No hay suficiente énfasis en las habilidades blandas
- Se trabajar sin propósito

En la definición de los objetivos
- Requerimientos pocos claros, inadecuado, poco realistas
- Requerimientos cambian con demasiada frecuencia
- Escasa capacidad de análisis empresarial o no entender las necesidades del negocio
- No tener clara la foto final
- Usuario final no involucrado o no comenzando con la cliente final
- No era necesario

En la elaboración
- Riesgos inesperados
- Retrasos de dependencia
- Sin recursos suficientes
- Complejidad de la solución
- Falta de un diseño de la solución
- Escribir código limpio y eficiente
- Falta de garantía de calidad
- Selección de tecnología y herramientas
- Dilación de los miembros del equipo
- Tiempo de inactividad del equipo
- Probar y validar el software. Falta de pruebas de calidad
- Revisión e inspección del código
- Mantenimiento del software
- Perseguir la última tecnología
- Demasiadas manos en la olla de desarrollo
- Esperando una «bala de plata»
- Pruebas inadecuadas
- Pruebas inadecuadas en el entorno de producción

Con esta clasificación, así a primera vista Pues debería buscar una metodología o un conjunto de ellas que ponga el foco en:

Temas de gestión.
- Que involucre a todas las partes, que defina roles y que disponga de algún tipo de métricas.
- Que ponga el foco en las personas, su motivación, en la comunicación y en las reglas de consenso.
- Que ayude a estimar.
En la definición de objetivos, la metodología debería facilitar
- Su definición, evolución y estimación
- La colaboración cliente y la relación con los objetivos empresariales.
- Una visión de la foto final
En la construcción del Software
1. Debe marcarnos el camino para garantizar la calidad, una buena arquitectura, un buen diseño, buen código. Pruebas y validaciones. Simplificar la complejidad y su mantenimiento.
2. Debe vigilar los riesgos del desarrollo.
3. Debe tener en cuanta los tiempos no productivos, falta de dependencias, de requisitos…

¡Somos agiles!

Quien no es ágil hoy en día, si eres de cascadas, te sugiero que te escondas antes de que los agilistas te encuentren y te obliguen a repetir el manifiesto ágil 100 veces.

Pues eso, que ya sabemos un montón de cracks del desarrollo, con un nivel técnico de referencia mundial se juntaron y escribieron unos principios de desarrollo de software que ahora marcan las directrices de desarrollo actual. ¡Son del 2001! (y no han evolucionado ?)

http://agilemanifesto.org/

http://agilemanifesto.org/principles.html

Y no se puede dudar de las ventajas que tienen, especialmente respecto al desarrollo en cascada, esto no significa que para una Prueba de Concepto donde lo tienes todo clarísimo, ¡te haces una cascada y tan feliz!. Pero para un desarrollo grande, perderse los beneficios de las iteraciones y los incrementales es suicidar el proyecto.

Además estos principios, Tambien hacen hincapié en la relación con el cliente y el negocio, los cambios de los requisitos, las personas, la comunicación, el progreso y la excelencia técnica…

Así que ahora toca, revisar cada una de las metodología agiles, las cuales cumplen muchos de estos principios y ver como nos pueden beneficiar para cubrir el proyecto y llevarnos a la gloria. ?

En el próximo post, los listaré, haré un pequeño resumen y sobre todo veré hasta donde yo creo que puede llegar su alcance.

¿Tienes ya alguna conclusión? ¿En tus proyectos eres de únicamente de SCRUM? ¿de XP? ¿Ambas? ¿RUP? ¿Top-Down? ¿Otros? ¿Y los aplicas correctamente?

¿Y como llevas los temas de gestión? ¿Y de los requisitos? ¿Garantizas un software de calidad?

¡A darle caña! ?