miércoles, 6 de marzo de 2024

Scrum no ha muerto, solo no se justifico el proyecto

Por que vemos a Scrum morir en empresas, pues por q no fueron formales y disciplinados en el momento de evaluar para que y donde aplicarian scrum. Scrum no es una bala de plata que mate a todos los lobos ;-) Algunas de las herramientas que se utilizan para valorar y evaluar la justificación del negocio, así como otros aspectos relacionados a la justificación y selección del proyecto. No es necesario, ni se recomienda utilizar todas las técnicas disponibles para cada proyecto. Algunas técnicas no son apropiadas dependiendo del proyecto específico y también se pueden utilizar para evaluar los

Tampoco se aborda la (4.5.2 )Planificar para el valor. 
Después de justificar y confirmar el valor de un proyecto, el Product Owner debe considerar las políticas de la organización, los procedimientos, las plantillas y las normas generales dictadas por el Scrum Guidance Body (o el puesto similar o una junta organizacional del proyecto) en la planificación de un proyecto; y a la vez, maximizar la entrega basada en valor. La planificación para el valor es la justificación y confirmación del valor del proyecto. La responsabilidad de determinar cómo se crea valor recae en los stakeholders (patrocinadores, clientes y/o usuarios), mientras que el Equipo Scrum se concentra en lo que se habrá de desarrollar. Algunas de las herramientas comunes recomendadas por un Scrum Guidance Body pudieran ser las siguientes:
1. Mapa de flujo de valor (Value Stream Mapping) El mapa de flujo de valor utiliza diagramas de flujo para ilustrar el flujo de información necesaria para completar un proceso. Esta técnica pudiera utilizarse para racionalizar un proceso ayudando a determinar los elementos que no aportan valor. 
2. Priorización basada en el valor para el cliente (Customer Value-based Prioritization) La priorización basada en el valor para el cliente le da importancia primordial al cliente y se esfuerza primero en implementar las historias de usuario con más alto valor. Dichas historias de usuario de alto valor se identifican y se colocan en la parte superior del Backlog Priorizado del Producto.

Quieres conocer mas , solicita la guia SBOK en www.opensourcepyme.com/conectate

jueves, 22 de febrero de 2024

Scrum estara muerto ? que dicen la AI

 

ChatGPT 

. Aquí están cinco posibles razones por las cuales algunas personas podrían argumentar que Scrum ha "muerto" como enfoque de gestión de proyectos:

1. **Rigidez en su implementación**: Algunas organizaciones implementan Scrum de manera muy rígida, siguiendo las reglas al pie de la letra sin adaptarlas a las necesidades específicas del proyecto o equipo. Esto puede llevar a una falta de flexibilidad y dificultades para la adaptación a cambios inesperados.

2. **Falta de enfoque en la calidad**: En algunos casos, la presión por entregar incrementos de producto en intervalos cortos de tiempo puede conducir a una menor atención a la calidad. Si los equipos se centran únicamente en cumplir con los plazos y no prestan suficiente atención a la calidad del trabajo realizado, esto puede llevar a problemas a largo plazo.

3. **Escalabilidad limitada**: Aunque Scrum es adecuado para equipos pequeños y medianos, algunas organizaciones encuentran desafíos al intentar escalar Scrum para proyectos más grandes o equipos distribuidos. La gestión de múltiples equipos trabajando en conjunto puede volverse complicada y requerir la implementación de prácticas adicionales.

4. **Falta de enfoque en la planificación a largo plazo**: Scrum se centra en la entrega incremental y en ciclos cortos de desarrollo, lo que a veces puede resultar en una falta de atención a la planificación a largo plazo y a la visión general del proyecto. Si los equipos no tienen una clara comprensión de los objetivos a largo plazo y cómo se alinean con las entregas incrementales, esto puede conducir a desviaciones del camino deseado.

5. **Cultura organizacional incompatible**: En algunas organizaciones, la cultura existente puede no ser compatible con los valores y principios ágiles que sustentan Scrum. Esto puede resultar en resistencia al cambio, falta de apoyo de la alta dirección o dificultades para implementar prácticas ágiles de manera efectiva.

Es importante recordar que Scrum, al igual que cualquier otro marco de gestión de proyectos, no es una solución universal y puede no ser adecuado para todas las situaciones. Su éxito depende en gran medida de cómo se implementa y adapta a las necesidades y contextos específicos de cada organización y proyecto.





martes, 13 de febrero de 2024

Tipos de arquitecturas de software

 Eleve sus conocimientos sobre arquitectura de software! 🏗️


¿Le apasiona crear soluciones de software robustas y escalables? ¡Sumérgete en el mundo de los estilos de arquitectura de software y potencia tu experiencia tecnológica! 💡

🌟Explora las complejidades de:

1️⃣Microservicios: desbloquee la agilidad y la escalabilidad dividiendo su aplicación en pequeños servicios que se pueden implementar de forma independiente.

2️⃣Maestro-Esclavo: Aproveche el poder de la computación distribuida con un modelo jerárquico en el que un nodo maestro controla varios nodos esclavos.

3️⃣Basado en eventos: adopte la comunicación asincrónica y la c


apacidad de respuesta en tiempo real mediante el diseño de sistemas en torno a eventos y controladores de eventos.

4️⃣Arquitectura en capas: Logre modularidad y facilidad de mantenimiento organizando su software en capas lógicas, cada una responsable de un aspecto específico de la funcionalidad.

5️⃣Orquestación: coordine y gestione sin problemas flujos de trabajo complejos e interacciones entre servicios para una ejecución optimizada.

6️⃣MVC (Modelo-Vista-Controlador): Esfuércese por la claridad y la separación de preocupaciones estructurando su aplicación en tres componentes interconectados para un desarrollo y mantenimiento eficientes.

Y algunos Otros mas en la Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7163039255466819584?utm_source=share&utm_medium=member_desktop 

lunes, 5 de febrero de 2024

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 

lunes, 29 de enero de 2024

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.


martes, 2 de enero de 2024

¿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