Eu bato nesta tecla frequentemente, mas nunca deixo de ficar espantado em como as pessoas conseguem fazer a associação completamente errada ao tentar adequar a posição de desenvolvedor de software em algum lugar. Existe uma pressão social para que enquadremos esta profissão em algum critério, preferencialmente apenas estendendo uma já existente. Eu não tenho nada contra a princípio, na verdade deixo sempre bem claro que na minha visão desenvolvimento de software é uma engenharia, uma ciência destinada a resolver problemas.
Eis que aí mora o perigo. Ao associar a profissão com engenharia logo se vê gente que tenta adequar tudo a esta área, como se houvesse apenas uma maneira de fazer engenharia. O maior problema, entretanto, é que o desenvolvimento de uma solução em software é diferente do da maioria das engenharias (talvez não da química… preciso pesquisar sobre isso). Numa engenharia tradicional (civil,agrónoma, sanitária…) geralmente você precisa entregar um projeto que vai ser executado por outros profissionais, quase sempre profissionais que não possuem o grau de engenheiro, ou seja: não saberiam resolver os problemas por si só. A implementação do projeto tem que seguir o plano minuciosamente, primeiro porque a mão-de-obra teoricamente não possui conhecimento suficiente para tomar decisão em caso de dúvida e em segundo lugar porque um projeto deste geralmente é algo big bang. Você não consegue construir meia ponte, deixar uns carros passarem por uma semana e ajustar o projeto. precisa construir a ponte toda, do início ao fim, de uma só vez e seja lá o que Zahl quiser.
Bem, detesto ser estraga-prazeres de tantos mas não é assim que software funciona. Há muito tempo que descobriram que a melhor maneira de produzir software é de maneira iterativa e incremental. Este é o princípio básico de RUP, Scrum e XP, só para citar algumas metodologias/processos de desenvolvimento. Nestes processos sabe-se muito bem que o nível de acerto em um projeto BDUF, que segue o modelo dos engenheiros do parágrafo anterior, é passo certo para o fracasso. Ok, mentira minha, certo não é. Eu conheço algumas poucas empresas, de ramos muito específicos (geralmente gente que lida com regulamentação governamental pesada) que consegue levar este modelo. Aliás, sabe qual é esse modelo onde você produz uma especificação antes e escreve código depois? Waterfall, ou Cascata.
Eu me lembro em algum momento de 2002 tendo uma aula na faculdade sobre este modelo. O professor, uma pessoa com curriculum bem razoável e instrutor certificado IBM para RUP, ou algo assim, desenhou o velho diagrama espiralado no quadro e escreveu embaixo uma lista copiada da apostila sobre vantagens e desvantagens dos dois modelos. Em seguida ele começaria a descrever o modelo iterativo incremental desta maneira:
Primeiro, é feita a análise do problema. A análise é, certamente, a parte mais importante de todo o processo. Neste momento são identificados os problemas, os atores, os casos de uso e tudo mais que é necessário para chegarmos na próxima etapa, o projeto do sistemas.
Na fase de projeto os projetistas pegam o trabalho do analista -que deve ser completo o suficiente para que o projetista faça seu trabalho sem ter que esclarecer qualquer dúvida- e criam o modelo da solução para aquele problema, criando diagramas de interação entre as classes e seus estados.
Logo em seguida os codificadores pegam este projeto e escrevem software. O sistema assim está entregue. Notem que um sistema feito desta forma divide corretamente as responsabilidades e gera código de qualidade e bem documentado. Nenhum programador ninja sai escrevendo código por aí sem que antes tudo seja validado pelo analista, projetista e arquiteto do sistema.
Naquela época eu sentia que havia algo errado mas não sabia dizer o que era. Apesar dele não ter explicado direito o tal espiral se isso era diferente do waterfall esta descrição não fazia sentido. Ele descreveu o processo de waterfall, com uma única peculiaridade de atribuir papéis aos participantes. Ele estava errado, não tinha entendido nem mesmo o que era modelo iterativo incremental, muito menos o RUP no qual se certificara.
Quem olha o gráfico das baleias corcundas pode realmente ter uma impressão desta, mas eu realmente espero que alguém que seja um instrutor certificado, ou mesmo um instrutor não certificado, saiba que mais importante que a figura é o embasamento literário. Os livros sobre o tema vão te explicar o que aquelas curvas significam e, ao contrário do senso comum, elas não significam fases no seu projeto. Ok, nova mentira, elas significam sim, até são chamadas de phase, mas o meu ponto é que este conceito não é o mesmo que você vai ouvir por aí.
Uma fase no RUP indica apenas um período de tempo com uma dada característica mais marcante. Na fase de Inception, por exemplo, a atividade mais marcante é a de modelar o negócio e trabalhar requisitos. Isso não significa que você não vai coletar e analisar requisitos mais tarde pelo contrário. indica apenas que a maior parte do trabalho naquele tempo é destinada a esta atividade. E por quê? Porque precisamos de modelos de análise completos? Não! Simplesmente porque naquela altura do campeonato não sabemos direito o que vamosconstruir e estamos tentando entender mais ou menos para começarmos a trabalhar.
Em RUP geralmente as funcionalidades com maior risco ou impacto arquitetural serão implementadas primeiro, XP e Scrum possuem uma estratégia que eu considero muito mais inteligente neste aspecto que é trabalhar logo de cara pequenos pedaços que o cliente escolher. No fim das contas o efeito é bem semelhante: começamos a trabalhar no sistema pedaço por pedaço, descobrimos os pontos que precisam ser ajustados, os ajustamos e seguimos em frente: o desenvolvimento iterativo é completamente baseado feedback que uma iteração dá para a equipe. XP e Scrum possuem diversas características mais interessantes que as implementações comuns de RUP para boa parte das pessoas (iterações curtas, planning game, reuniões super-ultra-rápidas diárias…) mas eu diria que estão ganhando tanto terreno e tão rápido pelas falhas nas pseudo-implementações de RUP que os instrutores certificados, appraisers CMM/CMMi/MPS.BR/Sigla-de-3+x-letrinhas-que-estiver-na-moda-este-mês e demais membros da fauna de processos de desenvolvimento de software insistem em aplicar. Após alguns anos se enganando o mercado começa a acordar e procura um novo salvador da pátria, nesta armadilha está caindo um conceito que é, na minha opinião, uma evolução pura e simples dos processos existentes (mais foco nas pessoas -em vez de temer o ‘programador ninja’ fazer com que o conhecimento se espalhe por todos- e em resultados palpáveis e obtidos rapidamente, por exemplo), processos estes que nunca foram implantados de fato na maioria das empresas, destas que compraram uma caixinha de pseudo-RUP e ganharam um belo waterfall com zilhões de documentos para preencher todo dia.
E o meu maior medo agora é de estar vendo isso acontecer com processos ágeis. Durante o excelente curso de Certified Scrum Master (onde a certificação é algo simbólico, não quer dizer nada além de que você teve x horas de treinamento, por isso pode tirar da sua assinatura de e-mail, por favor?) ministrado pela Teamware lá no Rio conversamos muito sobre isso no cocktail. Já se pode ver empresas muito conhecidas da comunidade por prometer mundos e fundos, entregar (quando entrega) software de péssima qualidade e aos olhos da cara que de repente viu no Scrum, por exemplo, vantagem competitiva.
Como nós vamos conseguir saber se estas pessoas entenderam o mínimo necessário? Não vamos. Apenas podemos nos preparar para que quando estas figurinhas aparecerem com seus Certified Scrum Master, Certified Rational QualquerCoisa, PMP, CMMi, MPS.BR e tudo mais que couber no cartão de visitas nós possamos fazer uma avaliação real, sem nos basearmos nas baboseiras que sempre são citadas.
Fazer este tipo de avaliação não é difícil. Se você não entende a vantagem competitiva e está apenas curioso pergunte ao fornecedor o que ele te oferece de diferente. Ouça bem o que ele lhe diz, estude. Caso não saiba avaliar contrate um consultor e peça referências em um fórum como o do GUJ (onde temos o maior prazer em rechaçar fornecedores ruins em geral). Peça para fazer uma visita ao ambiente de trabalho, qualquer menção da palavra ‘fábrica’ já é sinal de eliminação do processo seletivo: fábricas são um modelo que não funciona para software (pense numa fábrica de notícias num jornal. Funcionaria? É o mesmo princípio: atividade criativa não se serializa ou controla desta forma) e são o extremo oposto de metodologias ágeis (não necessariamente do RUP, mas mesmo assim a empresa deve perder muitos pontos na avaliação). A empresa tem um portfólio no site, todas têm, então ligue para os clientes anteriores. De surpresa, claro, não avise ao fornecedor ou ele irá te indicar apenas referências que ele sabe o que dirão.
Dá trabalho, mas é melhor gastar um mês fazendo a seleção de um fornecedor decente do que ficar anos e anos se lamentando de um projeto furado.
Hum…. os modismos com suas letrinhas bacanas estão realmente na mira dos geeks!
Escrevi algo em http://www.midstorm.org/~telles/2007/07/01/intencionalidades/
sobre o texto que deu o que falar em http://www.linhadecodigo.com.br/artigos.asp?id_ac=1262
Parabéns pelo artigo. A cada dia eu me convenço mais de que comprar software é uma tarefa árdua e que desenvolver software é muito mais do que abrir o manual da última moda e tentar disfarçar uma implementação porca que pode em muitos casos nem ser a mais adequada para a sua equipe/projeto.
Um grande abraço.
Ótimo artigo !!!
Em grandes empresas públicas, vendem a idéia de processo de software iterativos sem ter iterações, isso é real.
O pior é que esses muita gente ‘qualificada’ tende a piorar o esquema atual do desenvolvimento de software.
Professores de várias faculdades ensinam, não em todos os casos, o que nem aprenderam ainda.
Está claro e evidente que as empresas tem que investir mais em mão de obra do que em metodologias que só trarão mais complexidade aos processos de desenvolvimento de software. Não estou querendo dizer para as empresas pararem de utilizar essas metodologias, muito pelo contrário, algumas até que ajudam e tem uma finalidade peculiar para os projetos. Apenas me refiro para ver o lado “mais pessoal” do que estrutural.
Excelente artigo Phillip.
Phillip, um post do Thiago Arrais relacionado ao que vc falou:
Fábricas de software - Uma analogia levada longe demais.
valeuz…
Bravo! Sanidade nunca é demais nessa indústria.
Qual a relacao entre outsourcing e fabrica de sw?
eu posso falar que uma fabrica de sw faz outsourcing?
Grato,
C.A.
shoes, pq vc afirma que o termo fábrica não funciona para o desenvolvimento de software?
Porque fábrica se baseia em trabalho repetitivo e previsível, e criar software não segue este formato. Software é trabalho criativo. Imagine uma fábrica de notícias que publica um jornal, é um cenário bem parecido. Fábrica de Software é um modelo criado exclusivamente para baratear custos e que não leva em consideração como software de qualidade é produzido.
(E também porque já trabalhei com/para ou já comprei serviços destas empresas e sei bem que não funciona.)
Olá Phillip,
Concordo que não devemos esperar SCRUM de quem nunca entendeu o RUP mas que eu saiba fábricas não estão restritas ao modelo waterfall.
E mais, existem certos tipos de projetos que se encaixam bem no perfil de fábrica. Seguindo seu exemplo, a impressão do jornal poderia ser delegada à um terceiro (uma fábrica ágil ou não). O software que representa o “core” do negócio, dependendo da complexidade EXIGE UMA ABORDAGEM TOTALMENTE DIFERENTE. Aí estou contigo!
Mas aí vejo alguns problemas:
1. A maioria das pessoas têm dificuldade para diferenciar software de negócio do que não é associado diretamente ao negócio.
2. É preciso muita disciplina para que velhos hábitos não sejam despertados ou para que ajustes possam ser feitos rapidamente. Um exemplo, o cliente deve sempre interagir diretamente com desenvolvedores especializados e não com analistas de telas e fluxogramas.
Portanto fábrica de software não é o problema IMHO, mas as pessoas, elas precisam entender que algumas atividades têm essa “natureza artística” que você menciona.
Javix,
Eu não falie que Fábrica trabalha em Waterfall mas Waterfall não é a única coisa danosa para um processo de desenvolvimento, seja ágil ou não. Como mencionei acima fábricas se baseiam em linhas de montagem e software de qualidade dificilmente consegue ser criado segundo este princípio. A falta da existência de uma dedicação e entendimento do time sobre o projeto é mais uma causa de tantas e tantas falhas.
A ‘impressão do Jornal’ no seu exemplo está tão fora do negócio principal (que é editar um jornal) que eu a coloco no mesmo nível de escrever um compilador, uma JVM/CLR ou um framework como Hibernate e isso nós já terceirizamos há séculos. Assim como apenas se editarmos um jornal com uma técnica nova nós o faríamos na redação (ou pelo menos acompanharíamos da redação) em software se a tecnologia de infra-estrutura é commodity ela é tratada como tal. Acontece que se a maior parte do desenvolvimento de software fosse commodity não teríamos tantos softwares sendo desenvolvidos, essa simplesmente não é a realidade. Apesar de uma grande ‘zona cinza’ relativa aos domínios cada um tem sua peculiaridade e por isso somos pagos para desenvolver sistemas novos e por isso precisamos da nossa atividade sendo tratada como criativa (não necessariamente artística) e não como uma atividade previsível como montar um equipamento segundo um plano bem formado (note que a criação do equipamento em si por engenheiros não é feita no esquema de fábrica -apenas a montagem. Interessante, não?). Então, dado que:
1) A maior parte do desenvolvimento de sistemas é relacionada a um negócio
2) Mesmo as empresas que desenvolvem coisas não ligadas ao negócio (seriam análogas à impressão neste caso) não trabalham com fábricas (JBoss/Red Hat, Bea, Oracle, Sun, Thoughtworks, Jetbrains, Eclipse Foundation, Microsoft… só para citar algumas)
As fábricas não possuem espaço real em desenvolvimento de software que não como modelo de negócios que foca em baixo custo e qualidade zero.
Note que isso não tem anda a ver com terceirização que quando bem feita traz resultados. Fábricas não são terceirizações bem feitas.
[]s
Se produzir software custasse zero, tudo bem. Mas custa dinheiro. Em geral, o software será feito para alguem, que tem um tanto de dinheiro “fixo” para resolver um problema num prazo máximo. Como convencer alguem que vai pagar a conta que a quantidade de dinheiro que ele vai gastar vai ser definida de forma incremental, bem como o prazo? Para alguns projetos nunca antes realizados, inovadores, é realmente complicado prever e o waterfall falha totalmente. Mas… assim como desenvolver software não é igual a outras engenharias, nem todo desenvolvimento é iegual ao outro. Tem aquele projeto inovador, diferente, nunca antes feito, e tem aquela n-ésima ocorrência de outro website similar a outro já feito antes. Para este caso, é possível fechar escopo antes de sair fazendo.
Olhem o consumidor - “Tenho este dinheiro limitado e preciso do resultado até o dia D - do contrário, todo esforço terá sido em vão, pois ou o dinheiro acaba e você pode jogar tudo fora ou então a janela de oportunidade se vai e você também pode jogar tudo fora”.
Infelizmente vejo uma desconsideração total pela figura de quem paga pelo serviço. Todos nós somos consumidores. Já pensou fazer sua casa num método que ao longo do tempo o preço e prazo serão definidos? E se seu dinheiro acaba? Vai morar ná versão pré-acabada da casa? Tem até ente que topa isso… mas…
Mas, de novo, tem situações novas que mais se assemelham com as pesquisas… não é possível prever exatamente quanto se vai gastar nem quando se terá o resultado. Talvez o erro seja querer que todo e qualquer desenvolvimento de software se encaixe num modelo ou em outro. Parece que tem muita emoção e pouca racionalidade neste debate.
Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix (1)? 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!
Tem a ver com capacitação. Método é fundamental. Mas bons métodos, gestão e habilidades são como um tripé. No meu entender, tem gente que abusa de XP e outras metodologias ágeis por não terem a habilidade de antever as coisas. Não estou generalizando nem dizendo que XP não tem seu lugar. Critico apenas o uso do XP para observar resultados que uma pessoa experiente ou habilidosa anteciparia de bate-pronto. Muitas vezes o número de interações é excessivo ou abusivo.
Enfim, que a racionalidade reine em detrimento das modas.
Esta precisamos agrupar com outra para responder:
Criar um software custa dinheiro, muito dinheiro, mas o preço de escrever documentos de requisitos extensos e extensivos logo como primeira coisa no desenvolvimento é muito maior que o preço do desenvolvimento em si. Uma análise deste tipo não pode estar errada ou o projeto como um todo falha.
Infelizmente nas últimas décadas só vimos mais e mais análises falhando porque ninguém consegue prever o futuro de antemão, porque o negócio exige mudanças no escopo do sistema, etc.
A comparação com a criação de um filme não faz sentido. Um dia de filmagem para este projeto custa uma fortuna, o elenco ganha mais por hora que todos os indianos juntos ganham no ano, só as lentes das câmeras custam o preço de carros. Neste caso pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica do que desenvolver incrementalmente, cena-a-cena. O mesmo para a construção de prédios e aviões, mas não para software.
Software de qualidade é construído para ser flexível e as plataformas atuais suportam isso de maneira muito razoável.
Existe um argumento prático: eu posso dizer que vai custar X quando sei que vai estourar o orçamento ou podemos trabalhar no mundo real e investirmos este X incrementalmente. Mas ainda que o argumento não valha para você não tem problema: podemos trabalhar com custo fixo em metodologias incrementais, o RUP por exemplo quase sempre funciona assim.
Se fosse simples assim seria muito mais lucrativo comprar software pronto ao invés de desenvolver o seu. Comprar algo pronto é quase sempre melhor que criar algo novo mas a maioria das aplicações possui algo que não se encontra no mercado, e muitas vezes este é o diferencial da empresa.
Veja as grandes indústrias. Para domínios como ‘contas a pagar’ geralmente compra-se algo de prateleira, um ERP ou coisa que o valha. Para algo que realmente importa, para negócio da empresa, dificilmente compram algo pronto. Mais e mais os componentes secundários do software (segurança, gráficos, servidores, planilhas, transações, armazenamento, etc.) são ‘comprados prontos’ em frameworks e derivados mas o desenvolvedor continua focado em implementar regras de negócio daquele cliente.
Desenvolver software customizado é algo feito em exagero em muitos aspectos, muita cosia deveria ser comprada e não recriada, mas boa parte dos projetos são únicos em seu segmento porque trazem o diferencial, cultura e demais atributos específicos da empresa em questão.
Novamente você está fazendo uma analogia ruim comparando com construção civil. Uma casa com apenas um banheiro é inútil para seu usuário mas software com 30% das funcionalidades prontas não.
Acho que você se enganou fortemente quanto ao consumidor. Se eu tenho R$1000,00 e quero uma Ferrari eu vou obter? Se uma mulher grávida tem todo o dinheiro do mundo e quer que o filho nasça aos 2 meses ela consegue? Se eu quero um prédio de dez andares construído em duas semanas eu consigo? Isso é falta de respeito? Falta de respeito é dizer para o usuário que ele vai conseguir obter o que quer naquele preço e naquele prazo sabendo que estatisticamente a maioria dos projetos definidos nestes termos falham miseravelmente. É anti-ético, até.
A proposta ágil é exatamente oposta. Colocamos o cliente como quem guia a situação: se ele quiser gastar apenas X e se não mudar de idéia dá para saber com uma boa margem quando tudo será implementado. Mas este é o cenário que estatisticamente quase nunca acontece, geralmente ele vai mudar de idéia.
A diferença é que em um modelo ágil nós falamos: “Ok, você pode mudar de idéia”.
Nós respeitamos tanto quem paga o software que ao invés de nos trancarmos por meses a fio para depois mostrar um teórico produto final que o cliente olha e diz “não era nada disso!” nós colhemos feedback a cada passo, e se você aliar isso ao fato de que o cliente pode mudar de idéia você tende a chegar ao software como era esperado.
Também deixamos o cliente priorizar o que vai ser feito primeiro. Com isso o cliente consegue ter uma visão das partes mais importantes do seu sistema e mitigamos a maioria dos riscos envolvidos, para tecnologia e negócios.
Acho que você vai gostar muito da literatura sobre métodos ágeis, ela fala exatamente que cada caso é um caso.
XP? A maioria do que falei aqui se aplica em RUP ou qualquer metodologia iterativa incremental.
Se seu desenvovledor entende tanto do domínio que pode se antecipar ao usuário é algo fantástico, mas cuidado. Desenvolvedores (geralmente) não são pessoas que lidam com o negócio e tendem a construir mega-aplicações cheias de funcionalidades inúteis. Com o acompanhamento direto e feedback do cliente que uma metodologia iterativa dá você pode deixar o feedback do cliente podar as asas do desenvolvedor e economizar rios de dinheiro ao não implementar coisas que não serão usadas.
E que a inovação não seja engolida pelo senso comum ;)
[...] Claro que o processo de achar consultores é difícil e requer investimento. Seguir este plano é bem mais difícil que fazer uma ligação do tipo: “Alô, é da JCN? Me manda 300 programadores Java, por favor? 30 minutos? Obrigado”. Eu não diria que é uma solução para todos, sequer para a maioria, já falamos um pouco sobre isso aqui. [...]
[...] eu vi poucos projetos de apenas um mês que tenham sido relevância para o currículo de alguém. Como previsto, os agilistas retardatários estão em todo lugar, [...]
Mais uma referência: http://expressocapital.blogspot.com/2008/09/agile-and-matrix.html
[...] Este é o tipo de coisa sobre a qual eu falei aqui, aqui, aqui, aqui e, principalmente, aqui. [...]
[...] de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: [...]
[...] 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 [...]