Porque eu voaria em um avião desenvolvido de forma ágil

Eu costumo ver muitos comentários e exemplos positivos sobre agile em blogs listas de e-mails, mas curiosamente no final desses comentários e até de palestras eu vejo a pergunta:

Agile é legal e funciona bem para projetos pequenos, mas você voaria em um avião desenvolvido e testado de forma ágil?

Eu tento entender o motivo dessa comparação no passado, quando tínhamos poucas informações sobre ágil e toda essa história era novidade, mas não sei se da pra entender nos dias de hoje.

BTW, depois de ver isso novamente em uma lista alguns dias atrás, refletir durante algumas horas cheguei a conclusão que sim, eu voaria! E vou tentar responder o porque eu voaria em um avião desenvolvido de forma ágil de uma forma bem direta:

Porque eu já faço isso :p

Antes de continuar lendo, eu ressalto que comparações idiotas, merecem respostas e justificativas idiotas.

Sim, de fato o processo de montagem de um avião é muito mais ágil do que waterfall ou RUPista (Se fizermos uma comparação bem abstrata desse processo com o processo de desenvolvimento de software). Claro que existe uma diferença gigantesca entre desenvolver aviões e softwares, mas eu me permito fazer essa comparação já que ela foi feita anteriormente no questionamento sarcástico citado no início deste post.

Antes de explicar o porque eu voaria, vou tentar explicar alguns dos motivos que geram essas comparações pela internet:

  • Agile é um conjunto de valores embutidos em um framework técnico e gerencial para ajudar no desenvolvimento customizado de software. Por ser flexível e se basear em valores, ele permite que várias decisões sejam tomadas, e muitas vezes as pessoas que tomam essas decisões não conseguem compreender que ágil são valores e sub-entendem que são recomendações ou simplesmente processos. Quando isso acontece, essa pessoa toma livremente decisões que corrompem esses valores e ninguém pode questioná-las. Por esse motivo muitas empresas trabalham com ágil e tem projetos fracassados e com qualidade extremamente inferior. Esses projetos “ágeis” são encontrados aos montes e algumas pessoas podem ter se decepcionado com eles, o que gera comentários como “desenvolvimento orientado a post-its”, “mudanças feitas pelo telefone”, “voar em avião ágil” entre outras.
  • Agile está incomodando muita gente que ganha dinheiro ou fama com outros processos ou mesmo que não desejam reciclar-se. Entre os principais “prejudicados” pelo avanço do ágil estão empresas e entidades certificadoras, empresas de processos corporativos e de software, fornecedores de ferramentas (principalmente workflow, tracking e processos), consultores de desenvolvimento e teste de software que não se reciclaram, universidades e professores sem experiência de mercado, empresas de treinamento, os criadores dos processos e métodos baseados em fases (incluindo consultores) e órgãos reguladores de “alguma coisa”, como por exemplos normas e estimativas de software. A lista é muito maior e é composta por todas as pessoas que ganham dinheiro com esses processos (e é muita grana). Além disso, a comunidade ágil é muito ligada ao conhecimento aberto e open-souce software, o que também reduz o lucro desses fornecedores. . . Pense nisso.
  • Agile ainda não foi compreendido e muitas pessoas que conhecem ele teoricamente o questionam em comparação ao modelo tradicional (eu me incluía aqui). Muitas vezes, por ignorância falamos de algo que não dominamos. Costumamos dizer que uma mente fechada normalmente vem acompanhada de uma boca aberta e isso é muito comum no mercado de software. Como citei antes, o conhecimento teórico não nos faz refletir sobre os valores do ágil, mas sim sobre suas práticas, e eu confesso que ler sobre TDD, programação por pares e planejamento iterativo e incremental sem viver tudo isso, pode dar pesadelos durante a noite. Ágil é uma das coisas na vida que não se entende explicando, mas sim vivendo. Muitas dessas pessoas que criticam o ágil tem muito conhecimento teórico e muitas das vezes são pessoas tecnicamente brilhantes, mas não vão mudar de ideia até ter essa experiência. E quem está falando é um ex tradicionalista semi-xiita!
  • Agile envolve mais responsabilidade, empenho e suor do que modelos tradicionais. O ágil não te protege em um contrato, não prende fideliza o cliente, nem lhe permite entregar o mínimo possível. Ágil entrega o que o cliente quer a cada duas semanas, e o cliente decide quando estiver bom ou ruim, não existe um contrato dizendo que você vai entregar cinquenta telas, mas sim um compromisso de entregar o que o cliente quer. Todos no time devem concordar com isso e saber que cada pedacinho de software adicionado ao repositório deve agregar o máximo de valor para o cliente e não o que estava no contrato ou no termo de aceite escrito a alguns meses. Isso pode parecer bobeira, mas muitas empresas de desenvolvimento criam requisitos abstratos e dúbios/imprecisos para poder entregar menos ou colocar pessoas com menos experiência nos projetos, sabendo que o cliente vai ter que pagar pelo software desenvolvido no final. Pra mim isso se chama corrução.
  • Agile envolve muito mais conhecimento técnico e soft skills, logo charlatães e preguiçosos não conseguem acompanhar os requerimentos. Escrever test cases no testlink ou no excel é muito mais mecânico do que pegar uma folha de papel e fazer um mapa mental do que deve ser testado de forma exploratória, ler um documento assinado é muito mais fácil do que conversar com o cliente e descobrir o que ele realmente quer, sentar em uma baia durante oito horas é muito mais cômodo do que trabalhar colaborativamente, buscar uma certificação nova é muito mais prático do que desenvolver uma habilidade nova a cada seis meses. O mundo é feito de escolhas, felizmente, ágil nos obriga a ser melhores todos os dias, não só tecnicamente, mas como consultores e em nossas soft skills também. Em um time ágil o que conta não são quantos títulos você tem, mas sim o quão entusiasmado e empenhado você está.

