Semler é um empresário brasileiro conhecido por seus métodos pouco – ou nada – ortodoxos de gestão. Ele escreveu best-sellers como Virando a Própria Mesa e Maverick. Já li o primeiro, há muitos anos, mas confesso que não lembro absolutamente nada – apenas que o achei revolucionário. Resolvi ler este de que falo aqui depois que vi o Semler ser bastante citado por algumas pessoas bem conhecidas na comunidade ágil brasileira, especialmente o Daniel Wildt.

Neste livro – assim como nos demais, se não me engano -, Semler apresenta as práticas de gestão adotadas em sua empresa, a Semco. Um resumo: autogerenciamento, democracia organizacional (os funcionários escolhem seus próprios líderes), horário flexível, home office, ausência de organograma formal, ausência de descrição de cargos, ausência de missão, visão e valores, ausência de planos de longo prazo (no máximo, seis meses), funcionários escolhendo em que projetos vão trabalhar, funcionários definindo seus próprios salários.

Abaixo um conjunto de trechos que achei interessante reproduzir:

http://t.co/MOorxHZ
http://t.co/VmNnwGTn
http://t.co/uyKSL3uL
http://t.co/JgJhENNa
http://t.co/kQitoxk0
http://t.co/z79cemba
http://t.co/bAWjF8RM
http://t.co/7iJwxl3i
http://t.co/hwKUMg6j
http://t.co/0purSsTn
http://t.co/ycQRSnw4
http://t.co/pRRevs4b
http://t.co/5MFc6TUp
http://t.co/KktFNcSK
http://t.co/XUpRxCk2
http://t.co/QUW0m197

Este foi o melhor livro que já li até hoje sobre gestão (de pessoas). Mas um alerta: o livro talvez provoque muitas dúvidas e ceticismo naqueles que ainda não tiveram contato com modelos formais de auto-organização no mundo “empresarial”.

Atualmente no Brasil há dois principais congressos de desenvolvimento de software não ligados a tecnologias específicas: Agile Brazil e QCon. Se portanto você quer ser um grande desenvolvedor, deve participar de pelo menos um desses dois congressos, preferencialmente de ambos.

Estou aqui para falar do Agile Brazil, da edição deste ano, 2011. Antes, um esclarecimento: faço parte da organização e vou palestrar no evento.

A Agile Brazil 2011 (AB2011) – Conferência Brasileira sobre Métodos Ágeis de Desenvolvimento de Software – vai acontecer de 27 de junho a 1° de julho, em Fortaleza, Ceará. Além de dezenas de palestras, workshops, tutoriais e lightning talks, vai haver os imperdíveis keynotes de Jim Highsmith, Joshua Kerievsky e Vinícius Teles. Nos dois primeiros dias, 27 e 28 de junho, quatro excelentes cursos: CSM e CSPO, cursos oficiais da Scrum Alliance (SA), TDD: do básico ao avançado, ministrado por figurinhas conhecidas na comunidade nacional de desenvolvimento ágil, e Introdução ao Lean Thinking, pelo Lean Institute Brasil. Todos esses cursos estão com preços superespeciais. Um exemplo: os cursos oficiais de CSM e CSPO da SA custam em média no Brasil de R$1.700,00 a R$2.000,00; na AB2011, R$990,00 (primeiro lote).

Abri o post com uma obviedade e vou repeti-la: ser você quer ser um grande desenvolvedor, participe dos principais congressos. Participe da Agile Brazil 2011.

Definir o escopo é interessante por dois grandes motivos: dá aos envolvidos uma noção de custo e prazo do projeto e o mantém focado naquilo que deve ser entregue. O problema é que muita gente pensa que definir o escopo é o mesmo que fixá-lo. Além de achar que não dá para trabalhar com desenvolvimento ágil definindo escopo. Pelo contrário: é recomendável. O problema mesmo é a forma como o escopo é definido.

Antes de falar sobre isso, uma explicação: uma coisa é o escopo, outra é o detalhamento dos requisitos. De forma simples, escopo é apenas a lista de requisitos, sem seus detalhamentos.

Em métodos tradicionais, define-se o escopo habitualmente através de um documento de requisitos bem detalhados. Ou seja, um documento de requisitos normalmente contém tanto o escopo quanto o detalhamento dos requisitos. Esse tipo de abordagem tem dois grandes problemas:

Primeiro:

Como o documento de requisitos é muito detalhado, sua manutenção se torna bastante trabalhosa.

Quando o escopo muda, o documento deve ser atualizado. Devem ser retirados os requisitos que não são mais necessários e incluídos os novos, com seus detalhamentos. Além disso, uma mudança de escopo pode implicar numa mudança do detalhamento dos requisitos já existentes. Por exemplo: imagine um sistema tradicional de controle de ponto. No decorrer do projeto, o cliente decide incluir no sistema a possibilidade de controlar também escalas de revezamento. Isso vai promover alterações no cadastro de empregados, para indicar se o horário do empregado é tradicional ou é escala e qual sua escala de revezamento. No caso, então, seria necessário atualizar o detalhamento do cadastro de empregados no documento de requisitos. Há ainda as fusões de requisitos. Exemplos: dois relatórios com informações comuns que são condensados num só; duas telas que realizam operações similares que são condensadas numa só. Ou seja, mais atualização do documento.

