Canhão apontando para o mar.

Se você trabalha na indústria de software há alguns anos já deve ter experimentado diferentes processos de trabalho que prometeram ser a forma correta de fazer software – sempre há uma promessa de bala de prata diferente. Nos últimos 50 anos transitamos entre a ausência de métodos, variando posteriormente entre os mais prescritivos até os mais flexíveis. Já tentamos matar muitas formigas com tiro de canhão e, por conta disso, sua organização possivelmente está tentando ou já tentou adaptar seus métodos e processos à uma dinâmica mais simples, ágil e flexível. Seguindo a tendência, as organizações começaram a adaptar seu formato de trabalho e, eventualmente, forçar goela abaixo que todos os projetos se encaixassem na metodologia do momento. Surgiram coaches, apareceram quadros pelas paredes com papéis coloridos, pessoas são vistas em pé em reuniões diárias. Ainda assim, muitos tem a sensação de que os problemas não foram de fato resolvidos.

Pode ser que você ainda tenha o sentimento de que estamos buscando a forma ideal de trabalho. Então ficam as perguntas: O que falta? Há um processo ideal? Qual seria ele? Para entender como viemos parar onde estamos hoje, vale a pena olhar para trás.

O Processo Histórico – Do Caos à Ordem

A indústria de software nasceu sem processos. Grandes máquinas, alguns especialistas em operá-las e programá-las, tempos de feedback longos (entre perfurar cartões, aguardar o momento de validar os resultados, fazer a leitura, constatar um problema, retomar o trabalho, realizar ajustes e fazer tudo novamente).

Com o tempo, o potencial das máquinas foi evoluindo e, com isso, a capacidade de processamento. As possibilidades foram aumentando, surgiram diversas linguagens. Aumentaram as equipes e também a necessidade de organizar e gerir demandas, pessoas, clientes, contratos e riscos. O ambiente tornava-se cada vez mais complexo.

No final da década de 60 já dizia-se que enfrentávamos a crise do software [1]. O termo foi cunhado em uma conferência da OTAN em 1968. Alguns achavam o termo “crise” um pouco forte e emocional, e chamavam o problema de software gap ou lacunas de software. Mas o fato era que percebiam-se problemas. Já eram notórios os prazos não cumpridos, orçamentos estourados, requisitos que não atendiam as necessidades.

Assim, foi iniciado um debate sobre a necessidade de criar métodos e processos de trabalho que permitissem gerir esta confusão. Foi cunhado o termo Engenharia de Software. Como diz o relatório da conferência citada, “a expressão ‘engenharia de software’ foi deliberadamente escolhida
como sendo provocativa, ao implicar a necessidade de a fabricação de software basear-se nos fundamentos teóricos e disciplinas práticas, que são tradicionais nos ramos estabelecidos da engenharia”.

Conforme o debate evoluía, aplicava-se o único modelo conhecido de trabalho: o modelo fabril. A indústria de manufatura, com seus processos encadeados de trabalho, uma atividade após a outra, sequências com insumos e resultados pré-definidos, níveis de aceitação sobre o resultado conhecidos e mensuráveis, pessoas trabalhando em papéis especializados, foco em produzir resultados padronizados. Tudo isso nos fez acreditar que a indústria de software poderia se beneficiar do uso dos mesmos métodos.

A complexidade da indústria de software só aumentava e o cenário se tornava mais complicado. Na década de 90 isso foi evidenciado pelo Chaos Report [2]. Neste período, os motivos mais citados como causas para que projetos de software falhassem eram “baixo envolvimento dos usuários”, “falta de clareza e incompletude dos requisitos”, “mudanças de requisitos”, “expectativas e prazos não reais”, “falta de planejamento”, “produto já não estar adequado ao que o cliente precisa” etc.

