Historias de usuario y casos de uso , los mejores amigos

Los casos de uso NO han pasado de moda (aunque se utilicen poco en los últimos años) y se ha intentado reemplazarlos en gran medida por historias de usuarios en proyectos ágiles. Sin embargo, las dos técnicas pueden coexistir y complementarse.

Los casos de uso ofrecen varias ventajas de las que carecen las historias de usuarios. Este artículo describe algunos de los muchos beneficios que pueden proporcionar los casos de uso y por qué todo analista de negocios (BA), propietario de producto (PO) y equipo de desarrollo de software debería incluirlos en su kit de herramientas.

¿Qué es un caso de uso?

Esta definición proviene del inventor de los casos de uso, Ivar Jacobson: "Un caso de uso son todas las formas de utilizar un sistema para lograr un objetivo particular para un usuario particular". Esta definición concisa incluye tres ideas importantes:

Centrándose en los objetivos que un usuario tiene en mente al utilizar un producto.

Reconocer que existen múltiples clases de usuarios , cada uno de los cuales podría tener diferentes casos de uso que el BA o el PO deben obtener, comprender y abordar.

Indicando que puede haber múltiples caminos relacionados (escenarios) mediante los cuales un usuario podría lograr el resultado deseado.

Los casos de uso son una poderosa herramienta de obtención de requisitos para descubrir y explorar las transacciones valiosas para el usuario que una solución debe proporcionar. Cada vez que un usuario interactúa con un producto, tiene una intención en mente, algo que desea lograr. Cuando un participante de la elicitación dice “Quiero [hacer algo] ” o “Necesito [hacer algo] ”, probablemente [hacer algo] sea un caso de uso.

Fuente: https://medium.com/analysts-corner/use-cases-the-business-analysts-best-friend-375e06a7e428 

Guia de Scrum org version 2017, especial para el desarrollo de software ;-)

 Para los desarrolladores de software, es claro que la guia 2020 de scrum.org es mas generalizada que para cualquier tipo de proyecto o desarrollo.

pues en ultima pagina : "Simplificación general del lenguaje para una audiencia más amplia" La Guía Scrum 2020 ha hecho hincapié en eliminar declaraciones redundantes y complejas, así como en eliminar cualquier inferencia restante al trabajo de TI (por ejemplo, pruebas, sistema, diseño, requisito, etc.).

En cambio en la guia 201

7 , si explica la complejidad del desarrollo de software ;-) pues la palabra requisito (aplicada a la ingeniería de software), se menciona  veces : 

1. Las decisiones del Dueño de Producto se reflejan en el contenido y en la priorización de la Lista del Producto. Nadie puede forzar al Equipo de Desarrollo a que trabaje con base en un conjunto diferente de requisitos. 

2. La Lista de Producto es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto (x2). El Dueño de 

3. Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación

4. La Lista de Producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre el producto para entregas futuras.

5. Los requisitos nunca dejan de cambiar así que la Lista de Producto es un artefacto vivo.

Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en la Lista de Producto.

¿Más daño que bien? Sobre métricas DORA y las encuestas en entornos DevOps

 El primer defecto se refiere a cómo se ha llevado a cabo la recopilación de datos. Los informes DORA State of DevOps han utilizado encuestas a ingenieros de software para recopilar datos, y el marco DevEx afirma: "Las encuestas, en particular, son una herramienta crucial para medir DevEx".

Sin embargo, la investigación a nivel poblacional ha puesto de relieve profundas fallas en el uso de encuestas para evaluar el desempeño cuando se realizan a nivel de equipo u organización, donde estas fallas no se pueden gestionar de manera efectiva.

Los datos recopilados de una investigación realizada por Survation para la firma de auditoría de software Engprax han descubierto que las encuestas subjetivas a menudo dan como resultado autoevaluaciones infladas en las que el 94% de los ingenieros de software califican su desempeño laboral como promedio o superior. Los hombres tienen un 26% más de probabilidades que las mujeres de considerarse mejores que los trabajadores promedio. Un estudio histórico fue consistente con esto y encontró que los ingenieros de software tienden a sobreestimar su desempeño, con hasta un 42% calificándose a sí mismos en el 5% superior.

Además, “aquellos con menos conocimientos de programación” tienen más probabilidades de ser demasiado optimistas a la hora de evaluar el rendimiento de la entrega de software en proyectos grandes.

Esta positividad no se extiende a la administración: los ingenieros de software tienen casi un 17% más de probabilidades, en promedio, de estar de acuerdo en gran o moderada medida en que otros gerentes en la industria son generalmente buenos en comparación con los suyos.

Esta investigación también ha puesto de relieve otras barreras que impiden que los ingenieros hablen. Tanto la mayoría (75%) de los ingenieros de software que hablaron sobre algo que habían visto en el trabajo informaron haber enfrentado represalias, como la mayoría (59%) de los que no lo hicieron dijeron que no lo hicieron por temor a represalias. .

La investigación también ha puesto de relieve el riesgo de excluir a los ingenieros de software cuando se utilizan estas prácticas. Casi uno de cada tres (31%) no sintió que sus logros en el trabajo fueran bien celebrados en absoluto o sólo “en pequeña medida”. Casi uno de cada cuatro ingenieros de software dice que no puede asumir riesgos calculados sin temor a consecuencias negativas, esta investigación ha puesto de relieve los desafíos de utilizar este tipo de encuestas en entornos de equipo.

A menudo, cuando las encuestas se utilizan en un entorno de equipo, quienes las realizan notarán que a medida que se realizan mejoras (los resultados empeoran a medida que el equipo se siente psicológicamente más seguro para informar fallas), lo que demuestra cómo estas métricas no logran cuantificar correctamente el verdadero estado de las cosas.

