|
En los 80 se nos decía:  "Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo?. Empezáis sin
tener ni una página de requisitos, ni un análisis y una planificación
de los trabajos, y sus tiempos. ¿Os imagináis que un arquitecto hiciera
lo mismo?".
Aprendimos a hacer requisitos del sistema, especificaciones de
requitisos del software, planes de proyecto, gestión de riesgos,
matrices de trazabilidad. Y desde entonces nuestros clientes no pueden darnos planes de productos estables y nos piden re-inventar sus productos de forma continua.
Aprendimos tambien a mejorar los procesos en nuestras empresas, y al hacerlo descubrimos
sus limitaciones frente al talento de las personas.
A
falta de una, aprendimos dos formas de abordar los problemas: desde la planificación y los procesos, y desde la agilidad y las personas. Y ahora ques sabemos tanto de blanco como de negro, nos damos cuenta de la realidad tiene muchos tonos de color. Y
con lo aprendido estamos construyendo un laberinto, en el que nos pierden las
ganas de hacer bandos: ¿mejor
la planificación, mejor la agilidad, mejor sumar los dos...? y nos pierde también el afán de definir, etiquetar metodologías(?) e ir
ampliando la colección de
palabras "interesantes": Scrum, XP, ahora Kanban, Lean...
Un consejo es huir de que si esto es Scrum o es Kanban o XP o PMI.
Ser pragmáticos. Conocer las diferencias de base y enfoque entre
planificación y agilidad: las fortalezas y debilidades de cada una y a
partir de ahí, los "artefactos" de las diferentes doctrinas son simples prácticas, no "metodologías". Unos útiles para construir
planes, otros para mantener requisitos cambiantes; con sprints podemos
iterar basándonos en tiempo, con Kanban basándonos en funcionalidades,
etc. Cuanto mayor
sea el inventario de prácticas que conozcamos, las fortalezas y
debilidades de cada una, más recursos tendremos como gestores y más
flexible será nuestr trabajo, adaptándose al proyecto, y no al revés.
¿Por qué no se va a usar en un proyecto con gestión predictiva,
planificación de póquer para conducir una reunión de estimación por
juicio de expertos?. O un tablero de información Kanban.
¿Por qué no se pueden aplicar criterios de institucionalización de CMMI a los artefactos empleados por una empresa ágil? 
Trackback(0)
 |
TrackBack URI para esta entrada
RSS Comentarios
Tengo 24 años, muy joven pero me ha tocado vivir varias experiencias que en lo personal considero errores de los métodos formales o predictivos.
Como lo dice Martin Fowler en su artículo The New Methodology, estas metodologías formales basan muchos de sus principios en principios de otras ingenierias en donde la mayoría de sus problemas son susceptibles de un análisis matemático y un modelado previo. El diseño de clases, en papel se ve bien, pero en al momento de implementarlo es donde surgen los problemas y dudas.
En mi trabajo, existe una consultora que esta cerrando un proyecto y esta actualizando 200 casos de uso que tiene, además esta creando Casos de Uso de funcionalidad que ya existe, pues en su momento no realizó los CU para un análisis. Muchas veces de verdad que no entiendo, me cuesta muchisimo trabajo comprender el por que las consultoras no se dan cuenta que elaboran documentación inutil, que ni ellos mismos leyeron durante el desarrollo del proyecto... Si ya sabian que saldrían cientos de CU, por que se esmeraron tanto en crear perfectos CU? ¿Por que tanto perfeccionismo en detalles irrelevantes? ¿Por que hasta en el nombre del CU pierden tanto tiempo en buscar?... De verdad que no comprendo esa forma de pensar.
Aquí en México me doy cuenta que el principal problema no es que si los métodos formales sean buenos o malos, más bien que este tipo de metodologías fomenta:
- La pereza en un equipo de desarrollo: Tanta formalidad y tanta documentación hace que el equipo tenga pereza. Sería como ir a una Misa Ortodoxa en donde la formalidad y seriedad son fundamentales, pero termina por dar flojera. Aquí es donde se requiere inyectar dinamismo!!
En lo personal, empecé a interesarme por los procesos de desarrollo de Software hace como 1 año y medio. Al inicio fui un seguidor de PSP, pensé que era un buen proceso. Posteriormente conocí lo que es la Agilidad y quedé fascinado. Finalmente terminé por darme cuenta que no todo es malo en los métodos formales, existe una parte rescatable, pero en esencia y en su mayoría, los métodos formales cometen muchos errores...
Saludos!!