O grupo de estudos que gerou o relatório (The Standish Group) chegou a conclusão de que boas soluções para os problemas da época seriam tempos de entrega menores, com entrega de software antecipada e constante, entrega de pedaços de software pequenos e incrementais. Que coisa! Curiosamente, pareciam estar falando de premissas dos métodos ágeis. Mas, ainda não era sobre isso.

Saímos do modelo cascata para modelos incrementais. Continuávamos entendendo que precisávamos de mais planejamento, requisitos estáveis, bem definidos e documentados, papéis específicos (surge o termo stakeholders). E, assim, saímos do cenário de zero controle para total controle.

Fomos levados a crer que deveríamos planejar tudo e o sucesso seria seguir o plano sem desvios. Devíamos gerir as mudanças, afinal, mudanças eram ruins e extremamente nocivas ao resultado planejado. Sobrecarregamos o controle e prejudicamos a colaboração com pessoas especializadas, planos complexos, atividades encadeadas, tentativas de previsibilidade absoluta, artefatos em demasia, documentação como contrato, modelagem excessiva.

Vivenciamos a adoção da UML e a aquisição de ferramentas case que nos ajudassem a criar e manter todo o controle. Surgiram as certificações. Grandes empresas se adequaram aos processos e se certificaram, enquanto pequenas empresas ficaram órfãs de métodos por não conseguirem arcar com todo o custo para administrar essa “parafernalha”.

Tentamos controlar o caos, mas ainda existiam perguntas: Se estávamos adotando métodos conhecidos e amplamente usados na indústria, por qual motivo ainda errávamos? Como seria possível disseminar e adotar métodos tão robustos em empresas que não tinham condição de arcar com esse custo? Ficariam elas, eternamente, construindo software sem metodologia?

Mesmo com planos, requisitos, ferramentas, continuamos falhando. Demorávamos demais para entregar valor. O mundo passou a exigir de nós mais velocidade para viabilizar o negócio dos nossos clientes. Precisávamos continuar competitivos. Apesar de software incremental, ainda tínhamos burocracia e desperdício demais. Surgiram então os métodos ágeis, focados em minimizar o desperdício de trabalho, entregar valor mais rapidamente, aumentar a colaboração entre os envolvidos.

Uma das grandes mudanças de pensamento que norteiam os métodos ágeis é a aceitação da mudança. Enxergar a mudança como algo inevitável e inerente a qualquer negócio permitiu lidar melhor com a natureza instável do desenvolvimento de software. Assumindo isso, os métodos começaram a contemplar a melhoria contínua como parte do processo, entendendo que é preciso inspecionar e adaptar o software e o processo ao longo do tempo. Essa parecia ser a solução. Deveríamos ser ágeis!

Sou Ágil, Mas Ainda Falta Algo

Com os processos “tradicionais”, realmente percebíamos desperdício. Fazíamos muitas coisas desnecessárias. De fato, tínhamos lentidão da entrega de valor. Assim, quando as organizações decidiram “ser ágeis” parece que pudemos perceber mudanças positivas, mas enquadrar todos os problemas em um formato de solução era a melhor forma de implementar práticas ágeis? Quem decidiu na sua organização qual seria o método implementado? Scrum ou Kanban? Com base em quais critérios?

Uma questão que já foi entendida por quem estuda e aplica métodos ágeis: eles não são ideais para qualquer contexto. Basta entender o contexto em que o Manifesto Ágil foi gerado: desenvolvedores extremamente experientes e vividos, ou seja, plenamente capazes de realizarem auto-gestão. O conceito de auto-gestão pressupõe maturidade para a tomada de decisão. É muito provável que o time precise de conhecimento sobre boas práticas de desenvolvimento, sobre ferramentas e métodos a fim de selecionar as melhores e mais adequadas para o problema que estão tratando. Além disso, é preciso profissionalismo suficiente para saber de quais práticas podemos abrir mão e quais não devemos abrir de forma alguma.