Quando o detalhamento de um requisito muda, o documento deve ser atualizado. Exemplo simples: incluir mais três colunas num relatório.

Como as mudanças são mais custosas, normalmente o processo de mudança é mais elaborado, com documentos de solitações de mudanças, de avaliação de impacto, de aprovação de mudança, etc.

Segundo:

Promove uma indução ao congelamento dos requisitos com seus detalhamentos. Como o trabalho inicial de elaboração do documento de requisitos e extenuante, o cliente e a equipe acham que tudo sobre o projeto está no documento. O cliente então se afasta do projeto, esperando simplesmente receber o sistema no prazo acordado. A equipe desenvolve o sistema baseado no documento de requisitos. Ou seja, todo o aprendizado que poderia ser gerado com as entregas parciais é minorado.

De toda forma, os documentos tradicionais de requisitos podem trazer alguma vantagem. Tem-se um documento em linguagem humana que descreve o comportamento do sistema. Isso pode ser interessante por exemplo quando um novato chega na equipe. Mas acho que o custo não vale benefício. Até mesmo porque os aspectos mais relevantes para um programador saber normalmente não estão no documento, mas sim no código. Por isso a defesa do código expressivo.

Em XP, por exemplo, no início do projeto define-se o escopo (lista de histórias). Quando o escopo muda, basta retirar da lista os requisitos (histórias) não mais desejados e incluir os novos. No caso de uma fusão de requisitos, simples: inclue-se um novo requisito e excluem-se os dois que se fundiram.

A pergunta que normalmente se faz é: “Como estimar o projeto se as histórias não estão detalhadas?” Durante o planejamento do projeto, quando as histórias estão sendo identificadas, o cliente normalmente dá uma explicação rápida sobre cada uma. Por exemplo: num saite de oferta de empregos, há a seguinte história: “Eu como empregador quero anunciar uma vaga para que os candidatos possam encontrá-la”. Verbalmente então o cliente dá uma breve explicação: “O empregador informa o título da vaga, sua descrição, os prerrequisitos, os conhecimentos necessários e os desejáveis.” Isso é suficiente para estimar a história. Não precisa ser uma estimativa perfeita. Algumas histórias serão superestimadas, outras subestimadas. No somatório total, esses erros, para mais e para menos, acabam se equilibrando, conseguindo então um nível aceitável de precisão na estimativa total do sistema, que é o que se quer no início do projeto. Esse é o ponto: o que se quer no início do projeto é uma estimativa orçamentária do projeto, não uma estimativa precisa de cada história.

Alguns autores defendem que essa breve explicação de cada história deve ser documentada. Eu particularmente não gosto dessa abordagem, e nunca tivemos problemas com isso. Aqui na Fortes já desenvolvemos uns dez projetos utilizando essa forma de planejamento. Tivemos problema de prazo em um ou dois desses projetos, mas a causa não foi a falta da documentação dessa breve explicação. Muito menos a falta de um documento de requisitos.

Tracei um gráfico hoje no Google Insight que mostra bem o cenário Agile no BR:

http://bit.ly/scrum_vs_xp

O gráfico desde 2004 mostra uma queda vertiginosa nas buscas por Extreme Programming e um crescimento por Scrum.

Qual é o comentário de vocês?

Para quem acompanha os pensamentos do Yosha, sabe que por trás dessa mensagem há algo que ele vem falando há algum tempo: o que matou o RUP vai matar a agilidade. É um pândego, mesmo. Quer ver o circo pegar fogo. Concordo plenamente. Obs.: vocês vão entender o que esse parágrafo tem a ver com o assunto quando lerem o último.

Por que Scrum passou de XP?

Por que é natural. Para mim, isso não foi surpresa. Na verdade, até foi, mas depois de refletir um pouco, entendi que essa é a configuração natural. A situação atípica era a que acontecia antes, com XP sendo o mais procurado. A pergunta então seria: “Por que antes XP era mais procurado que Scrum?” Acho que era pela capacidade de mobilização da comunidade (se não me engano o Fowler já falou disso) e pelo suporte teórico promovido por Beck, Fowler, Jeffries, Cunningham, etc., pela quebra de paradigma promovida por XP, pelas práticas polêmicas como programação em par, TDD e código coletivo, pela crítica mordaz a documentação inútil, etc. Uma grande massa de desenvolvedores teve um estalo: “Meus deus! É isso…!” Scrum não conseguiria esse efeito inicial exatamente por tratar apenas de gestão. Faltariam respostas.

Nesse meio tempo, agilidade começou a se tornar sedutora. Os modelos tradicionais não estavam surtindo o efeito desejado, e empresas-modelo como Google, Yahoo!, Toyota, Nokia, 3M, etc. se anunciavam ágeis. Naturalmente os olhares começaram a se virar para a agilidade, que passou a interessar não somente aos “meros” desenvolvedores, mas também aos gerentes e dirigentes das empresas. Só que em geral gerente não entende de engenharia. As práticas técnicas do XP funcionavam como vetor de opacidade para essa turma. Naturalmente procuraram algo mais palatável, e também mais ligados a eles, algo que tratasse apenas de gestão. Bingo: Scrum. Vou contar um caso que aconteceu comigo (e olhe que tenho embasamento técnico). Certa vez, há alguns anos, um colega daqui me falou sobre testes unitários, me explicou superficialmente o conceito, e pediu minha opinião. Eu disse que achava que isso não funcionava, pois teria de se programar dois sistemas, ao invés de apenas um. Olha a bobagem… Não lembro exatamente o que me atraiu para o XP, mas suspeito que tenha sido algum texto do Vinícius.

Além disso, gestão é o ponto de partida canônico para melhoria em organizações de desenvolvimento de software. O primeiro nível do CMMI, por exemplo, é quase todo voltado para gestão. A lógica é mais ou menos a seguinte: “Vamos primeiro organizar um pouco essa bagunça. Depois a gente melhora a engenharia.” E essa abordagem me agrada. Pois bem, se se vai começar por gestão, nada melhor que Scrum. Apesar de XP contê-lo quase todo, mais adequado começar por algo específico.

Falei em “organizar a bagunça”. Mas há empresas que já estão “organizadas”, com processos bem definidos, mas que estão buscando a agilidade. Essas são aquelas que normalmente costumamos chamar de tradicionais (guidas por documentação, papéis, processos e fases rígidas, iterações longas). Intuitivamente entendo que é mais complicado implantar Scrum nessas empresas. Iterações de um mês nesse cenário é muito complicado. Dá tempo rodar todas as fases numa iteração? Nas idas e vindas entre cada fase, dá tempo de atualizar toda a documentação dentro de uma iteração? Aí vêm os diversos sabores de Scrumbut. Desde iterações individuais para especificação, design, programação e testes (ouço o Yosha gritar “RUPbut”) até pipelines para cada uma dessas fases. Curiosamente neste caso, dos pipelines, se potencializado à forma extrema, esse cenário se aproximaria muito do Kanban Development, ainda que sejam necessárias brutais adaptações e que seja fundado em valores diferentes. Um aparte: fazendo uma analogia, são essas brutais adaptações que me fazem crer que o RUP não é verdadeiramente ágil.

Além disso tudo, há todo o aspecto de marketing envolvendo o Scrum. Isso já foi perfeitamente explicado pelo Vinícius e pela Improve It em seu antológico post sobre seus novos rumos. Quem não quiser ler o enorme texto do Vinícius, um brevíssimo resumo: há uma organização por trás do Scrum (Scrum Alliance), seu vocabulário é mais “adequado” (“Scrum”, “Product Owner”, “Scrum Master”, “Product Backlog”, “Daily Scrum”, etc.) que o do XP (“Extreme”?! “Programming”?!) e há as tão “necessárias” certificações.

Mas é preciso entender que quase todas as empresas que realmente implantarem Scrum vão acabar no futuro avançando para XP, ou pelo menos para práticas como design incremental, refatoração, testes automatizados e integração contínua. E espero que isso realmente aconteça, para o bem de nossa indústria, sob o risco de vermos equipes pregando cartões na parede, fazendo rabiscos, negligenciando documentação, brincando de planning poker, e toda a sorte do besteirol ágil, mas continuando entregando porcaria e se dizendo praticantes de Scrum.

Está lá nos princípios do Manifesto Ágil:

The best architectures, requirements, and designs emerge from self-organizing teams.

Muitas implementações de modelos como o CMMI definem um processo-padrão, em que são estabelecidos papéis, atividades, etapas, documentos, etc. Apesar de indicar a necessidade de adaptação do processo-padrão para cada projeto, na prática esses modelos, através desse padrão, exercem uma forte influência no processo que é instanciado. Portanto, podemos dizer que há nesse caso um modelo organizacional que impõe às equipes uma forma de organização.

Os agilistas entendem que isso é ruim, que o melhor é que as equipes se auto-organizem, que definam seus próprios processos, seus próprios papéis, suas próprias atividades, etc. E isso é realmente fácil de aceitar. Desenvolvimento de software é uma atividade intelectual. Como qualquer outra atividade intelectual, não faz muito sentido impor um processo de trabalho. Imagine a imposição de um modelo de trabalho a uma equipe de escritores, de compositores, de arquitetos, de publicitários… Estabeleça metas e deixe que sua equipe se organize da forma que melhor julgar.

Há quem enxergue nisso uma anarquia completa, uma desvalorização peremptória de processos. Isso é um erro crasso. Agilistas valorizam sim processos. Isso fica claro no Manifesto:

We have come to value individuals and interactions over processes and tools. While there is value in the item on the right, we value the item on the left more.

A diferença fundamental é o olhar que se dá a processos. As próprias equipes são responsáveis por seus processos. Não há imposição:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Um outro erro comum é achar que os agilistas são niilistas quanto a processos, ou que se deve partir do nada e deixar que as equipes construam naturalmente seus próprios processos. Esse mito nasceu da proposta dos agilistas de simplificação drástica dos processos tradicionalmente estabelecidos. Mas isso definitivamente não quer dizer que se deve partir do nada. O ideal é partir de um modelo estabelecido, como o Scrum, e ir adaptando ao longo do tempo. Aqui na Fortes por exemplo indicamos o XP. Mas todas as equipes já realizaram suas adaptações. Hoje somente uma delas trabalha com programação em par de forma sistematizada, por exemplo.

E o autogerenciamento?

Curiosamente, pelos menos nas listas nacionais, mais se fala em autogerenciamento que em auto-organização. Esses conceitos, apesar de parecidos e “intersecionados”, são diferentes. Autogerenciamento implica em auto-organização. Mas o contrário não é verdade. Autogerenciamento é a inexistência de um gerente controlando o processo. Auto-organização é a inexistência de uma força externa à equipe impondo um modelo de trabalho. Autogerenciamento requer equipes e membros maduros. Auto-organização, não necessariamente (apesar de aconselhável).

Apesar de serem conceitos diferentes, e apesar do Manifesto não mencionar explicitamente o autogerenciamento, isso não quer dizer que não se deve buscá-lo. Em desenvolvimento de software, como em qualquer outra atividade do conhecimento, o ideal é construir equipes autogerenciadas. Para mim, um dos objetivos do Scrum Master deve ser se fazer desnecessário. Esse estado representaria o autogerenciamento.

Ainda assim, mesmo que toda a comunidade ágil fale em autogerenciamento, mesmo que a utilização de métodos ágeis levem à construção de equipes autogerenciáveis, não me sinto confortável de dizer que é um conceito diretamente suportado pela filosofia ágil.

·

·

atualização [07/08/2009]

Sugiro fortemente a leitura do comentário do Fábio Akita.

É preciso deixar claro que o que vou falar daqui pra frente é um entendimento bastante generalista. Há várias nuances válidas e detalhes não explorados no texto. Mas acho que o post responde à dúvida habitual a respeito de planejamento ágil de projetos. Além do mais, planejamento tem relação com uma série de questões, como gestão da comunicação, de recursos humanos, de aquisições, etc. O texto se limita apenas a estimativas de prazo – e custo, por tabela – e a elaboração de cronograma, que acho que é a dúvida corriqueira.

Como se faz tradicionalmente? De forma geral: levantam-se primeiramente as funcionalidades esperadas. Depois classifica-se cada uma em pequeno, médio ou grande (APCU e APF, habitualmente). Cada classificação dessas representa uma quantidade de pontos. Soma-se então os pontos de cada funcionalidade chegando-se a um subtotal. Ajusta-se esse subtotal de acordo com algumas complexidades do projeto e chega-se ao total de pontos do projeto. Depois calcula-se o tempo total do projeto de acordo com a velocidade histórica da equipe. Ex.: se o sistema tem 180 pontos e se e equipe produz em média 10 pontos por mês, isso quer dizer que o projeto deve durar 18 meses. Se vai durar 18 meses, e se a equipe custa $50.000 por mês, isso quer dizer que o projeto vai custar $900.000.

Em geral, em projetos ágeis a coisa funciona mais ou menos do mesmo jeito, com pequenas diferenças. Não há por exemplo essa classificação em pequeno, médio e grande para cada funcionalidade. Também não há esse ajuste em relação às complexidades do projeto. Elas são consideradas, mas de outra forma.

O planejamento começa apresentando-se as tais complexidades (normalmente requisitos não-funcionais, como nível de usabilidade, portabilidade, tolerância a falhas, escalabilidade, etc.) do projeto, para que a equipe tenha noção do buraco em que está se metendo e para que elas influam nas estimativas. Depois levantam-se as funcionalidades (em geral, histórias) esperadas. Depois, a equipe estima cada funcionalidade em pontos (aqui na Fortes utilizamos horas-ideais). Somam-se então os pontos das funcionalidades achando o total de pontos do projeto. O resto é igual: divide-se o total de pontos pela velocidade achando o tempo total do projeto, derivando igualmente seu custo.

É na elaboração do cronograma que o bicho pega, que denota a enorme diferença entre o que se faz tradicionalmente e o que se faz no mundo ágil.

Um cronograma tradicional estabelece uma série de fases para cada funcionalidade, realizadas por pessoas diferentes, em que cada fase representa a produção de um documento que é transmitido para a fase seguinte. Um exemplo de cronograma tradicional:

