Un impedimento en Scrum es cualquier obstáculo o problema que afecta la productividad del equipo y retrasa las actividades. Estos impedimentos pueden variar desde problemas técnicos hasta barreras comunicacionales o problemas organizacionales.
ejemplos: 1. Falta de participación de los DBA (Administradores de Bases de Datos): Si los DBA no están involucrados en los ciclos de liberación, pueden surgir problemas relacionados con la base de datos durante la implementación. Por ejemplo, cambios en el esquema de la base de datos pueden afectar la funcionalidad de la aplicación.
2. Errores en el despliegue de código: Si el proceso de implementación no se realiza correctamente, pueden surgir errores en la producción. Por ejemplo, una actualización de software que no se probó adecuadamente podría causar fallos en el sistema en vivo.
En Scrum, la gestión de impedimentos es fundamental para el éxito del equipo de desarrollo. Aunque no se considera directamente parte del ciclo de desarrollo, su manejo es crucial para mantener la eficiencia y la calidad del proceso. Aquí tienes algunas consideraciones importantes:
El Scrum Master es el responsable de identificar, registrar y ayudar al equipo a superar los impedimentos2.
Cuándo se Deben Contabilizar: Aunque no se cuentan directamente como parte del ciclo de desarrollo, los impedimentos deben ser capturados y gestionados durante todo el proceso.
Los impedimentos pueden surgir en cualquier momento: durante la planificación, la ejecución o la revisión del sprint.
Impacto en el Ciclo de Desarrollo: Los impedimentos pueden afectar la entrega de requisitos y la calidad del producto.
Por ejemplo, problemas con ambigüedad en las características, falta de recursos, errores en el despliegue de código o decisiones que requieren intervención de múltiples partes interesadas.
Resolución de Impedimentos: El equipo debe trabajar en conjunto para resolver los impedimentos lo antes posible.
El Scrum Master debe ayudar al equipo a identificarlos y definir un plan para su eliminación3.
Resumen de lo que me parecio clave de una consulta o 2 ;-) con Origen: Conversación con Bing, 25/4/2024
El modelo C4 es un marco utilizado en ingeniería de software para visualizar y describir la arquitectura de sistemas de software.
Desarrollado por Simon Brown, significa
"Contexto,
Contenedores,
Componentes y
Código",
que representan diferentes niveles de granularidad para representar la arquitectura de un sistema.
Contexto
El propósito de esta sección es ofrecer una perspectiva global del sistema, destacando sus interacciones y conexiones con entidades externas como usuarios, sistema de correo electrónico y otros sistemas externos. Aquí hay algunos puntos clave:
Partes interesadas: analistas de sistemas y negocios, propietarios de productos, líderes de equipo y nuevos miembros del equipo.
Descripción general estratégica:el contexto proporciona una visión estratégica del sistema, destacando cómo encaja e interactúa con el entorno empresarial más amplio. Esta perspectiva es vital para que las partes interesadas vean el sistema no como una entidad aislada sino como parte de un proceso o ecosistema empresarial más amplio.
Aclaración de límites: al delinear las interacciones del sistema con entidades externas, el contexto aclara los límites del sistema. Esta comprensión es crucial para identificar áreas potenciales de riesgo, dependencias y puntos de integración.
Orientación para el diseño y el desarrollo:comprender el contexto guía tanto el diseño como el desarrollo del sistema. Garantiza que el sistema esté alineado con los objetivos comerciales y las necesidades de los usuarios, haciéndolo más eficaz y centrado en el usuario.
Facilita la comunicación con las partes interesadas: el contexto proporciona un lenguaje común y una comprensión para diversas partes interesadas, incluidos ejecutivos de negocios, usuarios y equipos técnicos, fomentando una mejor comunicación y alineación con los objetivos del sistema. Es un momento en el que el enfoque del Domain Driven Design se vuelve muy útil.
Ejemplo de un esquema de contexto
Contenedores
Esta sección tiene como objetivo representar las decisiones tecnológicas de alto nivel tomadas para el sistema, detallando componentes clave como servidores web, bases de datos, sistemas de archivos y otros elementos integrales que constituyen la arquitectura del sistema. Aquí hay algunos puntos clave:
Partes interesadas: desarrolladores, arquitectos, líderes tecnológicos y equipos de operaciones.
Descripción general de la arquitectura: los contenedores ofrecen una vista de alto nivel de la arquitectura del sistema, presentando las principales tecnologías y plataformas utilizadas. Esto es vital para los nuevos miembros del equipo, los socios externos o cualquier persona que necesite una comprensión rápida de la composición técnica del sistema.
Marco de toma de decisiones:comprender los contenedores ayuda a tomar decisiones informadas sobre el escalado, la seguridad y la asignación de recursos. También ayuda a evaluar el impacto de posibles cambios o adiciones a la pila de tecnología.
Evaluación de riesgos: al identificar las tecnologías clave y sus interacciones, resulta más fácil evaluar y gestionar los riesgos asociados con las opciones tecnológicas, como la dependencia de un proveedor, problemas de escalabilidad o vulnerabilidades de seguridad.
Oportunidades de optimización: esta comprensión permite identificar oportunidades de optimización, como mejorar el rendimiento, reducir costos o simplificar la pila de tecnología.
Ejemplo de un esquema de contenedor
Componentes
Esta sección está diseñada para proporcionar una comprensión más profunda de los componentes fundamentales del sistema, ilustrando los elementos principales dentro de cada contenedor y cómo interactúan entre sí. Aquí hay algunos puntos clave:
Partes interesadas: equipos de desarrollo (incluidos desarrolladores y arquitectos de software).
Información arquitectónica detallada: proporciona información detallada sobre el diseño arquitectónico del sistema, ilustrando cómo funcionan juntas las diferentes partes del sistema. Esto es fundamental tanto para mantener las funciones existentes como para planificar nuevos desarrollos. Aquí hay algunos puntos clave:
Facilita el desarrollo modular: comprender los componentes ayuda a modularizar el desarrollo, lo que permite a los equipos trabajar en diferentes partes del sistema simultáneamente sin causar conflictos o dependencias.
Mejora la calidad y la capacidad de mantenimiento: una visión clara de los componentes permite un mejor control de calidad, un seguimiento de errores más sencillo y un mantenimiento más eficiente. También ayuda a identificar partes redundantes u obsoletas del sistema que necesitan refactorización.
Base para la escalabilidad: una comprensión detallada de los componentes es esencial para escalar el sistema de manera efectiva, garantizando que cada componente pueda manejar una mayor carga y complejidad.
Ejemplo de un esquema de componente para el componente Back for Frontend
Código
Esta sección presenta la capa más detallada del sistema, centrándose en la implementación real. Por lo general, incluye diagramas UML o representaciones similares para ilustrar cómo se implementan los distintos componentes del sistema. Aquí hay algunos puntos clave:
Partes interesadas: equipos de desarrollo (incluidos desarrolladores y arquitectos de software).
Comprensión básica: proporciona el nivel más granular de comprensión, esencial para el trabajo de desarrollo diario. Ayuda a los desarrolladores a comprender exactamente cómo se implementan e interactúan las funcionalidades a nivel de código.
Mejora la resolución de problemas: con una vista detallada del código, los desarrolladores pueden solucionar problemas de manera más efectiva, optimizar el rendimiento y garantizar la calidad del código.
Facilita la incorporación y la transferencia de conocimientos: la documentación detallada del código es crucial para incorporar nuevos miembros al equipo, ayudándoles a comprender rápidamente cómo funciona el sistema a un nivel práctico.
Permite la mejora continua: comprender el código es clave para las prácticas de mejora continua, como la refactorización, ya que permite a los desarrolladores identificar áreas de mejora e implementar cambios sin efectos secundarios no deseados.
Beneficios
Claridad
Vista integral: ofrece una comprensión multinivel del sistema, lo que ayuda en la planificación estratégica y reduce los errores al resaltar posibles problemas de diseño desde el principio.
Apoyo a la toma de decisiones: mejora la toma de decisiones informadas con respecto al diseño, la tecnología y la asignación de recursos.
Comunicación
Marco unificado: crea un lenguaje común para las discusiones entre diversas partes interesadas, mejorando la colaboración y el compromiso entre los equipos.
Alineación de las partes interesadas: mejora la alineación con los objetivos y expectativas del proyecto, crucial para el éxito del proyecto.
Documentación
Registro sistemático: proporciona documentación estructurada y estandarizada, esencial para referencia, cumplimiento y mejoras futuras. Herramientas como ADR ( Architecture Decision Record ) podrían resultar muy útiles para mantener la documentación actualizada mediante una metodología detallada.
Base de conocimientos: actúa como un valioso depósito de conocimientos para capacitar y guiar a los nuevos miembros del equipo. Este es un punto muy importante. Este tipo de conocimiento podría suponer un gran ahorro de tiempo y también evitar que surjan algunas deudas técnicas.
Compensaciones
Complejidad
Sobrecarga de detalles: para sistemas grandes, capturar cada detalle puede resultar abrumador y oscurecer la comprensión general. También puede resultar excesivo para sistemas pequeños.
Riesgo de claridad estratégica: centrarse excesivamente en los detalles puede correr el riesgo de perder de vista la visión estratégica de alto nivel. Todos conocemos la tendencia que nosotros (desarrolladores y arquitectos) tenemos a realizar demasiada ingeniería solo porque es divertido y satisfactorio.
Esfuerzo
Demandas de recursos: Requiere mucho tiempo y esfuerzo para crear y actualizar periódicamente, lo que exige recursos que podrían asignarse a otros lugares. Por lo tanto, hay que calcular el retorno de la inversión (ROI), un proyecto que es sólo de corto plazo o de transición no debería requerir este tipo de inversión.
Desafío de mantenimiento: Mantener la documentación actualizada con los cambios del sistema es una tarea continua y, a menudo, que requiere muchos recursos, así que vuelva a centrarse en el retorno de la inversión.
Gestión de detalles
Dificultad de equilibrio: lograr el nivel correcto de detalle sin complicar ni simplificar demasiado es un desafío. Necesita recursos experimentados, especialmente en arquitectura.
Necesidades variadas: Adaptar la documentación para satisfacer las diferentes necesidades de las partes interesadas sin redundancia ni confusión requiere una consideración cuidadosa. Nuevamente, debe confiar en un arquitecto experimentado que pueda garantizarlo.
Conclusión
En conclusión, el enfoque estructurado de documentar y comprender los sistemas de software a través del contexto, los contenedores, los componentes y el código ofrece importantes beneficios. Esta perspectiva multinivel es crucial para una comprensión profunda del sistema, lo que ayuda en la toma de decisiones, la participación de las partes interesadas y la gestión eficaz de proyectos. Sirve como una base de conocimientos vital y un marco estandarizado para las discusiones y la alineación entre las diversas partes interesadas.
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
. 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.
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
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.
