Clientes pasan no sentirse confortables por lo que pagan. Cuestionados sobre la menor productividad y calidad, los desarrolladores responden: «This is the Way«. Entonces surg el Guia de Scrum 2020.
La actuallización de Scrum 2020
Después de tres años, los creadores de Scrum actualizaron el guia de Scrum en noviembre de 2020. A pesar de 2020 no pasar a historia por este hecho, es importante para el Gestor de Software. Esto es porque su prinicpal impacto es en la reflexión de los objetivos de gobernanza corporativa en la gestión del desarrollo ágil.
¿Qué cambios tuvo el Guia Scrum 2020?
Primero, Time Scrum sigue siendo un equipo cross funcional con el Product Ownver, el Equipo de Desarrollo y el Scrum Master. Sin embargo, ese equipo no es más auto-organizada. La nueva versión establece qu el equipo es auto gerenciada. En consecuencia, se evita que los equipos usen prerrogativas de auto-organización para evitar asumir cualquier compromiso.
El equipo se autegerencia para entregar sus compromisos para atender los objetivos.
Con ello se percibe la necesidad de explorar mejor esos objetivos; un otro item que cambia en la nueva guia.
Compromisos y objetivos del Guia Scrum 2020
El Guia Scrum 2020 coloca compromisos asociados al Product Backlog, al Sprint Backlog y al Incremento. De esta forma, e Objetivo del Producto provee el contexto de Product Backlog. O sea, es la necesidad de negocio – el problema o la oportunidad motivadora de cambio – por detrás del Product Backlog. Adicionalmente, es la motivación para el equipo Scrum estar trabajando. Este deberia ser medido en terminos de resultados de negocio. Además de ser visible para el equipo Scrum y sus interesados.
El obejtivo del Sprint, relativo al Sprint Backlog; y la Definición de Done, relativa al Incremento, tambien son compromisos incluidos en la Guia Scrum 2020. Vale la pena explorar un pouco más esos objetivos en especial la definición de Done.
Evitar el desperdício y dar transparencia al desarrollo
La nueva versión de la Guia Scrum 2020 busca convertir a Scrum en un framework minimamente suficiente. Por tanto, este no ofrece y no pretende dar referencias detalladas para la gestión del proceso, de la misma manera que sus versiones anteriores. Por eso, al definir estos objetivos y compromissos como obligatorios, debería ofrecer a los responsables por la gestión de desarrollo referencias para hacerlo de una manera más alienada con los obejtivos de la gobernanza corporativa.
Diferentes niveles, la misma cadencia
El Guia Scrum continua no difeniendo el concepto de Release. Usamos Release como un marco de nivel más alto en relación a la entrega de una Sprint. Y establece que en eun incremento de ser responsable de uso para poder proveer valor. Además este establece que el momento en que un item del Product Backlog atiende la definición de done, nace un incremento.
La clave para atender la Release, está en diferente referencias de done. En el nivel más alto, la madurez de los features permiten la liberación de un nuevo incremento de producto, cuyo done está relacionado a (a)la homologación o aceptación del usuario.
El nivel más alto difiere de los Sprints, porque en este ultimo los objetivos están relacionados a (b) proporcionar experimentación, obtener feedback y promover aprendizaje sobre como esas nuevas features se incorporan en el producto.
Hay casos de desarrollo donde es necesario otros niveles más altos. No es universla la necesidad de niveles más altos. Sin embargo, donde surgen los problemas citados, la adopción de estos diferentes niveles de objetivos es un importante componente de la solución.
Por eso, no se conflutua con el desarrollo contínuo; apenas coloca la liberación (Release) de nuevas features maduras al largo de algunas Sprints en otra cadencia sobre la cadencia de los Sprints de Scrum. En la planeación y monitoreo de esta cadencia es donde se insertan los puntos de función y los indicadores de productividad.
APF como pivot en la organización del desarrollo
Si usted no esta conforme por lo que paga por software, nuevas Releases demoran, muchos defectos y los gastos solo aumentan, entonces el uso de métrcias de más alto nivel de las usadas internamente en Scrum, pueden ser un medio para resolver estos problemas. Al medir, el gestor de software necesita hacer algo que ahora es claramente su repsonsabilidad:
- Organizar el trabajo de manera que evite los desperdicios y alinee el esfuerzo invertidos a los intereses del «dueño».
Hay varias decisiones para tornar esto en realidad.
FATTO puede ayudarte a lidear con estos desafíos
El equipo debe asumir compromisos conforme las exigencias de eficiencia operacional y transparencia determinadas por la gobernanza corporativa. Esto es claro en la nueva versión de Scrum.
FATTO puede ayudarte desde la gestión de cambios con sus servicios de Gestão de Fornecedores hasta la operación de un Centro de Orçamentos o el Escritório de Métricas para absorver todo el trabajo relativo a la medición. Si quiere entender mejor como funciona, mi WhatsApp es +55(27)98123-9100.