Ok, de fato muitos vão ler e pensar “lindo discurso, mas continuo com meu ponto de vista. . .“. Esses podem ser o ponto três citado acima antes de terminar de ler esse post. Mas se preferirem, podem refletir e tentar descobrir como o Yahoo!, Google, Microsoft, Apple, ThoughtWorks, LinkedIn, Rackspace entre outras empresas, conseguem ser líderes de mercado e referências de qualidade, excelência técnica e inovação praticando ágil.

Voltando ao tema principal e sabendo que agile não é “agile”, vamos refletir sobre o processo de desenvolvimento de um avião.

Primeiramente, vamos fazer uma comparação um tanto que irreal daqui pra frente, pois o processo de desenvolvimento de software é um processo mais criativo do que repetitivo e o processo de fabricação de bens de consumo como aviões, carros entre outros é um processo mais repetitivo do que criativo. Enfim, vamos abrir a cabeça e refletir sobre algumas coincidências :)

Inicialmente vamos assistir esse vídeo da linha de montagem de um avião e vamos notar algumas semelhanças:


Vídeo pode ser visto no link: http://www.youtube.com/watch?v=QhU2X1z2HK0

O primeiro ponto que vamos observar sobre o vídeo, é que o processo na verdade é de montagem do avião, ou seja, as peças já estão devidamente construídas e testadas. Eu acredito muito que eu conseguiria escrever algumas dezenas de casos de testes para uma turbina como a desse avião, mas não consigo me imaginar testando isso de forma manual. Ou seja, são aplicados testes semelhantes aos de unidade para cada peça diferente do avião, o que me recorda os nossos testes automatizados do TDD. O mesmo para peças como o pitômetro por exemplo, que não podem ser testadas do modo antigo antes do avião estar pronto. Com certeza todos esses equipamentos tem suítes com centenas de testes automáticos assim como os que temos nos nossos builds automatizados.

Aos 0:22m do vídeo, podemos ver duas pessoas executando a mesma tarefa ou seja, trabalhando em pares, na verdade durante todo o vídeo podemos ver que o processo de montagem é muito mais focado em colaboração e troca de experiência do que seguir um script com documentos.

Podemos notar (ou supor devido a velocidade do vídeo) que algumas pessoas trabalham em mais de um papel. Elas instalam equipamentos e buscam as peças por exemplo, em outro caso citado abaixo, a mesma pessoa que instalou o volante (seja lá qual for o nome desse equipamento) testou se ele estava respondendo como o esperado. A colaboração e atuação em mais de um papel que usamos no ágil e principalmente no kanban.

Aos 1:30 podemos notar que as turbinas ainda não estão instaladas, mas já são realizados testes nas partes prontas como por exemplo no sistema de direção do avião. O teste exploratório continuo e com o parecer do cliente é uma das características do desenvolvimento ágil.

Refletindo sobre esse vídeo, vamos imaginar que esse avião fosse desenvolvido de modo cascata e concordando com o nosso modelo V:

  • Imagine que teremos quatro ou cinco fases. Na primeira, um grupo de físicos vão descrever um conjunto de cálculos teóricos sobre aerodinâmica. Nesse mesmo ponto, você testador vai escrever todos os casos de teste para validar essas leis no avião.
  • Numa segunda fase, engenheiros mecânicos/mecatrônicos e elétricos vão desenhar as peças e equipamentos que serão usados. Agora os testers podem escrever testes para avaliar se essas peças vão responder conforme o especificado contra as leis do primeiro documento.
  • Agora vamos montar as peças e o avião, tudo junto. Nesse ponto você tester, espera sentado.
  • Finalmente o avião está pronto. Agora você testa :)

Está aberta a temporada de contratação de Testers. Requerimentos: Conhecimento do modelo V de desenvolvimento, Certificação XPTO e principalmente estar aberto a cair de avião no primeiro teste manual.

Saindo de dados abstratos e indo a algumas felizes coincidências:

Mesmo o XP tendo introduzido a ideia de “testes primeiro” no mercado de software em 1997, essa abordagem já avia sido usada no projeto Mercury [1] em 1960. Esse projeto nada mais é do que o primeiro projeto espacial com missão de colocar um humano na órbita do nosso planeta. Acredito que seja um pouco mais complexo do que construir um avião comercial.

O primeiro projeto de desenvolvimento ágil do mundo, aplicando o predecessor do XP foi dentro de uma industria, que embora não seja aeronáltica, está muito perto disso, o projeto Chrysler Comprehensive Compensation System (conhecido como C3), da Chrysler (mercado automobilístico) é referenciado por muitos livros como o primeiro projeto a usar XP. De lá pra cá várias gigantes desses mercados (automobilísmo, aeronáltico, marítimo, etc) vem adotando agile para seus softwares.

Vários dos nossos objetos de estudo do mundo ágil/lean como o kanban vieram de mercados que envolvem com produtos de alta qualidade e que precisão ter o mínimo de defeitos como por exemplo os carros da Toyota.

Visto tudo isso, eu afirmo: Aviões não são desenolvidos usando metodologia ágil nem uma variação dela, muito menos algo semelhante ao modelo tradicional. É estupidez fazer comparações como a descrita no início deste post, bem como as comparações citadas acima como resposta.

Tudo que está escrito em verde é besteira, mas provavelmente fez sentido pra você por alguns instantes ;p.
(Continue lendo, agora vem a melhor parte :D )

