Prestem atenção à esse gráfico:

Esse é o gráfico de categorização de complexidade em projetos de desenvolvimento de software. Ele é usado em cursos avançados de Scrum, como o Scrum in Depth, e está disponível gratuitamente na internet, junto a muito material avançado sobre Scrum e agilidade. A informação vem acompanhada de alguns dados:

• Se adicionarmos a dimensão de pessoas, um nível adicional de complexidade é adicionado
• O último projeto simples foi em 1969

(Esse “último projeto simples” deve ter sido a gravação do Abbey Road, dos Beatles – e olha que se isso não foi complexo, pra não dizer caótico, eu não sei o que foi.)

O gráfico não é parte do curso de Professional Scrum Developer, apesar de eu ter utilizado ele semana passada na primeira edição do curso. Eu o acrescentei deliberadamente, e discuti em seguida o conceito de emergência, e como ele afeta software. É isso que quero discutir rapidamente aqui. Adianto que de forma alguma eu vou encerrar a discussão ou cobrir todo o assunto, aliás, eu vou confundí-lo ainda mais, mas eu vou escrever assim mesmo. Quando você me encontrar na rua pode me parar para dizer que não concorda, que eu estou errado, que não entendeu, ou me contar como o conceito mudou sua vida.

A discussão é importante, porque ela está na base da utilização da agilidade. Não é a toa que usamos a agilidade, e sem conhecer um pouquinho sobre complexidade fica parecendo que o manifesto ágil surgiu do nada, que o Scrum é definido pelas suas práticas, e que como os processos ágeis são empíricos, sua base teórica também deve ser. Ainda que muito empirismo tenha motivado os primeiros agilistas (quando esse nome sequer existia) muito estudo também os dirigiu. Estudos humanos, filosóficos, lógicos, matemáticos, físicos, entre outros.

Antes que você desista, já que já se passaram vários parágrafos e eu ainda estou introduzindo o assunto, já adianto que não vou te inundar de conceitos sobre complexidade, você procura na Wikipedia se gostar do assunto, ou assiste o vídeo do Akita, se quiser descobrir que eu nem arranhei a ponta do iceberg e há muito ainda a estudar.

De qualquer forma, vou tocar nos efeitos de um sistema complexo, e isso é muito simples. Primeiro vamos entender o gráfico.

De um lado, no eixo Y, estão os requerimentos, e o eixo vai de com mais concordância a com menos concordância. Quanto maior o número de Y, menos concordância há sobre os requerimentos.

Do outro lado, no eixo X, está a tecnologia, que vai do zero, onde está perto da segura, ao infinito, onde está longe da certeza.

Teríamos um eixo Z, de pessoas, que não aparece.

Projetos simples são projetos com requerimentos consensuais e transparentes e tecnologia segura e certa. Projetos complicados variam uma, e apenas uma, destas variáveis, e só um pouco. Não são muito diferentes, projetos complicados são iguaizinhos projetos simples, só que você precisa de mais esforço para gerenciá-los, mas pode usar as mesmas técnicas usadas com um projeto simples, que vai funcionar.

No outro extremo estão projetos caóticos, que possuem requerimentos sem consenso, e tecnologia incerta ou desconhecida. Este tipo de projeto é mais conhecido como “um projeto comum de software” para a maioria do mercado. Esses projetos são caracterizados pela completa falta de certeza em praticamente tudo, incluindo escopo, prazo ou custo. Nesse tipo de projeto não se sabe se uma mudança vai levar uma hora ou 30 horas pra ser feita, e com frequência se estima um valor, e é o outro. Nesses projetos o escopo está completamente descontrolado, e o papel do gestor, seja ele um GP tradicional ou um suposto time Scrum ou XP, é simplesmente tomar a culpa, já que a gestão não está fazendo nenhuma diferença e o projeto vai sofrer invariavelmente. O “suposto” é porque se fosse um time Scrum ou XP de verdade isso não aconteceria, como você verá a seguir.

No meio está uma terceira área, em cinza. Ela está destacada porque é lá que os projetos ágeis fazem sentido. É lá que eles ficam financeiramente viáveis. Nessa área não podemos usar as mesmas técnicas usadas em projetos simples ou complicados, porque há algo atrapalhando: projetos complexos não são lineares.

Você sabe o que significa dizer que algo é não linear? É algo no mínimo peculiar e ignorado na nossa sociedade que não consegue fazer contas que vão além de uma fórmula de báscara. Então eu vou te contar. É revelador. Mas primeiro temos que entender o que é algo linear.

Imagine que um desenvolvedor, ao iniciar um projeto, desenvolve 10 linhas de código por hora. Essa é a curva de produtividade do projeto:

Se mais ninguém for trabalhar no projeto, esssa seria a curva até o final do projeto:

Se mais um desenvolvedor que produz 8 linhas de código por hora for acrescentado ao projeto no inicio do tempo 2, ele ficará assim:

Até o final do projeto vamos ter algo assim:

Se você acrescentar um terceiro desenvolvedor que faz 14 linhas de código por hora, o projeto ficará assim, com um total de 32 linhas de código por hora (o total do desenvolvedor 1, mais o 2, mais o 3) no final do tempo 4:

