No post em que diferenciei complicado, complexo e caótico eu explico alguns conceitos que deixam claro em quais tipos de projeto faz sentido uma abordagem ágil, e em quais faz sentido uma abordagem tradicional, baseada em cascata. Explico também o que significa ser simples, complicado, complexo, e caótico, além de explicar as características de um contexto complexo. Você vai aproveitar melhor este post se ler aquele primeiro.

Estou estudando o framework Cynefin e percebo que alguns conceitos complementam bem o que eu já havia iniciado, já que ele levanta os modelos de gestão apropriados a cada contexto.

A categorização é parecida com a que eu havia proposto antes, e que é parte do curso de Professional ScrumMaster:

Nesse gráfico, temos expostos os contextos em que uma situação, um projeto de software, por exemplo, acontece. Estes contextos são classificados em ordenados e desordenados:

1. Nos contextos ordenados as decisões são baseadas em fatos, existe uma clara relação de causa e efeito (causalidade), e o sistema restringe os agentes, ou seja, é possível limitar as ações e criatividade das pessoas e ainda assim obter resultados. Um estilo comando e controle pode funcionar, ainda que eu prefira uma liderança democrática, e não autocrática. Os contextos simples e complicados são contextos ordenados.
2. Nos contextos desordenados há necessidade de avaliação empírica, e a análise de padrões é que determina a resposta. Há pouca ou nenhuma relação evidente entre causa e efeito (ainda que ela exista, é difícil de medir). Nesse cenário, somente o autogerenciamento e a autoorganização libertam os agentes para criar soluções que realmente endereçam os problemas que aparecem. Hierarquia estrutural e autocracia são o melhor caminho para o fracasso. Os contextos complexo e caótico são contextos desordenados.

O problema maior é tomar um pelo outro. A maioria dos líderes/gerentes imagina trabalhar em ambientes ordenados. Isso é um problema porque as respostas esperadas em cada contexto são diferentes. Ao tomar um pelo outro, as decisões ficam aquém do esperado e produzem desperdício, no mínimo.

No contexto simples e também no complicado, o ambiente é planejado e previsível.

No simples, sabe-se tudo ou quase tudo o que pode acontecer ao processo. Nesse contexto, os líderes sentem, categorizam e respondem, ou seja, eles avaliam a situação, as categorizam e decidem com base nos fatos categorizados. Nesse cenário, os líderes podem não perceber a mudança de contexto, de simples para complicado, complexo ou caótico, e caminham para a falha, já que o contexto mudou e eles continuam aplicando técnicas baseadas em sentir, categorizar e responder, na expectativa de uma previsibilidade que pode ser falsa, e achando que sabem mais do que sabem.

No ambiente complicado, muito pouco é desconhecido sobre o processo e o produto. Sabe-se mais do que não se sabe. Nesse contexto, os líderes sentem, analizam, e respondem, ou seja, é preciso analizar as situações que aparecem, e não só categorizá-las. Essa análise fica a cargo de experts, que precisam informar como responder. Nesse cenário, não os líderes (como no contexto simples), mas os experts é que correm o risco de não perceber a mudança de contexto, e, junto aos líderes, podem aplicar abordagens erradas para endereçar cada situação.

No contexto complexo, o desconhecido predomina sobre o conhecido, sabe-se pouco, e não se sabe o que não se sabe. É preciso levantar os fatos antes de tomar as decisões, e por isso, o processo não começa pelo sentir, como nos contextos ordenados, mas começa com sondar, e então sentir, e só então responder. É o processo empírico tateando a cada passo, porque sabe que não é possível crer no planejamento, já que não sabemos quase nada. Nesse cenário, tentar impor ordem e buscar previsibilidade é caminhar para o abísmo, já que o contexto é naturalmente desordenado; mais vale entender e abraçar a complexidade, adaptando-se sempre que necessário. Aqui o sistema restringe os agentes, devido à sua imprevisibilidade, e os agentes restringem o sistema, impedindo que ele caminhe para o total desconhecido, inspecionando frequentemente e adaptando sempre que necessário.

No contexto caótico, não só não sabemos nada, mas não conseguimos saber. Não adianta sondar, os resultados serão nulos ou inúteis. Causa e efeito não tem relação aparente alguma. Resta agir, e esse é o primeiro passo, seguido do sentir, e então responder. Os líderes agem, e então sondam os resultados, e respondem aos efeitos dessa sondagem, tentando trazer o contexto para algo no mínimo gerenciável, onde também não se sabe, mas pelo menos temos como tatear, ou seja, buscam o complexo. O ideal é atuar de forma rápida, a fim de reestabilizar; imagine um avião em queda, e girando – a primeira coisa que se faz é agir e fazer o avião parar de girar, só depois é que faz sentido buscar nivelar o avião. Buscar ler os instrumentos ou planejar seria absurdo. Neste contexto, o sistema e os agentes estão sem restrições, não há controle ou previsibilidade alguma, e não há como medir. Mas o caótico não é só ruim, ao mesmo tempo que busca agir, o líder tem em mãos uma grande oportunidade de mudança radical, proporcionada pela desordem absoluta e pela total falta de posição. Se o momento caótico passar e a mudança não acontecer, dificilmente ela acontecerá tão facilmente como poderia antes.

Reforçando: o grande erro está em liderar imaginando um contexto, quando na verdade estamos em outro. O mais comum é responder utilizando técnicas para contextos simples ou complicados, quando na verdade estamos no caótico ou complexo, por acaso os mais comuns no mundo de software.

Por exemplo, uma empresa que desenvolve software sob medida, sempre atuando em novos clientes, ambientes, tecnologias, e com pessoas diferentes, vive um ambiente no mínimo complexo e portanto pouco previsível. Aplicar técnicas baseadas em análise e resposta, como as baseadas no modelo cascata, ou atuar como um líder que comanda e controla, é ignorar o contexto em que o projeto vive, além de ignorar o que não se sabe. Pior, assumir que sabe, ou até basear-se em informações erradas, desatualizadas ou ambos.

O mesmo vale para o oposto. Uma empresa que trabalha com um software vanilla, que customiza para clientes sempre de forma semelhante, está sempre atuando no mesmo produto, ou seja, atua num ambiente provavelmente no máximo complicado. Nesse cenário, sondar é desnecessário, e trará um custo extra ao projeto. Basta analizar os resultados das medições e corrigir de acordo com o plano. Um modelo em cascata, baseado em alta previsibilidade, seria o ideal e o mais barato.

E você? Trabalha em qual contexto? As decisões dos líderes batem com o contexto?

Cliente presente é algo que todos entendemos que é obrigatório para entregar um projeto com sucesso. Será que é suficiente?

Tenho visto alguma frequência que desenvolvedores se esforçam para construir uma aplicação corretamente, buscam um modelo rico, OO, fugindo do modelo anêmico. Usam tecnologias de ponta, ORMs, bancos NOSQL. Tem cliente presente. Entregam em iterações curtas, e chegam até a buscar o release contínuo. Buscam evitar o Scrum flácido, praticam XP, programam pareados. E falham. Quero analisar aqui um dos motivos que tenho visto para essa falha.

