Archivo

Archivos diarios: noviembre 12, 2011

Hay una cita de autor desconocido que resume perfectamente lo que es la esencia del desarrollo iterativo incremental: “Cada sistema grande que funciona empezó por un sistema pequeño que funcionaba”.

El ciclo de vida iterativo incremental, base de las metodologías ágiles, determina un proceso evolutivo de desarrollo de software, donde partiendo de componentes más pequeños se van agregando otros nuevos, conformando cada vez un sistema con mayores características y cada vez más adaptado a las expectativas del usuario que en cada iteración va realizando los ajustes necesarios.

Se tiene una línea de negocio orientada al producto, ya sean cerrados que se venden tal cual o que tienen ligeras adaptaciones en función del tipo de cliente y que podemos utilizarlos dentro del ámbito de nuestra organización y resulta que no lo hacemos.

Esto, además de dar muy mala imagen al posible cliente (¿me estás intentando vender algo que lo puedes utilizar tu también pero no lo haces?, ¿me estás creando una necesidad cuando tu la tienes y no has hecho nada por usar lo que me pretendes vender?) provoca una pérdida importante de capacidad para la mejora continua del producto, ya que podemos sentir nosotros mismos la experiencia del usuario y corregir errores antes de que lo detecten los clientes (sobre todo si antes de lanzar una nueva versión, se implanta el producto dentro del ámbito de la organización).

Sobre esto último Maya Elhalal-Levavi realiza la siguiente reflexión: “No hay nada mejor para depurar una aplicación web que utilizarla regularmente tu mismo”.

Se quiere desarrollar un sistema de información en el que existe un riesgo muy alto de que alguna de estas variables se produzca (seguro que se os ocurren unas cuantas más):

- El área usuaria no va a colaborar o su colaboración va a ser residual.

- No existe una dirección usuaria que asuma la dirección o gobierno funcional del proyecto.

- El presupuesto disponible para realizarlo se encuentra sensiblemente por debajo del necesario y no existe voluntad de reducir el alcance del proyecto o la reducción del alcance no permite solventar la diferencia entre lo necesario y lo disponible o garantizar que se superan unos umbrales de calidad aceptables.

- Las áreas de proceso que se van a informatizar se modifiquen de manera sensible.

- El plazo impuesto para tener una versión del producto con un nivel de funcionalidades adecuado no se puede conseguir.

Lo mejor será que se invierta el dinero y el esfuerzo en algo más provechoso.

En el año 1973, un informe de Barry Boehm, predijo que los costes de software terminarían sobrepasando los costes derivados del hardware.

En la década de los sesenta Edsger Dijkstra introdujo el concepto de crisis del software.

Este cambio de tendencia que hoy en día se puede pensar que era evidente, en aquellos momentos no lo era, ni mucho menos. De hecho el Departamento de Defensa de los Estados Unidos (a la vanguardia entonces del mundo TIC) esperaba justamente el resultado opuesto en el informe de Boehm y como consecuencia del mismo se inició un cambio de enfoque en las inversiones que realizaban, centradas en conseguir ordenadores centrales de cada vez más potencia.

Faltaban años todavía para el boom de los ordenadores personales (si bien desde años antes, ya existían determinados modelos que eran considerados de esta manera), dominaban los mainframes y el desarrollo de software era todavía muy artesanal y orientado a problemas concretos en la plataforma en la que se trabajaba (más que a soluciones reutilizables en diferentes entornos).

Los problemas derivados del desarrollo de software ya podían ser visibles entonces, de hecho, persisten actualmente. Tal vez la diferencia es que hoy en día se tienen más identificados e investigados los problemas y se manejan posibles soluciones, sin embargo su adecuada aplicación depende de muchos factores (entre los que destaca por encima de todos, el humano) y eso es lo que condiciona que todavía nos encontremos con la situación en la que nos encontramos.

Del caos del nivel 1 de CMMI, al nivel 2 donde se gestionan/administran determinados procesos, en donde por lo menos a nivel de proyecto se quiere establecer un orden y de ahí al nivel 3 donde los procesos tienen un ámbito de aplicación organizativo (se pretenden eliminar las repúblicas independientes, que tanto daño hacen a las organizaciones que desarrollan software o que tienen que gestionar este tipo de servicios) y en donde se pretende normalizar el proceso de desarrollo de software.