De novo: fui simplista. Faltaram por exemplo as correções de cada funcionalidade e os testes de integração e correções de cada release. Mas a ideia é dar uma visão geral.

Esse mesmo projeto sendo ágil:

Release #1 [00/00/0000]
Funcionalidade #1
Funcionalidade #2
Funcionalidade #3
Funcionalidade #4

Release #2 [00/00/0000]
Funcionalidade #5
Funcionalidade #6
Funcionalidade #7
Funcionalidade #8

Nesse caso, cada funcionalidade é desenvolvida idealmente de forma geral por toda a equipe, uma após a outra. Quando se termina uma funcionalidade, termina mesmo, coberta por testes automatizados, unitários, de integração, de aceitação, exploratórios, de estresse. De fato, quanto a esses dois últimos tipos de teste, há equipes ágeis que os realizam por release. Aqui na Fortes, realizamos os testes exploratórios por funcionalidade. Quanto aos de estresse, ainda não os temos.

O planejamento do projeto, apesar de relevante, não é aquilo que evidencia peremptoriamente as diferenças entre os mundos tradicional e ágil, apesar de dar algumas pistas, como podemos observar nas questões das fases e na existência do papel separado de projetista. E olhe que, no caso do exemplo tradicional, expus um exemplo de projeto de certa forma iterativo-incremental. Imagine se apresentasse um cascata. Agora perceba que, no exemplo tradicional, as funcionalidades são desenvolvidas paralelamente. Imagine uma mudança de requisitos nesse cenário. Como reconstruir o cronograma? Como atualizar todos os documentos? Aqui na Fortes, já fomos por um breve período “tradicionais”. O que acontecia quando de uma mudança de requisitos? Abondonávamos o planejamento e íamos no peito e na raça.

Um dos mitos a respeito de desenvolvimento ágil é ausência de planejamento. Uma pena. E de certa forma, curioso. XP foi a metodologia que “popularizou” o desenvolvimento ágil, e há um livro, escrito por Kent Beck e Martin Fowler, só sobre planejamento em XP.

O Be on the Net se propõe a resolver esse problema, provendo alguns modelos sofisticados e algumas funcionalidades que normalmente são úteis nesse contexto. Além disso, a turma do Be on the Net faz um trabalho de bastidores para que seu saite fique bem classificado quando alguém pesquisar no Google. Alguns exemplos de ramos que podem se beneficar do produto: fotografia, cerimonial, viagem, confeitaria.

O primeiro saite criado com o produto foi o da fotógrafa Patrícia Figueira. Vale a pena conferir.

Para saber mais sobre o Be on the Net, visite seu saite em beonthe.net.

P.S.: “[OT] (off-topic)” não é uma etiqueta mágica que me permite falar aqui sobre qualquer assunto. Ainda que com esse recurso possa fugir do assunto principal deste blogue, ele não me dá o direito de falar sobre qualquer coisa. Há de haver alguma relação. Divulguei o Be on the Net pelo fato de ter sido um pedido do meu eterno mestre Vinícius e por ser um produto de software desenvolvido com eXtreme Programming (XP) pela ImproveIt, empresa que outrora foi a maior divulgadora e especialista em XP e metodologias ágeis no nosso país. Portanto, não me peçam para divulgar qualquer produto aqui. Se você é meu amigo, abriu um barzinho maneiro em Fortaleza, e me pedir para divulgá-lo aqui, terá o pedido indeferido.

Uma crítica habitual – e pertinente, de certa forma – que se faz a XP e Scrum é a falta de um sistema de governança. Ou seja, como definir um mecanismo que direcione as equipes a trabalhar com desenvolvimento ágil. Falo apenas de XP e Scrum pois não sei se as demais metodologias ágeis têm mecanismos de governança.

A ideia desse post é mostrar um exemplo de sistema de governança ágil. Esse exemplo se foca apenas nos aspectos práticos, sem entrar diretamente nas searas filosófica, psicológica e sociológica do manifesto e do movimento.

Já utilizamos a maior parte das ideias que vou expor aqui na Fortes. Algumas estão bem no início.

política de cargos, salários e benefícios

Estabeleça uma política agressiva (acima da média do mercado) de cargos, salários e benefícios. Nessa política, lembre-se de considerar características não-técnicas, como habilidade de trabalhar em equipe. Sei que esse é um tema difícil, que muitas vezes requer um trabalho de longo prazo, mas ter as melhores pessoas invariavelmente esbarra em ter melhores salários.

seleção de profissionais

Estabeleça um bom processo de recrutamento e seleção de profissionais. Realize diversas entrevistas, observe os aspectos pessoais, técnicos e interpessoais,  aplique testes e dinâmicas. Selecione os melhores profissionais. Uma dica: se você ainda não tem uma política agressiva de salários, lembre-se dos profissionais inexperientes e estagiários, observando as características pessoais (vontade de aprender, autodidatismo, iniciativa, boas notas nas disciplinas que interessam, etc.) e interpessoais (negociação, comunicação, solidariedade, etc.).

