Clientes passam a se sentir desconfortáveis pelo que pagam. Questionados sobre a menor produtividade e qualidade, os desenvolvedores respondem: “This is the Way“. Então, surge o Guia do Scrum 2020.
A atualização do Guia do Scrum 2020
Após três anos, os criadores do Scrum atualizaram o guia do Scrum em novembro de 2020. Apesar de 2020 não ficar na história por isso, a atualização é importante para o Gestor de Software. Isso, porque seu principal impacto é no reflexo dos objetivos de governança corporativa na gestão do desenvolvimento ágil.
O que mudou com o Guia Scrum 2020
Primeiro, o Time Scrum segue sendo uma equipe cross funcional com o Product Owner, o Time de Desenvolvimento e o Scrum Master. No entanto, essa equipe não é mais auto-organizada. A nova versão estabelece que o time é auto gerenciado. Por conseguinte, tenta evitar que as equipes usem a prerrogativa de auto-organização para evitar assumir qualquer compromisso.
O time se auto gerencia para entregar seus compromissos para atender os objetivos.
Dai, já se percebe uma necessidade de melhor explorar esses objetivos; um outro item que muda no novo guia.
Compromissos e objetivos no Guia do Scrum 2020
O Guia do Scrum 2020 coloca compromissos associados ao Product Backlog, ao Sprint Backlog e ao Incremento. Desta forma, o Objetivo do Produto provê o contexto do Product Backlog. Ou seja, ele é a necessidade de negócio – o problema ou a oportunidade motivadora da mudança – por detrás do Product Backlog. Adicionalmente, é a motivação para o Time Scrum estar trabalhando. Ele deveria ser mensurável em termos de resultados de negócio. E também ser visível para o Time Scrum e seus interessados.
O Objetivo do Sprint, relativo ao Sprint Backlog; e a Definição de Done, relativa ao Incremento, também são compromissos incluidos no Guia do Scrum 2020. Vale a pena explorar um pouco mais esses objetivos em especial a definição de Done.
Evitar o desperdício e dar transparência ao desenvolvimento
A nova versão do Guia do Scrum 2020 busca tornar o Scrum um framework minimamente suficiente. Portanto, ele não fornece e não pretende dar referências detalhadas para gestão do processo, da mesma forma que suas versões anteriores. No entanto, ao definir esses objetivos e compromissos como obrigatórios deveria fornecer aos responsáveis pela gestão do desenvolvimento referências para fazer isso da maneira alinhada aos objetivos de governança corporativa.
Diferentes níveis a mesma cadência
O Guia do Scrum segue não definindo o conceito de Release. Usamos Release como um marco de nível mais alto em relação à entrega de uma Sprint. E ele estabelece, que um incremento deve ser passível de uso para prover valor. Ele também estabelece que o momento em que um item do Product Backlog atende a definição de done, nasce um incremento.
A chave para entender a Release, está em diferentes referências de done. No nível mais alto, o amadurecimento de features permitem a liberação de um novo incremento de produto, cujo done está relacionado à (a) homologação ou aceitação do usuário.
Esse nível mais alto difere do nível dos Sprints, porque nesse último os objetivos estão relacionados a (b) proporcionar a experimentação, obter feedback e promover o aprendizado sobre como essas novas features se incorporam no produto.
Há casos de desenvolvimento onde é necessário outros níveis mais altos. E não é universal a necessidade de níveis mais altos. No entanto, onde surgem os problemas citados, a adoção desses diferentes níveis de objetivos é um importante componente da solução.
Portanto, isso não conflita com o desenvolvimento contínuo; apenas coloca a liberação (Release) de novas features amadurecidas ao longo de algumas Sprints em outra cadência sobre a cadência dos Sprints do Scrum. No planejamento e monitoramento dessa cadência é onde se inserem os pontos de função e os indicadores de produtividade.
APF como pivot na organização do desenvolvimento
Se você não está confortável pelo que paga por software, novas Releases demoram demais, trazem muitos defeitos e as despesas só sobem, então o uso de métricas de mais alto nível do que as usadas internamente ao Scrum, podem ser um meio para resolver esses problemas. Ao medir, o gestor de software precisa fazer algo que agora é claramente uma responsabilidade sua:
- Organizar o trabalho de maneira a evitar os desperdícios e alinhar o esforço investido aos interesses do “dono”.
Há várias decisões para tornar isso realidade.
A FATTO pode ajudar você a lidar com esses desafios
A equipe deve assumir compromissos conforme as exigências de eficiência operacional e transparência determinados pela governança corporativa. E isso está claríssimo na nova versão do Scrum.
A FATTO pode te ajudar desde a gestão da mudança com seus serviços de Gestão de Fornecedores até a operação de um Centro de Orçamentos ou o Escritório de Métricas para absorver todo o trabalho relativo à medição. Se quiser entender melhor como isso funciona, meu WhatsApp é +55(27)98123-9100.
