Consejos para realizar una gestión de requisitos desde un enfoque ágil.

El resultado de un proyecto (éxito o fracaso) depende en gran parte de la adecuada definición y gestión de los requisitos de producto/servicio a desarrollar. Pero, en general, no se trata de la cantidad ni detalles de los requisitos en su especificación, más bien se trata de la adecuada realizacion de una ingeniería de requisitos eficaz, y esto lo podemos obtener desde un enfoque ágil. Esta visión se plasma en los siguientes consejos para la gestión de requisitos desde una perspectiva ágil:

Metodologia_agil

1. Especificar requisitos suficientes para que el cliente pueda validar lo que se quiere obtener y el equipo de trabajo lo entienda. Pero no todos los requisitos necesitan el mismo nivel de detalle, para algunos puede bastar solo con su nombre y para otros puede ser necesario una especificación más elaborada.
url
2. Existen dos momentos en la vida del proyecto en los que especificar requisitos: Antes de iniciar los trabajos para establecer un compromiso de entrega con el cliente, es decir, establecer el alcance, costo y plazo del proyecto, todo ello con un nivel de precisión aceptable. Y en segundo lugar para explicar al equipo qué se espera como resultado de la implementación de un requisito, cómo y cúando puede darse por satisfecha su implementación. Los requisitos son dinámicos en el tiempo y pueden caducar o perder prioridad a lo largo del desarrollo. En este sentido, trabajar a muy largo plazo no tiene mucho sentido ya que mientras más anticipadamente se detallen los requisitos, más riesgo tenemos de no rentabilizar el esfuerzo asociado y más obstáculos podríamos tener para la gestión de los cambios en el proyecto.

3. Los requisitos pueden ser especificados usando diferentes técnicas; dependiendo de la relevancia o complejidad del requisito podrían incluso mezclarse diferentes técnicas, de forma complementaria o incluso solapadas. Sin embargo se deberían realizar unas especificaciones mínimas: Visión del producto o servicio, incluyendo una breve descripción, características principales, actores, modelo de negocio, productos competidores y modelo de dominio. Requisitos funcionales del producto/servicio, plasmando en un panel, lista o diagrama de todos los requisitos, con la idea de disponer de una panorámica de los requisitos. Y por último requisitos no funcionales generales o transversales, es decir, los requisitos no funcionales asociados a un requisito funcional específico.

4. Orientarse hacia una solución mínima viable y satisfactoria para el cliente. Cuando se trata de un desarrollo a medida debemos ser bastantes estrictos respecto del alcance, plazos y costo del proyecto, y es en esta situación en la cual es más necesaria la estrategia de la solución mínima y satisfactoria. Esto no descarta que si el resultado es exitoso probablemente se encontrará apoyo para continuar mejorándo.

5. Cubrir el rol de Product Owner que represente los intereses de la parte cliente, que gestiona bien el proyecto, y que explica detalladamente al equipo lo que debe implementar. Así pues, el Product Owner ideal integra tres roles tradicionales: Cliente, Jefe de proyecto y Analista. Aunque si no se dispone de una sola persona que desempeñe adecuadamente este rol se podrían establecer a dos o más personas que de forma coordinada cubran dichos perfiles.

6. Comunicar y reforzar la Visión del producto/servicio tanto en la parte cliente como en el equipo ejecutor, el cual debe conocer las características del producto o servicio, cuál es el modelo de negocio asociado, qué competidores existen y en qué se diferencia nuestro producto. Como ya se ha dicho, el proyecto no es estático y la visión del producto o servicio puede ir cambiando durante el desarrollo del mismo, con lo cual también es importante informar dichos cambios a los miembros del equipo. Se esta manera todos los participantes en el desarrollo podrán discriminar de forma eficaz entre unos requisitos y otros, para esto es imprescindible que conozcan la visión del producto de manera correcta.

7. Los requisitos no son estáticos, pueden cambiar durante el desarrollo o el mantenimiento de un producto. Los cambios pueden referirse a añadir, modificar e incluso eliminar requisitos, pero además, pueden existir cambios de prioridad en la implementación de los requisitos cuando aparezcan las desviaciones de expectativas del cliente con respecto del producto o servicio resultante. El cambio tradicionalmente es visto como algo negativo, sin embargo, en el enfoque ágil el cambio es algo natural, a lo cual no debería existir más resistencia que la comprensión y justificación del cambio, en lugar de ignorar o resistirse al cambio hay que gestionarlo de forma eficaz.

Como conclusion y recomendación general es aplicar un enfoque ágil para la gestión de requisitos. Es indudable que en cualquier desarrollo de producto o servicio la gestión de requisitos es esencial. En el enfoque ágil la gestión de requisitos no está aislada en el tiempo al inicio de los trabajos, no es un conjunto de actividades que se dan en un determinado momento y que como resultado  dan una especificación de requisitos. En el enfoque ágil, la gestión de requisitos está integrada y evoluciona junto a la planificación y desarrollo del proyecto, se realiza a lo largo de toda la ejecución y está condicionada por el modelo de proceso, sea este incremental (incremental sin Sprints) o iterativo e incremental (incremental con Sprints). Podríamos señalar algunas características y beneficios que introducen realizar un enfoque ágil:

  • El cliente debe estar continuamente participando en la especificación de requisitos y/o en mejoras a los requisitos ya implementados.
  • No es imprescindible identificar y detallar todos los requisitos al inicio, pueden cambiar y evolucionar en el tiempo.
  • Hay que involucrar tanto a clientes, como al equipo de trabajo en la definición de requisitos, y lo principal es transmitir y dejar claro la visión del producto/servicio a todas las partes.
  • Debido a que los requisitos podrían cambiar hay que gestionar adecuadamente esos cambios. Esta gestión de alcance es muy continua y se esperan cambios y ante cada cambio habrá que gestionar el alcance del proyecto.

Fuentes:
http://agilismoatwork.blogspot.com.es/2014/11/8-consejos-para-realizar-una-gestion.html

Anuncios
Tagged with: , ,
Publicado en Uncategorized

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Sígueme en Twitter (@guercano)
Calendario
noviembre 2014
L M X J V S D
« Oct   Dic »
 12
3456789
10111213141516
17181920212223
24252627282930
A %d blogueros les gusta esto: