Inicio arrow Artículos - apuntes arrow Construyendo un laberinto de nombres para perdernos. Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Construyendo un laberinto de nombres para perdernos.
Valoración del artículo: / 9
MaloBueno 
22.08.2010

En los 80 se nos decía: Brujula"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?".

Gestión predictiva y producción basada en procesos

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.

Gestión ágil y basada en 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.

 

CMMI vs Agile

 

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...

 

Procesos vs. agilidad


 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.

 

CMMI - Agilidad - Artefactos

 

¿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?

CMMI - Agilidad - Artefactos

Safe Creative #1008227110716

Share |

 

Trackback(0)
Comentarios (2)Add Comment
Métodos formales = Pereza
escrito por Ascari Romo, August 26, 2010
Hola Juan,

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!!
...
escrito por Juan Palacio, August 26, 2010
Hola Ascari,
Gracias por tu comentario, que comparto completamente. Para el tipo de proyectos de software en los que trabajo, el 80% de lo desarrollado por al Ingeniería de software consume energía sin dar valor. Osea: rozamiento ;-)
De todas formas, hay cosas como el mapa general y la conceptualización que hace la ISO 12207, Los conceptos para institucionalización desarrollados por CMMI, parte de la teoría de requisitos desarrollada sobre SRS's, parte de la teoría de planificación (WBS - Gantt) que es importante conocer y tener en el inventario de recursos de un gestor.
Hay otras partes como PSP en las que me cuesta ver utiliad alguna, pero tampoco he trabajado en proyectos para enviar naves espaciales o misiles balísticos ;-) así que... ¿?¿

Un saludo.
Juan

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative