Recentemente, organizou um workshop para experiência de três formas diferentes de transferência de conhecimento em um ambiente de produção. O produto, nesse caso, era um avião de papel de desenho incomum projetado por um “designer-chefe”. A idéia era tentar formas diferentes de transferir o conhecimento de como construir o avião e comparar a produtividade relativa dos diferentes métodos, que foram:

• Documentação – Os trabalhadores receberam instruções escritas para a construção do avião.
• Engenharia Reversa – Os trabalhadores receberam um avião concluído que eles poderiam estudar a fim de reproduzir os passos necessários para construí-lo.
• Mentoring – O “designer-chefe” construiu um passo a passo do avião e os trabalhadores replicaram cada passo conforme ele foi realizado.

Os resultados foram interessantes.

Utilizando a Documentação, apenas uma pessoa de um total de 8 chegou perto de construir o avião em 5 minutos. Usando a engenharia reversa, 2 pessoas em 8 produziram um avião em cinco minutos. Usando o Mentoring, todos da equipe produziram um avião e em menos de cinco minutos disponíveis.

O gargalo da transferência de conhecimentos em software

Durante o desenvolvimento de software, a transferência de conhecimento acontece o tempo todo, e é fácil imaginar um desenvolvedor no papel do “designer-chefe” descrito no exercício anterior.

Vamos dizer que eu sou um desenvolvedor, e que descobri e escrevi um super código que contem uma nova técnica para ligar dados com os controles de uma interface visual, e que essa técnica forma um padrão que os meus colegas desenvolvedores querem saber. Se você fosse um dos meus colegas desenvolvedores, você preferiria que eu (a) lhe desse um documento que escrevi sobre a técnica, (b) lhe dissesse onde está o código e sugerisse que você descobrisse por si mesmo, ou (c), pareasse com você e implementasse o padrão para um novo conjunto de dados?

Agora, certamente, o pareamento com você toma mais do meu tempo, e pode parecer menos eficiente do meu ponto de vista. Afinal, eu poderia estar projetando e implementando o próximo padrão. Mas a produtividade da equipe como um todo, ao invés de minha produtividade pessoal, é que é importante. E mentoring ajuda a aumentar a produtividade da equipe, evitando os gargalos de transferência de conhecimento.

O resultado quase sempre é suficiente para levar o fulano “perdido” do ponto A ao ponto B, mas, na maioria das vezes, o destino acaba amontoado em um cantinho da página, como se estivesse em segundo plano e não fosse a informação mais importante do mapa.

Certamente faz sentido desenhar um mapa dessa forma. Imagino que a principal razão para fazê-lo desta maneira é que, ao desenhar um mapa, imaginamos realmente fazer a viagem que estamos descrevendo. Começamos no início de nossa viagem imaginária e, eventualmente, encontramos nosso caminho para o destino. E, a menos que se comece com um papel enorme ou que seja particularmente bom em prever alocação de espaço, o mapa acaba contendo informações extras que não são necessárias, enquanto os detalhes do destino são omitidos porque acabamos com o espaço antes da hora.

Então, quando desenhar mapas, comece a desenhar do fim. O primeiro lugar a colocar em um mapa é o destino. De lá, trabalhe para trás, puxando as ruas que conduzem ao destino. Então, se sobrar espaço, desenhe os caminhos de volta ao ponto de origem. O resultado é um mapa que destaca os detalhes importantes.

Escrevendo Software

Grande número de programadores costuma escrever código de cima para baixo. Ou seja, começam no início do método e escrevem o código na ordem em que será executado. Faz sentido, já que fomos ensinados a ler e escrever de cima para baixo. Parece o caminho natural. Infelizmente, esta abordagem tende a introduzir código desnecessário para o método que terá de ser retirado mais tarde.

Então, quando escrever software, começe pelo fim (acho que vi essa frase aí para cima). Ao escrever um teste unitário, comece pela declaração assert, mesmo que ela seja exercitada sobre objetos que ainda não existem. Comece com o assert, veja o que a afirmação exige e escreva uma linha de código acima para satisfazer essas exigências. Se ao satisfazer essas exigências novos requisitos forem introduzidos, escreva uma nova linha de código acima disso, e assim por diante.

