Ahí van: un modelo de contrato, una plantilla para especificaciones de "requisitos del sistema" conforme al estándar IEEE 1362, y otra para "especificaciones de requisitos del software" con el modelo IEEE 830.

Puede resultar útil el "kit completo" una plantilla, o algún párrafo para "copia-pega" en otros contratos.

No todo lo que etiquetamos como procesos es la misma cosa. En algunos las personas ayudan al proceso, y en otros son los procesos los que ayudan a las personas.
En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como instrumento, como operario de apoyo. En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr más eficiencia y no diluir el esfuerzo en rutinas mecánicas.

En las metodologías ágiles es habitual desarrollar dos niveles de planificación:  una general, planificación de la versión, y otra más detallada, planificación de la iteración.

El objetivo de la planificación de la versión es calcular la dimensión del proyecto. Saber si estamos hablando de 10 o de 100, y tanto en Extreme Programming (Release planning) como en Scrum (estimación del product backlog) se realiza en una reunión en la que participa todo el equipo.

En ella el cliente, o el propietario de producto expone una a una las historias o funcionalidades que necesita y el equipo determina el tiempo que llevará su desarrollo.
Este proceso no es ajeno a los problemas típicos de dinámica de reuniones, y aunque tiene un guión concreto y conocido por todos los participantes, es habitual entrar en atascos de "parálisis por análisis", en los que los minutos van pasando sin que los participantes terminen de decidir entre las posibles soluciones para una determinada funcionalidad y fijen una estimación; y el moderador ve con impotencia cómo ha consumido ya 15 ó 20 minutos sin poder cerrar la primera funcionalidad, y la lista de las que aún están pendientes de valorar.

MoProSoft es la denominación del "Modelo de Procesos para la Industria del Software" desarrollado por la Asociación Mexicana para la Calidad en Ingeniería del Software (AMCIS) de la Universidad Autónoma de México (UNAM) por encargo de la Secretaría de Economía del mismo país.

Dicha Secretaría, dentro del Programa para el Desarrollo de la Industria del Software (PROSOFT ), que forma parte del Plan Nacional de Desarrollo 2001-2006, identificó como modelos referentes para la calidad en el desarrollo y mantenimiento de software: CMMI, ISO 15504, pero al analizarlos para su inclusión en el plan el comité designado no los consideró demasiado formalistas o pesados para la mayoría de las empresas mexicanas.
 

Incorporo esta presentación, junto con el resto de material de Navegapolis a los documentos del nuevo sitio Qualitatis (que mañana os presento, que hoy ya va siendo hora de dormir :-)

Es un "powerpoint" con la visión global de Scrum, que espero os pueda resultar útil.

• Visión global de Scrum .
  

Watts Humphrey, cuando acometió el desarrollo del original modelo CMM for Software, tomó el concepto de madurez para los procesos, de la "Quality Management Maturity Grid (QMMG) desarrollada por Philip B. Crosby en su libro Quality is Free (1979), y que según el autor establece un criterio de para determinar el grado de desarrollo y asentamiento de los procesos en una organización, en cinco escalones que denominó:

SÍNTESIS
¿Qué es mejor, el yin o el yang?. ¿La tesis o la antítesis?. ¿Los procesos o la agilidad?.

Los gestores y modelos ágiles que dan la espalda a la gestión predictiva, emplean en su trabajo un fondo de conocimiento incompleto; y lo mismo ocurre con la gestión predictiva que ignora los valores y prácticas de los modelos ágiles.

GESTIÓN SISTÉMICA
Las empresas son sistemas inter-relacionados, y no departamentos separados conectados por procesos de negocio. Desde esta realidad sistémica, un gestor de proyectos trabajando con técnicas ágiles en una empresa cuyo departamento de personal, programadores, departamento comercial y directivos trabajan sobre supuestos predictivos, acabará con sensación de impotencia y ganas de tirar la toalla.

“Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado”.

Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995.

Parece lógico suponer que antes de empezar a construir algo, lo mejor es conocer con detalle qué es lo que vamos a hacer. 

En las circunstancias de velocidad del mercado actual, no sólo es importante el valor en el momento del lanzamiento, sino también su capacidad de adaptación y evolución a través de versiones, modificaciones, actualizaciones o ampliaciones; porque ahora no ocurre como en los años 50 en los que un modelo de auto-radio permanecía años sin desfasarse. Ahora como en Alicia en el país de las maravillas: “necesitas correr todo lo que puedas para permanecer en el mismo lugar”.

Los entornos de negocio de muchos sectores han experimentado cambios importantes en las últimas décadas.
La gestión de proyectos, o al menos la gestión de los proyectos para desarrollar nuevos productos y servicios en estos sectores tiene que dar el paso de evolución apropiado para adaptarse a los cambios del entorno en el que trabaja; en los que ahora, la “bête noire” no es exceder fechas y presupuestos, sino salir rápido al mercado con el mayor valor innovador posible

Como dirían los maños más castizos: "ahora que habíamos aprendido a decir pilicola, van y lo llaman flim".

En los 80, cuando la gestión de proyectos clásica había desarrollado ya un cuerpo de conocimiento estable y contrastado, y Michel Hammer demostraba la potencia de la producción basada en procesos para lograr eficiencia, calidad y repetibilidad, van algunas empresas como Canon, Fuji-Xerox, HP, 3M, Nec y otras;  pasan de planificar, dividir el trabajo en fases y especialidades y... ¡logran mejores resultados que sus competidores! que desarrollan con modelos tan planificados y ordenadicos.