Adicionalmente aos aspectos da própria equipe, existem questões fundamentais para o atendimento das premissas ágeis. É preciso que exista uma relação próxima entre desenvolvedores, negócio e clientes. Entretanto, sabemos que nem todas as empresas e clientes apresentam essas condições.

Os métodos ágeis são pautados em valores. Isso ajudou a aumentar o propósito das pessoas. O foco nas pessoas também ajudou a criar senso de pertencimento. Além disso, são sugeridas diversas práticas, alinhadas a todos os valores e princípios.

O problema é que os métodos dizem apenas o que fazer, mas não dizem como fazer. Alguns, como o Scrum, por exemplo, são muito mais focados em resolver aspectos de gestão e focam pouquíssimo nas questões técnicas (embora elas sejam consideradas importantes, assume-se que o time deve elencar as mais adequadas e não cabe ao método apontar as melhores).

Como Decidir Sobre Qual Método Usar?

Para sair de um método para outro, a equipe ou a organização precisam traçar uma estratégia. É preciso ter entendimento e visão sistêmica. É preciso entender porque os métodos são como são. Mais que isso, é preciso entender o problema específico que pretende-se resolver, como o sistema de trabalho se comporta para, aí sim, adaptar algum método à sua realidade. Se você não entende como chegou onde chegou no seu projeto, corre o risco de aplicar os métodos e práticas mais novos e continuar enfrentando as mesmas dificuldades. Especialmente os gestores podem e devem se tornar um designer de processos de trabalho.

Uma abordagem para tentar tirar proveito dos métodos e usá-los no contexto certo é entendê-los. Após adquirir alguma bagagem, é preciso entender o problema que se tem nas mãos. Qual a essência do seu trabalho? Como é a relação com seu cliente? Você está envolvido com a construção de um software novo ou com a sustentação e manutenção de software legado? Como interagem e colaboram as pessoas no seu ambiente de trabalho?

Para nos ajudar a constatar que nem todo problema deve ter a mesma solução, veja a abordagem do Framework Cynefin

Framework Cynefin

O Framework Cynefin [3] (se pronuncia algo como “kuhnevin”) pode ser uma ferramenta para avaliar o tipo de problema que você ou sua organização tem. Entendendo o contexto do problema fica mais fácil identificar os critérios e as abordagens para melhor solucioná-los. Ou seja, não estamos aqui criticando as práticas ágeis, mas demonstrando uma maneira de avaliar qual prática tem mais chance de se adequar ao seu problema.

O Framework Cynefin apoia o processo de caracterização de um problema com base na identificação de seu contexto de tomada de decisão. Ele identifica cinco domínios: (1) Óbvio (você vai encontrar também a nomenclatura “simples”); (2) Complicado; (3) Complexo; (4) Caótico; (5) Disordem.

Domínio 1: Óbvio

Este domínio tem como principal característica a previsibilidade por conta de uma relação óbvia de causa e efeito. Os problemas são compreensíveis, as soluções são evidentes. Para resolver problemas desta classificação, deve-se observar os fatos, categorizá-los (no sentido de entender quais são as causas) e aplicar as melhores práticas reconhecidas para tratamento do problema. Este é o domínio onde podemos pensar em soluções por roteiros ou manuais, onde não é necessária uma especialização para resolver o problema ou é demandada apenas uma especialização mínima.

Domínio 2: Complicado

Este é o domínio em que causas e efeitos podem ser identificados mas requerem conhecimento especializado. É possível ter alguma previsibilidade, mas alguém com experiência precisa analisar o problema e situações similares, avaliar boas práticas que levariam ao resultado desejado e elaborar um plano para se chegar ao resultado. Há trabalho de evolução, mas não há grandes novidades ou inovação.

Domínio 3: Complexo