Fuente:https://dzone.com/articles/more-harm-than-good-on-dora-metrics-space-and-deve

Diagrama de Contexto, comienza a explorar el sistema

 Un diagrama de contexto es una representación visual de la relación entre elementos, datos,  procesos de negocio y el sistema.

Este diagrama tiene 3 componentes principales que incluyen entidades externas, procesos del sistema y flujos de datos. Proporciona los factores y eventos que debe considerar al desarrollar un sistema. Con él, podrá determinar el alcance, los límites y los requisitos del sistema

Todos los diagramas muestran símbolos particulares según sus usos.

Entidad externa: un elemento en el diagrama del sistema que ingresa datos en el sistema de información y recupera datos procesados.

Proceso- se refiere a todo el proceso del sistema. Este se encarga de procesar y distribuir información a las entidades del diagrama de contexto del sistema.

Línea de flujo: este elemento representa el flujo de datos dentro del sistema. Está respaldado por texto para mostrar qué tipo de datos se envían.

Fuente: https://gitmind.com/context-diagram.html

 

Que son los requisitos en el desarrollo de software ;-) Segun Bing

 Los **requisitos en el desarrollo de software** son una descripción de lo que un programa de software en particular debe hacer. Son las pautas para que los desarrolladores creen un producto funcional que satisfaga las necesidades de los usuarios². Los requisitos son críticos en el mundo del desarrollo de software y aplicaciones, ya que definen la funcionalidad y el propósito de una pieza particular de software o aplicación¹. 

Generalmente, hay dos tipos de requisitos en el desarrollo de software y aplicaciones: **funcionales** y **no funcionales**. Los requisitos funcionales especifican lo que debe hacer un sistema, mientras que los requisitos no funcionales especifican cómo debe comportarse el sistema¹. 

Los requisitos son esenciales para el alcance de un proyecto. Ayudan a determinar qué características estarán en el producto final, cuánto tiempo llevará desarrollar esas características y cuánto costará¹. Además, los requisitos también ayudan a identificar los riesgos al principio del proceso de desarrollo y, dependiendo de la metodología que esté utilizando, ahorrando tiempo y dinero considerables más adelante¹. 

Los requerimientos de software proporcionan la base para las pruebas prácticas. Al tener un conjunto completo y bien documentado de requerimientos, los ingenieros de software pueden crear casos de prueba que cubren todos los aspectos del software que están desarrollando. Las pruebas ayudan a garantizar que el producto final cumpla con todas las expectativas del cliente¹.

Espero que esto haya sido útil. ¿Hay algo más en lo que pueda ayudarte?

Origen: Conversación con Bing, 26/12/2023

(1) Requerimientos en el desarrollo de software y aplicaciones. https://bing.com/search?q=que+son+los+requisitos+en+el+desarrollo+de+software.

(2) Requerimientos en el desarrollo de software y aplicaciones. https://www.northware.mx/blog/requerimientos-en-el-desarrollo-de-software-y-aplicaciones/.

(3) Cómo definir los requerimientos de un proyecto de software. https://rootstack.com/es/blog/como-definir-los-requerimientos-de-un-proyecto-de-software/.

(4) Comprender los requisitos en el proceso de desarrollo de software. https://fwctecnologia.com/es/blog/post/%20requisitos%20del%20proceso%20de%20desarrollo%20de%20software.

biblioteca de libros gratis

 https://archive.org/

Internet Archive es una biblioteca sin fines de lucro con millones de libros, películas, software, música, sitios web y más gratuitos

Como mejorar los resultados del equipo, mejorando las retrospectivas

comenzar reflexionando sobre la directriz principal del espacio, propuesta por de Norm Kerth: "Independientemente de lo que descubramos, entendemos y realmente creemos que todos hicieron el mejor trabajo que pudieron, dado lo que sabían en ese momento, sus habilidades y destrezas, los recursos disponibles y la situación en ese momento"

Premisa: los datos deben direccionar la retrospectiva, sino se analizan datos y hechos solo estan promoviendo mejoras cosméticas ;-) 

Accion 1: Redactar planes de mejora en términos de acciones concretas específicas (no metas) que el equipo pueda medir objetivamente para evaluar si el equipo está aplicando el cambio de proceso. Primero, mida para ver si el equipo está siguiendo la acción planificada.

En segundo lugar, medir el cambio en el rendimiento para evaluar si el kaizen tuvo los resultados deseados.

Dentro de una retrospectiva, haga lo siguiente:

1.       Examine las mejoras comprobables anteriores para ver si el equipo realmente las hizo y si tuvieron un impacto positivo.

2.       Para cada mejora propuesta, pregunte cómo validará el equipo la mejora (cómo sabe si el equipo tomó la acción planificada y en qué medida).

3.       Si no puedes validar la mejora propuesta, no la aceptes.

Para medir si una acción de mejora realmente funciona, necesita un medidor, una escala y una línea de base del rendimiento actual

Accion 2: "Necesitan poner el kaizen en el backlog. Necesitan usar Scrum para mejorar Scrum". 

Identifique el impedimento más importante en la Retrospectiva del Sprint y elimínelo antes del final del siguiente Sprint. Para eliminar el impedimento de máxima prioridad, colóquelo en el trabajo pendiente del sprint como una tarea con pruebas de aceptación (consulte Mejoras comprobables) que determinarán cuándo está terminado. Tener cuidado sino ha analizado adecuadamente la dinámica del sistema y no ha entendido la causa raíz de la disfunción principal, no estara atacando el problema sino un sintoma :-) 

fuentes: 

scrumbook.org.datasenter.no/retrospective-pattern-language/testable-improvements.html

scrumbook.org.datasenter.no/retrospective-pattern-language/scrumming-the-scrum.html