O resultado é um teste unitário que não tem qualquer bagagem extra, nenhuma informação supérflua, com ênfase na parte mais importante, o assert .

A afirmação em um teste de unidade é análoga ao destino em um mapa. Ambos são as peças mais importantes. Ambos são excelentes pontos de partida.

ScrumMaster não significa “aquele que dominou Scrum”

O significado do título ScrumMaster pode ser interpretado de várias maneiras, devido à ambigüidade do idioma inglês. A palavra mestre, de acordo com dictionary.com, tem vários significados, incluindo:

• uma pessoa eminentemente qualificada em alguma coisa, como uma profissão, arte ou ciência (por exemplo, os grandes mestres do período impressionista);.
• uma pessoa cujos ensinamentos os outros aceitam ou seguem (por exemplo, um mestre Zen).

Agora, não parece razoável acreditar que assistir a um curso de dois dias de repente pode promover alguém para as fileiras do “eminentemente qualificado”. Adquirir qualquer coisa que possa ser classificada como uma habilidade quase certamente leva muito mais tempo que dois dias. Podemos concluir, então, que o título ScrumMaster não pretende classificar uma pessoa como eminentemente qualificada em Scrum .

É um pouco mais fácil acreditar que um curso de dois dias pode colocar um indivíduo na posição de ser capaz de prestar aconselhamento e orientação sobre um tema, e acho que deve ser uma prática muito comum para que professores de uma nova disciplina possam executar suas funções, em frente a uma sala de aula.

Podemos, portanto, aceitar que o ScrumMaster significa uma pessoa cuja orientação sobre Scrum outros estão dispostos a aceitar ou seguir.

O que há em um nome?

Ken Schwaber, em seu livro Gerenciamento Ágil de Projetos com Scrum , diz que escolheu “um nome estranho como” ScrumMaster “porque ele” queria destacar que as responsabilidades do ScrumMaster são diferentes daquelas do gerente de projeto tradicional”. Ele prossegue dizendo: “O ScrumMaster não ganha prêmios e medalhas, porque o ScrumMaster é apenas um facilitador”.

Perante isso, parece inteiramente adequado atribuir o título de ScrumMaster a uma pessoa que tenha frequentado um curso curto sobre Scrum. O título não transmite maestria. Na sua forma mais simples, é apenas um indicador de como empregar a pessoa que o ostenta.

“Se eu fizesse parte dos Recursos Humanos de uma empresa, somente contrataria pessoas que tivessem brilho nos olhos, uma “cara de orgasmo”, ou seja, que fosse cheia de vitalidade, de energia, que não visse a hora de “arregaçar” as mangas e começar a fazer aquilo que ela tem de melhor, porque tem consciência do que pode agregar e o que pode fazer de diferente em seu ambiente profissional. Além desse brilho único no olhar e da consciência da relevância que ela tem no que faz, eu destaco ainda outras habilidades:”

Flexibilidade. É a atitude para lidar com os imprevistos e contornar os momentos de crise. Para isso, tem que se “treinar” a improvisação. Mas como? Há alguns pontos que ajudam esse treinamento: reduzir o tempo que se emprega planejando uma tarefa; sempre que puder, troque um trabalho que exige minuciosidade e morosidade por ações; trabalhe com equipes que contenham uma diversidade de pessoas, que vai te ajudar a aceitar que não existem verdades absolutas; crie o costume de pedir a opinião para toda sua equipe e observe os vários pontos-de-vista para resolver um determinado problema; marque num papel os motivos que o levaram a determinar certa decisão e se você os mantém ou não quando a situação muda de rumo.

