archivo

Archivos diarios: octubre 23, 2011

El nivel 3 de CMMI tiene un ámbito de aplicación a nivel organizativo (o departamental si el desarrollo de software es un departamento más de la entidad), por tanto, resulta lógico que la gestión de proyectos vaya más allá de lo que es el proyecto en sí o de la cartera de proyectos de un jefe de proyectos, ya que lo que se pretende, por un lado es evitar la formación de repúblicas independientes que, pudiendo utilizar determinados procesos organizativos, tengan una dinámica de funcionamiento separada del resto (algo muy común en las empresas de desarrollo de software) y por otro fomentar una visión integrada y organizativa de los proyectos que tienen que estar alineados con las estrategias, objetivos y normativas de la organización.

Se pierde mucho valor en las empresas de desarrollo de software cuando la experiencia, conocimientos y activos de un proyecto no tienen más alcance que el grupo de personas que han trabajado en el proyecto y no existe una proyección hacia la organización. Esto sucede en empresas pequeñas pero también en entidades mastodónticas que no tienen definidos procesos que permitan aprovechar todo ese caudal, lo que las convierte en realidad en multitud de microempresas que solo tienen en común el nombre y las personas que van de un proyecto a otro.

En este proceso, se describen las acciones a realizar para determinar el proceso de desarrollo que seguirá el proyecto, el cual tiene que formar parte, del repositorio de activos de la organización (área de proceso: Definición de proceso organizativo).

Esto quiere decir que todo proyecto a nivel organizativo va a utilizar una metodología, un ciclo de vida, va a generar unos artefactos, seguir una estrategia que ha sido homologada para ser utilizada, lo que permite acotar la forma en que se enfoca el proyecto, algo que resulta ventajoso para tener una visión general de los proyectos en los que se trabaja, facilita la medición y la rotación de los empleados entre los diferentes equipos.

Puede haber excepciones y que el proyecto requiera de excepciones respecto a lo reflejado en algún área de proceso. Siempre hay que estar abiertos a que esto pueda suceder, porque es algo que pasará y es necesario tener presente qué se hará en estos casos. Lo que se hará será poner sobre aviso al área de calidad y/o al área de gestión de los procesos CMMI en la organización, los cuales deberán evaluar sí la excepción o excepciones están justificadas y si es así, dar el visto bueno. Tras la aprobación de las mismas, estas deberán quedar perfectamente documentadas en el plan de proyecto y se contribuirá al repositorio de activos con aquellos artefactos, prácticas o experiencias adquiridas si así resulta de interés para la organización.

Es importante tener en cuenta que cuando me he referido a áreas de proceso, sobre todo a aquellas que acotan procedimental o técnicamente un proyecto, siempre he hecho referencia a la necesidad de definir en las mismas diferentes escenarios en función de la naturaleza del sistema o sistemas con los que se va a trabajar, esto permite una mayor flexibilidad a la hora de seleccionar metodologías, arquitecturas, etc… (dentro de un orden) permitiendo un mayor ajuste a las necesidades del proyecto.

El hecho de que esté escribiendo una serie de artículos sobre CMMI y que valore positivamente lo que puede aportar a una empresa de desarrollo de software (si su definición es adecuada), no supone un cambio en mi apoyo y creencia en la máxima agilista que dice que: “Los individuos y su interacción se encuentran por encima de los procesos y las herramientas”.

Son las personas las que finalmente hacemos buenos o malos los procesos, ya que participamos en su definición, en su mejora continua y en su ejecución.

Richard (Dick) E. Fairley realiza una reflexión sobre la hegemonía real que existe de las personas sobre los procesos (traducción libre): “Programadores motivados y con conocimientos pueden sobreponerse a procesos inadecuados, sin embargo procesos perfectos nunca pueden compensar malos programadores o malos gestores de proyectos”.

Mientras que el negative testing se centraba en la localización de incidencias y errores en los artefactos que se producen en el proceso de desarrollo de software (entre ellos el propio software), el positive testing es la forma más habitual de testing ya que se centra la detección de incidencias en la verificación y validación de los objetivos reales que persigue el artefacto construido y su adecuación al proyecto que se está realizando y las entradas que reciba de artefactos anteriores o del mismo si para su obtención se está siguiendo un proceso iterativo e incremental.

Por tanto, las incidencias se encuentran cuando el artefacto no tiene el contenido o el comportamiento adecuado.

Si un sistema de información no cumple las expectativas, de manera que no funciona adecuadamente, no mejora e incluso empeora la eficiencia del proceso que informatiza sin aportar ningún tipo de valor a cambio (o no lo suficiente para justificarlo) se retoma periódicamente (con el coste correspondiente) para intentar solventar sus problemas y no se consiguen resultados, ¿por qué no parar?.

En estos casos, la eterna búsqueda de la amortización de la inversión no hace sino alejarnos más y más de ella porque siempre se va a recuperar menos que cada nuevo aporte de esfuerzo realizado (a lo que hay que sumar las pérdidas de productividad en el negocio, que pueden ser (y probablemente serán) todavía mayores).

Sé que es duro tomar la decisión de coger un sistema de información en el que se ha invertido mucho dinero y esfuerzo y tirarlo a la papelera pero más duro es intentar hundir una pared de hormigón a cabezazos.

El desarrollo de software, dentro y fuera del ámbito de un proyecto es el resultado de una serie de decisiones que son llevadas a cabo por diferentes personas. Este proceso trata de formalizar la toma de decisiones en la búsqueda de la unificación de criterios.

En el nivel 3 de CMMI las áreas de proceso tienen un alcance organizacional por lo que tiene sentido que se trate también de armonizar y homogeneizar determinados tipos de decisiones alejando la misma de interpretaciones o varas de medir personales y traspasándolas a un entorno repetible y más objetivo.

Que se plantee un área de proceso de estas características no nos debe resultar extraño, ya que estamos acostumbrados a que un jefe de proyecto o un gerente tome una decisión y el de la mesa, despacho o sala de al lado, para un mismo asunto tome la contraria.

Pero, ¿hasta dónde llegar? Sobre el papel no hay limitaciones, por lo que podría extenderse hasta a decisiones de bajo nivel, sin embargo y desde mi punto de vista, no resultaría operativo ni ágil y desaprovecharía el talento de las personas. No obstante sí que tiene sentido para decisiones de más alto nivel, para intentar darle un enfoque más objetivo y dotarlas de un mayor nivel de transparencia, como por ejemplo, la selección de un proveedor, de un producto, de si se apuesta o no por presentarse a una determinada licitación pública, la selección de una arquitectura en un proyecto (cuando existen diversas posibilidades que podrían ser válidas), etc…

En este área de proceso, se definiría el alcance del mismo, los criterios y métodos/procedimientos de evaluación para cada una de las actividades o tareas que requirirían un proceso de análisis de la decisión, el procedimiento para identificar las posibles alternativas de solución, cómo realizar el proceso de evaluación de las mismas y de la selección de la más adecuada.