Esse é um tema que já causou muita polêmica e AINDA causa, como vemos em posts como "Documentação Ágil" e "E a documentação?". Poderia citar vários outros.
Entretanto, vai aqui alguns mitos sobre documentação que ainda incomodam pessoas da nossa área:
1) A documentação serve para Especificar detalhadamente o funcionamento do sistema, pois dessa forma os Analistas de Negócio repassam algumas necessidades dos usuários para os desenvolvedores enquanto trabalham na especificação de novas funcionalidades.
Mera ilusão!!! A documentação, neste caso, está servindo como um mecanismo de comunicação entre os analistas e os desenvolvedores. Eu poderia aqui citar várias referências de profissionais que aboliram esse mecanismo de comunicação a muito tempo. Mas, em vez disso, faço as seguintes indagações:
a) Como desenvolvedor, você prefere conversar com o analista e entender as funcionalidades em 2 horas de "papo" ou prefere passar o dia lendo uma especificação de caso de uso extensa e tentar interpretar o que foi dito, ou melhor, escrito pelo Analista?
b) Como Analista (seja sincero!!), você acha que conseguiu entender perfeitamente o problema do usuário para chegar ao ponto de escrever um bolo de documentos e garantir que isso não vai mudar assim que o usuário ver o que foi implementado? Além disso, temos que ser sinceros, as pessoas que escrevem documentos de especificação não são nenhum Luís Fernando Veríssimo ou um Ariano Suassuna.
c) Como Stakeholder, você se sente a vontade para esperar que toda ou grande parte da análise seja escrita para entrar em desenvolvimento e só depois ter alguma funcionalidade do sistema pronta (ou não)?
Bom, proponho aqui (isso muitos já fizeram também) algumas ferramentas que podem substituir um documento extenso de análise: Boca, mão, pincel e quadro branco. Nesse caso, até uma foto do quadro ou um rascunho no papel podem servir para comunicação das idéias por trás de uma funcionalidade e, ao final do projeto, pode-se até criar uma documentação mais formal se for o caso
2) Deve-se ter uma documentação completa para garantir que, quando os atuais integrantes da equipe sejam substituídos, seus sucessores possam ter uma referência do que foi feito.
Ótimo!!! Mas não existe melhor documentação do que um código bem feito, e isso pode ser alcançado com algumas práticas como Programação em Par e Refatoração Contínua. No entanto, se mesmo assim houver a necessidade de uma documentação, deixe para fazer ao final do projeto, pois a probabilidade de mudanças nessa documentação será mínima.
Enfim, espero que os profissionais da área de TI possam focar muito no produto final em vez de se preocupar com atividades "burrocráticas" e desnecessárias. Não somos escritores de software, somo DESENVOLVEDORES de software.
sábado, 9 de maio de 2009
Como usar Scrum sem ser Ágil?
Depois de uma conversa com um amigo, decidi escrever este post para esclarecer alguns pontos em relação a Scrum e Agile, segundo meu ponto de vista. Antes de apresentar os pontos de interesse, vou mostrar parte deste diálogo:
Ele: "Paulo, então ficamos combinado de entregar, ao final deste Sprint, o documento inicial de requisitos e regras de negócio?"
Eu: "Seria bom nós já entregarmos algumas funcionalidades implementadas, pois é isso que prega o Scrum"
Ele: "Nada disso, o Scrum funciona para o gerenciamento de qualquer projeto e pode ter como resultado/meta um documento com os requisitos"
Alguns podem me crucificar, mas isso me fez achar que ele, de alguma maneira, tinha razão. Realmente nós podemos ter como resultado final de um Sprint qualquer produto que dê o máximo de valor para o cliente, mesmo que seja um documento.
No entanto, apesar do o Scrum ter surgido antes do Manifesto Ágil, não consigo ver seu uso (pelo menos na área de TI) sem que esteja atrelado às premissas básicas descritas no manifesto. E uma delas é: Software funcionando é mais importante que Documentação Extensa. Se o seu cliente acha que documentação é mais importante, aconselho a leitura do post "Product Owner: Um De$graçado Ganancio$o", do nosso amigo Rodrigo Yoshima.
Dessa forma, esse simples post vem deixar clara minha opnião de que Scrum não é ágil por si só. Ele precisa das pessoas certas para ser ágil. E se estas trouxerem algumas práticas da XP como TDD, pair programming, integração contínua e o que eu chamo de AQA (Agile Quality Assurance), melhor ainda.
Ele: "Paulo, então ficamos combinado de entregar, ao final deste Sprint, o documento inicial de requisitos e regras de negócio?"
Eu: "Seria bom nós já entregarmos algumas funcionalidades implementadas, pois é isso que prega o Scrum"
Ele: "Nada disso, o Scrum funciona para o gerenciamento de qualquer projeto e pode ter como resultado/meta um documento com os requisitos"
Alguns podem me crucificar, mas isso me fez achar que ele, de alguma maneira, tinha razão. Realmente nós podemos ter como resultado final de um Sprint qualquer produto que dê o máximo de valor para o cliente, mesmo que seja um documento.
No entanto, apesar do o Scrum ter surgido antes do Manifesto Ágil, não consigo ver seu uso (pelo menos na área de TI) sem que esteja atrelado às premissas básicas descritas no manifesto. E uma delas é: Software funcionando é mais importante que Documentação Extensa. Se o seu cliente acha que documentação é mais importante, aconselho a leitura do post "Product Owner: Um De$graçado Ganancio$o", do nosso amigo Rodrigo Yoshima.
Dessa forma, esse simples post vem deixar clara minha opnião de que Scrum não é ágil por si só. Ele precisa das pessoas certas para ser ágil. E se estas trouxerem algumas práticas da XP como TDD, pair programming, integração contínua e o que eu chamo de AQA (Agile Quality Assurance), melhor ainda.
Assinar:
Postagens (Atom)