É comum que o cliente, apesar de presente, não tenha todo o entendimento de como o software deve se comportar. Um Product Owner pode saber o que deve ser feito, mas frequentemente não sabe como a aplicação deve funcionar em detalhes. Mas tudo bem, ele sabe quem sabe. E quem sabe é o especialista de negócio, ou business expert. Essa é a pessoa que realmente realiza as ações de negócio hoje, provavelmente de forma manual no Excel, como boa parte do planeta. É ele que sabe como as coisas devem funcionar, em detalhes.

Só que entender o negócio é algo complicado, e hoje em dia, mais do que nunca, precisamos de especialistas. E quem faz o trabalho super especializado de entender o negócio? O analista de negócio, é claro; vou chamá-lo de André. Ok, temos times multidisciplinares, pessoas multidisciplinares. Isso significa que provavelmente temos mais de uma pessoa no time que sabe fazer análise, mas ninguém o faz tão bem quanto o André. O André se especializou, ele leu o BABOK todo, fez cursos e mais cursos de análise, entende bem de usabilidade, conhece diversas técnicas para entender o que o especialista de negócio precisa, e sabe como documentar isso, como passar esse conhecimento pra frente.

Mas ele não programa.

Quer dizer, ele está num time multidisciplinar, mas ele prefere não programar. Quando está na hora de ele ser multidisciplinar ele escreve uns casos de testes, e está aprendendo a especificar com testes de aceitação com os Test Cases do Visual Studio, ou Fitnesse, ou Cucumber. Já faz uns 5 anos ou mais que o André prefere não programar. E ele é feliz assim, ele gosta de investir seu tempo no desenvolvimento de suas soft skills, é o que ele mais gosta de fazer. Isso é normal, todo mundo tem suas preferências, e estas habilidades são úteis ao projeto.

Então ele vai lá, analisa o negócio. Prepara o conhecimento e o transfere da melhor forma possível para o codificador – vou chamá-lo de Carlos – que vai implementar com código o que André analisou. O Carlos não fala com o especialista de negócio, ele fala com o André.

O André fala com o especialista de negócio sobre o negócio. Se o domínio é um caixa eletrônico, ele fala em saques, depósitos, saldos.

O André também fala com o Carlos. Ele fala de regras de negócio, fluxos principais, fluxos alternativos, wireframes, critérios de aceitação e até de tabelas de banco de dados de vez em quando. E no meio desse monte de outras coisas, ele também fala de saques, depósitos e saldos.

O Carlos, quando tem uma dúvida, pergunta pro André, que pergunta pro especialista de negócio. O especialista responde pro André, o André responde pro Carlos. O Carlos daí conta pros outros codificadores, analistas de banco de dados, etc. Ou o André conta.

Não preciso dizer que isso é um telefone sem fio, não é? Quem já brincou de telefone sem fio sabe que o que sai de um lado dificilmente é igual ao que chega do outro lado. E é assim que tantos consultores, cursos, etc, recomendam que façamos análise de negócio. Com telefone sem fio. Esse é um dos grandes motivos para a falha na entrega: entendemos errado porque o processo de comunicação é falho.

O Carlos, ao contrário do André, não se aprofundou em análise de negócio. Pode ser que ele odeie analisar o negócio, pode ser que não, mas de qualquer forma ele não desenvolveu tanto suas soft skills. Ele prefere codificar, ele se aprofundou em padrões de projeto, em OO, em assuntos diferentes do que o André se aprofundou.

Como resolver isso? Eliminando o analista de negócio do projeto? Claro que não! Quem fará a análise, o Carlos, que não é tão especializado? Não, é o próprio analista que fará a análise do negócio, mas ele o fará de uma maneira um pouco diferente. Em vez de fazer a ponta entre especialista de negócio e codificador, ele vai trabalhar como um facilitador da comunicação dos dois. Ele vai trazer o codificador ao especialista de negócio, ou vice-versa, e usar suas técnicas e soft skills para levantar as informações mais relevantes, na maior quantidade possível. Os três, juntos, vão desenhar a aplicação.

E na hora de parear, porque não o André, sentado ao lado do Carlos, enquanto ele codifica? Isso sim, é trabalhar num time verdadeiramente multidisciplinar.

Ingrediente pro sucesso.

Já cansei dessa discussão. Já respondi em blogs vezes demais, twitter vezes demais. A resposta é sempre a mesma: não, gerência de projetos feita ao estilo proposto pelo PMI no PMBoK não combina com frameworks ágeis (incluindo Scrum, antes que algum desinformado pergunte). São quase diametralmente opostas na sua essência. Obviamente que há práticas valiosíssimas no PMBoK, mas não é isso que estou discutindo, estou discutindo a essência.

O negócio fica pior se você considerar como a maioria dos PMPs pensam, mas nem vou entrar nesse mérito, todo mundo sabe como PMPs e gerentes de projeto baseados nas ideias propostas pelo PMI se comportam, todos sabem que a esmagadora maioria se expressa através do comando e controle, algo inaceitável em qualquer prática ágil. Coloco no ar apenas se é possível separar a teoria de como ela é aplicada; fica a provocação.

Pra não ficar só no achismo, aqui vão algumas citações diretas do PMBoK, no que tocam o gerente de projetos.

Cap. 1
”O gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto.”
”Um gerente de projetos é responsável pelo fornecimento de objetivos específicos do projeto dentro das restrições do projeto…”
”O gerente de projetos controla os recursos atribuídos ao projeto para atender da melhor forma possível aos objetivos do projeto, enquanto o PMO otimiza o uso dos recursos organizacionais compartilhados entre todos os projetos.”
”O gerente de projetos gerencia o escopo, o cronograma, o custo e a qualidade dos produtos dos pacotes de trabalho.”

Cap. 2:
”Gerente de projetos. A pessoa responsável pelo gerenciamento do projeto.”
”Os gerentes de projetos precisam gerenciar as expectativas das partes interessadas…”
”As organizações por projeto em geral possuem unidades organizacionais denominadas departamentos, mas esses grupos se reportam diretamente ao gerente de projetos ou oferecem serviços de suporte para os diversos projetos.”
”Os membros da equipe do projeto se reportarão diretamente ao gerente de projetos ou, se forem compartilhados, ao PMO.”

Cap. 4
”O termo de abertura do projeto concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades do projeto.”

Parei no capítulo 4. Está bom, né?

Está evidente que essa figura não encaixa bem em práticas ágeis. O gerente de projetos controla e comanda o time gerenciando escopo, prazo, custo e qualidade. Ele diz o que o time tem que fazer, depois vai lá e verifica se eles fizeram. Essa figura, como está descrita no PMBoK, não existe em Crystal, XP, FDD, Scrum ou qualquer outro framework ou metodologia ágil.

Lembro até hoje do Ricardo Vargas, chairman mundial do PMI, fazendo o Keynote do Scrum Gathering Brasil ano passado. Foi super bonito, bem ao estilo Lulinha paz e amor, todo mundo se dá bem, somos todos amigos, até o Juan Bernabó perguntar o que ele achava de times auto-gerenciados, e aí ficou claro que discurso é discurso, prática é outra coisa. O Ricardo falou que, na opinião dele, isso não funcionava, que tinha sempre alguém que ficava enrolando, e que alguém tinha que cobrar. Não que não seja verdade na realidade dele, o Ricardo Vargas gerencia projetos muito complexos, de plataformas de petróleo, e coisas do tipo, e vai ver lá funciona como ele falou, funciona tudo o que PMI propõe. Só que em software não funciona, ele não deve saber porque não trabalha com software (porque se trabalhasse não entregaria nada, assim como os outros GPs que trabalham com desenvolvimento de software). Não que isso seja um problema para estes gerentes de projeto, já que gerentes de projetos à la PMI não ligam que não conhecem nada de software, porque segundo o PMI o gerente de projeto deve ser capaz de gerenciar um projeto de qualquer tipo, de uma plataforma de petróleo a um ERP, de uma reforma à um novo projeto de marketing. Ah, então tá bom.

