brujula 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? ¿Os imagináis que un arquitecto hiciera lo mismo?"

10 08 01

Aprendimos a redactar antes requisitos del sistema, la especificación de requitisos del software, el plan de proyecto, gestión de riesgos, matrices de trazabilidad... y entonces nuestros clientes no dijeron que no podían definir el producto desde el principio, que empezáramos cuanto antes, aunque no tuviéramos una descripción completa, y que ya nos irían diciendo.

Aprendimos a basar la calidad de nuestros programas en los procesos de nuestra empresa, y al hacerlo descubrimos sus limitaciones frente al talento de las personas.

10 08 02

A falta de una, aprendimos dos formas de abordar los problemas: desde la planificación y la ingeniería de procesos, y desde la agilidad y las personas; y cuando ya sabemos hacer las cosas "blancas" o "negras", descubrimos que los proyectos reales son de tonos grises más o menos claros. 

10 08 05

 

Y en este aprendizaje hemos creado dos bandos: planificación y agilidad, y hemos perdido la cabeza creando y etiquetando metodologías en cada bando: Scrum, XP, Kanban, Lean, Scrumban... 

10 08 03

 

El consejo es huir del "etiquetalismo metodológico, y ser prágmá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 el producto en pulsos de tiempo prefijado (sprints),  con técnicas kanban iteraremos el producto en un flujo continuo de crecimiento. 

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á nuestro trabajo, y nuestra capacidad de adaptarlo a las característcas de cada proyecto. 

 

10 08 06

¿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 gestión visual Kanban.
¿Por qué no se pueden aplicar criterios de institucionalización de CMMI a las prácticas empleados en una empresa ágil?

10 08 07

Este artículo se publicó originalmente el 22 de agosto de 2010 en navegapolis.net

 

Escribir un comentario


Código de seguridad
Refescar