archivo

Archivos Mensuales: octubre 2011

La creatividad de los desarrolladores de software es una de sus grandes virtudes (tal vez la que más) y mal empleada, uno de los mayores defectos.

Hay veces donde hay que crear, otras donde el trabajo a realizar está restringido al ámbito de un proyecto y donde resultas más conveniente ser práctico que complicar un desarrollo por intentar saltarse sus propios límites o el propio contexto en el que se encuentra el proyecto.

Teniendo en cuenta que la creatividad produce resultados y puede marcar diferencias si se aplica en aquellos proyectos y ámbitos donde es necesaria, resulta de interés crear el contexto adecuado o caldo de cultivo donde la misma pueda ser expresada, sin olvidar de lo necesario que resulta educar a los desarrolladores sobre los momentos en que resulta más adecuado ceñirse al guión establecido.

Me gusta esta reflexión de Frederick Brooks porque ofrece una visión romántica de lo que es un programador (traducción libre): “El programador, como el poeta, solo funciona si se encuentra un poco retirado de lo estrictamente racional. Construye sus castillos en el aire, desde el aire, creando a través del esfuerzo de la imaginación. Pocos medios de creación, son tan flexibles, tan sencillos de pulir y reconstruir y tan fácilmente capaces de concebir grandes estructuras conceptuales”.

Hay una cita de Fred Brooks que expresa varias problemáticas en los proyectos de desarrollo de software y en la gestión de las carreras profesionales en las empresas que se dedican a este negocio: “La conclusión es simple: si un proyecto de 200 personas tiene 25 gestores que son los programadores más competentes y experimentados, despide a los 175 programadores y pon de nuevo a los gestores a programar”.

– Es mejor la calidad que la cantidad.
– En cada rol en un proyecto debe estar el personal más adecuado para el mismo.
– Muy pocas personas son excelentes en todos los perfiles del desarrollo de software.
– La gestión vertical de las carreras profesionales es una autolimitación nada razonable que se ponen a sí mismas las empresas.

Proyecto desarrollado en cascada, meses de desarrollo tras el análisis, cambia el responsable funcional, el nuevo llega a falta de poco para la entrega y empieza a sugerir cambios.

¿Os suena? Es lo de siempre, cambie o no el responsable funcional. Podía haber sido incluso peor y cambiar además el proceso que se informatiza por completo o de forma sensible, riesgo que crece proporcionalmente con el tiempo de construcción y todavía más para determinados tipos de clientes, como por ejemplo la Administración Pública.

Por eso esta forma de desarrollar el software no funciona, por mucho que sea la metodología más utilizada, por mucho que se lleven muchos años trabajando de esta manera. Es cierto que a veces proyectos desarrollados así salen bien pero también lo es que la mayoría tienen resultados discretos o pésimos, para el cliente, para el proveedor y generalmente para ambos.

El equipo de proyecto, el proceso para conformarlo, para seleccionar los roles adecuados, para orquestar la posible colaboración entre diferentes equipos. De esto trata este área de proceso del nivel 3 de CMMI.

En demasiadas ocasiones se le presta muy poco atención a la composición del equipo. A veces parece como si la selección de los integrantes se hubiera echado a suertes.

Esto es un error. El equipo debe ser el mejor posible, teniendo en cuenta el contexto de todos los stakeholders. ¿Por qué digo que debe ser el mejor posible y no que el mejor (a secas)? Pues porque no siempre van a estar disponibles para trabajar en el proyecto en el momento adecuado las personas que mejor se ajusten al alcance del mismo (estarán asignadas a otros proyectos, tareas o trabajos y no es posible o conveniente su participación en este, el presupuesto del proyecto no permite que determinados perfiles puedan participar en él, etc…), ahora bien, esto no debe ser un obstáculo para renunciar a conformar el mejor equipo que sea posible.

En este proceso de CMMI el equipo de proyecto no es solo el equipo de desarrollo, sino también está formado por personal de las distintas áreas involucradas cada uno de los cuales con el rol, dedicación y poder de decisión suficiente (en su ámbito de actuación).