Esperem ver essa figura perdendo mercado em TI nos próximos anos. Cada vez menos GPs vão ser contratados. Alguns vão “virar” ScrumMasters, outros simplesmente vão para a rua ou vão fazer outra coisa. É inevitável.

E não acreditem em mim, vão lá ler. Baixem o PMBoK em algum lugar, leiam, e confirmem o que está escrito acima (sei lá se ele se vende ou se é de graça hoje em dia, o meu é hard copy). E descubram outras incongruências. E aproveitem para tirar suas próprias conclusões.

Cansei desta discussões. Que venham os flames agora, nos comentários.

Nas consultorias da vida eu já encontrei mais vezes do que gostaria projetos em que os desenvolvedores tem nojo do código. É sério, nojo mesmo, parece que estão olhando para algo pútrido, em decomposição. Porque será que deixamos as coisas chegarem a esse ponto? Você tem nojo do seu projeto atual? Qual a SUA responsabilidade nisso? Qual a nossa responsabilidade coletiva sobre isso? Vamos analisar.

Em um projeto tradicional o seguinte triângulo é usado com frequência:

No meio estaria a qualidade, resultado dos três extremos do triângulo. O triângulo geralmente significa que o cliente deve escolher dois pontos que ele quer fixar, e um ponto que vai ser flexível. Por exemplo, ele quer um projeto para 6 meses, e que custe 1 milhão. Para isso ele vai ter que flexibilizar o escopo. A qualidade é dada como fixa e constante.

No entanto, o que vemos no mercado é que os três pontos são fixos! O cliente do projeto quer um projeto para 6 meses, que custe 1 milhão, e que atenda um levantamento já realizado, ou seja, um escopo pré-definido. Nesses casos, tenho uma outra visão sobre o triângulo, ele não é mais um triângulo de compensações. Ele se parece mais com isso:

Isso é um triângulo impossível.

Mas estou sendo injusto. O triângulo não é impossível. Ele é possível, basta variar o quarto ponto, aquele que não aparece: a qualidade!

E é justamente isso que fazemos. Geralmente, como o escopo é fixo e os recursos também, é no prazo que temos sofremos. Estamos sempre atrasados, fazendo horas extras, dormindo pouco.

E vocês sabem o que acontece quando você pressiona um desenvolvedor por prazo? Ele diminui a qualidade! Isso é um fato! Imagino que se os inúmeros gerentes de projeto por aí tivessem essa informação eles iriam pensar duas vezes antes de se dobrarem sobre os ombros de um desenvolvedor e fazer aquela famosa pergunta: dá pra andar um pouco mais rápido? (ou outras semelhantes, como “já terminou?”, ou “dá pra entregar dia tal?”)

E sabe o que é pior? O desenvolvedor aceita essa pressão. Ele aceita cortar qualidade pra atender o prazo. Ainda pior, ele não conta que está cortando qualidade, e o coitado do gerente de projeto fica em uma situação ainda pior. Ou, mais frequentemente, o desenvolvedor sequer percebe que está cortando a qualidade.

A cada dia mais qualidade é cortada do projeto, mas atalhos são pegos. Em pouco tempo, o que acontece? Temos um código nojento, que ninguém mais quer trabalhar. O cliente, por outro lado, encontra um software nojento, resultado de um código nojento, e entende que o desenvolvedor só faz porcaria. A visão do cliente, não tenham dúvidas, é de que somos um bando de incompetentes. Já imaginou se seu médico cortasse qualidade toda vez que estivesse pressionado por um prazo? Já imaginou como seria uma cirurgia do coração? Mas não, ele não faz isso, ele é um profissional.

Pra resolver isso, há um instrumento vindo das práticas ágeis chamado “definição de pronto”. Vou falar dele semana que vem. Por enquanto, pensem sobre as consequências que sua decisão de aceitar pressão de prazo do cliente ou gerente de projeto, de forma recorrente. Pense que isso vai tornar sua vida miserável, e que você estará contribuindo para piorar a visão que se tem sobre nossa profissão.

Tenho estudado um pouco sobre motivação, principalmente por causa das consultorias que tenho feito. Tenho encontrado todos os dias confirmações de que temos grandes erros acontecendo no meio corporativo. Hoje eu quero falar da medição de performance e seu impacto na motivação e na entrega, e para isso vou começar com um texto que vem do livro “Agile Software Development – The Cooperative Game” do Alistair Cockburn e está disponível no site dele também, onde há um capítulo de exemplo (veja minha review na página de livros indicados).

“Picking Dandelions
Dandelions were beginning to clutter our back yard. Having three children aged 10 and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we’d get rid of dandelions in a few years.
The kids brought in bags of dandelions, and I paid out the cash.
On the third year, I commented to my now 12-year-old, Cameron, that it looked like we had more dandelions than the previous year.
He said, “Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn’t just putting them into the bag, I said, ‘I’m planting money for next year!’” ”

Traduzido:

“Pegando dentes-de-leão
Dentes-de-leão estavam se amontoando em nosso quintal. Tendo três filhos com 10 ou nenos anos, eu inventei uma solução brilhante: lhes ofereci um centavo por uma flor amarela e dez centavos por semente de dente-de-leão. Por cinco a dez dólares por ano, pensei que nos livraríamos de dentes-de-leão em poucos anos.
Os garotos trouxeram sacos de dentes-de-leão, e eu paguei em dinheiro.
No terceiro ano, eu comentava com meu filho Cameron, agora com 12 anos, que parecia que tínhamos mais dentes-de-leão que no ano anterior.
Ele disse: "Claro. No ano passado eu corri em volta, dançando e agitando todos os dentes-de-leão. Quando Sean perguntou por que eu não estava só colocando-os dentro do saco, eu disse: 'Estou plantando dinheiro para o próximo ano!" ”

É um texto curto e divertido, não é? Quem iria esperar esse final de história? Somente quem já está acostumado com os conceitos que vou expor neste post agora. Os conceitos ainda estão um pouco brutos, estou estudando ainda para depurá-los, há livros para comprar, e muito mais estudo a fazer. Este post é um primeiro passo para trazer isso para vocês.

Vamos tentar entender o que aconteceu com Alistair, qual foi o problema que ele teve? Ele estava pagando por entrega, ou seja, por dente-de-leão. Seu filho entendeu isso. Nada mais racional do lado de Alistair do que prever que em pouco tempo estaria livre das plantas. Mas ele não contava que os incentivos dele eram diferentes dos incentivos do seu filho. Para ele, o objetivo era limpar o jardim. Para seu filho, o objetivo era ganhar o máximo de dinheiro possível fazendo algo que o pai pediu. Quem ouvisse a história até a metade nunca saberia que havia uma divergência entre os incentivos de cada um. Eles pareciam idênticos, até o problema aparecer.

