24 setembro 2008

Agile and The Matrix

Foi lendo o Fragmental que me deparei com essa comparação, em um dos comentários:

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!


Adoro analogias, mas também acho que essa deixou um pouco a desejar. A resposta do Philip, sintetizando bem grosseiramente, foi:

- Documentos são caros;
- É difícil prever o futuro;
- Filmar é muito caro, pode valer a pena o preço para tentar adivinhar o futuro;
- Software é flexível;

Não descordo de nenhum dos pontos dele (embora tenha achado o terceiro meio confuso), mas gostaria de fazer as minhas considerações também. Como adoro analogias, achei que o assunto merecia um post só pra mim. ;-) [ licença Philip, licença Augusto. ]


O meu ponto de vista:

Em primeiro lugar, não acho que o story-board por si só configure um waterfall. Story-boards são uma ferramenta maravilhosa, pois conseguem expressar o projeto de forma âmpla. Mas apenas de forma âmpla, não detalhada.

Os detalhes serão, sim, pensados just-in-time. Quanta luz será usada? Incidindo em que posição/direção? Como os atores devem se posicionar? Devem falar essa frase mais ou menos rápido? Com que expressão? Com que tom de voz? E o penteado? Muitos e muitos detalhes são deixados pra última hora, não tem jeito. Ninguém consegue imaginar todos os detalhes com antecedência. E nem seria muito inteligente fazer, pense um pouco...

Esse não é um caso BDUF (Big Design Up-Front), mas de EDUF (Enough Design Up-Front). A diferença é sutil. (Engraçado, olha o primeiro resultado que o Google traz para enough: good enough)

O Philip escreveu que, "[no caso do filme,] pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica." Mas acho que, no caso do software, o problema é ainda mais crítico. Pois um pequeno detalhe, descoberto em cima da hora, pode acarretar uma mudança gigantesca no custo do projeto (guardadas as proporções).

É como se, na hora de analisar a iluminação da última cena, descobríssemos que o filme todo precisará ser filmado novamente porque senão ninguém vai assistir o filme, e o dinheiro terá sido praticamente jogado no lixo.

No caso do filme, é até difícil imaginar um cenário desses. Mas em software, esse tipo de coisa acontece praticamente todo dia. Não há como evitar as mudanças, pelo menos se estamos querendo desenvolver algo que realmente tenha qualidade, no sentido de maximizar o retorno do investimento.

O problema é mais simples que isso: não dá pra adivinhar o futuro e pronto. Não importa quanto dinheiro se esteja disposto a gastar.

Se não podemos prever as mudanças, e evitá-las é contra-producente (pra não dizer estúpido), a única solução possível é se preparar para a adaptação às mudanças (Embrace Changes): um dos pilares do desenvolvimento de software moderno.

05 setembro 2008

Scrum funciona sem XP?

Fui ouvir falar de Scrum bem depois de já ter batido muita cabeça tentando convencer as pessoas a usarem XP. Parece que de uma hora pra outra todos os mesmos conceitos que causavam pânico a qualquer gestor derrepente se tornaram moda. É como se o diabo tivesse sido promovido a arcanjo da noite pro dia, só porque mudou de nome (e de roupa). Não tenho dúvidas, Scrum é muito mais "vendável" que XP. Agora, cá pra nós, dá pra aplicar gerenciamento ágil com segurança sem usar práticas de desenvolvimento que o suportem?

Mesmo que se afirme que o Scrum tenha sido criado antes do XP, não foi assim que vi as coisas acontecerem aqui no Brasil. De um jeito ou de outro, não é esse o ponto central nesse post. Também não quero entrar no mérito sobre o Scrum tratar-se de uma disciplina mais âmpla, aplicável a outras áreas, além do desenvolvimento de software. Pretendo menos ainda atiçar uma disputa entre os dois ou dizer que "XP é melhor do que Scrum" ou outros maniqueísmos babacas (com o perdão da(s) palavra(s)).

Então a relação mais simples a se delinear entre esses dois, sob o ponto de vista de seus conteúdos, me parece ser:


E sob esse ponto de vista XP seria mais âmplo que Scrum. Mesmo porque as práticas de planejamento do XP são, em sua essência, Scurm - puro e escarrado. A menos de certos detalhes (ao meu ver) irrelevantes, não há o que tirar nem pôr.

Agora, falando especificamente sobre desenvolvimento de software, me parece arriscadíssimo aplicar o gerenciamento ágil sem técnicas como desenvolvimento orientado a testes, integração contínua, refactoring, etc.

Como posso me dar ao luxo de deixar o cliente escolher a ordem em que as funcionalidades serão desenvolvidas, ou permitir que a equipe levante os detalhes do sistema just-in-time, na hora de codificar?

Não há como implementar um software dessa forma sem se deparar volta e meia com algum detalhe que não havia sido pensado, suposições erradas a respeito do negócio, modelagens incoerente e outros mal entendidos. Aprendizado é uma palavra-chave aqui, certo?


Trabalhar dessa forma, portanto, pressupõe que o design do código volta e meia terá que passar por algumas "reformulações" (como se traduz refactoring mesmo?). Mas como pode uma equipe (de seres humanos) mexer na estrutura de um sistema poucos dias antes de uma entrega de um produto que deve estar "em qualidade de produção", relativamente sem bugs?

Alguém se arriscaria a mudar o modelo relacional do banco de dados de uma aplicação crítica, que já está em produção, e deve permanecer lá, sem erros, depois do upgrade daqui a duas semanas? Ou melhor: alguém se arriscaria a uma coisa dessas sem ter uma bela suite de testes automáticos pra dar segurança?

Costumo dizer que programar sem testes automáticos é o mesmo que um eletricista mexer em um painel de disjuntores sem ter as emendas dos cabos isoladas com fita. Vc botaria a mão ali?


Sinceramente, não me parece seguro aplicar Scrum a um projeto de software sem testes automáticos, integração contínua, design incremental, refactoring, e programação em par.

Na verdade, não me parece seguro aplicar coisa alguma sem isso! Não é privilégio do Scrum, claro.

Meu objetivo não é "falar mal" do Scrum.
Como li n'alguma coisa do ViniciusTelles (não lembro onde), "não tenho nada contra Scrum. Adoro Scrum! Tanto que o uso como metodologia de planejamento em meus projetos XP" (ou alguma coisa parecida com isso).

O que me deixa "encafifado", simplesmente, é que é muito comum as pessoas se apaixonarem por Scrum e morrerem de preconceitos de XP. Como pode?

(Veja também minha opnião sobre Agile x PMBok & cia)