Eu sei que a metáfora da construção civil tem sido utilizada para referenciar modelos mais rígidos, porém, analisando de um novo ponto de vista, o de um pedreiro, eu vejo uma analogia interessante.
Já são conhecidas as inúmeras comparações entre "engenharia" de software e engenharia civil: pilares da arquitetura Java EE, diagramas como planta e código como a casa construida, a função de arquiteto, engenheiro e a famosa frase que o programador é o pedreiro do software... Tudo isso nos perseguiu muito nos últimos 20 anos e muitos dos profissionais de T.I. não gostam dessas comparações.
O fato é que influenciado por tais comparações, há exatamente 9 anos atraz quando tinhamos uma equipe enxuta e dinâmica de desenvolvimento, eu costumava dizer: "Vamos fazer uma imersão em uma obra e entender quais são as razões de uma casa ser levantada aparentemente com menor esforço organizacional e corportativo que um software". Nunca fizemos.
Porém refletindo recentemente achei que isso vem mais ainda a tona com toda a onda de metodologias ágeis e resolvi escrever mais uma paródia:
"Certa vez um experiente desenvolvedor de softwares tirou férias para reformar sua casa de praia. Sendo sua personalidade um mashup de geek com work-a-holic, não parava de pensar em métodos de construção de softwares, afinal de contas aquele cenário de reforma era bastante sugestivo.
Neste dia a obra seria iniciada e tal desenvolvedor já havia passado as principais especificações da reforma: abrir uma nova porta de passagem, pintar, reformar madeiras e colocar piso em uma nova área.
Preocupou-se o dono da casa com o fato do orçamente ter tido como base tão poucas especificações: ninguém perguntou a cor da tinta a ser usada, ninguém perguntou se o piso seria simples ou porcelanato, mas enfim, o valor era justo.
As 8:00 chegou a equipe pronta para trabalhar, e o "pedreiro mais experiente", reuniu todos rapidamente (e em pé), e definiou como seria o andamento da obra naquela semana e quais seriam os principais objetivos.
Em 15 minutos todos estavam trabalhando.
E o dono da casa continuou a observar o trabalho de pessoal, em especial chamou a atenção que a quebradeira para abrir a nova porta estava sendo feita por dois pedreiros que se revezavam.
Religiosamente eles pararam de trabalhar as 17:00 horas.
Algumas dúvidas surgiram no dia seguinte, mas como o proprietário estava sempre lá, rapidamente puderem resolve-las.
E assim a obra foi seguindo até sua conclusão em 3 semanas: toda semana definiam o que seria feito, no término da semana eles faziam um pequeno churrasco na sexta depois do expediente, trabalhos pesados ou complexos eram feitos em duplas sempre, não havia alguém que simplesmente coordenasse tal processo. Tinha sim um pedreiro "master" que era um líder nato e carismático.
O desenvolvedor de softwares e dono da casa ficou satisfeito com o resultado apesar dos pequenos desvios (que alguns ele mesmo causou) e também uma diferença no valor cobrado pelos serviços.
Depois de 3 semanas cuidando da obra, quando voltou para sua empresa na semana seguinte ele estabeleceu novas regras:
• Vamos fazer uma reunião no começo da semana para definir as funcionalidades que queremos prontas no final dela;
• Se atingirmos esta meta, vamos fazer um churrasco, opa, na av. Paulista não rola. Vamos tomar sorvete por conta da empresa.
• Todo software complexo será programado por dois;
• Teremos um desenvolvedores mais experiente e com mais espirito de liderança que conduzirá a equipe
• O cliente deverá sempre estar disponível para tirar nossa dúvidas
• Todos trabalharão apenas 8 horas por dia
E para finalizar ele refletiu: se isso der certo, vou ter que dar um nome.
FIM.
Vinicius
http://twitter.com/vsenger
http://program-me.ning.com
http://www.eletronlivre.com.br
Já são conhecidas as inúmeras comparações entre "engenharia" de software e engenharia civil: pilares da arquitetura Java EE, diagramas como planta e código como a casa construida, a função de arquiteto, engenheiro e a famosa frase que o programador é o pedreiro do software... Tudo isso nos perseguiu muito nos últimos 20 anos e muitos dos profissionais de T.I. não gostam dessas comparações.
O fato é que influenciado por tais comparações, há exatamente 9 anos atraz quando tinhamos uma equipe enxuta e dinâmica de desenvolvimento, eu costumava dizer: "Vamos fazer uma imersão em uma obra e entender quais são as razões de uma casa ser levantada aparentemente com menor esforço organizacional e corportativo que um software". Nunca fizemos.
Porém refletindo recentemente achei que isso vem mais ainda a tona com toda a onda de metodologias ágeis e resolvi escrever mais uma paródia:
"Certa vez um experiente desenvolvedor de softwares tirou férias para reformar sua casa de praia. Sendo sua personalidade um mashup de geek com work-a-holic, não parava de pensar em métodos de construção de softwares, afinal de contas aquele cenário de reforma era bastante sugestivo.
Neste dia a obra seria iniciada e tal desenvolvedor já havia passado as principais especificações da reforma: abrir uma nova porta de passagem, pintar, reformar madeiras e colocar piso em uma nova área.
Preocupou-se o dono da casa com o fato do orçamente ter tido como base tão poucas especificações: ninguém perguntou a cor da tinta a ser usada, ninguém perguntou se o piso seria simples ou porcelanato, mas enfim, o valor era justo.
As 8:00 chegou a equipe pronta para trabalhar, e o "pedreiro mais experiente", reuniu todos rapidamente (e em pé), e definiou como seria o andamento da obra naquela semana e quais seriam os principais objetivos.
Em 15 minutos todos estavam trabalhando.
E o dono da casa continuou a observar o trabalho de pessoal, em especial chamou a atenção que a quebradeira para abrir a nova porta estava sendo feita por dois pedreiros que se revezavam.
Religiosamente eles pararam de trabalhar as 17:00 horas.
Algumas dúvidas surgiram no dia seguinte, mas como o proprietário estava sempre lá, rapidamente puderem resolve-las.
E assim a obra foi seguindo até sua conclusão em 3 semanas: toda semana definiam o que seria feito, no término da semana eles faziam um pequeno churrasco na sexta depois do expediente, trabalhos pesados ou complexos eram feitos em duplas sempre, não havia alguém que simplesmente coordenasse tal processo. Tinha sim um pedreiro "master" que era um líder nato e carismático.
O desenvolvedor de softwares e dono da casa ficou satisfeito com o resultado apesar dos pequenos desvios (que alguns ele mesmo causou) e também uma diferença no valor cobrado pelos serviços.
Depois de 3 semanas cuidando da obra, quando voltou para sua empresa na semana seguinte ele estabeleceu novas regras:
• Vamos fazer uma reunião no começo da semana para definir as funcionalidades que queremos prontas no final dela;
• Se atingirmos esta meta, vamos fazer um churrasco, opa, na av. Paulista não rola. Vamos tomar sorvete por conta da empresa.
• Todo software complexo será programado por dois;
• Teremos um desenvolvedores mais experiente e com mais espirito de liderança que conduzirá a equipe
• O cliente deverá sempre estar disponível para tirar nossa dúvidas
• Todos trabalharão apenas 8 horas por dia
E para finalizar ele refletiu: se isso der certo, vou ter que dar um nome.
FIM.
Vinicius
http://twitter.com/vsenger
http://program-me.ning.com
http://www.eletronlivre.com.br
Comentários
fazíamos reuniões às quartas, pela manhã, uma hora para que cada um soubesse O QUE fazer, PORQUE FAZER, quais os recursos e nosso 'dead-line'. Funcionava muito bem, mas gerentes são gerentes.. o nosso achava que aquela hora era completo desperdício de tempo que poderiamos empregar melhor "trabalhando, como todo mundo".
Era MUITO produtivo.. mas sabe como é, não aparecia como construir uma parede ou abrir uma porta.
o q certamente seria mais assertivo, seria termos construtoras de software, ao invés de termos fábricas de software. Isso muda td; alguêm aqui já conseguiu ver ao menos uma sombra de um software sendo produzido em linha de produção? sendo fabricado tal como um carro ou um laptop...
Vale notar que, assim como no mundo de TI, tem as equipes boas e as ruins, por isso, há pedreiros ágeis e pedreiros cascateiros. :)
Isso é algo pelo qual, nos desenvolvedores, temos que fazer força para mudar: fábrica não tem nada a ver com desenvolvimento de software, nada!
;-)