Scrum - Projetos Ágeis e Pessoas Felizes

Cesar Brod

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

3.3 Codificação

Como o usuário participou de todo o planejamento, especialmente como coautor das User Stories, ele deve estar sempre disponível (Customer Always Available) durante o processo de codificação, a fim de sanar eventuais dúvidas que possam surgir e colaborar com sugestões.

A equipe de desenvolvimento deve concordar com os Coding Standards (padrões de codificação) que serão utilizados, preferencialmente baseando-se em experiências de comprovado sucesso anterior. Todas as linguagens e frameworks de programação modernos possuem um ou mais padrões de codificação sugeridos, publicados na web. O livro Código Limpo – Habilidades Práticas do Agile Software, de Robert C. Martin (o Uncle Bob) é uma excelente referência para a ampla adoção e acordos sobre padrões de codificação.

Uma regra que sempre gera alguma surpresa (e até polêmica) é a do desenvolvimento baseado em testes, que estabelece que os testes devem ser definidos e codificados antes mesmo que uma classe e suas funções, que serão testadas, estejam escritas. A atitude de pensar nos testes que serão feitos já refina a codificação e contribui para a eliminação prematura de possíveis erros.

Os desenvolvedores devem trabalhar em pares (Pair Programming). O resultado prático é uma programação mais criativa, clara e menos sujeita a erros. Por incrível que possa parecer, a produtividade também é maior quando se tem dois programadores trabalhando ao mesmo tempo no mesmo código, além de ser mais fácil disseminar o conhecimento entre técnicas e projetos trocando-se os pares de tempos em tempos. No XP, a propriedade do código é coletiva (Collective Code Ownership); dessa forma, todos compartilham o mesmo orgulho e as mesmas críticas.

A otimização do código deve ser feita por último (Optimize Last) e apenas quando for necessária. Não tente resolver gargalos antes que eles apareçam. Lembre-se de que o preço do hardware é muito menor do que era há dez anos, ao passo que as horas de bons desenvolvedores estão mais caras. Pondere se não é mais barato aumentar o espaço de armazenamento ou comprar processadores mais rápidos – estejam eles fisicamente em seu ambiente ou na nuvem – do que pagar um mês de um DBA para otimizar a base de dados.

A última regra da Codificação é No Overtime – sem horas extras. Em XP, o dia é de oito horas e a semana, de quarenta horas, no máximo. Dessa forma é que os projetos devem ser dimensionados. Por mais que às vezes seja difícil afastar um programador de uma tarefa que ele faz com prazer, isso deve ser feito. A prática mostra que a produtividade diminui e a quantidade de erros aumenta quando se trabalha demais: existem limites que, antes de qualquer coisa, são limites físicos. Mesmo que o programador sinta-se compelido a continuar trabalhando, ele deve abandonar a codificação e concentrar-se na documentação e no planejamento. Apresente para a equipe jogos que possam ser jogados coletivamente. Xadrez é uma boa ideia. Nerds gostam de coisas “vintage”.

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

Utilizamos cookies para melhorar a sua experiência em nosso site. Para mais informações, visite nossa Política de Privacidade.