O primeiro problema então é a falta de comunicação. O pai deveria ter deixado claro que o objetivo era limpar o jardim.

Ainda assim, há um segundo problema. Mesmo que a comunicação se desse conforme o esperado, isso não significaria que o filho iria sustentar o objetivo do pai, e não o seu. Seus objetivos eram claramente conflitantes, já que para o filho ganhar muito dinheiro sempre deveriam haver muitos dentes-de-leão no jardim.

Vamos fazer um paralelo com a forma com que a indústria de software remunera seus funcionários. Entre os mais comuns estão:

• salário mensal + hora extra,
• salário mensal e hora extra proibida,
• pagamento por hora,
• pagamento por linha de código,
• pagamento por entrega.

Assumindo que os funcionários tem como objetivo ganhar o máximo de dinheiro possível, o que vai acontecer nos cenários onde a remuneração é atrelada ao tempo, como nos casos de salário mensal + hora extra, e pagamento por hora? Se para o funcionário ganhar mais, ele precisa trabalhar mais, então ele vai ter que ter trabalho pra fazer. Isso implica que se ele fizer tudo no horário certo e for pra casa, ele não vai maximizar seu salário. Para reverter isso, ele tem algumas opções: deixar os bugs correrem soltos e depois corrigir na hora extra, inventar funcionalidades desnecessárias ao projeto (goldplatting), inventar trabalho (análises desnecessárias, etc), trabalhar com arquiteturas difíceis de manter, tentar aumentar o escopo do projeto, e por aí vai. Nenhuma destas opções é boa para o projeto, mas são boas para o salário do desenvolvedor. E esses dois casos sozinhos devem ser a maioria do mercado.

Há o caso do pagamento por linha de código. Nesse caso, fica óbvio que o desenvolvedor vai criar a maior quantidade possível de linhas de código. Vai comentar tudo, vai criar declarações desnecessárias, loops que pouco fazem e por aí vai. Já imagine classes de 2 mil linhas e o inferno de manutenção. Pelo menos o pagamento por LoC é raro hoje em dia.

No pagamento por entrega, o objetivo é entregar. Nesse cenário, o desenvolvedor vai focar na entrega. Não vai inventar nada que não esteja focado na entrega, porque se isso acontecer o pagamento dele diminui ou atrasa. O problema é que nesse cenário o desenvolvedor faz a entrega a qualquer custo. Mesmo que para entregar mil reais em valor ele precise destruir dois mil reais. Se ninguém estiver medindo onde os 2 mil reais foram perdidos, então tudo bem. E não imagine que você vai conseguir resolver o problema na engenharia ou no conceito de pronto, porque ele vai dar um jeito de dar a volta nesses conceitos. Exemplo: precisa de testes, ok, vamos fazer testes inúteis, que não tomem tempo. Além disso, ele vai barganhar no custo de cada entrega, dizendo que as coisas são maiores do que são.

Em todos esses casos há ainda o problema do hiperfoco. O desenvolvedor hiperfocado na meta não olha para os lados, não pensa criativamente. E desenvolvimento de software é um trabalho criativo, ou seja, a performance do desenvolvedor vai cair caso você faça ele focar, porque ele não vai conseguir resolver os problemas. Há diversos estudos comprovando isso (vou colocar algumas referências no final).

Sobra somente o caso do salário mensal e hora extra proibida. Nesse caso, o desenvolvedor ganha sempre a mesma coisa, não importa o que faça. A motivação vai ter que vir de outro lugar. Se a empresa não motivá-lo ele vai virar uma pessoa apática, mas pelo menos não vai fazer 70 horas por semana e criar um monte de bugs. Como motivá-lo vai ficar para outro post, tenho coisas a falar sobre isso também.

O que eu quero que vocês levem deste post é: o que é reconhecido é feito. Se você pagar ou valorizar número de testes, espere ver milhares de testes na aplicação, mas não necessariamente testes efetivos. Se você valoriza linhas de código, os programas vão ser gigantescos, e por aí vai, você já entendeu.

“- Mas nem todo mundo quer maximizar o salário a qualquer custo”, vocês certamente dirão. Sim, há pessoas que possuem outros motivadores, mas os problemas que estou levantando acontecem a todo momento. A questão é criar uma cultura que incentive a automotivação, e não a motivação externa, mas, como eu disse, isso é assunto para outro post.

Eu trabalhei um bom tempo com uma metodologia muito interessante, que defendi por um bom tempo, o Balanced Scorecard. Hoje me preocupo muito com o BS em projetos criativos, pelos motivos que já citei. E pior, o BS é público, ou seja, não é só você se medindo, é a empresa inteira te medindo junto. Uma péssima ferramenta para motivar o funcionário. Se o objetivo é medir, meça, mas não divulgue, mantenha os dados na mão do gestor, que vai saber onde há problemas. No momento em que você libera a informação dos valores medidos o funcionário passa a se medir por ela.

Algumas referências interessantes sobre o assunto:

Veja esta palestra do Dan Pink sobre motivação. É de cair o queixo e ele compara o que a ciência sabe e o que as empresas fazem, e como isso não bate. Tem legenda em português:

Veja esta palestra sobre métricas ágeis apresentada no Agile 2009, disponível no InfoQ. Diversos fundamentos são colocados.

Veja o livro “Measuring and Managing Performance in Organizations”, citado na palestra acima. Ainda não li, mas está na minha lista.

E entenda o que um trabalhador do conhecimento quer de uma empresa, nesta thread do .Net Architects.

Ontem fiz uma palestra de apresentação de Scrum na IASP, uma universidade em Hortolândia. Foi uma apresentação de uma hora e meia, onde apresentei os problemas da engenharia de software hoje, alguns princípios da agilidade, um pouco da mecânica do Scrum, e como isso tudo se encaixa com a plataforma Microsoft. O público foi receptivo, e tiveram várias perguntas interessantes no final. Foi uma ótima experiência.

Seguem abaixo os slides da apresentação, e os links citados. (Agora só faltam mais seis.)

• Grupo de Scrum no Yahoo
• Scrum Alliance
• Site do Ken Schwaber
• Revista Visão Ágil
• Consultoria Giovanni Bassi
• Twitter Giovanni Bassi
• .Net Architects
• Podcast .Net Architects
• Grupo Online .Net Architects
• Twitter .Net Architects

Entre 6 e 9 de Outubro acontecerá o Agiles 2009, evento sobre agilidade, em Florianópolis.

O evento está com uma grade muito interessante, com figuras carimbadas da agilidade nacional, como Rodrigo Yoshima, Alexandre Magno, Rafael Sabbagh, Alexandre Gomes, Felipe Rodrigues, Manoel Pimentel, Renato Willi,entre outros. Há também palestrantes internacionais de peso, com palestras em Inglês e Espanhol.

Eu estarei lá, e como sempre, também um pessoal do .Net Architects. Estamos organizando a ida de São Paulo, e já confirmamos, com passagem comprada, o André Dias, o Victor Cavalcante, e o Raphael Molesim. Há ainda um pessoal do grupo de Floripa que deve ir.

Como acompanhar o evento? Pra variar, via Twitter. Já tem bastante coisa rolando lá na hashtag #agiles2009.

Se você não é de Florianópolis, sugiro avaliar ir pra lá. Além do excelente conteudo, o evento é logo antes do feriado de 12 de Outubro, o que vai garantir 3 dias de descanso na bela cidade.

