16. 08.
A natureza maleável do software muitas vezes traz a sensação de que ele pode ser produzido quase que instantaneamente. Embora esse sentimento seja justificável, escrever software de qualidade, para durar o tempo necessário para agregar valor para seus usuários, leva tempo. Às vezes mais do que todas as partes interessadas desejariam.
Independente de qual seja a definição de pronto da equipe de desenvolvimento, a construção de cada parte do software deve demorar o tempo suficiente para satisfazê-la. Um determinado time de desenvolvimento, por exemplo, poderia adotar a seguinte convenção para considerar que uma funcionalidade está pronta:
- Testes unitários e de integração realizados
- Deploy em servidor de demonstração/homologação
- Funcionalidade pronta para testes de aceitação
Mesmo com poucos itens, a lista acima requer uma boa dose de esforço para se alcançar. Na verdade, em muitos casos é comum aceitar como “pronta” uma funcionalidade que acabou de ser codificada. Tal prática é nociva para qualquer processo de desenvolvimento, uma vez que, além de comprometer a qualidade do produto, impossibilita a correta medição de esforço e prejudica as estimativas para projetos futuros.
Os métodos ágeis prevêem algumas práticas e princípios para disciplinar esse aspecto do desenvolvimento. Ao definir iterações curtas, na verdade estamos tentando garantir que o escopo para a iteração seja cuidadosamente escolhido, de modo a forçar a decomposição em atividades atômicas o suficiente garantir que cada uma seja executada por completo. Ao trazer o cliente para perto da equipe, facilitamos sua compreensão de que é importante que todos os passos previstos para completar uma funcionalidade sejam realizados na íntegra.
Ou seja, o produto estará pronto quando estiver pronto.
Os textos e livros a seguir discorrem com mais detalhes sobre o assunto:
- Building a definition of done
- Cuidando para o que o software não apodreça
- Scrum and XP from the trenches
- The Pragmatic Programmer
Leia também
30. 10.
Apesar de discordar com alguma freqüência de certas opiniões de Joel Spolsky , dessa vez não posso deixar de admitir que ele foi muito feliz ao citar os motivos pelos quais simplesmente acrescentar horas de trabalho a um projeto de desenvolvimento de software não o torna bem sucedido. Apenas quem já trabalhou na área sabe como funcionam os fluxos de inspiração que fazem um desenvolvedor render mais em cinco ou seis horas do que em uma semana seguida escrevendo (ou tentando escrever) código até tarde.
There’s a whole body of literature establishing that working more hours doesn’t produce software any faster. Edward Yourdon, the software entrepreneur and author, dubbed this kind of project the "death march."
Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.
Compelling them to spend even more hours sitting in front of a computer won’t really translate into more output–or if it does, it will be the wrong kind of output. When their brains are completely fried, software developers are almost certainly going to do more damage than good, writing unusable code and introducing bugs galore. And if you do ban the Internet and multiplayer games to force them to keep writing code past their natural bedtimes, well, they’ll probably start quitting on you. Running a death march is not the only way to make a project late and a budget buster. But it is a surefire way to do so.
Leia o artigo na íntegra .
Rodrigo Amaral