El alcance de este proceso comienza desde la propia metodología para identificar las tareas que debe realizar el equipo de proyecto y los conocimientos y habilidades que se necesitan para su ejecución. Con esta información y el conocimiento del personal que puede estar a disposición del proyecto, se realizaría la selección de los integrantes.

Una vez conformado el equipo lo siguiente es definir las actividades que permiten fomentar una visión compartida de los objetivos a conseguir y del método para conseguirlo (comunicación, trabajo en equipo, etc…), dar a conocer a cada componente su rol y responsabilidades, establecer los procesos necesarios para coordinar el funcionamiento del equipo y por último definir los procedimientos para poder establecer relaciones de colaboración con otros equipos de trabajo (para ello además de existir determinados procesos horizontales, requiere tener un conocimiento de las tareas y proyectos que se están realizando en la organización o en los que colaboran algunos de los interesados).

El nivel 3 de CMMI extiende el área de proceso del nivel 2 denominada Gestión de acuerdos con proveedores.

En el anterior nivel el objetivo principalmente era gestionar esos acuerdos, sin olvidarnos del proceso que permite llevarnos a los mismos, de la adquisición de esos productos o servicios y de la aceptación de los mismos.

En este nivel los objetivos son los mismos aunque con un enfoque más formal, más estratégico y con una visión más allá del alcance de un proyecto (o de un conjunto de ellos).

Este área de proceso se ocupa desde el método para la analizar proveedores potenciales de productos o servicios, evaluarlos y seleccionarlo hasta la verificación del cumplimiento de los compromisos fijados con los mismos y la posibilidad de revisar, si fuera necesario, los acuerdos adoptados con determinados proveedores.

Estamos ante una de las causas de la crisis del software. El exceso de optimismo. Pensar que todo es más fácil de lo que parece. ¿Cuántas veces no es hemos arrepentido de decir que esto es fácil, esto es trivial o esto está hecho en una semana? Muchas. Y lo peor de todo es que nos seguiremos arrepintiendo de ello porque tarde o temprano volveremos a caer.

Somos así, es nuestra manera de ser. Es cierto que, como somos una profesión de extremos, también pasamos por períodos en los que todo es imposible o en lo que todo requiere un esfuerzo dos, tres o cuatro veces el real, pero nuestra falta de término medio nos lleva a eso, a comprometernos a plazos, dedicación, calidad, etc… que después por el motivo que sea (propio o ajeno) no podemos cumplir. A veces no tendrá repercusión, otras le costará mucho dinero al proyecto.

Mejor optimismo que pesimismo (es mi forma de entender el desarrollo de software, respeto quien piense y con razón que una actitud conservadora origina menos disgustos), pero también es mejor pensar que precipitarse.

No soy el único, pensaba que era una más de mis rarezas.

Hay bastante más gente que coincide conmigo en que una de las cosas que más pereza les da es recoger el lavavajillas, ¿por qué? al rato deja de estar vacío y antes de que te des cuenta lo tienes de nuevo lleno.

Un bucle sin fin.

Esta sensación creada por una rutina sin fin puede alcanzarnos en nuestro trabajo. A mi me ha pasado y en diferentes momentos. Te das cuenta de que cada día es más de lo mismo, tal vez actores diferentes pero un argumento parecido.

La rutina tiene sus ventajas y sus inconvenientes. Sientes que controlas, te conviertes prácticamente en un autómata, te llevas menos trabajo en la cabeza, etc…, pero también limita tus posibilidades y te puede llevar por un camino equivocado y es que la rutina se torne en aburrimiento y el aburrimiento en pereza.

¿Es productiva la rutina? No hace mucho tuve una conversación con un amigo al respecto y no terminamos de ponernos de acuerdo. Tal vez los dos teníamos la razón, tal vez los dos nos equivocábamos o tal vez nos encontrábamos cada uno en una escala del gris.