Vejo vocês lá.

Acabo de responder um questionário de um aluno do Mackenzie sobre design patterns, que será utilizado em seu trabalho de conclusão de curso. Era curto (e isso é pré-requisito, ou eu não responderia), composto de apenas sete perguntas rápidas. Ele entrou em contato com alguns dos artigos que ando publicando sobre o assunto, e pediu meu feedback.

E porque estou contando isso pra vocês? Porque a terceira pergunta era essa:

Em algum projeto, durante a fase de análise, já foi detectado que a melhor solução era a não utilização de Design Patterns?

Fase de análise? Alguém ainda acredita em fase de análise? Parafraseando um twit meu, eu acredito em duendes, mas não acredito em fases de análise.

Minha resposta ao universitário:

Não entendo que exista uma "fase de análise". Isso leva a um modelo de desenvolvimento em cascata, que é prejudicial. E a analise arquitetural, que é feita um pouco antes do código, não deve chegar ao ponto de definição de padrões de codificação, mas sim a padrões arquiteturais. E mesmo essa, deve ser feita de forma incremental.

Não me estendi demais no comentário porque a pergunta já foi feita errada. Não é a primeira vez que entro em contato com conteúdo acadêmico fundamentado em práticas waterfall. As universidades, em sua grande maioria, estão presas à idéia de que construir software é igual a construir carros em uma fábrica, ou a construir uma ponte. Não é.

Temos que parar de "analisar o negócio" e voltar a escrever código. Milhões se gastam em papel, e proporcionalmente muito pouco em código funcionando. O overhead gasto em arquitetura, análise de negócio, análise de sistemas, documentação, gestão de projetos é grande demais. Tudo isso devia acontecer apenas como suporte do produto final funcionando. Temos que fazer análises arquiteturais, de sistemas, de negócio? Claro! Temos que ter uma fase para elas? Não, de forma alguma.

As universidades ensinam pouco aos estudantes, e quando dão para ensinar, ensinam isso: técnicas anacrônicas, despreparadas para a realidade. Os alunos chegam ao mercado de trabalho com a cabeça enviesada a favor de técnicas que não funcionam, e, dependendo da faculdade, ideológicamente estragados (principalmente se forem faculdades públicas).

Posso falar com autoridade sobre o assunto. Tenho aplicado, em paralelo à consultoria de arquitetura, também consultoria em agilidade. É comum o cliente entender a arquitetura, mas ainda ter problemas com processo, e acaba me perguntando como resolver, e aí aparece a consultoria de processo. Os resultados são impressionantes, e sempre muito positivos. E garanto: não existe fase de análise em projeto focado na entrega, ágil, produtivo.

Há muito o que caminhar ainda para que tenhamos uma profissão, para que possamos chamar nossa prática de desenvolvimento de software pelo nome de "profissão". Por enquanto, o que temos são discussões dispersas, práticas sem comprovação, e, sem dúvida alguma, ego demais.

Essa é uma questão com a qual me deparo frequentemente. Vou contar para vocês os cenários que tenho visto em muitas empresas, e que leva a escrever este post.

Fazer software é difícil:

• É difícil entender o que o usuário espera, o que o patrocinador do projeto espera, o que o gerente do usuário espera, e juntar tudo isso em uma solução única.
• É difícil fazer isso dar dinheiro.
• É difícil tornar isto prazeiroso para a equipe envolvida.
• É difícil conciliar todos estes interesses, muitas vezes opostos.
• É difícil encontrar uma boa arquitetura, onde exista equilíbrio na abstração, efetividade, e produtividade.
• É difícil encontrar bons profissionais, que gostam do que fazem, e são comprometidos com a empresa que trabalham, e não (só) com o salário que recebem.
• É difícil criar uma solução feita para enfrentar o teste dos anos, para o qual nenhuma técnica de testes (TDD, BDD, xDD) está preparada.
• É difícil escolher a plataforma correta para o desenvolvimento, incluindo a linguagem, a abordagem, e os princípios.
• É difícil, sobretudo, ter o envolvimento efetivo do usuário/cliente no processo de desenvolvimento.

E estas são só algumas das dificuldades. Se fosse tentar listar todas, o post seria sobre isso. Na verdade, teria que publicar um post beta para sempre, em revisão eterna.

Começo deixando isso claro, porque esse fato é reconhecido pela maioria das empresas. E reconhecendo-o, devem lidar com ele. Basendo-se nestas dificuldades, as empresas têm buscado soluções para estas dificuldades (problemas/oportunidades?). E boa parte destas soluções passam por proteger o desenvolvedor. O que significa proteger o desenvolvedor?

Proteger o desenvolvedor significa que os desenvolvedores devem ter a maioria dos problemas resolvidos para eles. Isso passa pela premissa de que eles são incapazes de resolver os problemas sozinhos. Por esse motivo, tira-se do desenvolvedor qualquer tipo de decisão, deixando a ele somente uma tarefa: codificar. Codificar o quê? O que o analista de negócios especificou. Como? Com o design do analista de sistemas. Com que técnicas e ferramentas? Com os frameworks corporativos, a (pré-definida) linguagem de programação homologada (atenção para o singular), e as abordagens (pré-definidas) pelo arquiteto.

Dessa forma, o codificador tem que tomar poucas decisões. Ele só tem que decidir o que não foi decidido para ele ainda. Neste estágio, não podemos mais chamá-lo de desenvolvedor, já que não desenvolve nada, só códifica. Todo desenvolvedor também é codificador, mas o oposto não é verdade.

Qual o problema com esta abordagem, que claramente vem de uma decisão gerencial? Enxergo de imediato dois:

O primeiro problema é assumir que o sistema de linha de montagem de uma fábrica de automóveis é plenamente compatível com o sistema de criação de um software. De que é possível alienar o trabalhador da informação, deixando para ele apenas um pedaço da montagem do software. De que é possível comunicar tudo o que é necessário com papel e diagramas. Enfim, de que é possível criar uma "fábrica de software", termo que devia ser apagado do vocabulário de qualquer pessoa que trate seu processo de desenvolvimento de software com seriedade. Estes sistemas, o de montagem de automóveis, e o de criação de um software não são compatíveis. Software é algo imaterial, que vive apenas na idéia das pessoas. Enquanto um desenho CAD é capaz de comunicar exatamente como uma caixa de câmbio deve ser produzida, um documento de especificação é incapaz de fazer o mesmo. Duas pessoas lendo o mesmo documento, ou mesmo falando com o mesmo usuário, terão idéias diferentes sobre o software a ser criado, não só no "o que", mas também, e principalmente, no "como". Entendendo isso, fica fácil perceber porque sistemas baseados em fábrica de software (seja ela interna ou externa à empresa), em linha de montagem, dão tão errado. Porque o software tem defeitos de especificação de negócios, de especificação técnica, e inúmeros bugs. Além disso tudo, nunca fazemos softwares parecidos (quem dirá iguais), enquanto que na linha de montagem de um carro, o carro é sempre o mesmo, mudam só alguns detalhes.