Desculpe pela comparação acima, mas é apenas uma demonstração de que manipulando algumas informações e com pouco ou nenhum embasamento, podemos aproveitar de áreas das quais as pessoas não dominam e explorar brechas para favorecer o nosso ponto de vista. Muitos blogueiros e até empresas usam e abusam desse artifício.

O desenvolvimento de software é uma atividade criativa, portanto merece ter pontos de atenção. As regras de negócio de Software estão em constante mutação e são muito mais abstratas do que as leis que regem outras engenharias como a engenharia mecânica por exemplo. Comparar construção de Software com Construção de Aviões não representa um argumento válido. Não estou falando que um é mais complexo que o outro, mas que cada engenharia tem sua complexidade única e seus desafios.

Enfim, se você pesquisa no google o texto “voaria avião ágil“, vai encontrar um bucado desses desinformados que fazem esse tipo de comparação e entre eles até uns caras com determinada “fama”, mas também vai encontrar um post muito bacana chamado “Toque de gênio” de um desenvolvedor e blogueiro chamado Vinicius Morgado. O post é pequeno em extensão, mas grande em significado e vou referenciá-lo e copiar um pedaço dele abaixo:

Esse post fala sobre uma palestra do Martin Fowler onde, após falar sobre Agile, durante uma sessão de perguntas, um iluminado (como cita o Vinicius) faz a seguinte pergunta para o Fowler:

“Você voaria em um avião que tivesse sido construído utilizando métodos ágeis?”

Então Fowler calmamente respondeu da única forma lógica possível:

Temos que, gradativamente, encontrar quais são as fronteiras do desenvolvimento ágil, simplesmente testando os seus limites (obviamente sem colocar a vida de ninguém em risco). Métodos ágeis ganham mais espaço em todo o tipo de projeto e assim tem sido diariamente ao redor do globo.

Completou dizendo que não sabia o suficiente sobre aviação para uma resposta mais acurada e terminou contando a seguinte piada:

“Um grupo de alunos havia construído um sistema para determinado avião.

Perguntaram ao professor desses alunos: – mestre, o senhor viajaria nesse avião?

O professor disse: – viajaria com toda certeza e estaria 100% seguro.

– Mas como o senhor pode ter tanta certeza que o avião não iria cair?

O professor então respondeu: – ora meu caro, se meus alunos fizeram esse sistema, é óbvio que o avião nem irá sair do chão!”

Por isso eu disse que todo o verde era besteira, eu não sei nem porque os aviões desligam as luzes da cabine para decolar e aterrissar :p . . . Com base em que argumentos eu vou fazer comparações entre desenvolvimento de software e construção de aviões?

O Vinicius descreve que esse foi um toque de gênio e eu não tenho como discordar dessa definição, muito menos pensar em uma melhor. O importante dessa história é entender que nossos conhecimentos são limitados a uma ciência muito complexa que é a computação, e essa ciência requer muita criatividade também. Vamos tentar melhorar todos os dias como profissionais e satisfazer melhor os nossos clientes. Aprender todos os dias um pouco mais e tentar nos livrar desses preconceitos que nos cercam. :)

Se me permitem reconsiderar inclusive o título deste post, faço das palaras do Fowler as minhas.

No mais eu continuo pensando: Embrace agile – Even if you’re flying ;)

[1] http://en.wikipedia.org/wiki/Extreme_programming
[2] http://viniciusmorgado.blogspot.com/2010/06/toque-do-genio.html

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

