Posts made in April, 2010
Respeitar as Pessoas
Um dos pilares que sustentam a filosofia da Toyota é respeitar as pessoas, e em se falando de Lean Software Development e Desenvolvimento Ágil de Software, não poderia ser diferente.
Foto por Toni Blay
Respeitar as pessoas significa dar a elas um ambiente de trabalho limpo e seguro, permitir que tenham metas praticáveis e realistas, confiar nelas, significa também, desenvolver uma organização onde as pessoas possam pensar e descobrir as melhores formas de executar seu trabalho ao invés de simplesmente receber ordens de o que e como fazer. É permitir que as pessoas tenham oportunidade de conhecer profundamente seu trabalho, refletir sobre ele e melhorá-lo. E não há trabalho algum que não possa ser melhorado.
Pare e pense. O que você pode fazer para melhorar o seu próprio trabalho?
Harvard e Desenvolvimento Ágil
A descoberta mais notável foi que criar um versão com poucas funcionalidades e entregá-la aos clientes cedo melhora a qualidade dramaticamente.
Este é um trecho do artigo do Professor Alan MacCormack da Harvard Business School “Porque Desenvolvimento Evolutivo de Software Funciona“, em que fala sobre o desenvolvimento de software iterativo:
Desenvolvimento de sucesso é evolucionario por natureza. Empresas lançariam primeiro uma versão com poucas funcionalidades de um produto para determinados clientes logo no inicio do desenvolvimento. Posteriomente o trabalho continuaria de forma iterativa, permitindo que o design evolua em resposta ao feedback dos clientes.
Evolution por teamtraveller
Qualquer semelhante com a abordagem ágil, é mera semelhança. O professor apresenta ainda quatro práticas levam projetos de software ao sucesso. Consulte o artigo de Alan MacCormack.
Ignore os Detalhes de Antemão
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.
