livro Domain-Driven Design Quickly

Como o livro original, Domain-Driven Design: Tackling Complexity in the Heart of Software, é considerado por muitas pessoas que admiro um must-read, resolvi lê-lo. Não consegui ir até o fim. Tentei por quatro vezes, na última vez fui até a metade, mas achei o livro muito cansativo, prolixo. Pode ser que meu nível de inglês tenha contribuído, apesar de algumas pessoas com inglês mais avançado terem me reclamado da mesma coisa. Decidi não recorrer à versão em português pelo motivo de sempre: em geral, as traduções na nossa área não são boas. Ainda mais em cima de um tema relativamente novo, como DDD.

No último Agile Brazil, em conversa com alguns amigos, relatei minha ‘insatisfação’ com o livro; muitos concordaram. Um deles, o Juan Bernabó, me recomendou um livro sobre o mesma tema, mais resumido, mais objetivo: Domain-Driven Design Quickly. Como podem ver, o livro pode ser baixado gratuitamente.

Li, e recomendo. Com um porém: acredito que certas partes não ficam bem explicadas, precisando recorrer eventualmente ao livro original. Ou seja, minha sugestão para quem quer ter um contato inicial com DDD: leia o DDD Quickly e, quando sentir necessidade, recorra ao livro original.

DDD talvez não traga nenhum conceito muito original, mas sua abordagem representa um novo ponto de vista que traz um frescor a alguns temas. A Ubiquitous Language amplia o conceito de nomes expressivos, reforçando o mapeamento do domínio com o código. As diferenças entre Entity, Value Object e Service são aprofundadas. Os conceitos de Agregate e Repository são explorados de tal forma que nunca vi em outro lugar.

A parte final do livro, que trata de conceitos como Bounded Context, Context Map e Anticorruption Layer, só li no DDD Quickly, sem recorrer ao livro original. É superficial, carece de exemplos, mas talvez o livro original tenha um boa complementação. Não me interessei muito, pelo menos no momento.

DDD é na minha opinião um conceito must-know. É consenso que ter um domain model isolado é uma boa prática de desenho de código. DDD talvez seja a disciplina que melhor reúnes os conceitos necessários para atingir esse objetivo.

Agile Brazil 2011

Quando você escolhe um médico, por exemplo, espera que ele esteja atualizado, que frequente os principais congressos de sua especialidade. Ora, se você quer ser um bom, um excelente desenvolvedor, espera-se o mesmo: que esteja atualizado, que frequente os principais congressos.

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.

a dialética do escopo

Hoje em dia não sei se a proposta da prática do XP de contrato de escopo negociável foi uma boa. Não pela prática em si, que é excelente, mas pela forma como ela é normalmente entendida e os efeitos negativos desse entendimento. Muitos a interpretam como ausência de escopo definido. Em Planning Extreme Programming, Beck e Fowler mostram claramente que o escopo é sim definido. A principal questão da prática é um modelo simples e fácil de alterar o escopo, em contrapartida à tradicional Change Request e toda a parafernália normalmente associada a ela.

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.

XP no “underground” – Scrum no “mainstream”

Rodrigo Yoshima (Yosha) enviou a seguinte mensagem para algumas listas de discussão de agilidade:

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.

auto-organização

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.

planejamento ágil de projeto

Uma das perguntas recorrentes nas listas de discussão é como se planeja um projeto sob a ótica da filosofia ágil. Não há uma diferença gritante do ponto de vista de técnicas em relação ao que tradicionalmente se faz. Mas há uma diferença substancial na forma como se encara esse planejamento e na forma de estimar seu prazo. Além disso, há outra grande diferença na forma em que o planejamento é acompanhado. Mas isso é vinho de outra pipa.

É 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.

governança ágil

Além de outras atividades, dirijo algumas equipes de desenvolvimento. Por conta disso, a governança é um tema que me é caro. Ou seja, como saber se minhas equipes estão melhorando. E já que acreditamos no modelo ágil, como saber se minhas equipes estão se agilizando.

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.