O segundo problema está na premissa que citei antes: os desenvolvedores são incapazes de tomar decisões sozinhos, não têm competência para isso, são incompetentes. Quando você trata o desenvolvedor como um incompetente, ele passa a se entender como um incompetente, e não se preocupa mais quando algo dá errado. Ele não busca mais a melhor solução, isso não é mais problema dele. Já que você está tratando ele como operário fabril, então ele vai se comportar como um. E já que ganha por hora, então o foco passa a ser fazer a maior quantidade de horas possível, que não vão dar em nada, já que ele sabe que nada dá em nada mesmo, porque é incompetente. A melhor maneira de acabar com o comprometimento de um desenvolvedor é tratá-lo como uma criança incapaz de tomar decisões.

Como resolver esses problemas? Atacando suas premissas. Primeiro: o desenvolvedor não é incompetente, e segundo: criar software é diferente de montar um carro. Como o assunto é proteger o desenvolvedor, vou falar da primeira. A segunda fica para outro dia.

Se você assume que seu desenvolvedor é incompetente, você tem duas opções: capacite-o para ser mais competente, ou mande ele trabalhar em outra empresa. Então vamos combinar assim: você entende que seu desenvolvedor não é incompetente. Sabendo que seu desenvolvedor possui competência para fazer um bom trabalho, você não deve tomar decisões por ele. Ele deve ser capaz de tomar as decisões corretas. Isso significa que ele deve ser capaz de falar com o usuário, decidir sobre a implementação de um requerimento, e saber usar padrões. O arquiteto pode ajudá-lo nessas tarefas, mas não deve realizá-las para ele. O arquiteto deve inspirá-lo, deve fazer coaching, mas nunca codificar para ele, porque ele é competente o suficiente para isso.

E onde ficam os frameworks corporativos, os padrões, a reusabilidade no nível da corporação? Muitas empresas fazem esse tipo de framework para ganhar tempo, diminuir a quantidade de código que escrevem, e agora? Este tipo de framework deve surgir quando necessário, e deve ter uma amplitude muito limitada. Acredito que é possível ter um framework corporativo, desde que ele emerja das necessidades reais dos projetos, ou seja, sejam abstraídos a partir de algo real que precisou ser implementado, e que pode ser reutilizado. Nesse contexto, os frameworks acabam sendo estritamente técnicos, e não de negócio, e atendem necessidades reais dos desenvolvedores. Por exemplo, não é possível ter uma entidade cliente e um repositório de clientes que possam ser reutilizados em qualquer sistema, porque em sistemas diferentes os contextos de uso do cliente são diferentes. A entidade cliente é grande demais para ser utilizada sem abstração, ela é um requisito de negócio, e cada sistema modela um processo de negócio diferente, e enxerga o cliente de forma diferente. O que faz sentido é ter componentes que resolvem problemas técnicos, como um repositório base, por exemplo, ou um framework corporativo para conexão com banco de dados seguro, ou ainda um framework de autenticação. Estes podem emergir quando necessários, e devem ser feitos seguindo boas práticas, como o open closed principle, para que não se tornem um peso no processo de desenvolvimento, mas sejam uma solução real.

Na prática, o que acontece nas empresas, é que o gerente não confia na equipe que tem, e estando acostumado a trabalhar no estilo comando/controle, diminui as variáveis que deve controlar para facilitar o próprio trabalho. É algo que pode até dar resultado em trabalhos mais repetitivos, como a montagem de um carro (e há casos onde esse tipo de coisa também não é verdade, vejam o caso da Toyota), mas certamente não funciona em software. Aplicar teoria clássica da administração na gestão de software é algo, no mínimo, anacrônico. O que deveria estar acontecendo é um movimento dos gerentes funcionais atrás de atualização, de forma a se prepararem para lidar com o trabalhador do conhecimento do século XXI, que não reconhece mais fronteiras hierárquicas, é criativo, independente, e, sobretudo, competente.

Se você é gerente, deixo aqui minha pergunta para você: que tipo de gerente você quer ser? O que entrega, tem funcionários felizes, baixo turn over, preparado para as necessidades contemporâneas? Ou o anacrônico, gerenciando conforme as técnicas ultrapassadas que pregam comando, controle, e que geram funcionários insatisfeitos, que em pouco tempo vão trabalhar em outro lugar se você não lhes der um bom calhamaço de dinheiro? E se você é empresário de TI, a pergunta é: que tipo de empresa você quer ter: a preparada para um mercado dinâmico, que demanda qualidade E custo, ou a ineficiente, que briga no mercado com centenas de concorrentes muito parecidos, depende de um nicho muito específico para viver, e que pode tomar a rasteira de uma empresa mais eficiente a qualquer momento e ir à lona? Ah, e se você é gerente, e não se entende também como empresário do seu próprio centro de custo, você está com problemas. Hoje o departamento de TI é um prestador de serviços, mesmo internamente, e você pode, se não der ROI, ser substituído tão rapidamente quanto um fornecedor. Fique atento.

Em resumo: se você está protegendo seus desenvolvedores está criando um ambiente onde a solução dos problemas não aparecem naturalmente, está restrigindo a capacidade dos desenvolvedores de dar a melhor solução para um problema, e está atrapalhando, e não ajudando o departamento que gerencia. Não proteja seus desenvolvedores, proteja o investimento que a empresa fez em você quando o colocou em uma posição gerencial, e busque produtividade encarando de frente a realidade que faz o desenvolvimento de um software nos dias de hoje. Permita aos desenvolvedores criar, e ajude-os a chegar lá, capacitando-os, e fomentando a reutilização quando ela fizer sentido, de forma a alavancar a produtividade.

A algum tempo percebi uma dinâmica um tanto perigosa que acontece nas empresas que demandam software via fornecedores internos ou externos. Isso engloba praticamente todo o mercado corporativo, mas deixa de fora empresas que desenvolvem software de prateleira. O que vou escrever a seguir trata deste primeiro tipo de empresa.

Sempre que um departamento precisa de um sistema, ele precisa demandar este sistema para alguém. Seja a demanda repassada para um departamento de TI interno, ou para um terceiro, o foco com razoável frequência costuma ser custo. Quando o departamento é interno estamos falando de rateio baseado em horas internas de outro departamento da empresa, então a discussão é em torno de horas. Quando a demanda vai para fora da empresa a discussão é financeira. Grandes empresas mantém departamentos de compras responsáveis por comprar desde toner para impressora e papel higiênico quanto software, e o tom, principalmente em tempo de crise, é comprar focado em preço. Para se proteger as empresas geralmente apostam em especificações e estimativas bem feitas (algo que não existe), e SLAs. Assumindo que a especificação determina o que vai ser entregue, faz sentido que o critério seja preço. Quer dizer, faria sentido se software não fosse software. Comprar software assim é como comprar serviços de advocacia por preço. Você faria isso se estivesse em uma enrascada? Arriscaria seu pescoço? E porque então arriscamos o dinheiro das empresas?

Invariavelmente os fornecedores, sejam eles internos ou externos, vão ter que baixar o custo para atender o cliente, que quer uma Mercedez pelo preço de um Fusca. Frequentemente o cliente simplifica o escopo ao máximo, a fim também de baixar o preço, e remove itens fundamentais a qualquer software. De cara morrem coisas "inúteis" como log de erros, por exemplo. Design gráfico também costuma nem entrar no projeto. Outros itens, de tanta falta de demanda, às vezes nem são oferecidos pelos fornecedores. Coisas "inúteis" como análise estática de código, integração contínua, e claro, uma análise arquitetural e/ou um arquiteto acompanhando o projeto. Afinal, essas coisas "inúteis" só acrescentam custo e não valor (atenção para a ironia). Então o cliente fala que não vai pagar por isso.

