|
 La tesis (ISO 12207, 15504, CMMI…) ha identificado y definido las cosas QUE hay que hacer.
La antítesis (XP, Scrum, FDD...) ha mostrado formas de trabajar que funcionan bien: CÓMO hacer determinados "qués".
Posiblemente la síntesis , la moraleja de ambos sea cuestionar los "POR QUÉs"
¿Qué hacer para que los proyectos de software salgan bien?
LA TESIS:
"Bueno..., tenga en cuenta que no sólo se trata de programar de forma adecuada. Hay que hacer de forma adecuada otras muchas tareas que tienen lugar desde que se le ocurre la idea de hacer algo, hasta que finalmente lo deja de usar."
Esto es lo que dice ISO con su estándar internacional ISO/IEC 12207 : Las cosas QUE intervienen en el desarrollo de un proyecto de software. QUÉ tareas tiene que hacer el cliente al adquirir el sistema (5.1 Acquisition), QUÉ tareas debe hacer el suminstrador para responder a la adsuisición (5.2 Suply), QUÉ tareas para desarrollar el sistema (5.3 Development) etc. ISO 12207, o CMMI o ISO 15504 son modelos. Los modelos dicen el QUÉ hay qué hacer, pero no CÓMO. Los modelos le dicen: hay que hacer un contrato, hay que mirar las opciones del mercado, hay que hacer requisitos, plan de proyecto, análisis, codificar, probar, etc... Ni CMMI ni ISO prescriben CÓMO hacer la gestión de la configuración, la planificación del proyecto o la gestión de los requisitos. CMMI dice: hágalo como usted quiera, siempre y cuando alcance el fin del área de proceso que venga al caso. O sea, siempre y cuando usted tenga control de las versiones, sepa cuál es el plan de proyecto, o los requisitos de lo que debe hacer. Que usa gráficos de Gantt, o post-it en pizarras… allá usted. Que si documentos Word con el estándar de requisitos de IEEE 830, o historias de usuario... Usted sabrá. Usted lo hará bien, si consigue el objetivo del área de proceso. Bueno, otra cosa será si quiere que yo lo certifique, porque entonces me lo tendrá que demostrar, y eso le complicará un poco la vida, pero... bueno, allá usted.
LA ANTÍTESIS:
"Bueno... tiene que hacer las cosas de esta manera: ponga a los programadores por parejas, desarrolle trozos pequeños en 2 ó 4 semanas cada uno. Haga una reunión de una jornada antes de empezar a programar cada trozo, y organícela en dos partes: en la primera cierre los requisitos con todo el equipo, en la segunda... Todos los días el equipo debe reunirse durante 5 minutos y responder a tres preguntas..." Este es el tipo de respuesta de la antítesis: de los modelos ágiles, que en rigor no serían "modelos" sino "prácticas", porque no dicen QUÉ hay que hacer, sino CÓMO hay que hacer. Y posiblemente la síntesis está en el PORQUÉ: ¿Por qué la descripción del sistema o ConOps con el estándar IEEE 1362 ? o, ¿por qué en un Product Backlog?. 
LA SÍNTESIS:
La talla única no resulta válida, y las prácticas más indicadas para unos, pueden resultar bien demasiado pesadas, bien insuficientes para otros. Los responsables de la gestión en cada empresa adoptan las decisiones para cada área de proceso sobre el conocimiento del grado y formas que necesita su empresa en tres áreas:
- Equilibrio agilidad - procesos
- Formas y modos de institucionalización.
- Formas y modos de ingeniería de procesos.
Y este conocimiento es consecuencia del análisis del tipo de trabajo, y de las características de la organización. 
Además de determinar un nivel de equilibrio entre agilidad y procesos, adecuado al tipo de trabajo que se realiza, hay otros dos factores importantes en el diseño y gestión del marco de trabajo de la empresa: la institucionalización y la ingeniería de procesos. Los modelos para la mejora de procesos como CMMI tienen una fortaleza importante, que a la vez es debilidad de las prácticas ágiles: se trata de las prácticas genéricas, que están presentes en todas las áreas de procesos para que en todas se consiga: - "Institucionalizar" las formas de trabajo
- Implantar prácticas de ingeniería de procesos.
Tal y como lo define CMMI en el glosario, institucionalizar las prácticas de trabajo es incrustarlas en la cultura corporativa de la empresa de manera que se realicen de forma rutinaria.
La institucionalización se refiere a las ventajas de documentar los procedimientos que emplea la empresa, y disponerlos de forma accesible a todos los interesados; a la necesidad de formar al personal para que las conozca y sepa emplearlas en el trabajo.
Claro que CMMI se refiere a la institucionalización de sus prácticas, pero lo cierto es que resulta útil tanto para los procesos como para las rutinas de trabajo ágiles.
Los criterios de rigor de documentación, comunicación, formación y ámbito dependen de las características de la organización y no de agilidad o procesos.
Para un pequeño grupo de emprendedores, que desarrollan en una "start-up"un innovador producto de software, aplicar procesos pesados para la institucionalización, les aporta más problemas que ventajas.
Una gran empresa, o una pequeña que quiere asentar principios para dar el salto: de personas que saben programar a empresa que sabe programar, debe incluir procesos para explicitar e institucionalizar su saber hacer, independientemente de que se trate de procesos o de agilildad. Y, en segundo lugar, las prácticas de ingeniería de procesos, son las relacionadas con la medición y mejora de las propias prácticas y procesos empleados en el trabajo.
Igual que para la institucionalización, es irrelevante que se trate de agilidad o de procesos. Las características de la organización determinarán para cada área "por qué" resulta conveniente o no, emplear modelos tipo PDCA , IDEAL , las métricas, los criterios y las formas apropiadas 
 |
RSS de los comentarios
Me llama la atención la contraposición generalizada entre agilidad y procesos. Sin entrar en aspectos más terminológicos, ¿se podría hablar de procesos ágiles y procesos prescriptivos (o hiperprescriptivos)?