la ingeniería de requisitos en el entorno Ágilfattocs.com/files/es/articulos/la ingenieria...

FATTO Consultoría y Sistemas - www.fattocs.com

FATTO CONSULTORIA Y SISTEMAS

GUILHERME SIQUEIRA SIMÕES

28/05/2019

La Ingeniería de Requisitos en el entorno Ágil

1


De preferencia al uso de una conexión de banda ancha

Este evento no tendrá video (webcam), solamente la presentación y audio

Si es necesario, ajuste el idioma de la sala en la barra de herramientas superior

Tendrá una duración de ~45 min. de presentación y ~15 min. finales para

preguntas

Puedes enviar tus preguntas por el chat durante la presentación

Para aquellos que poseen certificación PMP, el webinar otorga un crédito de 1

PDU

La grabación y material serán publicados posteriormente en nuestra página web

y redes sociales:

ORIENTACIONES INICIALES

2


FATTO Consultoría y Sistemas

3

Misión: “Ayudar a nuestros clientes en la planeación y evaluación

de desempeño de procesos de TI para aumentar el éxito de su

negocio.”

https://amzn.to/2PPA2xi

https://amzn.to/2PPA2xi


Agenda

La Ingeniería de Requerimientos (IREQ)

El SCRUM

El Requerimiento

Valores y principios del Manifiesto Ágil

4


La disciplina de la Ingeniería de Requerimientos consiste en un uso sistemático y repetitivo de técnicas que abarcan las actividades de

identificación, documentación y mantenimiento de un conjunto de requerimientos para el software, con el fin de que éstos cumplan con los objetivos de negocio y sean de calidad*.

¿Qué es Ingeniería de Requerimientos?

* Vease https://youtu.be/LG0KE8i-gj0

Actividades

Mantenimiento

Documentación

Obtención

Objetivos de Negocio

Técnicas Requerimientosde Software

5

https://youtu.be/LG0KE8i-gj0

FATTO Consultoría y Sistemas - www.fattocs.com6

El SCRUM

Dueño del Producto

Equipo de Desarrollo

SCRUM Master

Es un proceso de desarrollo interactivo e incremental (o creciente) para la gestión y el desarrollo de proyectos de software

Equipos multifuncionales, autoorganizados, pequeños: 3-9 personas

Ciclos de entrega cortos


Dudas…

¿Es necesario definir un alcance inicial?

¿Qué es el Product Backlog? ¿Quién lo elabora?

¿Quién descubre quienes son los interesados que deben ser

satisfechos?

¿Quién es responsable por priorizar las historias a desarrollar?

¿Quién refina las necesidades hasta el nivel de información

necesario al desarrollo?


Rol del Dueño del Producto (PO)

Responsable de maximizar el valor del producto resultante deltrabajo del Equipo de desarrollo

Es el único responsable por administrar la Lista del Producto


El product backlog

Es una lista ordenada de todo lo quese sabe que se necesita en elproducto (características, funciones,requisitos, mejoras, correcciones). Esla única fuente de requisitos paracualquier cambio que se realice en elproducto

Los requisitos nunca dejan decambiar, por lo que un ProductBacklog nunca está completo


Rol del Dueño del Producto

Gestionar la Lista del Producto es una actividad de la IREQ, yincluye (según la guía SCRUM):

Expresar claramente los elementos de la Lista del Producto;

Ordenar los elementos en la Lista del Producto para alcanzar losobjetivos y misiones de la mejor manera posible (priorizar);

Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;

Asegurar que la Lista del Producto es visible, transparente y clarapara todos y que muestra aquello en lo que el equipo trabajará acontinuación; y,

Asegurar que el Equipo de Desarrollo entiende los elementos de laLista del Producto al nivel necesario.


Roles del SCRUM y la IREQ

En un proceso tradicional, por lo general, cada rol esdesempeñado por una persona distinta. Luego, el trabajo de laIREQ se queda con alguien con un titulo como: analista derequerimientos o ingeniero de requerimientos