• value individuals
• value interactions

treinamentos

Estabeleça uma política de treinamentos. Isso pode ser feito de várias formas: estimulando grupos de estudo e coding-dojos, treinamentos formais, leitura de livros, etc. Aqui na Fortes temos um evento anual de integração. Esse evento serve também para rememorarmos o que fizemos durante o ano. Um dos tópicos deve ser “treinamentos realizados”. Se não se quiser fazer esse evento, pode-se elaborar um relatório simples contendo o mesmo tópico. Ou até uma prosaica atividade anual na sua agenda: “Que treinamentos fizemos?” Obs.: na política de treinamentos, lembre-se de incluir disciplinas de habilidades interpessoais.

• value individuals
• value interactions

diminuição da documentação

 Estabeleça as seguintes atividades mensais:

• Verificar se há documentação legada que pode ser descartada;
• Verificar se há documentação que pode ser descartada do processo;
• Verificar se há documentação que pode ser simplificada (desformalizada) no processo.

Documentação em excesso desestimula os relacionamentos e supervaloriza os processos.

• value interactions
• over processes
• Simplicity–the art of maximizing the amount of work not done–is essential.

contratos

Estabeleça contratos em que o cliente se obriga a participar pelo menos das reuniões de planejamento e de entrega. Insira ainda as condições de mudança de requisitos. Mantenha esse modelo bem simples, como normalmente as metologias ágeis pregam, de simples reordenação de histórias. Estabeleça ainda a seguinte atividade mensal: perguntar ao cliente em que você deve melhorar.

• value customer collaboration
• value responding to change
• Welcome changing requirements, even late in  development. Agile processes harness change for the customer’s competitive advantage.

montando equipes

Monte equipes multifuncionais. No template do plano de projeto, na seção de equipe, coloque o seguinte comentário: “[montar equipe multifuncional, incluindo analistas de negócio]”. Lembre-se ainda de colocar todos os membros juntos, na mesma sala. Essa proximidade favorece a comunicação.

• value interactions
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

relatório mensal

Peça que cada equipe elabore um relatório mensal com as seguintes informações:

quantidade de versões disponibilizadas

Quantidade de versões disponibilizadas para o cliente. Pode-se ainda diferenciar os releases de experimentação dos releases de produção.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

satisfação dos colaboradores

Colete a nota de satisfação de cada colaborador de forma anônima e tira uma média. Se houver uma queda nesse valor, investigue para descobrir o problema e encaminhar uma solução.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

satisfação do cliente

Da mesma forma que com os colaboradores, monitore a satisfação do cliente.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

progresso do projeto

Meça o progresso do projeto. Uma tabela simples com as colunas história, tamanho e o indicador de conclusão é o suficiente. Veja o exemplo abaixo:

história    tam  concl
----------  ---  -----
história 1   15   sim
história 2    8   sim
história 3   10   não
...
história N   12   são

percentual de conclusão do projeto: 23%

• Working software is the primary measure of progress.

relação entre o tempo gasto com desenvolvimento, correções e outras atividades

Idealmente as equipes devem trabalhar apenas desenvolvendo novas funcionalidades. Mas há necessidade de trabalharem também em correções de defeitos e em outras atividades como suporte. Portanto, monitore o tempo gasto pelas equipes nessas atividades extras. Veja o exemplo abaixo:

desenvolvimento ..... 65%
correções ........... 15%
outras atividades ... 20%

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

qualidade do código

Informações como:

• Cobertura do código por testes unitários;
• Código duplicado;
• Classes longas;
• Métodos longos e complexos.

Nesse caso, não tem jeito: vai ter de recorrer a ferramentas mais sofisticadas. Dê uma olhada nesses links aqui:

http://www.alissonvale.com/englishblog/post/Utilizando-metricas-de-codigo-para-melhoria-no-design-de-software.aspx

http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html

Essas ferramentas devem idealmente ser disparadas pelo servidor de build, gerando relatórios de métricas automaticamente.

• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.

ações de melhoria

Lista de ações de melhoria. É uma forma de saber se a equipe está melhorando continuamente. Se achar esse modelo excessivamente burocrático, você pode simplesmente pedir para informarem a quantidade de retrospectivas realizadas.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

metas

Estabeleça metas claras – e deixe que as equipes escolham seus processos e ferramentas. Você pode estabelecer essas metas para os indicadores numéricos presentes no relatório mensal que citei acima. Dependendo da senioridade da equipe, essa liberdade pode não ser tão benéfica. Nesse caso, estabeleça um padrão de referência (isso é um pleonasmo?) de processos e ferramentas e administre a rigidez com que induz a equipe a utilizá-lo. A falta de metas claras amplifica a necessidade por maior comando-e-controle, supervalorizando ainda os processos.

