archivo

Archivos diarios: noviembre 5, 2011

La priorización de funcionalidades permite que las primeras versiones del software contengan aquellos módulos que el área usuaria considera que va a tener más utilidad para ellos, de esta manera, además se obtiene el feedback para terminar de realizar los ajustes necesarios, los cuales se van insertando en las siguientes versiones que se van liberando.

En el caso de que haya problemas presupuestarios en el proyecto nos aseguramos de esta forma que las funcionalidades más necesarias y críticas se habrán puesto en marcha y con las diferentes iteraciones se habrá conseguido una mayor alineación entre las mismas y las expectativas del usuario.

Dejando para el principio lo más importante y para el final lo más accesorio, reduciremos también el porcentaje de funcionalidades de la aplicación que se implementan pero que no se utilizan o se usan de manera residual, ya que por un lado los usuarios enfocarán la mayor parte de sus peticiones en mejorar lo que hay ya desarrollado y en otras tareas prioritarias todavía no implementadas.

Se han realizado estudios que indican que más del 50% de la corrección de errores introducen errores adicionales en el código.

Por este motivo resulta fundamental la aplicación de buenas prácticas en la codificación, la utilización de una buena arquitectura y framework, la aplicación de pruebas unitarias y de integración continua y la realización de nuevas pruebas una vez que se haya integrado un componente corregido.

Por esto es tan importante que el proceso de desarrollo no sea algo improvisado sino algo reglado, donde cada miembro del equipo de proyecto conozca qué es lo que tiene que hacer y qué técnicas tiene que utilizar para programar.

Es así de sencillo salvo que haya instrucciones de muy arriba que obliguen al uso del sistema de información (si ya se ha desarrollado o adquirido) o que impliquen a los mismos en la definición y desarrollo del sistema y se les pida cuentas por los resultados obtenidos.

Si los directores usuarios no quieren controlar el desempeño del área usuaria en el proyecto, la utilización o desarrollo del sistema seguirá la deriva que quieran los usuarios (que será la que decida la corriente mayoritaria o con más poder) y esto es muy peligroso, sobre todo si los usuarios no sienten la necesidad de que les implanten/impongan un sistemas, algo que ocurre en la mayoría de los casos, ya que tienen medios artesanales y efectivos para llevar el día a día de su trabajo (herramientas ofimáticas, organización de ficheros en carpetas, etc…).

¿A que todos conocemos sistemas de información que se han ido al traste por este motivo?, ¿a que todos conocemos sistemas de información que no terminan nunca de ponerse en marcha porque siempre surge un “defecto” que es imprescindible de corregir antes?.

Y lo más importante de todo, llegado un punto, el equipo de proyecto debe parar, ya que los desarrolladores no podemos ni debemos estar tras los usuarios para que hagan uso del sistema (lo podemos hacer pero hasta cierto punto, ya que a todos nos gusta que nuestro trabajo sirva para algo, pero una vez que nos demos cuenta que el obstáculo es difícilmente salvable, es mejor no malgastar más energías y que sea la dirección usuaria o los propios usuarios los que, si quieren, sean los que se dirijan a nosotros).

¿Cuándo? Desde que se inicia el proyecto. Los errores que se propagan entre fases de desarrollo son muy costosos de corregir, ya que el esfuerzo se dispara en proporción geométrica desde el momento en que se producen. El testing antes de la entrega, puede ser una última barrera de defensa, mejor eso que nada, pero para que realmente sea efectivo debe ser tenido en cuenta durante todo el proceso de desarrollo (y este no comienza en la construcción).

¿Cuánto? Cuanto más mejor (si bien, lo mejor es ajustarse a la criticidad del proyecto, plazos, presupuestos, etc…). Sin embargo, por encima del número, debe primar más lo que es la calidad del testing o, lo que es lo mismo, tener la capacidad de orientar el esfuerzo de la manera más eficientemente posible, por ello es tan importante la experiencia y conocimiento del equipo de testers.

Dentro de CMMI-DEV que es el modelo de madurez de CMMI orientado al desarrollo de software existe una división en dos modelos, lo que sería el CMMI-DEV tal cual o el CMMI-DEV + IPPD (Integrated Product and Process Development).

La diferencia entre ambos modelos se encuentra en la aplicación o no de las siguientes áreas de proceso de nivel 3, las cuales son exclusivas de IPPD:

Equipos integrados.
Ambiente organizacional para la integración.

La aplicación de IPPD puede proporcionar además un enfoque adicional a las distintas áreas de proceso de CMMI-DEV, de manera que si la propia aplicación del nivel 3 ya proporciona una visión del proyecto a nivel organizacional, IPPD sube un peldaño esa visión, al tener como objetivo una mayor integración entre los equipos de trabajo, los propios empleados y su alineación con la cultura definida en la organización.

El área de proceso de Equipos Integrados del nivel 3 de CMMI requiere para poder efectuarse de manera efectiva de una estrategia a nivel organizativo que favorezca la alineación de los empleados con los objetivos de la organización, a sentirse parte de la misma y no un número más, a que sean conscientes de que la clave para obtener resultados no se centra exclusivamente en el esfuerzo individual sino que es necesario el trabajo en equipo y el trabajo en el colectivo (más allá del grupo de personas con las que compartes una actividad). En definitiva a definir una cultura y visión de empresa que sea compartida por aquellos que pertenecen a ella.

Todo esto requiere la definición de esa cultura de empresa y los mecanismos para que la misma sea conocida por los empleados y más allá de eso, para que esté integrada dentro del día a día de los trabajadores. Esa cultura de empresa, deberá tener como aspecto de gran interés el fomento de trabajo en equipo, para ello debe proporcionar y promocionar un ambiente integrado de trabajo (pasar de las buenas palabras a hechos que fomenten y permitan la colaboración).

Toda maquinaria requiere de engranajes, este área de proceso tiene en cuenta que para que la cultura de empresa prevalezca es necesario de personas que dinamicen su funcionamiento, que lideren las actividades que permitan mantenerla.

Es la evolución natural de los desarrolladores que han trabajado con el ciclo de vida clásico o en cascada y de las organizaciones que han venido utilizando esa metodología.

Está comprobado que la cascada no produce buenos resultados ya que se ajusta a un modelo ideal de desarrollo de software en el cual las especificaciones de los usuarios son las adecuadas (para lo cual el usuario tiene que tener perfectamente claro qué es lo que quiere y cómo lo quiere ver plasmado en un sistema de información y, por otro, que el equipo de proyecto capte de la mejor manera posible esas expectativas) y que no cambian durante el proceso de diseño y construcción.

El desarrollo de software tiene una naturaleza adaptativa, evolutiva, no predictiva y por tanto el ciclo de vida en cascada no se ajusta a ese patrón.

Por ese motivo, el primer paso que suelen dar los desarrolladores y organizaciones habituados a ese esquema de desarrollo es dividirlo en fases y convertirlos en desarrollos incrementales. El siguiente paso que se suele dar es revisar al final de cada fase las desviaciones respecto a las expectativas, de manera que se tenga en cuenta para la siguiente fase la cual además de funcionalidades nuevas tendrá los desarrollos necesarios para realizar los ajustes de la fase anterior, pasándose de esta forma a un ciclo de vida iterativo incremental.

Una vez llegado a ese punto el salto a una metodología ágil es cuestión de tiempo.