En SCRUM, la IREQ es responsabilidad principal del Dueño delProducto o delegada por este al Equipo de Desarrollo, que esmultifuncional. Sin embargo, al refinar un requerimiento, elEquipo de Desarrollo está ejecutando también la IREQ

Por lo tanto, es necesario que estos responsables dominenconceptos y técnicas de la IREQ


¿Requerimiento = Documentación?


Definición de Requerimiento

(1) Una condición o capacidad necesaria de un usuario para resolver un problema o alcanzar un objetivo

(2) Una condición o capacidad que debe ser atendida por un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto

(3) Una representación documentada de una condición o capacidad como en (1) o (2)

Especificación de Requerimiento

Deseo (proyecto)

Producto

Documentación de las capacidades del proyecto o producto

ISO/IEC/IEEE 24765

13


¿Requerimiento = Documentación?

¿En la vida real vamos a encontrar la especificación de requerimientos

como fiel reflejo a las condiciones o capacidades necesarias de los

usuarios?


El refinamiento del backlog

Consiste en detallar, estimar y priorizar sus ítems. La estrategia esrestringir el esfuerzo gasto para entender un requerimiento almínimo necesario para aquél momento

O sea, el requerimiento que irá ser implementado hoy tiene mayornivel de detalle que un requerimiento que será implementado en elpróximo bimestre

No es necesario refinar detalles de todos los requerimientos. Perolos más críticos o complejos necesitan de más detalles


Procesos de la Ingeniería de Requerimientos

Elicitación Análisis

Gestión

Levanta, investigael problema,

interesados y necesidades

Organiza, especifica,

verifica y valida

Administra conflictos ycambios, busca

aprobación, prioriza

Información

RequerimientosCambios

16


“Individuos e interacciones sobre procesos yherramientas.”

Comentario:

La principal fuente de requerimientos son losinteresados. La IREQ es una de las disciplinas de laIngeniería de Software donde más ocurre la interacciónentre individuos, justamente para descubrir lasnecesidades que deben ser cumplidas y comunicadas atodos. Los procesos y herramientas existen sólo paraapoyar este fin.

17

Valores del Manifiesto Ágil*

* Véase http://agilemanifesto.org

http://agilemanifesto.org/


“Software funcionando sobre documentaciónextensiva.”

Comentario:

La IREQ no define que se deba elaborar laespecificación detallada de todos los requerimientos yluego empezar el desarrollo. En verdad esto puede serun grave error.

Para que el software correcto esté funcionando, esnecesario que alguien descubra qué características sonnecesarias y comunicar esto a los desarrolladores.Documentar es una de las varias maneras de transmitireste conocimiento.

18

Valores del Manifiesto Ágil

FATTO Consultoría y Sistemas - www.fattocs.com 19

¿Requerimiento en qué nivel de detalle?

Véase https://youtu.be/cHwvkzMMfeY

Como un operador

de hotel, yo quiero

establecer buenos precios

para los cuartos en

mi hotel para

maximizar los ingresos

https://youtu.be/cHwvkzMMfeY


“Colaboración con el cliente sobre negociacióncontractual.”

Comentario:

El producto del análisis de requerimientos es laespecificación, que es un contrato entre cliente y elequipo de desarrollo, fruto de la colaboración entreambos.

20



“Respuesta ante el cambio sobre seguir un plan.”

Comentario:

¡La única certeza de los proyectos de software es quelos requerimientos cambian!

Un aspecto de calidad de una especificación derequerimientos es justamente que sea fácilmentemodificable.

21



#1: “Nuestra mayor prioridad es satisfacer al cliente

mediante la entrega temprana y continua de software

con valor.”

Comentario:

Software con valor es lo que resuelve los problemasque motivaran su desarrollo