Além dessas metas numéricas, peça também para cada equipe um relatório por iteração, indentificando as histórias planejadas e as concluídas, monitorando assim o nível de eficiência do planejamento. Essa é uma forma indireta de estabelecer metas.

• The best architectures, requirements, and designs emerge from self-organizing teams.

As ideias acima já garantem um bom nível de governança. Mais algumas ações podem reforçar o trabalho:

reporte para a diretoria

Aqui na Fortes, condensamos todos os dados numéricos presentes no relatório mensal, de todas as equipes, e calculamos indicadores gerais do setor de desenvolvimento. Reportamos esses valores para os demais diretores da empresa.

monitoramento das práticas

No relatório mensal, pode-se estabelecer um checklist para monitorar o andamento das práticas. Ex.:

[  ] ambiente informativo
[  ] build de dez minutos
[  ] TDD
[  ] integração contínua
[  ] programação em par / inspeção / revisão
[  ] código coletivo
[  ] reuniões diárias

Na integração contínua, pode-se ainda solicitar a quantidade de integrações realizadas.

equipe de QA

Estabelecer uma equipe de QA para fazer incursões nas equipes para saber se as informações reportadas condizem com a realidade.

Observem o seguinte gráfico:

Ele mostra a relação entre o esforço gasto com desenvolvimento em si (novas funcionalidades), com testes e com correções de bugs. É claro que a separação entre funcionalidades e testes é muito difícil, quiçá impossível, de ser estabelecida. Mas façamos um pequeno esforço mental para entender essa separação.

Os pontos A e C são extrapolações, não existem no mundo real. No A, não há qualquer teste. Seria o caso do desenvolver simplesmente escrever o código, compilar, não realizar o obscuro “teste do desenvolvedor” e entregar para o cliente. No C, todo o esforço é gasto com testes (“Testar o quê, se nenhuma funcionalidade foi produzida?”). Existe o lance das provas formais, que não conheço direito, mas até onde sei é algo impraticável em 999.999.999 de cada bilhão de softwares.

Por observação, boa parte das equipes se encontra entre A e B. Uma pena, já que isso se mostra uma tremenda estupidez. Na verdade, estupidez não é nem estar entre A e B; é não querer sair de lá. Por quê? Simples: o ponto B é o de maior produtividade. Ou seja: teste um pouco mais e será mais produtivo. Não é nem uma questão de fazer tão bem feito, com poucos bugs. É uma questão simples de produtividade. O curioso é que qualquer equipe deveria no mínimo se posicionar em B. E por que muitas não se posicionam? Assunto para outro post. Lembrei de uma frase que a mamãe costumava repetir: “O preguiçoso trabalha mais que o trabalhador.”

Sendo assim, os menos atentos diriam: “O ideal então é se posicionar em B, que é o ponto de maior produtividade.” Não é bem assim. Pergunto: seria certo se posicionar em B uma equipe que está produzindo um software embarcado que guia um míssil ao seu alvo? Claro que não! É preciso observar o nível de bugs no ponto B. Um erro nesse software poderia ser catastrófico. Ou seja, esse software deve ser virtualmente perfeito, sem bugs. Essa equipe deve se posicionar o mais próximo possível de C.

“Resolvido, então. Devemos sempre nos posicionar o mais próximo possível de C, correto?” Também não. Depende da natureza do software. A tolerância a erros de um software de um míssil é totalmente diferente da tolerância de um software gratuito para comunidades virtuais, por exemplo. Um erro neste nunca seria catastrófico. “Mas mesmo não sendo catastrófico, não seria melhor não ter erro nesse software?” Seria. Mas devemos observar outro fator: produtividade (funcionalidades). A partir de B, à medida que nos aproximamos de C a produtividade cai, já que o investimento em testes aumenta. Na prática, a grande maioria dos softwares não comporta um posicionamento próximo de C devido à baixa produtividade.

Um aparte: a curva dos defeitos em relação aos testes é logarítmica. Isso é apenas minha opinião, apesar de achar fortemente que estou certo – minha experiência e intuição me gritam. Se souberem de alguma pesquisa ou estudo científico que mostre essa relação, ficaria muito grato se me indicassem.

“Onde se posicionar, então?” Infelizmente ainda não descobrimos resposta objetiva para isso. O que vale aqui é a experiência e o bom senso da equipe, além do próprio processo empírico. Algumas heurísticas também podem ajudar.

Uma última análise: de modo bem simplista, podemos dizer que o basicão do TDD (100% de cobertura) está no ponto G, em que o esforço de testes é igual ao esforço de funcionalidades. Nessa minha simulação, de B para G, há uma queda de 22% na produtividade e de 63% nos defeitos. Coisas como essa explicam por que os agilistas (especialmente os XPeiros) somos tão vidrados em testes.

P.S.: para efeito deste post, em “testes” incluem-se coisas como programação em par e inspeção.

