12+1 cosas que nunca deberíamos de hacercuando trabajamos con RequisitosJordi Borja – jborja@visuresolutions.com
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.                                                             2
1.- Nunca creas que negocio no sabe lo que quiere•   Negocio SÍ sabe lo que quiere. Quizá no sepa explicarlo.     – Es nue...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.          ...
2.- Nunca asumas que el rol del analista está claro•   Definir claramente la diferencia entre las actividades de Gestión d...
2.- Nunca asumas que el rol del analista está claro•   Definir claramente la diferencia entre Analista de Negocio y Analis...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
3.- Nunca esperes que el Usuario te de un buen requisito• Los usuarios tienen que explicarnos cuál es el problema que  nec...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
4.- Nunca ignores la parte social de los requisitos•   La comunicación usuario / analista es clave.     –   Disponemos de ...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
5.- Nunca consideres los requisitos …• “Completos”   –   Asegúrate de que todos los stakeholders han sido consultados.   –...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
6.- Nunca confundas pruebas con calidad• No hay peor percepción de calidad que un sistema no haga lo  deseado.• Pruebas = ...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
7.- Nunca subestimes la Definición de Requisitos. Ni la Gestión.                                                          ...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
8.- Nunca gestiones documentos. Gestiona requisitos.• Los documentos hacen difícil…   –   Acceso concurrente a diferentes ...
Agenda1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca asumas que el rol del analista está claro.3.   Nunca...
9.- Nunca creas que con CMMI ya vas a tener éxito en requisitos.                                       ProcessContexto    ...
Agenda1.    Nunca creas que negocio “no sabe lo que quiere”.2.    Nunca asumas que el rol del analista está claro.3.    Nu...
10.- Nunca creas que con desarrollos ágiles los requisitos no son importantes.          •   Los requisitos son el cimiento...
Agenda1.  Nunca creas que negocio “no sabe lo que quiere”.2.  Nunca asumas que el rol del analista está claro.3.  Nunca es...
11.- Nunca hagas dos veces el mismo trabajo.•   Define un proceso para crear catálogos de requisitos reutilizables.     – ...
Agenda1.  Nunca creas que negocio “no sabe lo que quiere”.2.  Nunca asumas que el rol del analista está claro.3.  Nunca es...
12.- Nunca compres una herramienta si no tienes proceso. Ni al revés!                                                     ...
Agenda1.  Nunca creas que negocio “no sabe lo que quiere”.2.  Nunca asumas que el rol del analista está claro.3.  Nunca es...
12+1.- Nunca creas que un mundo mejor no es posible…                                                  28
29
Próxima SlideShare
Cargando en…5
×

2012 The Requirements Week Visure Solutions Jordi Borja 12+1 cosas que no debemos hacer cuando trabajamos con requisitos