Porque isso acontece? Pois é, foi isso que eu descobri. Talvez vocês já saibam, mas para mim foi algo que de certa forma estava na minha cara, mas eu nunca tinha parado para ver.

A questão é simples: quem paga pelo software e quem paga pela manutenção? É muito frequente que o cliente final pague pelo desenvolvimento do projeto, mas não pelas pequenas manutenções subsequentes. O dinheiro sai do seu centro de custo somente no nascimento do projeto. Quem paga as manutenções geralmente é TI, que mantém uma equipe de suporte, alocada no seu centro de custo, debaixo do seu budget.

Esse fato leva o cliente a pedir o software mais barato possível. Os problemas e necessidades que vierem depois são resolvidos "de graça", ao custo do departamento de TI. E como o software foi feito de qualquer jeito, a manutenção é muito cara, o que leva a equipe de suporte a inchar cada vez mais, ou entregar cada vez menos valor. Quem disse que não existe almoço grátis?

Não é a toa que os CIOs são tão criticados por não entregar valor. Cerca de 80% do custo de TI vão para manutenção, e devido a essa dinâmica, uma manutenção cara que se originou nos próprios incentivos dados por TI.

Como eu disse no começo, essa é uma dinâmica perigosa, já que os custos do projeto são muito maiores do que o planejado, e o software não é feito para durar, mas para sair de qualquer jeito. E o trabalho do arquiteto é justamente fazer software para durar.

Gostaria de saber se isso é uma visão particular das minhas experiências ou se vocês confirmam esta visão. Comentários são muito bem vindos.

"You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one's impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)
Does this sound like what you are asked for when you're asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better."

Primeiros parágrafos do livro "Software Estimation: Demystifying the Black Art", da Microsoft Press, que você compra aqui na Amazon por meros 50 reais.

É tão importante deixar claro que uma estimativa não é um contrato, não é um compromisso, que o cara abre o livro dizendo isso.

Quantas pessoas e empresas entendem isso?

Acho que esse parágrafo, por si só, resolveria 90% dos problemas comerciais decorrentes de mudança de escopo e desvio de prazo presentes no mercado hoje.

Estimativa == Cálculo aproximado.

Combinado?

Eu tinha falado antes das regras para desenvolvimento de software, segundo Patrick Hynds, e a última, a regra de quatro palavras dele, era essa:

"Sem especificação, sem estimativa"

Fiquei de falar um pouco mais dela, e esse post serve para isso.

A regra, a princípio, me pareceu óbvia e simples, mas isso é só uma impressão. Por isso quero falar dela aqui com mais detalhes.

Vamos começar pelo final, entendendo a segunda parte da frase. Preciamos entender o que é estimativa. Estimativa no dicionário (grifo meu):

Cálculo aproximativo que se faz de algo.

"Aproximativo" é a palavra chave. Significa que nada que seja uma estimativa é preciso, mas é aproximado. Pedir uma "estimativa precisa" é como pedir para subir para baixo, para sair para para dentro, e outros absurdos. Estimativa sempre é imprecisa, sempre é, no fundo, um chute. A não ser que você tenha uma bola de cristal, sua estimativa nunca vai ser precisa, a não ser que você considere desvios altíssimos (200% por exemplo) dentro da sua taxa aceita de precisão. Mas aí eu diria que você precisa rever seu conceito de precisão.

Sim, uma estimativa pode variar 200%. Ou 0%. É um chute, ele pode entrar no gol ou passar longe. E excelentes jogadores, com frequencia, também batem para fora.

Com isso claro, podemos falar da primeira parte da frase: especificação. Mas antes eu quero falar de como o mercado compra software hoje.

O modelo dominante hoje no mercado é comprar projetos fechados de software. Isso significa que o cliente determina o que quer, e os fornecedores dizem quanto vai custar. A visão geral, que entendo ser muito equivocada, é que o fornecedor é especialista, e vai conseguir um preço muito abaixo do que o próprio cliente conseguiria atingir, dada uma condição de competição.

A questão é que nesse cenário todos os fornecedores colocam a margem de risco no projeto. Nenhum deles vai assumir que a margem de risco é zero só para ganhar uma venda. Sabem porque? Porque não basta vender, tem que entregar. E é aí que o negócio complica. Sabendo disso, todo mundo coloca uma "gordurinha" no projeto, mesmo os departamentos internos, que atendem clientes da própria empresa.

Voltando então à especificação. É muito comum também no mercado brasileiro que a compra de software, seja ela interna ou externa, seja feita com base em uma especificação. Só que, se as especificações, da maneira com que em geral são feitas, só permitem a venda no estilo "Time and Material", ou seja, hora aberta. O cliente geralmente pede o que vai querer, e não como vai querer. O "como" é responsabilidade do fornecedor que ganhar a concorrência, ou do departamento interno de TI, caso seja ele o fornecedor. Só que dizer "o que" mas não "como" aumenta ainda mais o risco da estimativa, que já é, por definição, imprecisa, e portanto arriscada, porque o fornecedor pode errar feio na definição de como vai fazer o que o cliente pediu. O resultado é que o custo proposto para a execução do projeto acaba ficando muito acima do que seria se o "como" tivesse sido definido.

Um bom exemplo é especificação baseada em casos e cenários de uso. São documentações de negócio, de alto nível. Dizem "a nota fiscal deve ser emitida clicando em x, y e z." Isso é "o que" deve ser feito (emitir a NF). O "como" vai ser definido pelo fornecedor, que não tem a menor idéia do que é o projeto. Dessa maneira o cliente está pedindo para pagar mais. Ah, e a todos os analistas de sistemas: MER e diagrama de classes têm o mesmo problema.

MER, use cases, diagrama de classes, todos vão gerar especificações incompletas? Vão. Qual o resultado? Estimativas ruins. Nesse cenário, dou um passo além das propostas de Patrick Hynds, e digo que estimativa, por ser imprecisa por natureza, em pouco se beneficia de uma especificação mais completa, mesmo que ela indique o "como". Digo isso porque ninguém sabe exatamente o que precisa quando compra um software, e mesmo que soubesse, isso poderia mudar, como de fato muda. Realizar uma especificação apurada em momento de escolha de fornecedor, ou seja, muito antes da codificação iniciar, é pedir para ter documentação desatualizada, ou seja, o projeto já começa com problema.

Como fazer então? Só há uma resposta: processo iterativo e curto. Nesse cenário as estimativas são trabalhadas com maior aproximação, e, ainda que imprecisas, tendem a ficar mais próximas do que será depois executado. Isso se deve porque a quantidade de informação a ser trabalhada é pequena, e porque o time trabalha com feedback constante entre, e durante, as iterações. Nesse cenário não faz nenhum sentido gerar estimativa para todo o projeto, a não ser que ela seja entendida como o que é: um chute.

Fica a dica então: compre desenvolvimento iterativo, e peça estimativas de períodos curtos. Não se engane.

