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