401 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
401
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Algo estamos haciendo mal.
  • 2012 The Requirements Week Visure Solutions Jordi Borja 12+1 cosas que no debemos hacer cuando trabajamos con requisitos

    1. 1. 12+1 cosas que nunca deberíamos de hacercuando trabajamos con RequisitosJordi Borja – jborja@visuresolutions.com
    2. 2. Agenda1. Nunca creas que negocio “no sabe lo que quiere”. 2
    3. 3. 1.- Nunca creas que negocio no sabe lo que quiere• Negocio SÍ sabe lo que quiere. Quizá no sepa explicarlo. – Es nuestra responsabilidad… ‒ Conocer el negocio y sus procesos. ‒ Crear el “clima” conveniente para entender sus necesidades. ‒ Identificar correctamente a todos los involucrados ‒ Aplicar técnicas para ser capaces de “entender” lo que quiere negocio. ‒ “Hablar el mismo idioma” que ellos. Validar los requisitos. ‒ No tratar de convencerles de cuáles son sus problemáticas reales. ‒ Proporcionar soluciones factibles y certificadas a sus problemáticas. ‒ Aceptar cambios en los requisitos a medida que cambien las necesidades de negocio. ‒ Proporcionar estimaciones realista. ‒ Definir un proceso maduro de Gestión y Definición de Requisitos.• Pero negocio también debe conocer sus responsabilidades. – Facilitarnos el conocimiento del negocio. – Seguir estrictamente el proceso de requisitos definido. – Ser precisos cuando proporcionen información... y proporcionarla a tiempo. – Priorizar de forma objetiva. – Estar disponibles y ser participativos durante el ciclo de vida de requisitos. – Revisar y proporcionar feedback.• 4 factores clave: CULTURA, PROCESO, TÉCNICAS Y HABILIDADES 3
    4. 4. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro. 4
    5. 5. 2.- Nunca asumas que el rol del analista está claro• Definir claramente la diferencia entre las actividades de Gestión de Proyectos e Ingeniería de Requisitos. – Diferenciemos entre: ‒ Seguimiento y Control del Proyecto. ‒ Entender las necesidades del sistema a construir y proponer una solución. – El contacto con el negocio debe ser responsabilidad de ambos roles. 5
    6. 6. 2.- Nunca asumas que el rol del analista está claro• Definir claramente la diferencia entre Analista de Negocio y Analista de Sistema – Problema vs. Solución. – Lo que hay que hacer vs. lo que es más fácil de hacer. – Primero definamos por completo el problema. Después, que el Analista de Sistema proponga alternativas de solución a ese problema. – El Analista de Negocio debe de comunicar a Negocio los pros y contras de cada alternativa 6
    7. 7. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito. 7
    8. 8. 3.- Nunca esperes que el Usuario te de un buen requisito• Los usuarios tienen que explicarnos cuál es el problema que necesitan resolver… pero no son expertos en requisitos!• ¿Qué debemos hacer? – Conseguir la implicación del usuario. – Aplicar técnicas para capturar el máximo de información. – Mantener al usuario en el ámbito del problema. – Diferenciar los que es necesario y opcional. – Asegurarnos de que lo que se pide se puede probar y hay un criterio de aceptación claro. – Capturar las necesidades de todos los stakeholders. – Verificar que no hay conflictos y en su caso, resolverlos. – Validar constantemente con el usuario que la solución que proponemos resuelve su problema. 8
    9. 9. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos. 9
    10. 10. 4.- Nunca ignores la parte social de los requisitos• La comunicación usuario / analista es clave. – Disponemos de técnicas para poder mejorar esa comunicación. – Pero son necesarias también habilidades sociales para resolver los problemas de comunicación, como…: ‒ Falta de motivación ‒ Falta de tiempo ‒ Tensiones y opiniones enfrentadas ‒ Generalización ‒ Selección ‒ Distorsión ‒ Falta de Liderazgo o Liderazgo imperante. ‒ Falta de confianza ‒ Sobrevaloración del conocimiento ‒ Alcance de acuerdos. Moderación. ‒ Falta de pensamiento analítico ‒ Comunicación oral y escrita – Algunas de estas habilidades sociales incluyen: ‒ Escucha activa ‒ Asertividad ‒ Persuasión y negociación ‒ Motivación ‒ Empatía , credibilidad y obtención de la confianza. ‒ Colaboración ‒ Compromiso ‒ Comunicación 10
    11. 11. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”. 11
    12. 12. 5.- Nunca consideres los requisitos …• “Completos” – Asegúrate de que todos los stakeholders han sido consultados. – Utiliza la técnica adecuada según el contexto. – Pregunta lo mismo de diferentes formas. – No te olvides de los requisitos no funcionales – Separa lo necesario de lo deseable.• “Aceptados” – No confíes en que alguien ha revisado un documento. – Utiliza la técnica adecuada de validación según el contexto. – Resuelve los conflictos y consigue el consenso• “Estables” – Si algo puede cambiar, va a cambiar. – El cambio no es malo. Lo importante es saber gestionarlo. – Proporciona información para poder analizar la conveniencia del cambio. 12
    13. 13. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad. 13
    14. 14. 6.- Nunca confundas pruebas con calidad• No hay peor percepción de calidad que un sistema no haga lo deseado.• Pruebas = Cumplimiento de una especificación. – ¿Pero qué ocurre si la especificación no es correcta?• Es posible probar los requisitos antes de construir los sistemas – Técnicas de validación• Es posible mejorar la calidad del sistema mejorando la calidad de los requisitos. – Ambigüedad – Verificabilidad – Justificación – Contradicción / Consistencia – Atomicidad. – …. 14
    15. 15. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión. 15
    16. 16. 7.- Nunca subestimes la Definición de Requisitos. Ni la Gestión. 16
    17. 17. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos. 17
    18. 18. 8.- Nunca gestiones documentos. Gestiona requisitos.• Los documentos hacen difícil… – Acceso concurrente a diferentes partes del mismo. – Versionado individual de los requisitos. – Acceder siempre a la última versión de la específicación – Filtrado, reordenación, clasificación. – Trazabilidad. Análisis de impacto y de cobertura. – Control de acceso. – Discusiones individuales sobre requisitos. – Uso de atributos – Workflows individuales de los requisitos. – Obtención de métricas e indicadores. – Reutilización – …• Además, incentivan… – Requisitos no atómicos. – Sobre especificación. 18
    19. 19. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos.9. Nunca creas que con CMMI ya vas a tener éxito en requisitos. 19
    20. 20. 9.- Nunca creas que con CMMI ya vas a tener éxito en requisitos. ProcessContexto AssetActual y legislativo LibraryModelosMadurez Adecuación de procesos (3.1) Mejora Desarrollo de la solución Continua Fase 3 Fase 5RequirementsCapabilityModelEvaluaciones Technical Visure Asset University Library 20
    21. 21. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos.9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.10. Nunca creas que con desarrollos ágiles los requisitos no son importantes. 21
    22. 22. 10.- Nunca creas que con desarrollos ágiles los requisitos no son importantes. • Los requisitos son el cimiento sobre el que se construye cualquier sistema. • Independientemente de la metodología que usemos, los requisitos son el factor clave de éxito. 22
    23. 23. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos.9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.10. Nunca creas que con desarrollos ágiles los requisitos no son importantes.11. Nunca hagas dos veces el mismo trabajo. 23
    24. 24. 11.- Nunca hagas dos veces el mismo trabajo.• Define un proceso para crear catálogos de requisitos reutilizables. – Los requisitos no funcionales pueden ser un buen comienzo. – Los requisitos funcionales pueden reutilizarse en… ‒ Componentes reutilizables. ‒ Familias de producto y variantes.• Mantén trazadas al catálogo de requisitos las pruebas asociadas. – Los procesos de certificación se basan en ello!• Reutiliza GRUPOS de requisitos, no requisitos individuales. – El copy/paste o la referencia no son suficientes 24
    25. 25. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos.9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.10. Nunca creas que con desarrollos ágiles los requisitos no son importantes.11. Nunca hagas dos veces el mismo trabajo.12. Nunca compres una herramienta si no tienes proceso. Ni al revés! 25
    26. 26. 12.- Nunca compres una herramienta si no tienes proceso. Ni al revés! 26
    27. 27. Agenda1. Nunca creas que negocio “no sabe lo que quiere”.2. Nunca asumas que el rol del analista está claro.3. Nunca esperes que el usuario te de un buen requisito.4. Nunca ignores la parte social de los requisitos.5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.6. Nunca confundas pruebas con calidad.7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.8. Nunca gestiones documentos. Gestiona requisitos.9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.10. Nunca creas que con desarrollos ágiles los requisitos no son importantes.11. Nunca hagas dos veces el mismo trabajo.12. Nunca compres una herramienta si no tienes proceso. Ni al revés!12+1. Nunca creas que un mundo mejor no es posible… 27
    28. 28. 12+1.- Nunca creas que un mundo mejor no es posible… 28
    29. 29. 29

    ×