14 thoughts on “Porque eu voaria em um avião desenvolvido de forma ágil

  1. Muito bom o post como sempre. É realmente impressionante como pessoas têm a capacidade de manipular as informações e exemplos para, atrevo-me a dizer, difamar algo que não conhecem. E vemos isto saindo de bocas de profissionais tidos muitas vezes como excepcionais, não só do mercado mas – como na maioria das vezes que ouvi – também da boca de acadêmicos, que tomam um embasamento teórico – muitas vezes de materiais dos primórdios dos movimentos ágeis, um tanto desatualizados – e soltam pérolas que por vezes não sabemos se rimos ou choramos.

  2. Prezado Camilo,

    primeiramente parabéns pelo post, muito crítico e corajoso.

    Seu post, apesar de muito bem fundamentado, vai por água abaixo se perceberes que, sempre que fazem o comentário da metodologia ágil e aviões, falam do SOFTWARE interno do avião, e não da montagem do mesmo. E a complexidade de um software de avião é inimaginável, levando em consideração que qualquer bug poderá colocar em risco a vida de centenas de pessoas. A complexidade desse software envolve integração com DIVERSOS tipos de hardwares e com DIVERSOS outros softwares do próprio avião.

    Times como: Yahoo!, Google, Microsoft, Apple, ThoughtWorks, LinkedIn, Rackspace são, em sua grande maioria, desenvolvedores dos seus próprios produtos (creio que com exceção apenas da TW). Nenhum deles precisa prestar contas aos seus clientes no que diz respeito a prestação de serviços de desenvolvimento de software, tampouco estão (muito) preocupados com os bugs que são descobertos a toda hora em seus softwares. Se conseguires entrar em contato com algumas dessas empresas reclamando de bugs, eles vão dizer: fica tranquilo, na próxima versão esse bug será corrigido. E pronto.

    A comparação correta seria com empresas como EDS, IBM, TCS, Capgemini, Accenture, etc. Mais uma vez seus exemplos (como o da Chrysler e Toyota) foi de produtos próprios, os quais processos de aprovação de componentes para montagem são EXTREMAMENTES rígidos, ULTRA criteriosos e SUPER tradicionais, nada ágeis, seguindo certificações de mercado como ISO, Inmetro e outras específicas para essas áreas.

    “Tudo que está escrito em verde é besteira”, ufa…

    “Agile envolve mais responsabilidade, empenho e suor do que modelos tradicionais. O ágil não te protege em um contrato, não prende fideliza o cliente, nem lhe permite entregar o mínimo possível. Ágil entrega o que o cliente quer a cada duas semanas, e o cliente decide quando estiver bom ou ruim, não existe um contrato dizendo que você vai entregar cinquenta telas, mas sim um compromisso de entregar o que o cliente quer.”
    Qualquer um conhece o gráfico do “Early Testing” e sabe que corrigir um erro ou uma tela feita erroneamente durante o desenvolvimento possui um custo MUITO maior do que fazê-lo na etapa de requisitos ou análise (ou whatever).

    “Agile envolve muito mais conhecimento técnico e soft skills”
    Qualquer profissional de qualquer área precisa possuir boas competências técnicas e “soft skills”, mas esses bons profissionais são caros.

    “O mundo é feito de escolhas, felizmente, ágil nos obriga a ser melhores todos os dias, não só tecnicamente, mas como consultores e em nossas soft skills também. Em um time ágil o que conta não são quantos títulos você tem, mas sim o quão entusiasmado e empenhado você está.”
    Posso contar nos dedos quantos profissionais eu conheci no mercado que tinham essas características.

    Desenvolver softwares complexos com metodologias ágeis é possível sim, mas se levar em considerações variáveis do mercado como: CUSTO, TURNOVER e PROFISSIONAIS MULTIDISCIPLINARES com todas essas características geniais que citasse acima, eu prefiro ainda o modelo tradicional.

    CUSTO – Não vejo espaço para Juniores ou Plenos nesse tipo de projetos.
    TURNOVER – O fulano decidiu sair na metade do projeto pra concorrente que vai pagar 50% do seu salário, e agora? Como dividir esse conhecimento? Visto que estamos falando de projetos super complexos, duvido que o cliente ou demais colegas tenham perfeita compreensão de todas as regras de negócio. Entra aí mais uma vez o custo, custo da curva de aprendizado do negócio.
    PROFISSIONAIS MULTIDISCIPLINARES – Mais uma vez, esses profissionais são caros e raros. O que aumentaria absurdamente o custo global de um projeto.

    Eu preferia contratar uma empresa que não utilizasse metodologias ágeis. Ou o custo iria sair muito elevado, ou a empresa iria sair no prejuízo, e negócio bom, só é bom quando é bom para os dois lados.

    Por fim, mais uma vez parabéns pelo seu post. Espero ter agregado com minhas colocações.

    Um abraço,
    Luiz Gustavo Schroeder Vieira, FCE, CTAL-TA
    Consultor de Testes
    BSTQB TAG Member
    +55 (48) 9994-3569
    Skype: luizgsvieira
    luizgustavo@LUGATI.com.br
    http://testavo.blogspot.com
    http://www.LUGATI.com.br

  3. Cara,
    Excelente post. Gostei muito da forma que você abordou o tema, sem fanatismo (como tem muita gente por ai) e com muita coerência. Apesar da extensão do post (hehe), valeu muita a pena ler até o final.
    Eu também me incluía nessa galera que falava muito mal das metodologias agéis, até conhecer uma empresa que aplicava ela da forma correta.
    Parabéns pelo post.

  4. Olá Gustávo,

    Obrigado pelo comentário, pelo elogio e pelas críticas :)

    Assim como o Fowler, não tenho conhecimento para afirmar ou negar nada sobre aviões nem sobre os seus softwares embarcados, o post aborda uma situação fictícia e é muito mais filosófico, teórico e principalmente reflectivo do que sólido e embasado em provas cientificas.

    Embora desconheça esse ambiente, acredito que exista muita complexidade extra devido ao firmware desenvolvido. Me lembro que durante um ano eu estudei e discuti muito sobre isso com uma amiga que trabalhava em uma empresa que fabricava no-breaks. Ela me contou sobre algumas dificuldades extras que esse tipo de software trás, como por exemplo as limitações extremamente rígidas de espaço do de disco e memória, muitas vezes em KBs, além das limitações técnicas das peças e a necessidade das descrições das interfaces/contratos dos serviços que cada uma dessas peças implementava, etc. Segundo ela, a equipe usava uma variação do Scrum adaptada para atender aos requisitos do MPS.Br.

    Mesmo com todos esses parênteses, eu permaneço com o meu ponto de vista: Ágil é sobre desenvolver o melhor software para o cliente, não importa o software, portanto eu voaria em um avião cujo sistema foi desenvolvido com XP sim, sem medo :). Sobre a pergunta que originou esse post, nas oportunidades que eu já vi, ela foi bem dúbia, portanto me reservo ao direito de mantê-la como atualmente. (Embora, curiosamente, dois desses posts na internet tenham mudado a forma de perguntar de ontem para hoje, enfim, nada que o google cache não tenha me confirmado :) )

    Dadas todas essas restrições e particularidades, eu acredito que o desenvolvimento para firmware não se enquadra nem no modelo waterfall nem no modelo ágil e realizando uma pequena pesquisa sobre um software embarcado, pude notar que existem várias caracteristas de ambos os lados, como o apoio em testes automatizados para tudo do agile e over-documentation do waterfall, mas prefiro evitar essa discussão, afinal, o processo é muito diferenciado e só foi usado como exemplo.

    Não sei qual o seu background em eng. de software, mas é sabido que o ágil surgiu como uma resposta ao diversos problemas no desenvolvimento tradicional de software comercial e já avançou para alguns outros tipos de software como produtos, para alguns firmwares como os de Sistemas Operacionais (além dos próprios sistemas operacionais), manutenção de códigos legados, open source software, serviços em clouds e clusters, mobile entre outros. Além disso é usado com louvor em vários tipos de empresas como as de produtos, de outsourcing, offshore, manutenção, consultoria e etc.. Desenvolvimento ágil evoluiu com algumas tecnologias de apoio como testes automatizados, integração continua, gestão de configuração que também foram evoluindo com agile. Como falei algumas vezes no post e nessa resposta, não sei quais as limitações e os problemas atuais dos sistemas embarcados de aviões, mas acredito que agile poderia ajudar a melhorar em algum ponto e quem sabe no futuro, podemos ver algum ou alguns projetos de software embarcado rodando nos aviões? Aposto que a dez anos discutia-se sobre usar metodologias ágeis em bancos e até no governo, que hoje acontece com muita frequência. Além do mais, conheço uma companhia aérea americana que desenvolvia todos os seus sistemas internos e externos (não embarcados) de forma ágil. É tudo questão de tempo.

    Você realmente acredita que Google, Apple, Microsoft e Yahoo! por exemplo, não conseguiriam desenvolver os mesmos softwares que essas outras empresas desenvolvem? Eu acredito que conseguiriam sim, e com muita facilidade. Não estou desmerecendo ninguém, ainda porque essas empresas fazem isso muito bem e são muito reconhecidas pelo seu trabalho, mas temos que observar que essas quatro empresas atuam com projetos muito mais complexos do que a média das empresas e desses projetos saem as técnicas e ferramenas do “futuro”. Além do mais, falar que empresas como essas não dão satisfação para o usuário é amadorismo. A Microsoft tem que se virar de todas as formas para que seus produtos não tenham bugs, pois outros sistemas operacionais estão roubando o mercado dela, inclusive a Apple e o Google. A Apple lança um produto por ano e tudo tem que ser perfeito, pois quando um problema é encontrado ele vira a matéria dos jornais durante todo o ano (e ela faz hardware e software). O Google é a empresa mais poderosa do mundo, e posso contar nos dedos as vezes que eu precisei acessar meu Gmail ao longo desses quase dez anos e não consegui. Eu não consigo imaginar um projeto que eu tenha participado que essas empresas não conseguiriam fazer igual ou melhor.

    E sim, o kanban que é usado em muitos projetos que adotam agile e lean como metodologias de desenvolvimento, veio da Toyota e o C3 da Crysler é citado como o primeiro projeto ágil de software (usando XP), e sim, empresas que desenvolvem com ágil também são super criteriosas, mas focando no que o cliente quer.

    Concordo contigo que o early testing é “bonitinho” e é verdade, só que quando desenvolvemos de forma iterativa e incremental, como no ágil, nossos erros estão limitados a duas semanas de vida, e isso inclui os defeitos de análise, de software, de arquitetura entre outros. Para ser bem sincero, não me considero um caçador de bugs mais, mas sim um “evitador” de bugs, pois os testes existem antes do desenvolvimento. Quando usamos conceitos como Specification by Example por exemplo, a nossa documentação evolui junto com o código e são poucas as oportunidades para que um defeito seja pego depois. Além de que, quando trabalhamos de forma ágil, evitamos o pior e mais caro tipo de defeito, o defeito de negócio, o que o cliente vira ao final do projeto e diz “Não era isso que eu queria . . .”. Ágil veio para evitar essa insatisfação.

    Qualquer profissional de qualquer área precisa possuir boas competências técnicas e “soft skills”, mas esses bons profissionais são caros.
    O conceito de caro é muito relativo. Mas não tem nada a ver com o tema :p

    Posso contar nos dedos quantos profissionais eu conheci no mercado que tinham essas características.
    Procure novas empresas para ter essas experiências. Agora mesmo tem mais ou menos 110 desses a minha volta :) Pense bem, talves o ambiente tradicional cheio de mecanismos e padrões de “fábrica” possa estar limitando a criatividade das pessoas, e no final, não importa o quão rígido e conhecido seja o processo que será automatizado ou solucionado com software, sempre haverá um espaço para a criatividade torná-lo mais robusto e eficiente.

    Custo, Turnover e Profissionais Multidisciplinares
    Novamente, custo não é algo que ágil deve solucionar, turnover independe de metodologia e profissionais multidisciplinares vão atrás de boas oportunidades.

    Não vejo espaço para Juniores ou Plenos nesse tipo de projetos.
    Não importa o quão júnior é um profissional, se ele estiver motivado ele está habilitado a trabalhar em um projeto ágil. Novamente, a parte técnica é parte das qualidades de um bom profissional, depois de algumas semanas pareando com alguém mais experiente ele vai transformando potencial em experiência. Eu prefiro apostar em um júnior cheio de vontade de aprender e que será fácil de moldar do que em um especialista com cinco ou seis linhas assinatura sem vontade de aprender e cheio de preconceitos. Prefiro apostar em vontade e potencial do que em medos e pessimismo.

    TURNOVER – O fulano decidiu sair na metade do projeto pra concorrente que vai pagar 50% do seu salário, e agora? Como dividir esse conhecimento? Visto que estamos falando de projetos super complexos, duvido que o cliente ou demais colegas tenham perfeita compreensão de todas as regras de negócio. Entra aí mais uma vez o custo, custo da curva de aprendizado do negócio.
    Novamente, ser ágil e falar “não usamos UML e Casos de Uso” não significa que não tenhamos documentação :p Só significa que não temos que gastar dezenas de horas lendo um calhamaço de documentos. Todo o código é coberto por testes descritivos que explicam o comportamento e o design, cada funcionalidade é coberto por pelo menos um critério de aceite que descreve em linguagem natual o que está acontecendo e por trás executa diversos testes automatizados que garantem o seu funcionamento. Até o ambiente é automatizado! A comunicação do projeto não é centralizada, mas sim espalhada, para isso temos stand ups, retrospectivas, showcases, card wall, burn ups and burn downs sempre visíveis, iteration review, mesas abertas ao invés de baias entre outros recursos, práticas e ferramentas para disseminar o conhecimento e fomentar a comunicação. Preferimos conversar do que ler documentos.

    PROFISSIONAIS MULTIDISCIPLINARES – Mais uma vez, esses profissionais são caros e raros. O que aumentaria absurdamente o custo global de um projeto.
    Quem tem que resolver esse tipo de problema não é a metodologia, mas sim a empresa. Mas curiosamente, as start-ups, que teoricamente são as empresas mais fracas financeiramente falando e tem o negócio mais instável, optam por profissionais multi-disciplinares e por metodologias ágeis em sua maioria. Certo? Você como empreendedor, teria coragem de falar para seus clientes que você opta pelo mais barato e por isso não contrata bons profissionais porque são caros? Como empreendedor você deve olhar essa oportunidade de negócio e começar a fazer a diferença. Valorizar os bons e multi-disciplinares profissionais, entregar mais qualidade e inovar. Pensar algo como “Ser ágil pode ser melhor, mas é muito caro, logo vou continuar entregando produtos medianos para meus clientes” não é um pensamento de um empreendedor visionário.

    Por fim, mais uma vez parabéns pelo seu post. Espero ter agregado com minhas colocações.
    Eu que agradeço. Seu comentário quase do tamanho do post me ajudou a ver a quantidade de aspectos que não foram abordados e a quantidade de dúvidas que ainda existem e podem ser exploradas em posts futuros. Além disso me ajudou a refletir sobre alguns pontos e reconsiderar algumas ideias, obrigado. Espero que tenha te ajudado a ver o desenvolvimento ágil com melhores olhos.

    No mais, minha intenção com esse post não é convencer ninguém que ágil é melhor, mas sim que tudo que ágil não é um processo em que tudo é feito por telefone e gritado para a equipe. Ágil não significa fazer com pressa, mas fazer no tempo certo, nada a mais, nada a menos, e como eu comentei no post, isso não é algo que pode ser entendido lendo ou assistindo a aulas, mas sim vivendo. :)

    Espero que um dia você participe de uma equipe ágil realmente empenhada, e não precisam ser gênios da programação e testes, mas sim pessoas comprometidas com o projeto, e possa mudar de ideia como eu mudei :)

    Abraços,

    Camilo

  5. Olá Eduardo,

    Obrigado pela visita e pelo comentário.
    Realmente o post ficou extenso e um pouco cansativo, mas é um tema que merecia essa atenção. Fico feliz que tenha lido tudo e não tenha se arrependido :)

    Concordo contigo, não podemos generalizar e ser fanáticos, principalmente quando falamos de algo tão intangível quanto processo de desenvolvimento de software, mas trabalhei nos dois modelos e acredito muito na forma ágil de desenvolver :)

    Novamente, obrigado.

    Abraçcos,

    Camilo

  6. Oi Camilo,

    Na minha opinião, a pergunta não é mais correta, ou melhor, a mais pertinente, para me fazer voar ou não, nesse pássaro de ferro que costuma pesar centenas toneladas (e ainda vôa!? que heresia!).

    A pergunta que eu faria seria a seguinte: “O que me levaria a voar num avião?”

    Pergunta difícil essa, provavelmente, seria bom ter vários itens e a pessoa marcar o que acha que é relevante pra tomar essa decisão.

    O quero dizer é que o fato isolado do avião, ou seja o que for, ter sido desenvolvido de forma ágil, não irá me fazer voar nele, comprar o produto, etc.

    Com todo respeito a quem costuma fazer essa pergunta, mas ela é totalmente estúpida, é a mesma coisa que eu te perguntar se você voaria em algo que pesa toneladas?

    Só quem é ignorante em Agile e/ou sobre o funcionamento do avião, iria responder não, apenas com esse fato.

    Abraços! E parabéns por levantar a discussão de forma tão lúcida e bem humorada.

  7. Cara, você tem a mesma visão que eu tinha quando era funcionário, por isso entendo quando você fala de “equipe ágil realmente motivada” ou de “juniores motivados” ou quaisquer outras pérolas.

    Existem desafios do dia-dia de uma equipe de desenvolvimento, não só tecnicamente falando, mas principalmente quando a pessoa é Júnior no sentido de não saber agir quando certas situações acontecem.

    Essas questões como turnover, custo, etc. não é resolvido por metodologia mas o gestor deve levar sim em consideração uma vez que ele que está pagando o salário da equipe.

    E o retrabalho só existe a cada 2 semanas? +2+2+2+2+2+2+2+… quantas semanas um projeto realmente complexo tem? E os Testes de Regressão lá na frente, como ficam? Continuam exploratórios? Matriz de rastreabilidade? TEM CERTEZA QUE UM SER HUMANO É CAPAZ DE LEMBRAR TODAS AS COMBINAÇÕES COM UM DIRECIONAMENTO MACRO DO QUE DEVE SER TESTADO (exploratory testing, post-its, whatever)?

    Rodeado de 110 desses caras? Uma coisa é você ser genial e ter muitas características positivas (far exceed expectations). Outra coisa é “dar conta do negócio”, ou seja, ser feijão com arroz com algumas características pessoais legais. Se está rodeado de 110 desses caras, tenho absoluta certeza que é exceção, e não regra.

    Resumindo, de maneira geral não sou contra metodologias ágeis, embora pareça. O que acontece é que peguei asco de agile lovers a partir do momento que eu observei alguns (muitos) desastres de “papas” do SCRUM por aí. E confesso que adorei minhas vivências em projetos ágeis, e não trabalhava com gênios, apesar de ter uma excelente percepção do meu time.

    No meu ponto de vista (não só no meu pelo visto), a empresa que opta por desenvolver um software da COMPLEXIDADE e CRITICIDADE de um software de avião utilizando este tipo de metodologia, com certeza preza pela qualidade. Mas provavelmente não tem noção do quanto pode gastar no decorrer deste projeto, quase impossível prever os custos.

    Já trabalhasse em algum projeto com linguagem de programação de alto nível (Java, C#, etc.) que integrasse com hardware? Não há TDD, BDD, ATDD (e whatever) do mundo que resolva quaisquer combinações que possam prever as da integração com um hardware com uma API levemente complexa. Digo, em tempo hábil.

    Eu gosto muito e acredito muito em metodologias ágeis, inclusive os diversos produtos de software que a LUGATI estará lançando em 2012, utiliza boa parte (eu diria que algo em torno de 90%) desses conceitos.

    Sensacional!

    Um abraço,
    Luiz Gustavo Schroeder Vieira, FCE, CTAL-TA
    Consultor de Testes
    BSTQB TAG Member
    +55 (48) 9994-3569
    Skype: luizgsvieira
    luizgustavo@LUGATI.com.br
    http://testavo.blogspot.com
    http://www.LUGATI.com.br

  8. Olá Fabrício,

    Muito obrigado pelo comentário!

    De fato o seu comentário ressalta um ponto importante. Muitas vezes estamos tão acostumados com determinadas coisas que elas se tornam naturais demais.
    Os conceitos (ou pré-conceitos) dos modelos tradicionais e hierárquicos sobre os modelos ágeis de software que estão amplamente difundidos fazem com que aceitemos alguns conceitos sem questionar. É mais um dos motivos que geram tantos mitos sobre a qualidade do desenvolvimento ágil.

    Novamente, obrigado.

    Abraços,

    Camilo

  9. Não ficou claro como a LUGATI trabalhará com ágil.

    “Como que vão garantir a qualidade no desenvolvimento do software se a alteração do requisito é feita ao telefone pelo Product Owner e gritado para a equipe pelo Scrum Master? Controle de mudanças? Em software pequeno é fácil ter esse controle.”

    Sinceramente, o paragrafo acima não me convence de que seja claro para a empresa o que ágil significa. Ninguém grita no telefone o que deve ser mudado e de imediato o programador pega aquilo e implementa. Há um processo por trás que garante a qualidade do produto. Qualidade esta, que é a maior bandeira do desenvolvimento ágil. Não sou eu quem digo isso, os livros dizem. Se não confia em livros, confie em dados.

    Desenvolvimento é relativamente novo, e ainda aprendemos com ele. Testar APIs complexas não é nada novo, muito menos trabalhar com integração entre hardware e software, de qualquer forma, concordo com você que há uma complexidade maior do que simplesmente integrar com uma API SOAP ou RESTful, mesmo assim, em minha experiência, já vi isso acontecer, mock não é uma bibliteca, não é uma prática de desenvolvimento de software. Mock é um conceito, e assim sendo, pode ser aplicado ao hardware. Recomendo-lhe a leitura do livro Arduino: A quick-start guide, ou ainda Programming your Home, ambos da Pragmatic Programmers.

    Concluo dizendo uma frase que você mesmo já deve ter usado com algum cliente: “There’s no silver bullet on software engineering”. Ninguém disse que o Ágil pode ser aplicado a tudo, mas até descobrirmos seus limites, continuaremos o levando adiante. Não é um ataque, tampouco um ataque pessoal, mas os limites apontados por você até o momento demonstram apenas falta de conhecimento sobre o assunto.

  10. Muito bem Carlos, esse é o espírito.

    A questão não é conhecimento na metodologia A ou B, o motivo pelo qual eu questiono as metodologias ágeis é simplesmente no uso dela como “preferida” para qualquer tipo de projeto. Principalmente quando a empresa desenvolvedora a utiliza em projetos terceirizados (outsourcing), acho que está jogando dinheiro no lixo. Não confio em gráficos de Burndown e afins, mais uma vez eu aperto a tela de que relatório geralmente é utilizado para “agradar” o cliente. Na prática é muito diferente. Em livros, tanto o RUP como a metodologia ágil são lindos, na prática existem suas limitações.

    Reforçando o que você mesmo disse, a metodologia (nem A, nem B e nem C) não resolve todos os problemas. A forma de trabalho deverá ser direcionada para cada realidade.

    Ah, esqueci de colocar a tag #ironia no comentário abaixo:
    “Como que vão garantir a qualidade no desenvolvimento do software se a alteração do requisito é feita ao telefone pelo Product Owner e gritado para a equipe pelo Scrum Master? Controle de mudanças? Em software pequeno é fácil ter esse controle.”

  11. Olá Gustavo,

    Reconheço que o principal problema de contratar júniores não são fatores técnicos, mas sim as soft skills e consultant skills, mas claro, esses profissionais estão alí para evoluir isso também, e sempre vão te rum senior do lado, por isso eu falei sobre o pareamento. Ninguém é louco de colocar um júnior na linha de frente com o cliente, mas sim, júniors podem trazer visões técnicas mais inovadoras e simples do que muitos sêniors, já vi isso contececer muitas vezes.

    Em BH eu tive a oportunidade de prestar seriços como consultor para uma empresa de cinco amigos extremamente seniores (mais de vinte anos em computação), que construiram uma empresa e contrataram em sua maioria profissionais plenos e júniors, a maioria sem nenhuma experiência de mercado, mas com grande conhecimento acadêmico e com muita vontade de fazer software com qualidade. Eles praticam coaching todos os dias, acompanham esses novos profissionais e dão treinamento constantemente. Essa empresa está disputando projetos com duas ou três empresas CMMi 3 e 5. E olha que eles só implementam um pouco do scrum, portanto nem é resultado de metodologia, mas de força de vontade.

    Existem várias formas de atrair bons profissionais. Uma delas são altos salários, mas você pode prover um ambiente agradável e usar tecnologias e modelos inovadores por exemplo. Muita gente troca 25% de salário por esses tipos de “benefícios”. Claro, não estou falando que é fácil, mas é uma estratégia muito usada por start-ups e vem dando muito certo.

    Não só júniores como também pessoas sem nenhum background em computação. Eu converso frequentemente com uma QA que é formada em nutrição e executa o trabalho de QA com muito louvor, inclusive melhor do que muitos mestres certificados que conheci. Diversidade é um fator muito importante para entregar o software que importa com qualidade :)

    Amigo, nenhum ser humano precisa lembrar nada depois dessas duas semanas. . . é por isso que as funcionalidades são totalmente descritas na forma de testes de aceite, usando por exemplo BDD e Specification by Example e o produto é mantido sempre integrado, funcionando e pronto para usar como descrito em continuous delivery. Através de recursos mais antigos como integração continua e TDD já conseguiamos desenvolver com qualidade o tempo todo, agora com build pipeline e BDD por exemplo, conseguimos manter a qualidade o tempo todo. Acesse a página do flicker por exemplo, (http://code.flickr.com/) você ai notar algo como “Flickr was last deployed 3 hours ago, including 6 changes by 4 people.”. Isso significa que eles tiveram commites em produção que passaram por uma série gigante de testes automatizados de unidade, de interface, cross browser, performance, segurança etc. A cada duas semanas, quanto temos as novas USs para implementar cobrimos todos esses testes, logo não precisamos nos preocupar mais com isso. Se acharmos um bug, escrevemos um teste para ele, assim depois de corrigido garantimos que não vai acontecer mais. Todas essas praticas são amplamente usadas em times ágeis, regressão não é um sofrimento pra gente. :) O teste exploratório é complementar e todo novo comportamento identificado nele é escrito na forma de comportamento testável.

    Como comentei no primeiro item para quem odeia ágil, as experiências em projetos com má implantação, principalmente quando se aplica apenas Scrum, podem causar esse ponto de vista. Ágil é muito mais XP do que qualquer coisa gerencial, e é importante ter em mente que Scrum é baseado em ágil e nem todo ágil é Scrum. E sim, eu sei, outro dia mesmo um desses super sayajins que sabem de tudo falou sobre um tema bem recente relacionado a agile sem ter conhecimento sobre ele, só para aparecer, e quase queimou esse tema durante uma palestra, por falar sem saber do assunto. Espero que tenha novas oportunidades com ágil e elas possam ser melhores :)

    Sobre a continuidade dos processos usados atualmente em software embarcado, eu acho muito normal, pois está funcionando. Temos poucos relatos de bugs que ocasionáram em tragédias ou grandes problemas e isso é muito bom. Em time que ta ganhando não se mexe :) Mas eu realmente acredito que daria certo com ágil também :) espero poder ver isso no futuro.

    Sim. Já trabalhei em dois projetos de PDV (Ponto de Venda) com máquinas que emitiam cupons fiscais, já trabahei em um projeto de controle de acesso usando crataca eletrônica e em outro de controle de ponto usando biometria, já trabalhei em projetos com diversas APIs e atualmente estou trabalhando em um projeto com cerca de 12 APIs muito complexas, mais de 70 assets por página além de integração com outros sistemas e migração de dados de NoSQL Database. Em todos esses projetos o uso de testes de unidade e BDD eram possíveis. Como no comentário do Carlos, podemos mockar se não for possível trabalhar diretamente com o hardware necessário.

    Fico muito feliz com a novidade (e fico mesmo!). Precisamos de mais pessoas descrevendo suas experiências (preferencialmente as boas) com ágil em português, e principalmente sobre testing, pois não temos muito mais do que quatro ou cinco blogs fazendo isso. Além disso o mercado brasileiro pode exportar muito para fora, mas para isso deve alinhar a forma de trabalho das empresas dos EUA e Europa, que em sua maioria trabalham de forma ágil.

    Abraços,

    Camilo

  12. Olá Carlos,

    Obrigado pela visita e pelo comentário.

    Bem lembrado sobre as balas de prata, por isso eu coloquei no final do post o comentário feito pelo Fowler sobre a pergunta. Acho que ele descreve bem esse cenário :)

    Obrigado também por lembrar do conceito de Mock.

    Abraços,

    Camilo

  13. Que texto fantástico! Achei ótimo o exemplo com o avião, vale extrair ótimos conceitos e um deles é que “pronto é pronto”. As partes devem chegar prontas e testadas onde farão parte de produto.

    Infelizmente o desenvolvimento e teste ágil não é compreendida por quem tem dificuldades em vencer paradigmas. Ainda escuto alguns desenvolvedores dizendo que se eles tem que realizar os testes (unitário) do seu desenvolvimento, porque a qualidade (testers) existe?

    Quanto ao texto, de fato ele ficou extenso, mas em momento algum senti gargalo na leitura, pelo contrário, muito agradável de se ler.

Leave a Reply