Además de hablar en siglas y comportarnos como peligrosos talibanes enfrentándonos, armados de plataformas y tecnologías aparentemente antagónicas, opuestas y hasta enemigas, las personas de sistemas nos vemos afectadas, en este momento, por una nueva ola que acabó imponiéndose como “el tema del momento”. Nos referimos a la implantación de una metodología de trabajo en nuestras empresas, ya sean consultoras de sistemas o bien otro tipo de compañías que tengan como parte de las mismas un área de sistemas.

Y he aquí, como no podía ser de otra manera, por nuestro carácter de personas combativas y leales, tenemos que elegir una y solo una de las metodologías de moda para utilizar en nuestras empresas, dando como resultado el surgimiento del Al Qaeda que tenemos dentro y dando comienzo, en forma casi encarnizada, a las luchas internas por la imposición de una metodología que sea la mejor de todas. Y aquí es donde el perro se mordió la cola…

Uno de los principales errores que tenemos las personas en general, es el querer aplicar un método de resolución de problemas que una vez usamos exitosamente, para resolver todos los problemas.

Cuando analizamos las metodologías ¨candidatas¨ a implantar en nuestros lugares de trabajo, surgen, casi automáticamente, dos tipificaciones de metodologías: las metodologías ágiles versus las metodologías duras (tradicionales). Podemos mencionar entre las primeras a XP (Extreme Programming, junto a su partner XT- Extreme Testing -) y SCRM, en tanto que dentro de la segunda categoría una de las más conocidas es CMMI.

Descripción breve de cada una de ellas

Resumiendo, CMMI es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. En la actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición.

La versión actual de CMMI es la versión 1.2. Existen, a su vez tres sabores dentro de la versión disponible:

  • CMMI para Desarrollo (CMMI-DEV o CMMI for Development), que trata sobre los procesos de desarrollo de productos y servicios de software.
  • CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), que trata sobre la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.
  • CMMI para servicios (CMMI-SVC o CMMI for Services), actualmente en borrador, está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro del sabor CMMI-DEV, existen dos modelos:

  • CMMI-DEV
  • CMMI-DEV + IPPD (Integrated Product and Process Development)

Las prácticas de CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (usando un método de evaluación conocido como SCAMPI) y recibe una calificación (o acreditación) de nivel 2-5 si sigue los niveles de madurez (se comienza ya estando en el nivel 1).

También es posible que la organización seleccione áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el “Perfil de Capacidad” de la Organización.

El modelo CMMI v1.2(CMMI-DEV) contiene las siguientes 22 áreas de proceso:

Por otro lado, la programación extrema o Extreme Programming (XP) es uno de los más conocidos procesos agiles de desarrollo de software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de los requerimientos en el ongoing de un proyecto es un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Ser capaz de adaptarse a los cambios de requerimientos en cualquier punto de la vida del proyecto es una aproximación más realista que intentar definir todos los requerimientos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requerimientos.

Los principios originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback), coraje y respeto.

Simplicidad: La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. La simplicidad también se aplica a la documentación, el código debe ser autodocumentado.

Comunicación: Para los programadores el código comunica mejor cuanto más simple sea. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad.

Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del mismo se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplan con los requerimientos y ayuda a los programadores a centrarse en lo que es más importante. El código también es una fuente de retroalimentación gracias a las pruebas unitarias que informan sobre el estado de salud del mismo.

Coraje: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje? Hay que ser valiente para confiar en que la programación de a pares beneficia la calidad del código sin repercutir negativamente en la productividad. Se requiere coraje para implementar las características que el cliente quiere en este momento sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones.

Respeto: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hagan que las pruebas existentes fallen o que demore el trabajo de sus compañeros.

Las características fundamentales del método, entonces son:

Desarrollo iterativo e incremental; Pruebas unitarias continuas; Programación de a pares; Frecuente integración del equipo de programación con el cliente o usuario; Corrección de todos los errores antes de añadir nueva funcionalidad; refactorización del código: reescribiendo ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento; y Propiedad del código compartida.

Scrum es, a su vez, un modelo de referencia que define un conjunto de prácticas y roles, que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, cuyo rol sería similar al de director de proyecto, el ProductOwner, que representa a los stakeholders y el Team que incluye a los desarrolladores.

Forma de trabajo de Scrum.

Durante cada sprint, que generalmente tiene una duración de entre 15 y 30 días (la duración la define el mismo equipo), se crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es el conjunto de requerimientos de alto nivel priorizados que define lo que se va a construir.

Los elementos del Product Backlog que formarán parte de un sprint se determinan durante la reunión de Sprint Planning. En la misma, el Product Owner identifica los elementos del Product Backlog que se construirán, dando conocimiento al equipo. De esta manera, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Un aspecto muy importante, es que durante el sprint los requerimientos permanecen congelados.

He aquí el un paneo general de los métodos. Si los analizamos a cada uno, de a uno en vez, podríamos encontrar ventajas y desventajas de cada uno y veríamos que en realidad ninguno cumple el 100% de los requerimientos necesarios para ser adaptable para llevar adelante cualquier tipo de proyectos, y así ces omo distintos métodos permiten conducir el mismo tipo de proyectos al éxito. Veamos:

  • Un proyecto que tenga los requerimientos perfectamente bien definidos y estables podría ser tanto llevado a cabo por una metodología tradicional en Cascada como por Scrum. Ahora bien, si este proyecto es grande, no solo se trata de desarrollar, se debería complementar con una administración de proyectos tipo PMI o bien una metodología tradicional como CMMi. En esta caso, Bajo el Paraguas de CMMi, las fases de Construcción y testing, (que en CMMi están consideradas dentro de las áreas de IP – Ingeniería de Producto – y de VAR y VAL – Verificación y Validación ) podrían contener varios ciclos de Scrum o Sprints.
  • Para un proyecto pequeño, cuyos desarrolladores son muy experimentados y el cliente muy accesible, podría utilizarse una metodología ágil. De acuerdo a nuestra experiencia, es muy importante el AND como operador entre estas variables. Si el cliente no puede estar presente y convertirse en un miembro activo durante el proyecto, esta metodología no podrá utilizarse con éxito. A su vez, si los desarrolladores son muy noveles, no tendrán el grado de autonomía que requiere esta metodología, e irán directo al fracaso.
    Una variante válida para el comienzo de utilización de una metodología ágil, es el crear células de trabajo (al estilo de los operadores de fábrica) donde se trabajen en grupos pequeños, con una serie de requerimientos acotados que se puedan construir también en un tiempo corto definido, que puede estimar el mismo grupo, en base a la porción de backload de requerimientos que le asigne el LP o el LT.

En este grupo, las funciones básicas que deben cumplirse son las de funcional, desarrollador y tester. La cantidad mínima de cada célula debería ser de tres personas. La persona funcional haría las tareas funcionales y de testing funcional y de integración, en tanto que las otras dos podrían ser desarrolladores, uno senior y otro junior, por ejemplo, para que, de esta forma el junior vaya tomando conocimientos.

Existen muchas más combinaciones que pueden hacerse, teniendo en cuenta los distintos aspectos de accesibilidad del cliente, seniority de los recursos, estabilidad de los requerimientos, madurez en el conocimiento de la metodología de trabajo, etc.

De la misma forma, otro aspecto interesante a explotar es el testing, entendiéndolo tanto como actividades de verificación y validación, que abarcaría, aproximadamente los siguientes tipos de test: de caja blanca, negra, de regresión, unitario, funcional, integral, de aceptación de usuario, y por qué no, hablar del último grito de la moda en Testing, el XT (Extreme Testing). Pero esto ya es material para otra nota…

 
Share This
Suscríbase a nuestras novedades

Suscríbase a nuestras novedades

¿está interesado en nuestros contenidos de ERP? Suscríbase para nuestros newsletter y no deje de estar informado.

¡Listo, ya está suscripto!