Mi amigo defendía el hecho de que el dominio de una especialidad permite ser más productivo en la misma, creas automatismos, te equivocas menos, etc…, pero, ¿acaso es necesaria la rutina para llegar a ser un experto en una materia?, y si te sacan de tu zona de control, ¿qué es lo que pasa?.

Aprendiz de todo, maestro de nada, el que mucho abarca, poco aprieta dice el refranero. Creo que no se trata de dirigirnos a los extremos y que desarrollando un ámbito concreto de una profesión se puede llegar a tener un cierto dominio de la misma sin caer en la rutina.

Llegado un punto el sistema de información empieza a deteriorarse. Existen funcionalidades que dejan de usarse o su utilización residual y que no se eliminan, hay errores que persisten versión tras versión y que afectan a la calidad del dato y a la adecuada realización del proceso a través del sistema, en lugar de mantenerlo lo más simple y funcional posible se añaden funcionalidades cada vez más complejas y que no proporcionan el valor esperado y/o dificultan el mantenimiento, etc…

El sistema crece y llegado un punto resulta complicado de controlar, sobre todo en proyectos grandes. Es complicado en estos casos tener una visión global de todo y no caer en errores que contribuyan a ese deterioro.

Por otro lado tenemos también tanto la corrección de incidencias y la adición de funcionalidades que conllevan en muchos casos la introducción de nuevos errores en el sistema ya sea en el propio código que se corrige o en el módulo que se añade o provocado por efectos colaterales en otras secciones del código y funcionalidades de la aplicación.

Frederick Brooks que dirigió el desarrollo del sistema operativo OS/360 sabe muy bien a que se refiere cuando habla de los inconvenientes del mantenimiento, sobre todo en proyectos complejos, de tamaño moderado y con grandes equipos de trabajo y su posible repercusión en el deterioro de la aplicación y lo podemos apreciar en su siguiente reflexión: “El problema fundamental del mantenimiento de un programa es que la corrección de un defecto tiene una probabilidad importante de introducir otro”.

En el artículo donde reflexionaba sobre la importancia de la experiencia en los proyectos de desarrollo de software y que la misma se hacía más fuerte y más precisa en mayor medida con el fracaso que con el éxito y utilizaba para ilustrarlo una cita de Frederick Brooks.

En esta entrada voy a hacer uso otra cita muy conocida del mismo autor, haciendo referencia también al desarrollo del sistema operativo OS/360. Mi objetivo no es hacer apología del error, sino hacer de los mismos una visión constructiva (claro que un error o un fracaso tiene consecuencias negativa y hay que asumirlas, pero lo peor que pueden tener consigo es no extraer ninguna conclusión o aprendizaje de los mismos).

La cita a la que hacía referencia es la siguiente: “Es una experiencia muy humillante cometer un error que puede costar millones de dolares, pero también puede ser muy memorable”.

Stakeholder es el término en inglés que define a los interesados en un proyecto de desarrollo de software (esta es una particularización del concepto ya que es igualmente válido para cualquier tipo de proyecto).

¿Qué es un interesado? Todas aquellas personas o departamentos que participando o no directamente en la realización de los trabajos se ven afectados por el resultado de los mismos.

Con esta definición, las personas y departamentos involucrados pueden ser muchos. Se puede llegar a trabajar con todos, sin embargo lo más interesante (aunque eso lo determinarán las características del proyecto) es seleccionar de entre ese dominio, aquellos en los que realmente el impacto del desarrollo sea sensible, ya sea porque participan en el mismo, porque gestionan el proceso o procesos que se informatiza, porque exista una trascendencia económica que interesa gestionar y controlar o porque son destinatarios de la solución (o pueden verse condicionados por la misma).

La identificación de los stakeholders resulta por tanto esencial en un proyecto, ya que es necesario que de alguna u otra forma tengan participación en el mismo definiendo el rol que deben tener en la ejecución de los trabajos y determinando las expectativas que tienen respecto a los resultados del proyecto, las cuales condicionarán los trabajos a realizar y servirán de umbral a la hora de evaluar la calidad de los trabajos (la validación de las expectativas es una variable importante, la que más pero no la única, para medir el nivel de calidad de los resultados).