Autoconfiança e Autoconhecimento. Essas habilidades são importantes para você assumir riscos e ter segurança, são ótimas para o espírito empresarial, visando ser um líder e empreendedor. Para isso, saia da sua zona de conforto e comece a ter uma visão mais ampla de até onde você pode chegar; marque num papel seus objetivos, circule os que já alcançou e sempre determine novos; fuja das pessoas muito protetoras e de superiores que não delegam tarefas, limitando sua capacidade; para melhorar seu autoconhecimento, tente enxergar como as pessoas ao seu redor o vêem ou procure um especialista no assunto, como um terapeuta, para melhorar suas capacidades pessoais.

Iniciativa. Serve para tornar as ideias boas em prática. É agir com velocidade e inovação. Para potencializar essa habilidade: ofereça ajuda para resolver situações difíceis e imprevisíveis; se tem tendência a evitar os riscos, passe a considerar os erros cometidos no passado como novas oportunidades para aprender; desenvolva atividades que estão coligadas à iniciativa como delegar tarefas, análise de custo-benefício; clarifique suas prioridades para colocá-las em prática.

Competitividade. Ter metas claras, não deter-se em chegar ao objetivo comum. Preocupar-se em realizar um excelente trabalho, ir além dos objetivos determinados por seus superiores, ter tendência a inovar e desfrutar coisas que antes não conseguia. Todos esses fatores referem-se a uma competitividade sadia, um passo para o sucesso. Esta habilidade está intimamente ligada às suas emoções e motivações pessoais. Questionar sobre seus objetivos e metas, sobre aquilo que realmente gosta de fazer e evitar rotinas de trabalho, sempre inovando, é um modo de potencializar essa habilidade.

Visão no cliente. Descobrir os desejos ocultos do outro, investir tempo sobre as necessidades das outras pessoas e clientes, enfim, detectar aquilo que satisfaz o cliente. Para potencializar essa habilidade: controle suas emoções e tenha flexibilidade para relacionar-se com os diversos tipos de pessoas; quando tem que lidar com clientes que não são muito claros naquilo que desejam, aprenda a questioná-los, para detectar sua real necessidade e desejos; tente manter-se sempre disponível para o cliente; seja simpático; desenvolva um histórico de pedidos de todos os seus clientes, para que quando eles entrarem em contato, você possa otimizar a comunicação.

Compreensão interpessoal e empatia. Ter sensibilidade para lidar com todos, satisfazer aos demais, tornar-se o líder do grupo graças à sua empatia. Esta é a habilidade-chave, principalmente para aqueles que lidam diretamente com o atendimento ao cliente e profissionais na área de prestação de serviços, pois cabe a esses profissionais identificar com empatia aquilo que seus clientes realmente necessitam. Na verdade, a empatia se desenvolve com a prática, primeiro conscientemente (tomando notas do que o outro diz, escutando dúvidas e necessidades), e depois convertendo isso num hábito diário.

Capacidade de liderança. É a capacidade natural dos outros seguirem a você. Se você tem facilidade em motivar seus colegas de trabalho e eles sempre pedem a sua opinião para tomar decisões importantes, você já tem essa capacidade dentro de si. Fazer com que os superiores também te sigam é uma boa proposta. Para pontecializar ainda mais essa capacidade, dedique uma parte do seu tempo para escutar os demais da equipe, conhecer os problemas pelos quais estão passando e deixar claro que eles podem confiar em você para alcançarem suas metas; tente ganhar o respeito dos demais por meio de suas atitudes, trabalhando com coerência e dando sempre o bom exemplo.

Persuasão. Influenciar e persuadir os demais para alcançar os objetivos propostos é uma habilidade muito poderosa. Alguns têm um inexplicável magnetismo com os outros membros da equipe para que eles dêem o melhor de si. Mas, para conseguir ganhar mais capacidade de persuasão, há algumas dicas: melhore sua capacidade de comunicação e a maneira de por no papel o planejamento das metas; seja coerente em tudo o que diz ou faz, pois é a segurança de sua credibilidade e, assim, poderá fazer com que os outros te sigam. Apenas não confunda essa poderosa habilidade de persuadir com a de manipular as pessoas, pois nesse caso essa capacidade deixa de trazer benefícios profissionais para você.