La tendencia de las organizaciones, conforme van creciendo o cuando ya han llegado a un número de empleados y/o proyectos que no se puede gestionar de manera adecuada (no hace falta especificar un número concreto de unos o de otros, ya que un gestor de cualquier entidad de este tipo y si me apuráis, cualquier empleado, se da cuenta cuando la maquinaria no funciona y para verlo no es necesario revisar resultados económicos) debería ser establecer un modelo organizativo orientado al proceso.

Los procesos pueden gustar o no, pero permiten definir un ámbito de trabajo, siempre es mejor esto, que el hecho de que cada cual haga su guerra por separado y se pierda la visión de que la empresa puede ser un conjunto de piezas distribuidas, pero siempre atendiendo a un interés común.

La clave de la implantación de CMMI o de cualquier otro tipo de modelo orientado a procesos se encuentra en ajustarlo a la realidad de la organización donde se implanta, a su contexto y a su negocio. Es decir, no se puede implantar un modelo que no se pueda cumplir, un modelo a ciegas que no tenga en cuenta qué es la organización, qué puede asumir y hacia dónde se va a dirigir. Precisamente éste es uno de los factores de fracaso de la aplicación de este tipo de modelos, definirlo como si la organización no existiera.

La aplicación de CMMI no asegura que los proyectos salgan mejor, ya que el éxito o el fracaso de los proyectos trasciende a los procesos, pero sí que determina un buen punto de partida y habla bien a las claras de cómo es la organización de la entidad que desarrolla el software. Por eso no es de extrañar que tanto administraciones públicas, como organizaciones privadas tengan cada vez más en cuenta la adecuación de las entidades a las que contratan servicios de desarrollo de software a modelos organizativos orientados a procesos basados en algún estándar o modelo reconocido internacionalmente.

Como mínimo una entidad debe aspirar a tener el nivel 3, si bien, en función de su estado actual, podría optar por pasar primero por el nivel 2 y aplicar algún área de proceso de nivel 3. ¿Se requieren muchos cambios? Se requieren cambios y si son muchos o pocos, significativos o no, depende de cómo la organización funcione actualmente y también dependerá de la definición de un modelo de procesos acorde a las necesidades y naturaleza de la organización. Desde mi punto de vista se ve CMMI nivel 3 como un muro insoslayable y sin embargo, un simple vistazo a sus áreas de proceso, permite darnos cuenta de que el monstruo no es tan fiero como lo pintan.

A continuación, se enumeran las áreas de proceso de nivel 3.

CMMI-DEV

- Desarrollo de requisitos.
- Solución técnica.
- Integración de producto.
- Verificación.
- Validación.
- Enfoque en el proceso organizativo.
- Definición de proceso organizativo.
- Formación organizativa.
- Análisis de riesgo.
- Análisis de decisiones y soluciones.
- Gestión de proyectos integrada.
- Gestión de proveedores integrada.

CMMI-DEV + IPPD

- Equipos integrados.
- Ambiente organizacional para la integración.

Se puede tener amigos dentro de las personas que conforman tu contexto laboral, es algo razonable. Ahora bien, es importante distinguir lo que es la relación dentro de las paredes de tu organización y tu relación fuera de ella, es decir, dentro te debes guiar por sentimientos profesionales y fuera como estimes conveniente.

Si tu relación de amistad te hace perder objetividad y establecer dos tipos de reglas o dos varas de medir, la de tus amigos y la de los demás, te estás echando tierra sobre tus tareas de gestor y si no lo eres, como profesional.

No somos robots y es natural que nuestro trato con las personas que consideramos nuestros amigos sea diferente y puede serlo, siempre y cuando no supere los límites que afecten a una interpretación objetiva de su trabajo y el de los demás.

Ante un hecho X realizado por alguien que sea tu amigo y por otro que no lo sea, las consecuencias deben ser las mismas. ¿Que es difícil?, ¿alguien ha dicho que no lo sea? Yo no puedo ser el que lance la primera piedra, pero eso no quiere decir que no intente ser, cada vez más, lo más objetivo posible.

¿Y que tiene que ver esto con la productividad? Pues mucho. Si uno ve que para llegar a la meta tiene que correr muchos kilómetros más, cuesta arriba y que llegar antes no asegura nada, posiblemente vea mermada su motivación y con ella, su productividad.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.199 seguidores