Simples, não é? Isso é o que se espera em um projeto linear. Somos capazes de adicionar “recursos” (odeio esse termo quando aplicado a pessoas) aos projetos, e estas movimentações são somadas ou subtraidas linearmente. E é assim que a grande maioria dos projetos de software é planejado: um desenvolvedor faz 10, logo 2 iguais devem fazer 20. E assim se constroem gigantescos cronogramas de centenas de linhas e anos de planejamento. Com base nessa suposta lineariadade vemos cronogramas absurdos, que planejam em detalhes anos à frente. Além do Microsoft Project esses gestores devem usar também bolas cristal. Sabem porque?

Porque isso simplesmente não existe, isso não acontece, não se confirma. É um planejamento inutil. Sabe porque não acontece? Voltando ao exemplo anterior, quando você acrescenta o segundo desenvolvedor, o primeiro vai ter que parar para sincronizar com ele o que está acontecendo no projeto. Além disso, eles podem não se entender e a produtividade dos dois cai. Ou eles se dão muito bem, e a produtividade deles fica muito maior do que o esperado. Ou suas habilidades são perfeitamente complementares e não há nenhum problema que eles não possam resolver, e o projeto fica pronto em um quarto do tempo. Isso é o resultado real das interações entre dois seres humanos; elas nunca são lineares. Nunca. É impossível prever qual vai ser o resultado dos dois desenvolvedores trabalhando juntos.

E eu só estou tocando no item pessoas, que sequer aparece no gráfico do Ken Schwaber lá de cima. Ele toca em outros dois eixos: negócio e tecnologia. E os problemas são muito semelhantes.

Essas características não lineares, estas coisas que “aparecem” do nada devido à interação entre as partes, é o que chamamos de emergência. As partes cooperam positiva ou negativamente, produzindo um padrão muito difícil (senão impossível) de prever.

Quando o padrão fica muito complexo ele fica impossível de prever e portanto de controlar. É nesse momento que ele sai da área cinza do gráfico, que deixa de ser complexo e passa a ser caótico. Ele ainda seria previsível se possuíssemos uma quantidade de calculadoras que tende ao infinito, e se pudéssemos medir todas as variáveis. Infelizmente nós não temos nem um, nem outro. Dessa forma, a impressão que fica é que o resultado das interações das partes é aleatório e imprevisível, mas não é, nós é que não possuímos capacidade pra medir todas as variáveis. Na prática, isso é irrelevante. Apenas aceite que o resultado é imprevisível para todos os fins práticos.

Se o resultado de um projeto de software é imprevisível qualquer esforço de gestão é inutil. Temos então que impedir que o projeto fique caótico, temos que tentar mantê-lo “apenas” complexo.

É aí que entra o processo de controle empírico. Nesse processo estamos reavaliando o status atual a cada passo dado (e isso inclui até mesmo o tamanho do próprio passo). Fazemos isso porque sabemos que precisamos perceber os resultados emergentes o quanto antes para podermos nos adaptar a eles. Isso é feito com inspeção e adaptação constante, e com transparência que jogue luz sobre os acontecimentos. Não por acaso esses são os três pilares do Scrum.

Do mesmo livro citado acima:

“Porque planejar?
Para colocar um conjunto comum de entendimentos a partir do qual emergência, adaptação e colaboração possam ocorrer.”

E porque tanta gente passa reto por essa frase sem tentar entender seu profundo significado?

A emergência e falta de linearidade é também um dos motivo (mas não o único) que os frameworks ágeis colocam sobre o time, e não sobre um gestor único, a responsabilidade de gerenciar o projeto. Um único GP, por mais capacitado que seja, é somente um, e por isso é linear e simples, incapaz de lidar com as saídas de um sistema complexo. Para resolver o problema precisamos de um agente também complexo, materializado no time e suas interações ricas.

Vou parar por aqui, porque já imagino que o assunto deve estar complicado o suficiente. Fica só uma pergunta:

E agora? O que você vai fazer com esse conhecimento?

Há alguma coisas que você pode fazer para passar a lidar com o “problema” da complexidade. Antes de mais nada pare de usar “complexo” e “complicado” como se fossem sinônimos. Não são. A seguir, passe a perceber os resultados das interações ricas que acontecem entre as variáveis de um projeto, e como elas podem afetar o resultado do projeto. Desta forma você poderá compreender e ser testemuna dos efeitos de emergência em projetos de software. Tente então avaliar como um processo de inspeção e adaptação constante, que permitisse entender claramente o que estava acontecendo (por causa da transparência), poderia lhe ajudar a diminuir os riscos daquela interação, lhe permitiria ter virado o barco antes de ele atingir um iceberg, ou talvez aproveitar alguma oportunidade que foi perdida.

Mas não espere resolver esse problema sozinho. Já temos mais de uma década de práticas ágeis acumuladas, e só agora elas começam a chegar na grande maioria. Busque conhecimento que vai além de si próprio. A comunidade brasileira é bastante vibrante e possui diversos exemplos interessantes, com práticas que foram sucesso em um lugar e fracasso em outro. Avalie isso tudo sobre a luz destas teorias, que estão na base. Leia livros para entender isso tudo melhor, participe de conferências e discussões sobre o assunto. E se melhorar for urgente na sua empresa avalie contratar um consultor para ajudar. E cuidado com os que “implantam” Scrum em poucos dias. Isso é impossível. Já encontrei algumas empresas que passaram por esses consultores, e o resultado é um tsunami sobre os projetos.

E se você ainda não leu os recentes posts sobre emergência – documentação emergente e arquitetura emergente, sugiro que leia em seguida. Se já leu e não conhecia muito bem o conceito de complexidade e emergência, leia de novo, vão fazer ainda mais sentido.