Trabalho em Equipe. Se sentir bem em estar colaborando com todas as pessoas, em que elas também lhe digam o que deve fazer; escutar e respeitar as opiniões alheias diversas das suas; preferir trabalhar em conjunto para alcançar um objetivo comum a trabalhar sozinho para almejar por metas individuais. Essas são atitudes daqueles que possuem essa brilhante capacidade de trabalhar em equipe. Aprender a aceitar críticas; aprender a delegar tarefas; pedir opiniões para os demais e eliminar as barreiras formais em situações rotineiras são formas de você potencializar mais essa habilidade.

Visão do Negócio. Para aqueles que se preocupam em estar sempre atualizados; têm a própria opinião sobre em qual lugar está sua organização e para onde ela irá caminhar e é capaz de prever as consequências das suas decisões antes que elas virem um problema. Essas são as características de quem já possui essa habilidade, de aguçar seu faro para um todo. Para potencializar ou começar a treiná-la: desenvolva seu lado e sua curiosidade intelectual, acostumando-se a ler livros, revistas e jornais periódicos; dedique uma parte do seu tempo para planejar, analisar e estabelecer prioridades na sua área de atuação; para prever possíveis consequências no futuro, passe a analisar a realidade do mercado em longo prazo, contrastando dados do passado com dados do presente.

Leila Navarro é coach, escritora e palestrante há mais de 10 anos, tendo consolidado, neste tempo, um forte nome no Brasil e no exterior. Ao abordar temas Comportamentais, de Liderança, Gestão de Pessoas, Vendas e Empreendedorismo, já teve suas palestras assistidas por mais de um milhão de pessoas e hoje integra o ranking dos 20 maiores palestrantes do Brasil, segundo a Revista Veja. Além disso, já ganhou por duas vezes o Prêmio dos 100 Melhores Fornecedores de RH – Categoria Palestrante do Ano (2005 e 2009). Para saber mais sobre Leila Navarro, acesse: www.leilanavarro.com.br

No TDD existem 3 aspectos que nos ajudam a atingir este cenário.

Primeiro, iniciar com um teste nos força a descrever o que queremos fazer antes de considerar como faremos. Isso nos ajuda a manter o nível correto de abstração para o objeto a ser criado. Se a intenção do teste unitário (o que queremos testar) não está clara, nós provavelmente confundimos alguns conceitos e não estamos prontos para iniciar a codificação do objeto. Iniciar com um teste também nos ajuda a descobrir que características precisam ser visíveis fora do objeto.

Segundo, para manter os testes unitários fáceis de entender, temos que limitar a sua abrangência mantendo-o tão curto quanto possível. Testes com dúzias de linhas acabam enterrando em seu interior o próprio objetivo do teste. Tais testes nos dizem que o objeto que estamos testando é muito grande e complexo e precisa ser dividido em partes menores e mais simples. A composição resultante da divisão deve revelar uma clara separação de interesses conforme trazemos à tona sua estrutura interna, e podemos então escrever testes mais simples para os objetos extraídos.

Terceiro, para construir um objeto durante o teste unitário, temos que resolver todas as suas dependências, o que significa que temos que saber quais são elas. Isto encoraja a independência de contexto, uma vez que temos de ser capazes de configurar o ambiente do objeto testado antes de poder testá-lo – o teste unitário na verdade é somente um outro contexto. Podemos notar que um objeto com dependências implícitas ou com muitas dependências dará uma bela dor de cabeça na preparação para o teste.

Com o TDD, podemos então utilizar uma abordagem incremental de testes que levará nosso código na direção correta, a diração dos princípios da arquitetura de software.

Esses três grupos constituem uma espécie de ecossistema. Mudanças em um grupo afetam a distribuição das pessoas nos outros. Não é possível alterar a distribuição de forma significativa, pois o aumento de participação em um dos grupos estimula o crescimento nos outros 2, mantendo a distribuição próxima a 90:9:1. A participação social tende a seguir a regra 90:9:1 quando:

