Muitos defensores e propagandistas do Scrum falam e escrevem como se não existisse nenhum defeito em sua aplicação. Isso é uma visão errada, pois seria dizer que um mecanismo mínimo é capaz de garantir dezenas ou centenas de características importantes do processo de desenvolvimento de software.
Por exemplo, não há nada no Scrum que garanta a implementação de alguns requisitos não funcionais. O Product Backlog é basicamente uma lista de coisas que o Product Owner deseja ver funcionando, requisitos funcionais, e possivelmente alguns requisitos não funcionais ligados a interface, mas e quanto a outros requisitos, como qualidade de código, aderência a arquitetura, aderência a padrões, etc…
Bem, Scrum não se propõe a fazer isso, mas ele fornece o espaço onde isso pode ser feito.
Aprender Scrum não é aprender a implantar o arcabouço mínimo, aprender Scrum é aprender a evoluir constantemente o arcabouço mínimo. O projeto precisa de controle de qualidade de código, inclua isso no processo. Precisa de definir requisitos de segurança, inclua isso no processo. Mas como?
Ora, dois momentos importantes são o pré-jogo, chamado por alguns de Sprint 0, e a reunião de retrospectiva.
No primeiro, da mesma forma como levantamos o Product Backlog, devemos fazer um levantamento dos requisitos não funcionais, tanto os que são pedidos como os que tipicamente não são pedidos pelo P.O. como “eu preciso ter isso”. Atividades adicionais podem ser colocadas no processo ou acertadas na forma de trabalho da equipe e comporem um grupo de tarefas padronizadas para cada história. No nosso caso, por exemplo, temos sempre que criar uma tarefa para fazer o teste da história segundo a metodologia de teste que usamos.
Já na reunião de retrospectiva a equipe tem a oportunidade de verificar o que não está dando certo e o que tem que ser mudado. É aí que vários requisitos não funcionais aparecem ou passam determinados como necessários no projeto.
O importante é reconhecer que o Scrum não é um sistema de gerência de projeto mínimo e suficiente, mas sim um sistema de gerência de projeto mínimo e necessário, mas que deve ser complementado de forma a atender outras características importantes do seu processo.
Então, um Scrum de qualidade está constantemente melhorando em busca de levar o projeto a qualidade máxima. E, como isso é feito de forma paulatina e de acordo com a demanda, temos a vantagem de não implementar desde o início processos ou atividades desnecessárias para o escopo do projeto.
Pelo que entendi, o SCRUM é um framework que contém uma estrutura mínima e não absoluta de práticas e como é um modelo aberto, eu posso então, acrescentar sem fugir de sua estrutura conceitual, outras boas práticas de forma a amadurecer meu processo no que se diz respeito a minha realidade e necessidade, como exemplo, o plano de testes mencionado.
Está correto meu entendimento?
Abçs!!!
Perfeito Rafael!
Parte da natureza do Scrum é a sua capacidade de ser estendido. Ficar fazendo Scrum mínimo a vida toda não é fazer Scrum, pois não há melhoria, e a melhoria constante é o verdadeiro motivo para qualquer modelo de gerência de projetos, seja ele ágil ou não.