Scrum: Sustenta-se sozinho?

AGRADEÇA AO AUTOR COMPARTILHE!

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.

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:

011

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:

061

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:

063

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”:

013

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

AGRADEÇA AO AUTOR COMPARTILHE!

Vitor Massari

Mais artigos deste autor »

Profissional com mais de 15 anos de experiência em projetos de software. Sócio-proprietário da Hiflex Consultoria, profissional PMP e agilista, acredita no equilíbrio entre as várias metodologias e frameworks voltados para gerenciamento de projetos.
Lema: "Agilista convicto sempre, agilista obcecado jamais"


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">