• 90% dos usuários constituem a audiência, ou ‘lurkers’. São as pessoas que tendem a ler ou observar, mas não contribuem ativamente na comunidade.
• 9% dos usuários são editores, ou ‘editors’. Essas pessoas  contribuem algumas vezes, modificando ou adicionando texto a um artigo já criado. Raramente criam algo novo.
• 1% dos usuários são criadores, ou ‘creators’. Eles conduzem grande parte das atividades da rede social, ditando o conteúdo e tendências dos textos e artigos do site.

Observar este princípio e suas conseqüências é fundamental para qualquer organização que pretenda estabelecer um ambiente de colaboração e comunicação 2.0. Blogs, fóruns, wikis e redes sociais tendem a seguir a regra 90:9:1, e podem levar a uma grande agilidade na gestão e compartilhamento do conhecimento da empresa, atualmente uma questão estratégica.

• Como era o método XYZ da classe FooBar na versão 2.0.3.12 do projeto?
• Quais foram as alterações feitas para incluir suporte à NF-e?
• Quando esta linha de código foi adicionada ao método XYZ?
• Consigo compilar e executar o sistema na versão 2.0.2.15 para reproduzir e consertar o bug de um cliente?

Se o seu controle de versão não consegue responder a estas perguntas, então está na hora de rever as práticas do seu time. Uma ferramenta de controle de versão não deve servir somente como um backup do código fonte, onde, ao final do dia, o desenvolvedor deposita seu trabalho inacabado. Ela deve ser um santuário, o repositório sagrado que exige do desenvolvedor todo respeito e cuidado. Afinal, o artefato mais valioso de um projeto, o código fonte, está guardado ali. Portanto, não basta instalar um controle de versão e sair usando. O time deve rever seus conceitos e absorver as mudanças necessárias, que podem ser dolorosas. No entanto, após um tempo, o time começa a colher os frutos do terreno bem preparado.

Há pouco tempo li um artigo muito bom do Eduardo Miranda sobre gerência de versionamento, onde ele cita algumas práticas boas e ruins. Vamos a elas:

Boas práticas

1. O código-fonte no servidor deve estar sempre pronto para compilação. Ou seja, a qualquer momento do dia deve ser possível buscar a cópia da última versão disponível do servidor e compilar uma nova versão da aplicação.
2. Toda changelist (conjunto de alterações que foram submetidas juntas) submetida visa melhorar o produto, nunca piorar. O código fonte é sagrado e deve ser total e completamente respeitado. Uma changelist corrige um defeito, adiciona uma funcionalidade, refatora um trecho de código. O desenvolvedor não pode submeter changelists que quebrem o build, seja pela adição de erros de compilação ou pela quebra dos testes automatizados. O time com o qual trabalho tem uma prática problemática que é fazer chekins parciais de código para compartilhar com outro desenvolvedor as alterações feitas. Não tem problema, desde que feito em um ramo de versão temporário especialmente criado para isso (também conhecido como branch). Assim, o ramo principal (o chamado trunk) não fica ‘contaminado’ com códigos incompletos. Somente quando toda codificação estiver terminada e os testes unitários completos, podemos fazer um merge do ramo temporário com o ramo principal. Claro que o trabalho é maior devido ao merge, mas a maioria das atuais ferramentas de CVS oferecem um bom suporte para isso.
3. Submeta suas alterações o mais rápido possível e com freqüência. Quanto mais tempo um arquivo fica em alteração mais difícil se torna seu merge e mais aumenta o risco de quebra do build. Divida suas alterações em pequenos pacotes compiláveis e testáveis e submeta sempre.
4. Oh-oh! Atenção, build quebrado! Se o build está quebrado não submeta alterações nem sincronize sua cópia de trabalho. Um build break é um estado que deve ser tratado com a máxima prioridade. Neste estado não é possível garantir que a sua alteração compila e não quebra testes, portanto não é possível garantir sua qualidade. Por outro lado, sincronizar sua cópia de trabalho irá corrompê-la, o que te impedirá de compilar e testar as funções localmente.
5. Controle tudo que é necessário para compilar e instalar a aplicação. Código-fonte não é a única matéria prima para compilação e instalação dos aplicativos. Sua aplicação pode depender de bibliotecas de terceiros. Neste caso, é necessário armazenar no repositório uma cópia do binário na versão utilizada pela aplicação. Em caso de atualização, a nova versão deve ser submetida junto com toda a alteração no código-fonte da sua aplicação necessária para suportar a versão.
6. Estabeleça critérios de qualidade. Código sem erros de compilação é o mínimo aceitável. A partir do momento que o objetivo passa a ser melhorar a aplicação, novos parâmetros de qualidade devem ser adotados para aprovação de um check in: código sem warnings e hints, testes unitários executados, métricas de complexidade mantidas, etc.

