Esta entrada nace como parte del trabajo final de la asignatura de Ingeniería de Requisitos de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.
El objetivo de esta entrada es analizar el Proceso de Requisitos de Software que se esta llevando en mi organización desde el punto de vista de la Ingeniería de Requisitos propuesta por Klaus Pohl.
Contexto del Proceso de Requisitos de Software.
La Organización.
La organización para la que trabajo es una de las empresas de software más grande de Colombia, cuyo propósito de negocio es transformar la forma de hacer negocios de sus clientes, a través de sus servicios de Consultoría en Tecnologías de la Información y Fabrica de Software.
La información aquí expuesta, no viola ningún acuerdo de confidencialidad puesto que esta información se encuentra en el Portal Web de la organización a la cual me refiero.
Esta organización tiene casi 20 años de experiencia en el mercado nacional e internacional; cuenta cerca del 1500 empleados, y tiene presencia en cerca de 9 países.
El perfil de los clientes, se puede resumir en dos palabras: GRANDES y RELEVANTES. Estos clientes, son las empresas más relevantes en sus respectivos sectores de mercado en cada uno de los países donde la organización tiene presencia.
Debido a lo anterior y a la necesidad de diferenciarse de la competencia, la organización ha aplicado las mejores prácticas y metodologías que han surgido durante los años. Como resultado de esto, la organización esta certificada en ISO 20000 y valorada en CMMI-DEV Nivel 5; y pone en practica los lineamientos de estándares internacionales como COBIT, ITIL, PMI, entre otros.
Actualmente, la organización esta en un proceso de adopción e institucionalización de las metodologías Ágiles; esto con el fin adaptarse a las exigencias actuales del mercado.
Scrum, al ser una metodología Ágil se encuentra fuertemente inspirada y adherida a los valores y principios del Manifiesto Ágil. Adicionalmente, es común aplicar los principios y practicas recomendadas por otras metodologías ágiles como Extreme Programming y Lean Software Development.
Antecedentes del Proceso de Desarrollo de Software.
El proceso de desarrollo de software que se lleva a cabo en la organización esta basado en la metodología Scrum con unos ligeros toques de Disciplined Agile Delivery.
Scrum, al ser una metodología Ágil se encuentra fuertemente inspirada y adherida a los valores y principios del Manifiesto Ágil. Adicionalmente, es común aplicar los principios y practicas recomendadas por otras metodologías ágiles como Extreme Programming y Lean Software Development.
De estos principios y valores, los que se relacionan más estrechamente con la Ingeniería de Requisitos son:
De los Valores del Manifiesto Ágil
- Valorar más a los individuos y su interacción que a los procesos y las herramientas
- Valorar más el software que funciona que la documentación exhaustiva
- Valorar más la colaboración con el cliente que la negociación contractual
- Valorar más la respuesta al cambio que el seguimiento de un plan
De los Principios del Manifiesto Ágil
Estos principios y valores limitan y fortalecen la Ingeniería de Requisitos, haciendo que se concentren sus actividades únicamente en aquellas cosas que generen valor al negocio.
El Proceso de Requisitos de Software.
- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
- Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
- Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
- El software que funciona es la principal medida del progreso.
- La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
- Eliminar el Desperdicio
- Decidir lo importante e irreversible lo mas tarde posible
Estos principios y valores limitan y fortalecen la Ingeniería de Requisitos, haciendo que se concentren sus actividades únicamente en aquellas cosas que generen valor al negocio.
El Proceso de Requisitos de Software.
El proceso de desarrollo de software que se lleva a cabo en la organización plantea varias actividades relacionadas con la Ingeniería de Requisitos. Así el Proceso de Requisitos de Software que se realiza constaría de:
- Durante la Inception, de los siguientes resultados:
- Documentos Iniciales del Proyecto
- Capacitación Metodológica
- Alcance y Visión
- Impact Mapping
- Story Mapping
- Ambientes disponibles
- Definición de la Arquitectura
- Product Backlog
- Durante cada Sprint, del trabajo constantemente en la expansión, reducción y refinamiento del Product Backlog.
- Durante cada Sprint, del trabajo realizado en el Sprint Planning con el cliente.
- Durante cada Sprint, del trabajo realizado en el Sprint Review con el cliente.
El papel del Product Owner.
Dentro del Proceso de Requisitos de la organización, el Product Owner es el líder del producto a construir. Es el principal interlocutor entre el equipo de desarrollo y los stakeholder; y tiene toda la responsabilidad del éxito del producto que se esta construyendo. Es la única autoridad que indica que características y que funcionalidades se van a construir; y en que orden.
El Product Owner es una voz unificada de los stakeholders de cara al equipo de desarrollo.
Los requisitos son manifestados, principalmente, por medio de Historias de Usuario. Estas historias son apiladas en un artefacto denominado Product Backlog. Esta pila de historias son ordenadas acorde a diversos criterios definidos por el Product Owner.
Los criterios de priorización pueden variar, pero principalmente se toma el concepto de Valor de Negocio, como el criterio de diferenciación y priorización de las historias. Se colocan las historias con mayor Valor de Negocio en la parte superior de la pila, y las de menor valor en la parte inferior.
Así las historias de usuario se van construyendo siguiendo este orden y priorización. Este orden podrá cambiar en cada Sprint, pero la idea general se mantiene.
El Product Owner es un rol que trabaja diariamente en el desarrollo, recopilación y priorización de las Historias de Usuario. Mantiene una comunicación constante con el equipo de desarrollo, proporcionándoles retroalimentación constante acerca del trabajo realizado y por realizar.
El problema del Product Owner.
A pesar de las ventajas del rol de Product Owner dentro del Proceso de Requisitos de la organización, este rol presenta varios retos a tener en cuenta:
- La persona asignada a este rol tiende a estar del lado del cliente: En el contexto de la organización, el Product Owner siempre estará del lado del cliente. Esto hace que siempre se deba hacer un esfuerzo de capacitación constante en el rol de Product Owner a la persona seleccionada.
- La persona asignada a este rol tiende a ser alguien que conoce a fondo el negocio del cliente: El Product Owner siempre será alguien que conoce a fondo el negocio del cliente. Será una persona que tiene la visión clara de lo que el producto será y no será. Sin embargo, esta persona siempre desconocerá las restricciones en políticas, procesos y tecnologías del área de TI.
- La persona asignada a este rol se puede convertir en un cuello de botella: El Product Owner será la persona que marcará el ritmo del proyecto. Si el Product Owner esta dedicado al 100% al proyecto, siempre tendrá Historias de Usuario listas para ser estimadas y desarrolladas. De lo contrario se corre el riesgo que la velocidad de trabajo del equipo de desarrollo sea superior a la velocidad de trabajo del Product Owner, haciendo que el equipo se quede sin Historias de Usuario para estimas y desarrollar.
- La persona asignada a este rol se convierte automáticamente en un factor critico de éxito: El desempeño del Product Owner determinará si el producto tiene éxito o no. Al esta la persona que tiene la visión clara de lo que el producto será y no será; la ausencia de esta persona será un impedimento significativo en el proyecto.
- La persona asignada a este rol tiende a no representar a todos los stakeholder: El Product Owner siempre sera alguien del lado del cliente que conoce a fondo el negocio. Sin embargo, puede pasar por alto las necesidades de negocio de otras áreas de negocio que podrían estar involucradas indirectamente en el proyecto.
Todos estos retos se pueden resumir en el siguiente: La persona asignada a este rol no está capacitada en la Ingeniería de Requisitos. Dada la naturaleza de negocio del Product Owner, siempre se correrá el riesgo que pase por alto practicas, actividades, técnicas y artefactos de la Ingeniería de Requisitos.
Comparación del Proceso de Requisitos Vs. el Framework de Ingeniería de Requisitos de K. Pohl.
Al comparar el Proceso de Requisitos que se maneja en la organización con el Framework de Ingeniería de Requisitos propuesto por K. Pohl, se evidencia lo siguiente:
Desde el punto de vista de las metodologías Ágiles, el Proceso de Requisitos cubre perfectamente las perspectivas de Uso del Contexto y Sujeto del Contexto. Los requisitos de estas perspectivas son manejados por el Product Owner.
Dentro de cada una de estas, las actividades se cubren así:
- Educción de Requisitos: Dada la naturaleza del Product Owner, este tiene todo el conocimiento y habilidades para educir satisfactoriamente los requisitos.
- Documentación de Requisitos: El Product Owner convierte los requisitos en Historias de Usuario. De esta forma se esta aplicando un Patrón Sintáctico para reducir la ambigüedad de los requisitos.
- Negociación de Requisitos: Por definición, toda Historia de Usuario debe ser negociable. Así mismo, el proceso de desarrollo de software determina si la historia es implementable o no. En caso de no serlo se realiza un refinamiento a fondo de esta historia.
- Validación de Requisitos: Por proceso de desarrollo de software, periódicamente (al menos 1 vez por Sprint) se refinan las Historias de Usuario con el fin de disminuir su ambigüedad. De aquí se realizan lecturas basadas en perspectivas para crear los Casos de Prueba y la actualización de la Definición de la Arquitectura. También se realizan validaciones por medio de prototipos en el Sprint Review.
- Gestión de Requisitos: Por proceso de desarrollo de software, el Product Owner es el responsable de la gestión del Product Backlog. Adicionalmente, el Product Owner es responsable por el constante contacto con los stakeholder y el equipo de desarrollo; sincronizando la información que viaja entre estos.
Por otro lado, el Proceso de Requisitos también cubre parcialmente las perspectivas de TI del Contexto y la perspectiva de Desarrollo de Software del Contexto. Se presenta el caso en que los requisitos de estas perspectivas no son manejados por el Product Owner, sino por el Arquitecto de Software.
Al ser estas perspectivas y actividades parcialmente cubiertas, es aquí en donde se presentan las oportunidades de mejora para estas perspectivas.
Es así que dentro de cada una de estas perspectivas las actividades se cubre de la siguiente manera:
- Educción de Requisitos: Dada la naturaleza del Arquitecto de Software, este tiene todo el conocimiento y habilidades para educir satisfactoriamente estos requisitos de los stakeholder pertenecientes a estas dos perspectivas. Así mismo, se analizan las Historias de Usuario arquitecturalmente significativas. Sin embargo, hace falta un formalismo mas explicito para la educción de restricciones y atributos de calidad.
- Documentación de Requisitos: Las restricciones de Arquitectura y Tecnología y los Atributos de Calidad, con sus respectivos escenarios, son documentados en el documento de Definición de Arquitectura. Los mecanismos para lograr que estos escenarios se cumplan no se escriben como Historias de Usuario. Adicionalmente hacen falta mecanismos que permitan guiar el diseño del sistema.
- Negociación de Requisitos: Estos requisitos al no estar escritas como Historias de Usuario, no se consideran negociables dentro de la metodología. Estos requisitos restringen la forma en que hará el desarrollo.
- Validación de Requisitos: Estos requisitos se validan de forma estática por parte el Comité de Arquitectura de la organización; y por el Arquitecto de Software del lado del cliente.
- Gestión de Requisitos: Debido a que estos requisitos no forman parte como tal del proceso (al no ser Historias de Usuario), no se hace evidente su gestión directa, o al menos la necesidad de gestionarlos directamente. Se gestionan a partir del análisis de las Historias de Usuario arquitecturalmente significativas.
No hay comentarios:
Publicar un comentario