viernes, 11 de julio de 2008

Team Skill 4: Administrando el Alcance

Es hora de seguir con los post dedicados a Managing Software Requirements - A Unified Approach de Dean Leffingwell y Don Widrig (ISBN: 0-201-61593-2). Ya conté que este libro data de 1999 (podría decirse que es un veterano en lo que respecta a Ingeniería de Software) y presenta una metodología ordenada que puede servir como guía a la hora de identificar, analizar y especificar formalmente los requerimientos de un sistema de software y que ayuda en la administración de cambios de los mismos. Para presentar los temas de una forma ordenada, Leffingwell y Widrig han dividido esta metodología en 6 Habilidades Grupales (Team Skills). En los post anteriores, ya vimos tres de estas habilidades:
  • Team Skill 1: Analizando el Problema: que básicamente se encarga de las disciplinas de Business Modeling y de entender cuál es el problema del usuario, mediante cinco pasos concretos que pueden ayudar a identificar las causas del problema, los stakeholders, las restricciones, etc.
  • Team Skill 2: Entendiendo las Necesidades del Usuario: que básicamente se encarga de suavizar tres grandes síndromes que suelen ocurrir a la hora de capturar requerimientos, mediante distintas técnicas de relevamiento propuestas.
  • Team Skill 3: Definiendo el Sistema: que habla un poco sobre cómo mediante documentos de Visión, de Especificación de Software y tal vez de Marketing, definir formalmente el Alcance del Sistema.

Lo que vamos a ver hoy, en la Habilidad Grupal que nos ocupa, es la forma que Managing Software Requirements propone para administrar el alcance definido en los Team Skills anteriores. El problema del alcance del proyecto es una dificultad común. No es inusual que los proyectos sean iniciados con el doble de funcionalidades que un equipo puede implementar con una calidad aceptable. La causa principal: los clientes quieren más, marketing quiere más y el equipo quiere más. Pero lamentablemente, cuando los tiempos apremian, debemos asegurarnos de poder entregar algo a tiempo.

Estableciendo el Baseline del proyecto

Con el fin de administrar el alcance, el libro presenta la noción de baseline, término muy usado en el mundo de la administración de proyectos. El baseline es un acuerdo para la comprensión de lo que el sistema va a hacer, un conjunto de ítems de configuración compuestos por funcionalidades o requerimientos dispuestos a ser entregados en una versión especifica de la aplicación. Si el alcance y las expectativas exceden la realidad, probablemente el proyecto esté destinado al fracaso. Después de todo, nosotros somos sólo los recursos, no los que tomamos las decisiones finales. Por lo tanto, la pregunta es: ¿Qué debe estar completado en la siguiente liberación (release), dados los recursos que estarán disponibles para el proyecto?

Como Dean Leffingwell y Don Widrig son de verdad muy técnicos y meticulosos, para llevar a cabo la definición del baseline proponen 5 pasos que pueden sernos de gran ayuda:
  • Paso 1: Armar una lista numerada de funcionalidades.
  • Paso 2: Priorizar las funcionalidades de la lista: Se puede establecer un ranking de 3 valores, por ejemplo: Crítica, Importante y Útil. Obviamente uno puede elegir la categorización que más le satisfaga, pero siempre hay que tener en cuenta que cuanto más valores tengamos, la lista será más difícil de mantener y de utilizar. (Imaginen si usáramos una escala del 1 al 10.)
  • Paso 3: Estimar el esfuerzo: Lo mismo que en el paso anterior. Como ni siquiera contamos con una WBS bien definida, seguramente las funcionalidades no estarán explotadas al nivel de detalle necesario para poder estimar con el detalle de horas. Por lo tanto, también se sugiere una escala de 3 valores como: Alto, Medio y Bajo.
  • Paso 4: Estimar el Riesgo: Lo mismo que antes: Alto, Medio y Bajo.
  • Paso 5: (si es necesario) Reducir el Alcance: Conviene que el baseline quede establecido con requerimientos críticos y uno o más importantes.

Negociando con el Cliente

Para establecer el baseline indudablemente vamos a tener que llevar a cabo algunas negociaciones. El libro menciona algunas buenas recomendaciones que el equipo puede necesitar en algunas ocasiones:
  • Empezar alto, pero no irrazonable.
  • Separar a las personas del problema.
  • Enfocarse en intereses, no posiciones.
  • Entender la posición de cierre.
  • Inventar opciones para mutuo beneficio.
  • Aplicar criterios objetivos.
  • Sub-prometer y sobre-entregar.
Leffingwell y Widrig no esperan que el proceso describa una forma en la que el desafío de definir el alcance desaparezca. Sin embargo, los pasos esbozados pueden esperar a tener un efecto material sobre el alcance del problema, permitiendo a los desarrolladores enfocarse en subconjuntos críticos e incrementar la calidad del sistema para que cumplan o superen las expectativas del usuario. Además, la participación del cliente en ayudar a resolver el problema de la administración del alcance aumenta el compromiso de ambas partes y fomenta una mejor comunicación y confianza entre el cliente y el equipo de desarrollo de la aplicación.

Con una clara definición del proyecto, o un documento de Visión en la mano, y el alcance logrado a un nivel razonable, contamos con más herramientas para encarar las siguientes fases del proyecto. Lo que sigue, el Team Skill 5: Refinando la Definición del Sistema, será en el contexto de la fase de Elaboración de un proyecto, donde toma rol protagónico la disciplina de Análisis & Diseño, continúa por supuesto la toma de requerimientos y el modelado del negocio y se comienza con la implementación del sistema.

Entradas Relacionadas