Olá amigos,
Neste artigo vou abordar um pouco sobre o Scrum sustentar-se ou não com a ajuda de metodologias e frameworks.
Vou começar falando sobre a figura abaixo que demonstra que o Scrum segue um ciclo PDCA.
Temos um dia para planejamento (Sprint Planning Meeting) e um dia para revisão (Sprint Review) e retrospectiva (Sprint Retrospective) e de 2 a 4 semanas para a execução (Sprints) onde existe uma reunião de inspeção diária (Daily Scrum) que ajuda a identificar riscos.
“Mas Vitor, e o restante da Sprint? Como é conduzida? Como garantir qualidade de tal forma que o Product Owner não rejeite a entrega ao final da Sprint?”
Os agilistas mais puristas dirão sobre as tais equipes “autogerenciadas” (saiba porque não concordo o termo neste artigo) que sempre identificarão e resolverão os problemas e sobre o feedback contínuo entre Product Owner e equipe de desenvolvimento.
Ok, mas será que só isso basta? Só esses conceitos garantem qualidade na entrega da Sprint?
Cada dia mais acredito que a resposta seja não. São necessários frameworks ou metodologias complementares para ajudar na execução de um projeto Scrum.
Já abordei diversas vezes sobre a aderência entre o guia PMBOK e o Scrum. Em projetos Scrum, executamos boa parte das boas práticas do PMBOK e as práticas que não fazem parte do Scrum (Recursos Humanos, Aquisições, Custos) ajudam a complementá-lo. Para entender mais sobre o que eu penso sobre o assunto veja este artigo e este outro artigo também.
Para casos de desenvolvimento de software acredito muito no uso da metodologia Extreme Programming (XP) durante a execução de uma Sprint.
Para quem não conhece, o XP é uma metodologia composta por 13 práticas que devem ser seguidas conforme figura abaixo:
Uma descrição simples e objetiva das práticas do XP pode ser obtida no Wikipedia.
Por ora, gostaria de falar de 5 práticas em particular:
Propriedade Coletiva: Todos os desenvolvedores acessam o código de todos. Não existe “dono” de determinado módulo, funcionalidade ou classe.
Programação em Par: Uma excelente técnica para mitigar riscos e bugs durante a programação. Enquanto um membro faz a programação o outro membro acompanha e fornece feedback ao colega. Existe muito preconceito com relação a esta prática, principalmente de gestores à moda antiga que dizem: “Estou pagando dois para fazer o serviço de um?” ou “Por que estão dois na mesma máquina? Estamos com um recurso parado”. Como diria o célebre Compadre Washington: “Sabe de naaaaaada inocente” ! 🙂
Integração Contínua: Utilizar ferramentas automatizadas para compilação frequente do código para verificar se o código integrado ao repositório invalidou alguma coisa. Vide fluxo na figura abaixo:
Refatoração: Tornar o código “elegante” mantendo o comportamento anterior às alterações. Retirar duplicação de código ou sintaxes “feias” dentro do seu código
Desenvolvimento orientado a teste (TDD): A técnica de escrever e executar um teste antes de desenvolver. Evita o teste viciado feito pós-programação. Se você quiser saber mais detalhes sobre esta prática, sugiro adquirir o livro Test-Driven Development de Kent Beck. Por ora, veja o fluxo do TDD na figura abaixo:
Veja que interessante. Podemos ter um projeto com framework Scrum, complementado com práticas do PMBOK e seguindo uma metodologia XP na sua execução! É o chamado “tailoring”, ou seja, “feito sob medida”, adaptado.
Veja a figura abaixo que representa um outro exemplo de “tailoring”:
Temos um projeto rodando com framework Scrum, com metodologia XP na execução, alinhado aos 4 valores do Agile Manisfesto (veja minhas reflexões sobre o manifesto nos artigos parte 1, parte 2, parte 3 e parte 4) e regido pela filosofia Lean de desenvolvimento de software (veja meu artigo sobre Lean aqui).
Resumindo: use as metodologias, frameworks e boas práticas existentes como ferramentas. Use as que forem adequadas e trarão maior sucesso para seu projeto sem se preocupar com rótulos, terminologias e xiitismos. Você não deixará de ser “Scrum na veia” se usar outras técnicas para complementar processos e garantir a qualidade da entrega da sua Sprint!
“Mas Vitor, e o Product Owner? Em outro artigo, e mesmo em suas palestras e workshops, você diz que sem um bom Product Owner o Scrum não dá certo de jeito nenhum! O Product Owner também não deveria ter alguma metodologia ou framework de apoio?”
Resposta: SIM! Mas isso é assunto para o próximo artigo! 🙂
Abraços e até a próxima
