055.1 Lección 1
Certificación: |
Open Source Essentials |
Versión: |
1.0 |
Tema: |
055 Gestión de Proyectos |
Objectivo: |
055.1 Modelos de desarrollo de software |
Lección: |
1 de 1 |
Introducción
La vida está llena de proyectos. Un proyecto podría ser planificar una noche de cine, un viaje o un evento familiar, programar la semana de los niños o mejorar su trabajo en un pasatiempo. No importa lo que quieras llevar a cabo: necesitas hacer planes y tomar acciones. Normalmente creamos varios escenarios, acompañados de un plan B, plan C, etc. Esto no es diferente en el mundo del desarrollo de software.
Roles en el desarrollo de software
Se necesita una variedad de habilidades para una gestión exitosa de proyectos, por lo que es útil encontrar diferentes personas para desempeñar roles bien definidos. Las siguientes secciones describen algunas de las funciones que se encuentran comúnmente en proyectos de software.
Gerente de Proyecto
Gestionar un proyecto es una tarea muy compleja. Algunas situaciones parecen fáciles al principio, pero se necesita cuidado y experiencia para resolverlas correctamente. La persona que hace esto es conocido como el gerente de proyecto.
Las responsabilidades del gerente de proyecto incluyen garantizar que el proyecto se termine a tiempo, dentro del presupuesto y con una calidad aceptable. Incluso si no escriben una sola línea de código, los gerentes de proyecto son los que son responsables y rinden cuentas de los resultados del equipo. Tienen que alinearse con los clientes en cuanto a los plazos. También hablan con las personas que desempeñan otros roles para asegurarse de que todo esté en orden.
Analista de negocios e ingeniero de requisitos
No hay lugar para la microgestión, al menos no en un lugar de trabajo saludable. Los analistas de negocios (BA) y los ingenieros de requisitos (RE), internos o externos al equipo del proyecto, son la mano derecha de los directores de proyecto. Son responsables de crear documentación concisa y clara sobre los requisitos. También son el puente entre los clientes y los desarrolladores. Los clientes se comunican a través de un lenguaje sencillo, que BA/RE garantiza que proporcionará documentación clara e inequívoca con la que los desarrolladores podrán realizar su trabajo de forma eficaz.
Imagínese que le piden que traiga un “gran pastel” a una fiesta. ¿Qué significa “grande”? ¿Diez rebanadas o veinte? Quizás sea el pastel de una gran boda y deberían ser cien porciones. El BA/RE tiene que especificar requisitos tales como cantidades exactamente, de modo que los desarrolladores sepan, por ejemplo, que una aplicación está diseñada para un número específico de usuarios.
Estamos apenas comenzando a definir los requisitos, pero ya se puede ver la importancia de una comunicación clara. La comunicación es esencial para cualquier trabajo conjunto, pero quizás sea incluso más importante en un proyecto de código abierto, ya que personas con antecedentes muy diferentes pueden trabajar en cada parte del proyecto. Alguien puede colaborar como estudiante, alguien más como padre, una persona jubilada, entre otros. Aun así, el progreso tiene que ser fluido en este entorno, por lo que la comunicación no puede retrasar el progreso.
Desarrolladores, arquitectos y evaluadores
Para implementar los requisitos, un proyecto de software necesita desarrolladores que creen el producto en función de la documentación y las decisiones de diseño. Su trabajo es juzgado por el arquitecto, quien generalmente tiene el conocimiento técnico y de dominio más extenso que cualquiera en el proyecto. Cada desarrollador, especialmente los de alto nivel, es responsable de su propio código, pero las decisiones importantes las toma o aprueba el arquitecto.
A veces, las personas son designadas específicamente como probadores, quienes son responsables de todo tipo de pruebas, documentando los resultados y creando tickets de problemas.
Planificación y programación
Ahora que hemos discutido los roles básicos, hablemos de las fases de un proyecto: planificación, programación, implementación, mantenimiento/prueba y entrega. Algunas fases difieren en varios modelos de desarrollo de software, pero la planificación y la programación son temas generales que discutiremos antes de profundizar en los diferentes modelos.
La planificación se lleva a cabo después de que los BA/RE proporcionen la lista de requisitos. La planificación consiste en una o más reuniones sobre lo que el equipo quiere lograr, cómo planean lograrlo y cuánto tiempo llevaría. Por lo general, en estas reuniones también se realizan algunos análisis de riesgos.
Luego, los planificadores tienen que programar el trabajo y crear hitos. En cada hito, el equipo sabe que se ha hecho una parte grande e importante. Los componentes o funciones a largo plazo pueden tardar meses, por lo que los planificadores deben tener en cuenta las vacaciones, los feriados y, especialmente durante las estaciones frías, algunas bajas por enfermedad, para garantizar un tiempo de entrega preciso y evitar prisas y pánico al acercarse la fecha límite. Con un buen cronograma, los desarrolladores se sienten más relajados y pueden entregar soluciones de alta calidad a tiempo, sin averías.
Herramientas comunes
Dos herramientas que benefician a todos los modelos, y a la gestión de proyectos en general, son un sistema de control de versiones (VCS) y una plataforma de gestión del ciclo de vida de las aplicaciones (ALM). El control de versiones se analiza en profundidad en otra lección, así que digamos algunas palabras sobre las ALM.
ALM es un marco integral que gestiona el ciclo de vida de una aplicación de software desde el desarrollo inicial hasta el mantenimiento y el eventual retiro. ALM integra personas, procesos y herramientas para mejorar la colaboración y la eficiencia, garantizando que todas las etapas del ciclo de vida del software estén bien coordinadas y alineadas con los objetivos comerciales. Este enfoque ayuda a mantener la calidad, el rendimiento y la confiabilidad de las aplicaciones durante toda su vida útil.
Ahora que tenemos una descripción general de los roles y las fases del ciclo de vida, profundicemos en los modelos.
Modelo de cascada
Esta es una de las metodologías más tempranas y sencillas en el desarrollo de software. Puedes imaginarlo como una escalera, donde es necesario terminar cada escalón antes de seguir adelante. Pero el modelo va en una sola dirección, lo que lo hace adecuado para proyectos con requisitos claros y cambios mínimos o nulos esperados.
Aunque la simplicidad de este modelo puede ser una ventaja, la metodología rígida puede ser un inconveniente cuando se necesitan flexibilidad y adaptabilidad. Y hoy en día, normalmente todo cambia mientras trabajas en tu proyecto.
Como se explicó en las secciones anteriores, para comenzar el desarrollo, un proyecto debe tener los requisitos, un plan terminado y un cronograma de trabajo finalizado con hitos. En el modelo en cascada, estos son el resultado de la ingeniería de requisitos y el análisis empresarial.
Ingeniería de requisitos
En esta fase inicial, se recopilan y documentan todos los requisitos del proyecto. Este trabajo implica extensas discusiones entre el director del proyecto y las partes interesadas para comprender sus necesidades y expectativas. El resultado es un documento completo de especificación de requisitos que describe lo que debe hacer el sistema.
Análisis de Negocios
Los analistas de negocios examinan los requisitos desde una perspectiva comercial para asegurarse de que se alineen con los objetivos de la organización. Los BA realizan estudios de viabilidad, evaluaciones de riesgos y análisis de costo-beneficio para determinar si el proyecto es viable y vale la pena. Los conocimientos adquiridos se utilizan para perfeccionar el alcance y los objetivos del proyecto.
Diseño de software
El diseño de software es el paso en el que el arquitecto crea una especificación de diseño detallada para que la sigan los desarrolladores. Dada esta especificación, el equipo puede comenzar a implementar los requisitos; en otras palabras, iniciar la fase de desarrollo, que viene a continuación.
Desarrollo
La fase de desarrollo es donde ocurre la magia: donde se escribe el código. Siguiendo asiduamente la documentación y las decisiones de diseño, los desarrolladores escriben sus partes. Después de que los desarrolladores revisen su código con otros desarrolladores o con el arquitecto, esta fase se puede considerar finalizada.
Pruebas
Al desarrollo le sigue una fase de pruebas, gestionada por los evaluadores. Hay diferentes tipos de pruebas, que se describen en otra lección, como pruebas unitarias, de integración, sistemas y pruebas de aceptación.
El objetivo de estas pruebas es sacar a la superficie los problemas antes del lanzamiento y permitir que los desarrolladores los solucionen a tiempo, no después de que el proyecto se haya implementado y publicado y los usuarios puedan sentirse irritados y frustrados por los errores.
Operaciones
Una vez superadas las pruebas y corregidos los errores, el proyecto puede publicarse, es decir, implementarse en el entorno de producción. Esta fase puede contener instalación, configuración y, a veces, incluso la capacitación del usuario. Una vez que el proyecto está listo para usarse, se encuentra en una fase de mantenimiento, donde el equipo puede manejar los problemas de los usuarios y entregar actualizaciones si es necesario.
Evaluación del modelo de cascada
¿Qué has notado al leer sobre este modelo? ¿Lo encuentras eficiente? ¿Falta algo? Veamos los pros y los contras.
El modelo en cascada se beneficia de:
- Estructura clara
-
El proceso lineal hace que sea fácil de gestionar, comprender y seguir.
- Documentación meticulosa
-
la documentación detallada y exhaustiva en cada fase ayuda al equipo a comprender lo que se necesita durante el desarrollo y el mantenimiento futuro.
- Previsibilidad
-
Los hitos claros y definidos ayudan a proporcionar un cronograma y un presupuesto previsibles.
- Gestión de proyectos más sencilla
-
Gracias a su flujo lineal y sencillo, el modelo es fácil de gestionar.
El modelo de cascada sufre de:
- Rigidez
-
La inflexibilidad lineal del modelo dificulta la implementación de cambios una vez finalizada la fase de requisitos.
- Pruebas tardías
-
Durante la fase de desarrollo, las pruebas son desordenadas o faltan, lo que puede llevar a un reconocimiento tardío de problemas importantes.
- Supuesto de requisitos perfectos
-
El modelo requiere y supone que cada requisito sea correcto y claro, lo que puede resultar muy poco realista. El modelo no deja espacio para realizar comprobaciones durante el desarrollo para garantizar que los requisitos sean precisos y comprendidos por los desarrolladores.
- Falta de feedback
-
Sólo en la última fase un cliente puede decir algo sobre el producto. Entonces, si algo (o muchas cosas) no cumple con sus expectativas, el problema aparece sólo al final.
Desarrollo de software ágil, Scrum y Kanban
Para explorar este conjunto de modelos de desarrollo de software más modernos, comencemos con la palabra ágil: ¿Qué significa? La agilidad expresa la capacidad de reaccionar y moverse rápidamente, tanto en el mundo físico como en el mental. El objetivo es el mismo en el desarrollo de software.
El desarrollo ágil de software es una metodología que se basa en el desarrollo iterativo, la flexibilidad y la colaboración. Se centra en ofrecer pequeñas mejoras y al mismo tiempo recopilar comentarios e implementarlos durante el desarrollo. Este enfoque permite reacciones, ajustes y respuestas rápidas, ahorrando tiempo y asegurando que el proyecto cumpla con las expectativas de los usuarios y clientes.
El movimiento ágil fue lanzado en 2001 mediante un Manifiesto para el desarrollo de software ágil en línea que enumeraba sus principios de la siguiente manera:
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo.
A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcional sobre documentación integral
Colaboración con el cliente sobre negociación de contratos
Respuesta al cambio sobre seguir un plan
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
Scrum
Scrum es uno de los marcos más populares (quizás el más popular) dentro del desarrollo ágil de software. Scrum se basa en los siguientes componentes básicos:
En pocas palabras, Scrum requiere un Scrum Master para fomentar un entorno donde:
Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog.
El Scrum Team convierte una selección del trabajo en un Incremento de valor durante un Sprint.
El Scrum Team y sus stakeholders inspeccionan los resultados y los ajustan para el próximo Sprint.
Repetir
¿Pero quién es el scrum master y el propietario del producto? ¿Qué es un product backlog y un sprint? Profundicemos en los roles y procesos.
Sprints y planificación de sprints
Un sprint es una fase de desarrollo que normalmente dura de dos a cuatro semanas, durante la cual se completan algunas tareas y/o características previamente acordadas. Para llegar a un acuerdo sobre las tareas, entra la planificación de sprint. Este proceso es donde el equipo toma decisiones sobre qué tareas se pueden completar durante el próximo sprint.
Estas elecciones se basan en las prioridades establecidas por el propietario del producto (PO), que controla el proyecto y, a menudo, proporciona su financiación.
Product Backlog y Sprint Backlog
Como se acaba de explicar, el PO gestiona la lista de prioridades, que contiene todo el trabajo deseado en el proyecto. En Scrum, esta lista se llama product backlog. Cada sprint backlog contiene las tareas seleccionadas para el sprint actual del product backlog. El sprint backlog contiene los elementos elegidos por el equipo durante la planificación del sprint.
Daily Scrum or Stand-up
Las reuniones diarias Scrum o stand-up son reuniones breves y eficientes en las que los equipos discuten su progreso, resaltan los problemas y los obstáculos y comparten sus planes para el día. Por lo general, se realiza al comienzo de la jornada laboral.
Incremento
Un incremento es un objetivo alcanzado durante un sprint. Cada sprint debe resultar en uno o más incrementos. La corrección de la tarea o características logradas por el incremento debe verificarse mediante pruebas.
Revisión del sprint
La revisión del sprint es una reunión para inspeccionar el resultado del sprint. Estas reuniones suelen ser más que demostraciones: el objetivo es obtener comentarios basados en los resultados del equipo Scrum. Como el objetivo es alcanzar el objetivo del producto, las partes interesadas dan opiniones y sugerencias sobre futuras adaptaciones. El resultado de estas reuniones pueden ser cambios o adiciones a la cartera de productos.
Sprint Retrospective
El objetivo del Sprint Retrospective es mejorar la calidad y la eficacia, y no sólo en el producto actual. La retrospectiva debe revelar tensiones ocultas dentro del equipo, cualquier falta de información que ralentice los procesos, dependencias externas que deberían aliviarse para aligerar la carga del equipo, etc. El equipo discute qué salió bien, qué problemas enfrentaron y qué soluciones se encontraron (o no) para esos problemas.
El resultado es una lista de problemas junto con posibles soluciones asignadas a la persona responsable.
Scrum Master
Todas estas reuniones están organizadas por el Scrum master. Cada equipo Scrum necesita uno. Son responsables de facilitar los procesos de Scrum y ayudar al equipo a seguir avanzando hacia el objetivo del producto mientras se encuentran problemas durante los sprints. El Scrum master no sólo guía los procesos, sino que actúa como coach para asegurar una comunicación efectiva dentro del equipo.
Product Owner
El propietario del producto es responsable de maximizar el valor del producto creado por el equipo Scrum. Este rol puede variar entre diferentes organizaciones y equipos. Incluso al delegar tareas, el propietario del producto sigue siendo responsable de los resultados.
El éxito requiere respeto organizacional por las decisiones del propietario del producto, que se reflejan en el trabajo pendiente del producto y el incremento de la revisión del sprint. El propietario del producto es una sola persona que representa las necesidades de varias partes interesadas en el trabajo pendiente del producto. Cualquiera que desee cambiar el trabajo pendiente debe persuadir al propietario del producto para que lo haga. El propietario del producto define y prioriza la visión y el trabajo pendiente del producto y garantiza la transparencia, visibilidad y comprensibilidad del trabajo pendiente.
El Scrum Master y el propietario del producto colaboran para impulsar el éxito del proyecto. Su asociación ayuda al equipo de desarrollo a ofrecer funciones de alto valor de manera eficiente y eficaz.
Desarrolladores
Los desarrolladores implementan los requisitos siguiendo el sprint backlog acordado. Pueden trabajar de forma independiente, pero hay varias ocasiones en las que pueden colaborar: por ejemplo, programando en pareja o revisando el código de otro desarrollador.
Evaluación del modelo Scrum
Scrum se ha vuelto el favorito entre los equipos de software, pero también tiene pros y contras.
El Modelo Scrum se beneficia de:
- Flexibilidad
-
Los procesos son flexibles e iterativos, lo que permite cambios basados en la retroalimentación.
- Participación del cliente
-
La retroalimentación periódica de las partes interesadas garantiza la alineación con las necesidades del cliente.
- Calidad mejorada
-
Las pruebas y revisiones frecuentes mejoran la calidad del producto.
- Colaboración en equipo
-
El modelo enfatiza el trabajo en equipo y la comunicación a través de reuniones diarias y periódicas.
El modelo Scrum sufre de:
- Disciplina requerida
-
Scrum exige un estricto cumplimiento de sus prácticas, lo que puede resultar un desafío.
- Aumento del alcance
-
Existe el riesgo de que se agreguen cada vez más solicitudes de clientes y retrasen el lanzamiento, si la acumulación de productos no se gestiona bien.
- Confusión de roles
-
Los roles estándar, como Scrum Master y Product Owner, pueden malinterpretarse o implementarse mal.
- Intensidad de recursos
-
Las reuniones diarias y las revisiones frecuentes pueden consumir mucho tiempo.
Kanban
Kanban es otro marco ágil popular que enfatiza la visualización del trabajo, la gestión del flujo y las mejoras de procesos. Una de las grandes diferencias entre Scrum y Kanban es que Kanban no requiere iteraciones de longitud fija. Por lo tanto, hace que la entrega continua sea más flexible y puede equilibrar diferentes prioridades de trabajo.
Veremos qué necesitan los equipos para un proyecto Kanban en las siguientes subsecciones.
Tableros Kanban
Un tablero Kanban es una herramienta visual que rastrea el flujo del trabajo a través de etapas. Las columnas principales y más importantes son “To Do”, “In Progress” y “Done”. Se pueden agregar más columnas, pero estas tres columnas principales deben estar en el tablero. Esta visualización ayuda a los equipos a detectar cuellos de botella y ver el estado de las tareas en un abrir y cerrar de ojos.
Límite de trabajo en curso
Un límite de trabajo en progreso (WIP por sus siglas inglés) ayuda a evitar la multitarea y mejora la concentración. Con este límite, llega un punto en el que no se pueden agregar más tareas a la columna “In Progress”. De esta forma, los desarrolladores no se verán sobrecargados de tareas y podrán centrarse en las tareas en las que están trabajando actualmente.
Miembros del equipo
Los miembros del equipo son responsables de completar las tareas y establecer un flujo a través del sistema Kanban. Colaboran para priorizar el trabajo, resaltar y abordar cualquier tipo de problema que surja.
Administrador Kanban
El administrador Kanban supervisa el proceso Kanban y garantiza que el equipo siga los principios y prácticas de Kanban. Este administrador facilita reuniones, monitorea los flujos de trabajo y ayuda a resolver cualquier problema que pueda surgir.
Evaluación del modelo Kanban
El núcleo de este modelo es simple. Veamos los pros y los contras.
El Modelo Kanban se beneficia de:
- Flujo de trabajo visual
-
los tableros Kanban brindan una visibilidad clara del estado y el progreso del trabajo.
- Flexibilidad
-
Al carecer de iteraciones fijas, el modelo admite la entrega continua con una adaptabilidad sustancial.
- Límites de tareas
-
El límite de WIP ayuda a evitar que los miembros del equipo se sobrecarguen y, por lo tanto, mejora su concentración y eficiencia.
- Mejora continua
-
El modelo fomenta la evaluación periódica y la mejora de los procesos.
El modelo Kanban sufre de:
- Falta de plazos
-
Sin plazos establecidos, la gestión del tiempo es un desafío.
- Menos estructura
-
El modelo puede carecer de la estructura que algunos equipos necesitan para mantenerse organizados.
- Disciplina requerida
-
Los límites efectivos de WIP y la gestión de la junta requieren una atención cuidadosa.
- Posible simplificación excesiva
-
Las descripciones de las tareas pueden simplificar demasiado proyectos complejos si no se implementan cuidadosamente.
DevOps
DevOps es un enfoque de desarrollo de software que integra los equipos de desarrollo (Dev) y operaciones (Ops) para mejorar la colaboración, la eficiencia y la velocidad de entrega. El objetivo principal de DevOps es acortar el ciclo de vida del desarrollo de software y proporcionar una entrega continua con alta calidad de software. DevOps enfatiza la automatización, la integración continua y la entrega continua (CI/CD) y la estrecha colaboración entre equipos tradicionalmente aislados.
La automatización es crucial en DevOps para tareas como la integración de código, pruebas, implementación y gestión de infraestructura. La automatización de tareas repetitivas reduce los errores, acelera los procesos y permite a los equipos centrarse en un trabajo más estratégico.
El monitoreo y el registro continuos son esenciales para mantener la salud y el rendimiento del sistema. Las prácticas de DevOps incluyen la configuración de sistemas integrales de monitoreo y registro para detectar problemas, analizar tendencias y mejorar la confiabilidad del sistema.
Evaluación del modelo DevOps
Aunque DevOps es altamente recomendado para muchos tipos de proyectos de software modernos, aún se deben considerar los pros y los contras.
El modelo DevOps se beneficia de:
- Velocidad y eficiencia
-
El modelo acelera los ciclos de desarrollo e implementación a través de la automatización.
- Colaboración mejorada
-
El modelo cierra la brecha entre los equipos de desarrollo y operaciones.
- Entrega continua
-
El modelo garantiza que el software esté siempre en un estado implementable, lo que lleva a lanzamientos más frecuentes.
- Alta confiabilidad
-
Las pruebas y el monitoreo automatizados mejoran la confiabilidad y reducen los errores.
El modelo DevOps sufre de:
- Cambio cultural
-
El modelo requiere un cambio cultural significativo y aceptación en toda la organización.
- Complejidad
-
La gestión de canales de CI/CD y la infraestructura automatizada puede ser compleja.
- Riesgos de seguridad
-
La implementación continua puede introducir vulnerabilidades de seguridad si no se gestiona con cuidado.
- Sobrecarga de herramientas
-
DevOps puede resultar abrumador debido a la multitud de herramientas y tecnologías involucradas.
Ejercicios guiados
-
¿Qué significa agilidad?
-
¿Cuál es la definición de Scrum, según la Guía Scrum?
-
¿Por qué Scrum puede funcionar mejor que el modelo en cascada con respecto a los comentarios de los clientes?
-
¿Cuáles son los aspectos positivos de DevOps?
Ejercicios exploratorios
-
¿Por qué el modelo en cascada no es el mejor para usar en un entorno que cambia rápidamente?
-
¿Qué puede pasar cuando el rol del Scrum master está mal implementado?
Resumen
La relevancia de la gestión de proyectos en el desarrollo de software, especialmente en proyectos de código abierto, radica en su capacidad para proporcionar estructura, mejorar la comunicación, definir roles, gestionar riesgos y garantizar la calidad. Estos elementos son cruciales para la finalización exitosa de los proyectos y para fomentar un entorno de desarrollo colaborativo y productivo.
En esta lección, analizamos el modelo en cascada, las metodologías ágiles y DevOps. El conocimiento de estos modelos es esencial para comprender la gestión de proyectos en el desarrollo de software. No existe una forma perfecta de trabajar: cada proyecto es diferente. En esta lección, aprendió las funciones, los procesos y los pros y los contras de varios enfoques, que pueden ayudarlo en el futuro a comprender y quizás elegir el modelo correcto para un proyecto.
Respuestas a ejercicios guiados
-
¿Qué significa agilidad?
La agilidad expresa la capacidad de reaccionar y moverse rápidamente, tanto en el mundo físico como mental.
-
¿Cuál es la definición de Scrum, según la Guía Scrum?
-
Un Product Owner ordena el trabajo para un problema complejo en un Product Backlog.
-
El Scrum Team convierte una selección del trabajo en un Incremento de valor durante un Sprint.
-
El Scrum Team y sus stakeholders inspeccionan los resultados y los ajustan para el próximo Sprint.
-
Repetir
-
-
¿Por qué Scrum puede funcionar mejor que el modelo en cascada con respecto a los comentarios de los clientes?
Debido a que la retroalimentación se recopila durante el desarrollo, el producto final puede satisfacer mejor las expectativas del cliente.
-
¿Cuáles son los aspectos positivos de DevOps?
Velocidad y eficiencia — Colaboración mejorada — Entrega continua — Alta confiabilidad
== Respuestas a ejercicios exploratorios
-
¿Por qué el modelo en cascada no es el mejor para usar en un entorno que cambia rápidamente?
El modelo en cascada recopila comentarios solo al final del desarrollo. Por lo tanto, cualquier requisito que los desarrolladores no hayan entendido bien debe corregirse al final. Si el entorno cambia muy rápidamente, este modelo no debe usarse porque no hay provisión para retroalimentación en la mitad del ciclo de desarrollo.
-
¿Qué puede pasar cuando el rol del Scrum master está mal implementado?
Un rol de Scrum master mal implementado puede obstaculizar la capacidad del equipo para entregar productos de alta calidad de manera eficiente y puede socavar los beneficios de adoptar Scrum. Es posible que el equipo carezca de una orientación adecuada sobre las prácticas y principios de Scrum, lo que lleva a una aplicación inconsistente o incorrecta del marco.
Sin un Scrum Master eficaz para eliminar los obstáculos, los impedimentos pueden ralentizar el progreso y reducir la productividad del equipo. Puede ocurrir una falta de comunicación entre los miembros del equipo y las partes interesadas, lo que resulta en malentendidos y expectativas desalineadas. El equipo puede experimentar una disminución de la moral y la motivación debido a problemas no resueltos, falta de apoyo y facilitación ineficaz de los eventos Scrum. Las ineficiencias pueden surgir de reuniones mal realizadas, falta de concentración y planificación y revisiones de sprint ineficaces.