O segundo dia do Scrum Gathering foi tão bom quanto o primeiro. Começamos com uma apresentação de marketing da ScrumAlliance, seguida depois de várias palestras. Uma palestra inesperada do Juan Bernabo, sobre Management 2.0 foi bem legal (alguns arriscaram a dizer que foi a melhor de todo o evento). O Fabio Camara, MVP de VSTS, falou de VSTS e Scrum, e, pelo que eu ouvi, causou bastante polêmica ao colocar a visão e experiência dele sobre o ScrumMaster. Gostei também da palestra de como apresentar Scrum para o cliente, do Fabiano Milani. Assim que ele colocar o Powerpoint no ar vou baixar, porque esse é um dos assuntos mais complexos no Scrum, na minha opinião.

O evento terminou com um painel onde os congressistas fizeram diversas questões à 4 palestrantes do evento. As perguntas foram muito boas, e eu, claro, não pude deixar de fazer a minha, que foi só parcialmente respondida. Questionei sobre o futudo do Scrum e, já que o Scrum agora pretende resolver os problemas de desenvolvimento de software, se devemos esperar ver agora uma melhoria naquelas estatísticas do Chaos Report do Standish Group. Ninguém se atreveu a dizer que sim.

O evento foi bem legal, atendeu às minhas expectativas, e teria me arrependido de não ter ido. A troca de experiências foi fenomenal, além de ter sido muito legal ter revisto figuras do mercado de agilidade, que eu não via desde que participei do painel de sistemas disbribuídos no lançamento do InfoQ Brasil, como Felipe Rodrigues, o Manoel Pimentel, o Victor Hugo Germano, Alexandre Gomes, etc.

Por falar nisso, o InfoQ Brasil vai fazer uma cobertura sobre o assunto, então fique ligado por lá se você quiser ver umas fotos do evento, além de obter mais informações.

Você também pode conferir o que houve no gathering pelo hashtag #ScrumGathering no Twitter. Bastante gente, eu inclusive, twittou sobre o evento. Em alguns momentos você chega a ver um chat entre o Victor Cavalcante e o André Dias…

Entrei em contato com algum material do Patrick Hynds, MVP de segurança. Eu não o conhecia, mas o pouco que vi me deixou muito claro que ele é uma pessoa muito experiente. Gostei especificamente de 4 regras que ele coloca como as que devem guiar o processo de desenvolvimento de software. Ele as chama de "regra de uma palavra", "regra de duas palavras", "regra de três palavras" e "regra de quatro palavras", e tem esses nomes porque são definidas com estas quantidades de palavras.

Elas são exatamente novidades, mas como são muito curtas e simples acabam tendo um peso juntas. Ao mesmo tempo que parecem óbvias, entendo que também podem ser um pouco polêmicas.

Bom, vamos à elas. Abaixo de cada uma coloquei a minha percepção sobre a idéia.

1. Status
   Verifique o status com frequência. E verifique ele cedo no projeto, porque quanto mais tarde mais caro vai custar corrigir o que não foi medido antes.
   Desenvolvedores novos devem passar status no mínimo uma vez por dia. Reuniões diárias, ao estilo daily meeting do Scrum são recomendadas. Profissionais mais seniors podem passar status com uma frequência um pouco menor, mas todos, sem exceção, devem passar status obrigatoriamente, sob pena de perda de emprego. Somente depois do status obtido e conferido é que algo pode ter o status de "pronto".
2. Nunca adivinhe
   Nunca assuma nada. Status não serve para nada se você só anotou o que outra pessoa te disse. Você tem que conferir que o status é o que é. Se você está colhendo o status e a pessoa que deve lhe passar este status não te comprova o status, você tem o direito de assumir o status que quiser, já que a discussão está no nível do achismo.
3. Não seja ansioso
   Desenvolva um conceito de "pronto" e se atenha a ele. Entenda que, em nenhuma situação, código concluído significa projeto terminado, por mais que você queira que signifique. Entenda também que "pronto" é um conceito binário: ou está pronto, ou não está. Não existe "pronto mas falta <coloque algo aqui – testes, documentação, etc>".
4. Sem especificação, sem estimativa
   Esse é muito legal, e vou tratar dele melhor em outro post. Em poucas palavras: qualquer estimativa deve ser baseada (e solicitada) com base em uma especificação que não deixe margem à dúvidas. Mas é mais que isso. Bem mais.

O primeiro e o segundo fogem bastante do conceito de times autogerenciáveis, já que claramente há alguém gerenciando o time, ou, no mínimo, colhendo status. Meu medo é só com o regime comando-controle, que é muito improdutivo, mas de resto tudo me parece justo, principalmente com times menos seniors, e com acompanhamento à distância, como no caso de terceirização ou times distribuídos.

Aqui você tem um PPT dele explicando como prevenir a falha em projetos. Bem legal, recomendo.

Hoje foi o primeiro dia do Brazil Scrum Gathering, primeiro Scrum Gathering realizado fora da Europa e Estados Unidos, e eu estava lá. O dia foi o máximo, com uma abertura de, pasmem, Ricardo Vargas, chairman mundial do PMI. Seguiu depois com várias palestras de técnicas relacionadas a Scrum, e também casos de sucesso. Houve uma palestra sobre CMMi com Scrum. O ponto alto do evento foi um keynote do Ken Schwaber, feito virtualmente.

Minhas impressões:

O PMI está preocupado com a adoção massiva do Scrum. O Ricardo Vargas deixou claro que Scrum e PMI não são excludentes. Isso na teoria parece ser verdade. Na prática, como 99% dos PMPs praticam as propostas do PMI, são coisas diametralmente opostas. Em determinados monentos o Ricardo Vargas soltou algumas frases interessantes. A primeira foi que você não precisa respeitar o PMBoK, o que caiu como uma bomba para os muitos PMPs da platéia. A segunda foi que ele, Ricardo Vargas, não entende gestão compartilhada porque em projetos 90% das pessoas de qualquer equipe quer mais é ir embora para casa em vez de se envolver de verdade em um projeto. Isso, de cara, impede qualquer convivência entre PMI e Scrum. Mas enfim…

O keynote do Ken Schwaber eu achei fraco. Para o cara que é o presidente da ScrumAlliance, eu esperava mais. Ele praticamente resumiu vários pontos do curso de CSM, inclusive realizando um treinamento lá como todos, na hora. Isso foi ruim porque a maioria do público já entendia Scrum, e muitos eram CSMs, ou seja, não agregou. Depois ele abriu para perguntas, e eu tive a chance de fazer uma das várias perguntas que já tinha elaborado. Aproveitei para fazer uma pergunta que os xiitas de agile (xiitas nunca são bons) defendem com a alma: Projetos em Scrum falham? Reposta: Falham (para tristeza dos xiitas). Você pode perceber que o projeto é inviável financeiramente depois de algumas sprints, por exemplo. Ainda assim, ele disse que projetos de Scrum são feitos para não falhar. Oras, os defensores do waterfall também diriam isso… Mas enfim…

No final houve um coquetel no próprio hotel, e uma boa parte dos palestrantes e alguns participantes resolveram esticar em um happy hour, que acabou agora à pouco. Foi bem legal, porque pudemos trocar muitas experiências tanto no coquetel, quanto no happy hour.

Eu falei para todo mundo: US$ 200 por um evento desse, com os palestrantes que estavam lá, nesse nível, incluido até mesmo almoço, estava de graça. Quem não foi, e gosta do assunto, perdeu uma excelente oportunidade. O próximo gathering vai ser na Alemanha, ou seja, vai ficar bem mais complicado participar.