La IREQ busca comprender las necesidades del clientepara definir el mejor conjunto de requerimientos parael software, satisfaciendo las necesidades de negocio

22

Principio #1 del Manifiesto Ágil


#2: “Aceptamos que los requisitos cambien, incluso enetapas tardías del desarrollo. Los procesos Ágilesaprovechan el cambio para proporcionar ventajacompetitiva al cliente.”

Comentario:

Un trabajo bien hecho de la IREQ disminuye “cambios”en etapas tardías. Muchos “cambios” en verdad sóloexisten para corregir equívocos en la definición originaldel alcance. No deberían existir.

Los cambios verdaderos surgen por eventos nuevos enel ambiente de negocio. Evaluar el impacto de uncambio es una de las actividades de la IREQ

23



#3: “Entregamos software funcional frecuentemente,entre dos semanas y dos meses, con preferencia alperiodo de tiempo más corto posible.”

Comentario:

La IREQ puede ser ejecutada en acuerdo a distintasestrategias de desarrollo. Trabajar con ciclos cortospermite una retroalimentación temprana de la calidaddel trabajo. Es un equívoco suponer que ejecutar laIREQ significa siempre elaborar toda la especificaciónde requerimientos a un solo golpe

24



#4: “Los responsables de negocio y los desarrolladores

trabajamos juntos de forma cotidiana durante todo

el proyecto.”

Comentario:

Trabajar junto es una estrategia clásica para aumentarel desempeño del equipo. Esto minimiza problemas decomunicación y facilita el levantamiento de losrequerimientos correctos. Además, permite que setrabaje con una especificación de requerimientosmenos detallada.

25



#6: “El método más eficiente y efectivo de comunicar

información al equipo de desarrollo y entre sus

miembros es la conversación cara a cara.”

Comentario:

De acuerdo, y este método puede ser empleadotambién en el trabajo de la IREQ

26



#10: “La simplicidad, o el arte de maximizar lacantidad de trabajo no realizado, es esencial.”

Comentario:

Un objetivo del análisis de requerimientos es identificarnecesidades similares que pueden ser mezcladas enlugar de simplemente desarrollar todo lo que essolicitado por los usuarios

El mayor merito del trabajo del responsable de la IREQes rechazar una solicitud de un interesado queresultaría en un requerimiento incorrecto (fuera delalcance)

27



La IREQ es una disciplina independiente de cualquier

tipo de proceso de desarrollo, pero necesaria a todos

ellos

El modo que se ejecuta la IREQ en un proceso

tradicional no es igual al de un proceso ágil

Aunque se cambie nombres de actividades, títulos de

quien las ejecuta, momentos en que estas son

ejecutadas y artefactos generados, la IREQ sigue

presente en todo el desarrollo

28

Conclusión


¡ENCUESTA!

29


PRÓXIMOS EVENTOS

WEBINARS:

• SCRUM: Lo que comienza bien, termina mejor - como un Product Owner

elabora un backlog de calidad y resuelve conflictos

Fecha: 02 de julio de 2019 https://bit.ly/2TcJgoY

• ¿Gestión de Riesgos: cómo manejar las incertidumbres del proyecto?

Fecha: 13 de junio de 2019 https://bit.ly/30z56I6

CURSOS SUGERIDOS:

• Ingeniería de Requerimientos: Software orientado al negocio

http://www.fattocs.com/es/ireq-ead

30

https://bit.ly/2TcJgoY

https://bit.ly/30z56I6

http://www.fattocs.com/es/ireq-ead


¿PREGUNTAS?

¡Muchas gracias por la atención!

GUILHERME SIQUEIRA SIMÕES

E-mail: [email protected]

Linkedin: https://br.linkedin.com/in/guilhermesimoes/es

Skype: guilherme.s.simoes

Whatsapp: +5527981117505

31

la ingeniería de requisitos en el entorno Ágilfattocs.com/files/es/articulos/la ingenieria...

Documents