Práticas ruins

Qualquer prática que não vá de encontro ao objetivo de ter no repositório uma versão compilável, testada e sempre melhor da aplicação, é uma prática ruim e deve ser evitada. Mas algumas são típicas e merecem destaque:

• Não submeta alterações em cima da hora. Sexta-feira, 18h, você louco para ir embora e não estará no sábado de amanhã de prontidão para resolver algum problema.
• Não segure as alterações em sua cópia de trabalho por muito tempo. Código-fonte fora de repositório estraga como comida fora da geladeira. Tentar submeter uma alteração feita há 2 meses no repositório gera um trabalho enorme e um elevado risco de quebra de build.
• Nunca ignore a política de check in. Mesmo alterações simples podem quebrar um build.

Finalizando

O controle de versão é provavelmente a ferramenta mais útil e fundamental no desenvolvimento de software e uma das mais utilizadas no dia-a-dia do desenvolvedor. É necessário sempre se preocupar com a facilidade de uso, para que ela não atrapalhe a produtividade nem caia em desuso, sem, contudo, abrir mão dos seus objetivos primordiais.

1. Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software funcional.

2. Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente.

3. Entregue software funcionando com uma freqüência de duas semanas a dois meses, escolhendo sempre o menor escala de tempo possível.

4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos no projeto diariamente.

5. Construa os projetos com pessoas motivadas. Forneça o ambiente, os equipamentos e as ferramentas de que elas precisam e confie que elas farão o trabalho.

6. Uma conversa cara a cara é a melhor forma de transmitir e receber informação do time de desenvolvimento.

7. Software funcionando é a principal medida de progresso.

8. Processos ágeis promovem um desenvolvimento sustentado. Gerência, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

9. A atenção contínua à excelência técnica e a um bom design aumentam a agilidade.

10. Simplicidade – a arte de maximizar a quantidade de trabalho desnecessária – é essencial.

11. As melhores arquiteturas, designs e requisitos surgem de times auto-gerenciados.

12. A intervalos regulares, o time reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo com as reflexões.

Pare por um momento e reflita sobre os princípios acima. Serão tão radicais e impossíveis como algumas pessoas acham ou simplesmente seguem o bom senso? Será tão difícil fazer os projetos funcionarem desta forma? Você realmente acredita que seu cliente prefere uma ótima e farta documentação a um sistema funcionando em um curto prazo? Ou que um e-mail substitua um bom bate-papo? E que tal fazer somente o necessário, sem ficar ‘viajando na maionese’?

Estes princípios formam um senso comum e prático, sobre o qual podemos alicerçar nossos esforços para a construção de um software de sucesso.

(Referência: Agile Modelling – Scott Ambler)

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners. O André fez uma tradução livre para o português. O post original pode ser visto em One Day in Kanban Land.

No entanto, a dificuldade em planejar não é desculpa para não fazê-lo. O planejamento reduz o risco, diminui a incerteza, ajuda na tomada de decisões, estabelece uma maior confiança e dissemina informações. Infelizmente, o planejamento tradicional não vem funcionando. Ao tentar combinar e responder às necessidades do trio escopo\cronograma\recursos, o planejamento tradicional não nos leva a respostas e produtos satisfatórios.

E por que o planejamento tradicional não funciona? Mike Cohn, em seu livro Agile Estimating and Planning, elenca 5 causas para as falhas de planejamento.

