Lendo o livro Rework de Jason Fried e David Heinemeier Hansson, a famosa dupla da 37 signals, me deparei com um tópico que tenho visto ser abordado na comunidade ágil há algum tempo e estou cada vez mais certo de que se aplica não somente a software mas a qualquer tipo de negócio: Ignore os Detalhes de Antemão.
por chrisjohnbeckett
Isso não quer dizer que os detalhes não fazem diferença. Sim, fazem. Porém, você deve ser preocupar com eles apenas pouco antes de precisar implementá-los de alguma forma. No início de seus projetos ignore-os. Simplesmente decida sobre eles depois. Preocupe-se em fazer o básico primeiro. Lembre-se, você não precisa manter suas decisões para sempre, pode mudá-las no meio no caminho. Mantenha o equilibrio entre rigidez e flexibilidade, os dois extremos são prejudiciais.
Essa mesma linha de pensamento explica porque métodos extremamente prescritivos e burocráticos geralmente não levam a bons resultados. Levantar requisitos com muita antecedência e nível exagerado de detalhes, é um exemplo de engano desse tipo, como sabemos, requisitos mudam, o cliente não sabe bem o quer desde o inicio, e o software deve ser flexível e capaz de evoluir em conformidade com as necessidades de negócio do cliente. Essa abordagem precipitada de levantamento de requisitos é chamada de BRUP (Big Requirements Up Front).
Outro grande erro é o famoso Big Design Up Front (BDUF) em que se tenta criar todo o design de um software antes de sua implementação, novamente a falta de flexibilidade em abordagens como essa geralmente levará qualquer projeto ao completo fracasso.
Em Lean Software development qualquer coisa que termine com Up Front pode ser vista como desperdício. E desperdício é algo que deve ser eliminado porque não agrega valor algum.
Você prática BRUP ou BDUF em sua organização? Tem bons resultados com abordagens assim? Qual é a sua opnião a respeito? Deixe um comentário.
opa! Andre, Legal o post, eu nao conhecia as siglas, mas já tive a oportunidade de ver muitas situacoes como as citadas. Principalmente nos “software de prateleiras”. E até hoje nunca vi uma que deu certo, no final tinha muito tempo gasto, custo elevado e o projeto virou um elefante branco.
gostei do post 🙂
André,
A organização qeu eu trabalho vem utilzando as 2 abordagens. Tambem não conhecia as siglas mas penso que a maoiria das pessoas com as quais eu trabalho ainda acreditam que podem descobrir todos os requisitos e finalizar o desging do projeto antecipadamente.
Estamos ‘engantinhando’ no uso do scrum e a cultura local ainda ganha batalhas contra a agilidade.
sds,
Taise