Neste domínio não é possível aplicar relações conhecidas de causa e efeito, mas elas podem ser conhecidas “a posteriori”, apesar de não serem repetíveis. Pode ser difícil, inclusive, saber as perguntas a serem feitas para obter algum resultado. É o domínio do imprevisível. Por isso, não adianta realizar análises prévias ou buscar especialistas, pois não é possível prever a solução ideal. As soluções, geralmente, emergem a partir da experimentação, ou seja, só é possível avaliar se uma solução foi adequada fazendo uma análise sobre algo que já passou. Nestes casos, cabe tentar prover mecanismos em que seja possível explorar, analisar e prover solução, possivelmente sendo necessário iterar sobre este processo caso a solução ainda não seja a mais adequada.

Domínio 4: Caótico

Neste domínio não é possível identificar relação de causa e efeito. A abordagem precisa ser realizar uma escolha rápida para tratar o problema e tentar levá-lo a um estado de maior ordem (por exemplo, para o domínio complexo). Geralmente, não há espaço para avaliar a melhor solução, apenas escolher uma que funcione e fazer o problema estancar e o sistema se estabilizar. Desse modo, é um domínio que precisa primeiramente de ação para, só então, realizar análise e propor solução definitiva.

Domínio 5: Disordem

Este é o domínio que ninguém deseja estar. Se você não consegue definir em qual dos outros domínios seu problema se encaixa, provavelmente ele está no domínio da desordem. Por isso, não há como começar a tratá-lo. A única saída aqui é identificar o que se sabe e o que não se sabe sobre o problema, agregar informações e focar em categorizar o problema em algum domínio conhecido. Uma abordagem é tentar fragmentar o problema em problemas menores, para categorizar cada parte adequadamente afim de prover o tratamento adequado.

Onde Estamos e Para Onde Vamos?

Pelas características descritas no Framework Cynefin, podemos perceber que os problemas do desenvolvimento de software dificilmente se encaixam em um domínio diferente de Complicado ou Complexo. A natureza do software é imprevisível e variável, bem como o ambiente de desenvolvimento é complexo porque envolve pessoas, demandas de diferentes tamanhos, clientes com desejos distintos etc.

Provavelmente, se for possível tratá-lo como um problema simples, deve estar havendo desperdício ao usar pessoas que trabalham na indústria da criatividade para executar tarefas repetíveis e de solução simplificada.

Por conta disso, a escolha de um método de desenvolvimento precisa comportar a maioria dos problemas de software: variabilidade, incerteza, mudança, experimentação. Parece adequado, por exemplo, escolher abordagens tipo Scrum para problemas do domínio Complexo [4], uma vez que o método tem como foco prover experimentação e feedback.

Como o espectro da indústria de software lida com desenvolvimento de inovação, mas também lida com manutenção, sustentação etc, é provável que estes outros problemas se enquadrem em outra categoria e devam ser tratados com métodos diferentes.

Sendo assim, convidamos você a analisar o seu problema e adquirir conhecimento sobre a finalidade de cada método e práticas sugeridas, antes de amá-los ou odiá-los. Convidamos você a ser um designer de processos de trabalho. Só o conhecimento e a reflexão sobre problema e solução farão de você alguém que não vai sugerir balas de prata para solucionar problemas, nem buscar soluções robustas como canhões para matar simples formigas.

Referências

Como leitura complementar deste post, veja o artigo The New Methodology escrito por Martin Fowler em 2015, onde ele expõe questões similares sobre a evolução das metodologias de desenvolvimento de software.

Veja a explicação sobre o Framework Cynefin dada pelo próprio criador, Dave Snowden, neste vídeo:

Demais referências usadas no artigo:

[1] P. Naur and B. Randell, (Eds.). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231pp. Disponível em: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

[2] Standish Group International. The Chaos Report, 1994. Disponível em: https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf

[3] Cynefin framework. Disponível em: https://en.wikipedia.org/wiki/Cynefin_framework

[4] Livro Scrum Essencial – Um Guia Prático Para o Mais Popular Processo Ágil. Rubin,Kenneth S., 2017 – Alta Books.

Deixe uma resposta