1. O planejamento é baseado nas tarefas necessárias e não nos recursos desejados. É vital o time manter o foco nos requisitos solicitados; são eles que agregam valor para o cliente (veja “Você entrega algo de valor para seu cliente?”). Tarefas por si só não agregam valor algum. Além disso, os planejamentos tradicionais, por basearem-se em tarefas, preocupam-se com a dependência entre elas. Assim, atrasos em qualquer tarefa acumulam-se no final do cronograma, pois são repassados pela cadeia de dependência.

2. Executar tarefas simultaneamente agora acaba gerando atrasos no futuro. Com a melhor das intenções, o time pode ver a multitarefa como uma possível solução para atrasos. No entanto, ao trabalhar em duas tarefas ao mesmo tempo, um membro do time provavelmente prorrogará o término das duas. Como outras tarefas dependem das primeiras (lembra do item anterior?), é quase certo que um atraso será embutido na cadeia de dependência, refletindo-se no prazo de entrega final.

3. Não se atende aos requisitos pela prioridade dos mesmos. O pensamento tradicional diz que, se todo trabalho é completado, não importa a ordem em que é feito. Nesse caso, é natural que a seqüência e priorização das tarefas siga a conveniência do time de desenvolvimento e não a importância dos requisitos para o cliente. Como conseqüência, é muito provável que no final do projeto, para manter o cronograma, o time acabe descartando requisitos importantes que não foram corretamente priorizados.

4. O planejamento antecipado sempre contém um certo grau de incerteza que é ignorado. O planejamento tradicional não considera as incertezas presentes em todo projeto de software. Ele assume que a análise inicial será completa e perfeita e que coletará todos os requisitos do produto. Assume também que os usuários não mudarão de idéia, que nenhuma necessidade nova aparecerá durante a execução do projeto e que sabemos exatamente como os requisitos serão  implementados. É claro que isso não é verdade; tudo o que não sabemos no início do projeto é uma incerteza que deve ser considerada no planejamento, e a melhor forma de lidar com as incertezas é através de iterações curtas com feedbacks rápidos e constantes.

5. Estimativas com alto nível de incertezas e baixa probabilidade de acerto acabam se tornando compromissos. Dentro de cada estimativa está embutida uma probabilidade do trabalho ser finalizado no tempo previsto. Uma probabilidade varia de 0 a 100%. Portanto, ao estimar a duração de uma tarefa estamos dizendo que existe uma probabilidade de x % de terminarmos a tarefa em y dias. O problema é que compromissos não podem ser assumidos sobre probabilidades; eles são assumidos sobre uma data.

O planejamento ágil ataca esses problemas focando nos requisitos. A unidade mínima de entrega é um requisito completo; não importa quantas tarefas foram terminadas, se um requisito não está completamente implementado, ele não está entregue. A priorização baseia-se nos requisitos de maior valor para o cliente e não nas tarefas do time de desenvolvimento. O time todo trabalha para entregar um requisito, por isso praticamente não existe multitarefa. O planejamento é incremental; assume-se que no início do projeto sabemos muito pouco sobre o que será feito e sobre como será feito. O time encontrará essas respostas gradativamente, conforme implementa requisito por requisito.

Parece utópico, mas funciona. Qualquer um que desenvolveu software sabe que nunca conseguimos levantar todos os requisitos necessários para um sistema, por maior que seja o esforço. Conheço uma pessoa que trabalha para uma grande empresa indiana que possui a famosa certificação CMM5. Há 2 anos ela realiza levantamento de requisitos para o sistema de um grande banco brasileiro. Dois longos anos de trabalho da equipe; nenhuma linha de código foi escrita, nenhum requisito foi entregue; somente algumas centenas de artefatos obrigatoriamente gerados pela especificação do CMM5. Claro, CMM5 garante qualidade, mesmo que a um custo altíssimo, certo? Mas qual a probabilidade dos requisitos levantados há dois anos ainda serem válidos? Será que ainda representam o que o cliente quer atualmente? Acho pouco provável.

E você, qual sua opinião?