Achei uns artigos muitos bons navegando por ai.
Um dos que me "chocou", chamou mais a atenção, espantou... sei lá, um dos que gostei foi este artigo.
Ele me levou a lembrar que lá atrás na faculdade, quando nos era ensinado Análise de sistemas num esquema puramente WaterFall, utilizando abordagens Bottom-Up e Top-Down, nos era dito também, que para construir software deveríamos fazer como o pessoal de Construção Civíl, o qual fazia todo o projeto de um prédio, e depois começava a construir. Se eles conseguem/podem fazer isso por que um simples software não pode ser feito assim?!
No Artigo do primeiro link, ele começa contando uma historinha, contando quando foi para uma construção, ou para uma aula de engenharia civíl, não entendi direito, mas vou traduzir aqui:
"O que você está fazendo aqui?" - Eles perguntaramQuem já fez alguma construção, ou já precisou de que alguém construisse algo para você (o que é bem mais provável, visto que somos desenvolvedores de software), sabe que a obra sempre custa mais do que no início seu pedreiro disse que custaria, e a maldita obra parece não ter fim. Minha mãe está passando por uma reforma em sua casa, e já fazem quase 2 meses, isso que era pra terminar em 2 semanas. Sem contar, que obras externas sempre dependem das condições climáticas.
Eles eram Encarregados, Gerentes de Projeto, Superintendentes, e estavam fazendo um projeto no Lean Construction Institute (LCI) (o que é isso ai não tenho a mínima idéia, mas eu acho que era pra ser conhecido). Verdade, que que o cara estava fazendo la?
Então o cara começou a explicar: "No desenvolvimento de Software, nos é ensinado que devemos gerenciar projetos como os projetos de Construção Civíl. Onde uma construção é planejada no início, custos e prazos são previsíveis, e os clientes recebem o que eles esperam receber."
Silêncio... "Você está brincando, certo?" "Não! Verdade, é assim que nos é ensinado."
Então, incredulidade torna-se em grades gargalhadas!
Outro artigo que achei legal, simples e direto foi este de Joel Spolsky. Tem ainda este.
Mas realmente uma Analogia mais real é a que Marcos Pereira, descreveu em: Desenvolver Software é igual a dirigir. Um dia ainda será assim em todo o lugar, e a paz mundial reinará! Mas até agora, poucas pessoas tem se beneficiado disso.
Outra pedrada, é um post do Thiago Arrais, onde ele diz que Fábricas de Software são uma analogia levada longe demais.
Acho que uma outra analogia boa para desenvolvimento de software como é feito atualmente neste modelo de WaterFall, está na agricultura. De que depende a agricultura e que o seu plantio tenha um bom rendimento? (Porque sejamos francos, tudo gira em torno do dinheiro. Ok, eu não sou nenhum agrônomo, mas vou tentar não falar merda)
- De um bom preparo do solo no princípio - Ter bons profissionais, Análise e Arquitetura inicial
- Plantar em época correta. - Saber o que usar.
- Cuidado no início, com pesticidas, fungicidas e tudo mais. - Ser maleável quanto a arquitetura incial, pois ela pode mudar conforme o entendimento do que é pra fazer vai aumentando.
- Rezar para não chover demais, nem de menos, em tempo de germinação. - Literalmente, rezar para que o entendimento inicial, realmente tenha previsto quase tudo, e que não surjam problemas muito complicados
- Saber a hora de colher.
- Rezar para não chover demais nem de menos em época de colheita. - Rezar para mostrar pro cliente na hora certa o software, para que ele não se decepcione de início. =)
- Conseguir estocar ou vender em uma época que o preço está bom. - Ter um ótimo departamento de Relação com o cliente, para fazer ele enxergar o software mais belo do que realmente é. =)
Enfim, eu ainda trabalho em um modelo WaterFall, não tenho como mudar isso facilmente. Não vou ficar falando por ai, que sou contra tudo, que vamos revolucionar o mundo, matar todos os gerentes que não pensam igual a nós, como muitos falam por ai. Mas quem sabe com o tempo, ou conhecimento necessário, ou status necessário, ou apoio necessário, ou todas essas coisas juntas, eu consiga ir fazendo esta mudança.
E por fim, não poderia faltar aquela velha analogia de desenvolvimento de software.
7 comentários:
Eu gosto de pensar que desenvolvimento de software também é fazer todo o projeto e depois partir para a construção. A diferença é que a construção é extremamente barata porque é executada por máquinas em segundos ou minutos e não por pessoas em semanas ou meses.
Isso nos permite projetar, construir e reconstruir nossos produtos centenas de vezes ao dia. Seria simplesmente desperdício ignorar essa habilidade.
Escrevi um texto uma vez sobre isso (não sei se o link vai ser publicado, mas lá vai):
http://thiagoarrais.wordpress.com/2006/03/24/reconstruindo-2/
Legal este seu outro post Thiago. É verdade, refazer um software é fácil. Apesar de nós acharmos custoso, não temos como comparar com a reconstrução de um prédio.
De certa sua idéia de planejar tudo antes de construir está correta, porém esse planejamento tem que ser aberto a mudanças, que com a mais absoluta certeza ocorrerão.
Mas muitas outras questões entram nesta, e creio que a principal é a financeira. O cliente, quer mais, pelo mesmo preço. Pois quando não terminamos de pagar uma coisa fica fácil exigirmos mais senão não pagamos o resto... hehehe
Enfim, não adianta me extender neste tipo de discussão, pois há muiiito pano pra manga =)
Valeu
Se a gente observar as metodologias de desenvolvimento de software todas elas possuem um pouquinho do "iterativo e incremental".. Principalmente com a ideia de sair das especificações e requisitos e ir evoluindo ate o release..
Porem o desenvolvimento em cascata, não pode ser considerado de forma purista.. Afinal é normal durante outra fase do processo, a descoberta de novos requisitos. Existe a necessidade de retroagir com fases que ja foram realizada, ou melhor re-realizar fases novamente... E por analogia é dificil conceber que uma construção civil, em seu acabamento deva re-realizar o fase das fundações... Então nem sempre a analogia é silogismo com o real conceito de que queremos exprimir..
Logo a analogia para desenvolvimento de software vai ficar simplismente "ao grosso modo"..
O modelo em cascata, com retro-ação a fases passadas tem sua visao melhorada no modelo academico da espiral.. Que por sinal inspirou o UP, e logo depois o RUP..
Não defendendo o burocratico RUP, (que documenta ate os peidos dos desenvolvedores) mas pegando a sua "alma" e se adicionarmos uma pitada a mais no Principio de Pareto (80-20%) "especifica 80%,elabora,implementa e faz a recursão" temos em menos tempo, mais qualidade que o cascata purista...
E o interessante notar que o principio de pareto é mais facil de observarmos o silogismo pela analogia no nosso cotidiano, afinal em tudo nos começamos generalizando, depois detalhamos, depois detalhamos o detalhe, e detalhamos... detalhamos ato o fim..
Silvião
silviao@panteon.com.br
Fala Silvião!
Pois é. É o que realmente acaba acontecendo na prática, é essa iteração das fases. O problema principal, é que quando projetos são vendidos eles utilizam-se da especificação para mostrar ao cliente, quanto tempo levará e qual será o custo total do projeto. E a partir daquela especificação as coisas começam a ser mais detalhadas, e problemas a serem encontrados durante a evolução do projeto, sem contar nas "coisinhas" adicionadas pelo cliente durante a produção. Isso quase que 100% das vezes ocasiona os tão conhecidos atrasos na entrega, ou no trabalho 24/7 dos profissionais envolvidos, ou ainda o que é pior, adicionando mais gente ao projeto achando que com "nove grávidas se faz um filho em um mês".
O que Metodologias Ágeis pregam é justamente este desenvolvimento iterativo com releases e sprints curtos. Porém, o que mais acho interessante é a parte de o cliente "pagar" por produto recebido. O que achei bem bacana, foi este Modelo de Contrato de Escopo Negociável. Onde literalmente o projeto vai ser feito em partes e no final o cliente recebe mesmo aquilo que ele pagou para ter, nem mais nem menos =) (ao menos em teoria =])
Como eu sempre digo, ser completamente purista/radical não funciona, em nenhum aspecto da vida.
Analogias são boas mesmo, porém, eu acho que ainda muito é ensinado por quem não sabe realmente fazer. O que ocasiona este tipo de pensamento bitolado na construção de um edifício.
Jujo
Essa relação Analista e Cliente da pra ter uma outra analogia com o psicoterapeuta e o paciente..
O paciente deitando no divã e "contando seus problemas" e o analista "analisando quais são os problemas", que não necessariamente são esses contados pelo cliente.... rs
Quanto as praticas de XP, voce pode analisar que desde o momento que alguem aprende a programar em alguma linguagem (os hello world da vida), a sua primeira metodologia, a primaria e instintiva e que todo mundo usa é um XP...
O que eu acho engraçado é que falam que XP nao funciona em grandes projetos. E reza a "lei" que é verdade, por causa da pouca documentação em comparado a outras metodologias e bla bla bla..
Se isso fosse TOTALMENTE verdade, quem trabalha em grandes projetos deveria ter que "reaprender a programar"????
Melhor não neh!!!!!!
Silviao
Concordo contigo.
O instinto do pelego é começar a programar. Com isso ele começa a achar os problemas, e via aprimorando sua técnica. Vai se conhecendo melhor, melhorando suas métricas e tudo mais.
Quer coisa mais subjetiva que peão perguntar pra vc: "Quanto tempo leva para vc fazer um cadastro de X?", hahahaha é complicado, mas é claro qeu é necessário ter este tipo de métrica, porém só o tempo dirá.
Com relação ao XP, por isso que o tal do SCRUM tem ganhado nome. Porque ele pega muita coisa do XP purista, e aplica em uma coisa Ágil, mas mesmo assim mais "organizada" e documentada digamos assim.
Mas o principal problema está em quebrar paradigmas mesmo. Quem sabe já não estamos com uma nova geração que já começará aprendendo que o modo como o instinto manda ele fazer é o mais correto mesmo, que ele não precisa aprender nenhuma grande metodologia milagrosa =)
Esperamos pelo que virá =)
Sim, provavelmente por isso e
Postar um comentário