P.P.S.: “defeitos” referem-se ao esforço que a equipe fez para corrigir erros depois de realizados os testes, depois do deploy. Ex.: num período de um ano de um projeto, a equipe gastou 10% do esforço para corrigir bugs encontrados em produção.

Certa vez, na escola técnica (atual CEFET) ou na universidade, não lembro direito, cheguei a praticar atletismo. Chegamos ao salto em altura. Alguns (os “seminovatos”) já haviam praticado uma ou duas vezes. Os demais eram absolutamente “novatos”, virgens no esporte, marinheiros de primeira viagem. Qual o objetivo da disputa? Passar o sarrafo o mais alto possível sem derrubá-lo. Todos os novatos queríamos passar o sarrafo com as costas viradas para o chão, como fazem os profissionais, da forma que sempre vimos na tevê. Já os seminovatos utilizavam uma técnica “especial”: passavam o sarrafo de frente, com o ventre voltado para o chão. Resultado: os seminovatos venceram-nos de lavada. Fiquei impressionado. Como eles ganharam de todos nós se utilizavam uma técnica menos eficaz? A melhor técnica para mim era a de costas, claro, já que era a que todos os profissionais usavam.

Noutra vez, brincando de jogar basquete na quadra do colégio, combinamos (todos do mesmo nível, seminovatos) uma disputa: quem acertaria mais lances livres. Qual o objetivo da disputa, então? Acertar no cesto o maior número possível de bolas. Alguns fizemos os primeiros arremessos como fazem os profissionais, impulsionando a bola apenas com uma mão, utilizando a outra como apoio. Outros, “não sei por quê”, utilizavam as duas mãos para impulsionar a bola. Foram motivo de chacota, no começo da disputa. Como podiam arremessar de forma tão desengonçada? Nunca haviam visto uma partida de basquete? Só que, à medida que a disputa se desenrolava, a chacota se transformou em perplexidade, pois os desengonçados nos venciam.

O que aprendi com essas historinhas? Que algumas técnicas são mais eficientes, mas só depois de muito treino. Para um novato, as técnicas “naturais” são melhores. Mas há técnicas que, depois de treino, são mais eficientes que as naturais.

Minha sensação é que o mesmo acontece com TDD.

Qual o objetivo de um programador? Entregar código com um bom desaine e coberto por testes unitários. A forma natural é escrever todo o código e depois ir refatorando e cobrindo por testes unitários. Se se pedir a um programador acostumado a fazer dessa forma para escrever código utilizando TDD, ele vai ser bem menos produtivo. Isso pode até ser verdade, mas só no princípio. Um programador fluente em TDD é mais rápido que um programador tradicional.

Infelizmente a analogia com as minhas peripécias esportivas não é perfeita – como qualquer analogia. No esporte, é fácil provar que técnica é mais eficiente: no boliche, quantidade de pinos derrubados; no salto, altura atingida; no basquete, quantidade de lances convertidos. Em software dificilmente – de fato, acho que nunca – conseguiremos provar que TDD é mais eficiente, já que não temos como medir produtividade. Ficaremos pela percepção de cada um.

Pois bem… Certo dessa minha intuição, de que TDD é melhor, pedi para que meus programadores passassem a escrever código utilizando TDD. O resultado inicial foi tão desastroso que abandonaram a ideia à minha revelia.

Quando soube desse abondono, me falaram: “Tales, é um desastre. Ficamos bem mais lentos.” Perguntei: “Mas vocês acreditam que TDD é melhor?” Alguns acreditavam, outros não; mas todos não-convictos. Propus: “Vamos experimentar por algum tempo. Se não gostarmos, desistimos.” Retrucaram: “Mas, Tales, vamos ficar muito improdutivos.” Sugeri: “Façamos assim: comecem programando normalmente, como sempre fizeram, mas se obriguem a fazer TDD uma hora por dia. Depois de duas semanas, aumentem para duas horas. Depois de mais duas, para três horas. E assim sucessivamente, até vocês  se certificarem se TDD é melhor ou não.” Ou seja, a ideia era não ter uma queda brusca de velocidade no princípio.

Essa sugestão que dei para a equipe é recente e ainda não sabemos se a proposta deu certo. De qualquer forma, fica a ideia para os leitores, que era o que queria com esse post, lançar a ideia.

P.S.: cheguei a contar essas historinhas esportivas para uma nossas equipes. Um dos membros dessa equipe – Sávio, meu irmão – fez outra analogia. Ele contou que no princípio digitava apenas com os dois indicadores. Era até rápido. Mas ele intuía – uma obviedade, de fato – que digitaria mais rápido ainda se utilizasse todos os dedos. Só que sabia também que não seria tão produtivo no início. O que ele fez? Começou se forçando a digitar com todos os dedos meia hora por dia. A cada semana, aumentava meia hora, até chegar ao ponto de perceber que digitava mais rápido com todos os dedos que com os indicadores.