Avaliação dirigida a negócio dos modelos de computação distribuída

Ferramentas para obter agilidade

Relatório técnico
Kent Beck, Three Rivers Institute
Junho, 2008

www.microsoft.com/teamsystem
msdn.microsoft.com/process
msdn.microsoft.com/practices

Este relatório técnico tem cunho informativo, apenas. A MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍTICAS OU ESTATUTÁRIAS QUANTO ÀS INFORMAÇÕES DESTE DOCUMENTO.

A conformidade com todas as leis de direitos autorais (copyright) aplicáveis é de responsabilidade do usuário. Sem limitação dos direitos de acordo com as leis de copyright, nenhuma parte deste documento poderá ser reproduzida, armazenada, introduzida em sistema de recuperação de dados ou transmitida de qualquer forma ou por quaisquer meios (eletrônicos, mecânicos, fotocopiadores, gravadores ou de qualquer outra forma) para quaisquer finalidades, sem a permissão expressa da Microsoft Corporation, por escrito.

A Microsoft pode ter patentes, pedidos de patentes, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que protegem o assunto deste documento. Salvo conforme expressamente disposto em qualquer acordo de licença da Microsoft, por escrito, o fornecimento deste documento não concede ao usuário nenhuma licença a essas patentes, marcas comerciais, direitos autorais ou outra propriedade intelectual.

© 2008 Microsoft Corporation. Todos os direitos reservados.

Microsoft e Visual Studio são marcas comerciais do grupo de empresas da Microsoft.

Todas as outras marcas comerciais são de propriedade de seus respectivos titulares.

Sumário

 Introdução
 A forma abreviada
 Fluxo
 Transparência
 Mapa de prática da ferramenta
 Previsões
 Sobre o autor

Introdução

A Microsoft me convidou para compartilhar as minhas idéias sobre o relacionamento entre ferramentas e desenvolvimento ágil de software. O desenvolvimento ágil procura aumentar o valor da criação de software, aumentando o feedback disponível para clientes e programadores. O feedback nos chega dos mais freqüentes lançamentos em produção, testes, construções de software e de estruturas sociais que incentivam a conversação e o diálogo. Entretanto, reduzir a duração do ciclo implica aumento no número de transições entre atividades, e isso altera as exigências relativas às ferramentas de desenvolvimento eficientes.

The Agile Manifesto [Beck et al 2001] diz, “Valorizamos processos e ferramentas mas, ainda mais, pessoas e interações". Como acontece com muitas tentativas que incentivam a mudança, isto está declarado com tanta veemência que leva a conclusões equivocadas. Alguns entenderam que o desenvolvimento ágil de software não exige ferramentas, ou que a comunidade assim envolvida só tem neo-luditas que atiram CDs de ferramentas nas fogueiras e desenham o planejamento do projeto nas paredes das cavernas com as pontas queimadas de gravetos. Gosto de oportunidades que me permitam contestar essa impressão, justificar o uso adequado de ferramentas (e processos) no desenvolvimento ágil e antecipar a evolução das ferramentas de desenvolvimento de software.

A forma abreviada

Valorizar indivíduos e interações em detrimento de processos e ferramentas é justo e sensato. Os processos e as ferramentas destilam a experiência comum. Junto advém uma experiência incomum e os processos e as ferramentas não conseguem se adaptar. Só os humanos conseguem. É nesse ponto que entram os indivíduos e as interações: descobrir como não estancar diante de situações extraordinárias.

Adotar cegamente processos e ferramentas diante da inovação é tão ineficiente quanto persistir na variedade, no debate, na negociação e na criatividade perante circunstâncias rotineiras e repetitivas.

O desenvolvimento ágil reside sobre princípios que contradizem aqueles encontrados em alguns desenvolvimentos de software. Fluxo, responsabilidade universal pela qualidade, prestação de contas e transparência são alguns dos princípios do desenvolvimento ágil e podem levar a alterações substanciais no estilo do desenvolvimento. Outro princípio primordial do desenvolvimento ágil é reconhecer que o software é criado por pessoas. Uma metáfora (aparentemente inconsciente) de um processo de software é como um programa, com programadores agindo como computadores. Se pudéssemos escrever o processo perfeito e suportá-lo com ferramentas assegurando que o processo acompanhasse o pensamento, não importaria o talento, a experiência, a disciplina ou a criatividade dos integrantes da sua equipe, o sucesso estaria garantido. Este viés, a metáfora "processo como programa/humano como computador", deixa transparecer a ênfase da repetitividade no modelo capacidade-maturidade. Reagindo a isso, a comunidade que surge ligada ao desenvolvimento ágil de software enfatiza a inovação de muitos desenvolvimentos de software.

Ao escrever ou executar código pela primeira vez, nenhuma repetição é possível e, assim, não há aproveitamento de ferramentas ou processos. Ainda assim, mesmo em situações desconhecidas, existe alguma rotina. O código é testado, escrito, integrado e implantado. Mesmo sem ter nunca escrito um assistente digital médico, eu ainda lembro como programar. Eu devo padronizar e automatizar as tarefas que permanecem rotineiras. Se a implantação for diferente do que pode ser suportado pela minha ferramenta de implantação automática, precisarei implantar manualmente até reconhecer a próxima rotina. Não posso distorcer a arquitetura para que corresponda às ferramentas.

As ferramentas evoluíram para suportar de modo eficiente as várias atividades do desenvolvimento de software. O desenvolvimento ágil, o crescimento de um movimento quase universal para ciclos de liberação cada vez mais curtos, modifica a base da concorrência das ferramentas de software. Em lugar de eficiência da atividade única, as ferramentas precisam suportar transições freqüentes entre as atividades.

O princípio do fluxo determina que, se tudo for igual, mais vale entregar lotes menores de funcionalidade com mais freqüência do que lotes maiores com menos freqüência. Uma parte desse efeito oferece a habilidade de reagir mais rapidamente à mudança. Se o caminho de uma nova idéia para um recurso implantado é um mês e não um ano, a equipe pode entregar respostas mais rápidas para necessidades novas ou modificadas. Outro aspecto são as maiores oportunidades de aprendizado que resultam de implantação antecipada e mais freqüente. Por fim, a implantação freqüente incentiva (um termo muito mais agradável do que "força") a equipe a aprender como fazer tudo bem. Uma fase de testes manuais de seis semanas é insensato em um prazo de entrega de um mês.

O fluxo é valioso em todo o desenvolvimento de software. Uma maneira de analisar o desenvolvimento ágil de software é que ele impulsiona o princípio do fluxo muito mais rápido. Passar de lançamentos anuais para trimestrais pode ser um esforço, mas a tendência continua e os trimestrais transforman-se em mensais, semanais e até mesmo (por fim) diários. Todos os tipos de software são entregues com mais freqüência hoje do que eram há dez anos e a tendência continuará indefinidamente.

Uma conseqüência do fluxo aumentado, observada por minha parceira Cynthia Andres, e que afeta profundamente as ferramentas do desenvolvimento ágil é que, quanto maior o fluxo, maior o número de transições entre as atividades. A porcentagem total de tempo gasto para analisar ou projetar tende a ser parecida (e essa seria uma confirmação interessante), mas em lugar de uma transição entre as decisões de análise e de projeto, o desenvolvimento orientado a fluxo pode ter dezenas, centenas ou milhares. A prioridade das ferramentas passa de suportar a eficiência de determinada atividade para troca eficiente entre as atividades.

O quadro simplificado acima não representa inteiramente este problema das transições. Em lugar de uma cachoeira em miniatura, o desenvolvimento ágil mistura análise e testes, projeto e testes, codificação e execução de teste e estabelece um loop rápido de retorno entre informações obtidas durante a implementação e análise, projeto e decisões de implementação subseqüentes.

As ferramentas precisam considerar as transições. A interface de usuário que aceita horas de codificação a cada vez, seguida por um enorme processo de construção, tende a ser complicada se aplicada a um estilo de desenvolvimento que exija vários ciclos de construção/teste por minuto. Da mesma forma, a ferramenta de planejamento que aceita uma grande modificação nos detalhes do plano a cada poucos meses, provavelmente não será compatível com planejamento semanal. Não que essas ferramentas não pudessem suportar mais transições, mas se elas não forem bastante utilizadas, é improvável que os seus custos indiretos sejam amortizados. 

As equipes que pretendem aplicar o princípio do fluxo precisam de ferramentas que suportem transições rápidas entre as atividades. Por exemplo, usar post-its na parede para o planejamento tem muitas desvantagens: eles não podem ser distribuídos facilmente em várias locais, não são permanentes e as informações espaciais perdem-se com facilidade.

Entretanto, a única coisa que pode ser bem feita com post-its na parede são as transições. Um par pode estar no meio da codificação (/análise/projeto/testes), descobre uma nova exigência fora do escopo do ciclo atual, rabisca no post-it, e volta para a codificação sem interromper o fluxo do desenvolvimento. Tempo perdido? Dez segundos. Até mesmo a troca mais rápida para outro aplicativo, provavelmente, seria longa o suficiente para quebrar a concentração deles.

Algumas vezes as equipes podem usar partes de ferramentas de modo efetivo, se prestarem atenção ao custo das transições. Por exemplo, se tarefas forem acrescentadas diariamente a um plano, cuidar para dispor todas as tarefas bem arrumadinhas à mão, não tem sentido. Criar tensão entre estética e precisão significa comprar confusão. Ninguém deseja ver um gerente de projeto deixar cair tarefas no chão para não criar linhas cruzadas. É melhor conformar-se com um formato menos atraente, mas que aceite as mudanças mais facilmente.

Resumindo: quanto maior o fluxo, maior a necessidade de suportar transições entre as atividades. A eficiência-padrão perde para tarefas paralelas rápidas, que não atrapalham.  Se for preciso optar, a equipe estará em situação melhor se tiver uma ferramenta menos eficiente, mas com mais capacidade de transição.

Como construtor de ferramentas não gosto de forçar uma troca. Eu gostaria de fazer e usar ferramentas funcionalmente superiores (pelo menos no subconjunto de recursos 80/20) e preparadas para o trabalho em lotes pequenos. Além disso, gostaria de ferramentas que cuidassem dos novos desafios apresentados pelo desenvolvimento ágil.

Transparência

A seção anterior é, basicamente, retrospectiva. Fala sobre dar suporte às atividades existentes em desenvolvimento de software, incentivando as transições fluidas entre essas atividades. Mas, existe mais em ferramentas para desenvolvimento ágil do que isso.

Aprendi que todas as mudanças quantitativas de uma ordem de grandeza criam uma mudança qualitativa. Assim, a mudança de 10 km por hora (a cavalo) para 100 km por hora (em automóvel), não apenas resultou em transporte mais rápido, mas (com o tempo) alterou as atitudes das pessoas em relação ao transporte e ao papel da mobilidade nas suas vidas.

Ao passar de implantações anuais para mensais e, depois, diárias, encontramos duas ordens de grandeza de mudança quantitativa. O desenvolvimento ágil de software, assim, será qualitativamente diferente. Uma mudança sobre a qual escrevi no trabalho "Test-Driven Development: By Example" (Desenvolvimento dirigido a teste: por exemplo) é que os programadores precisam aceitar responsabilidade primária pela qualidade do seu trabalho. Para que isso seja feito de modo eficiente é preciso ter suporte de ferramenta e, também, uma mudança de atitude. A transparência individual proporcionada por testes escritos por desenvolvedor é um pré-requisito para maior transparência da equipe.

A transparência da equipe torna-se essencial com o desenvolvimento ágil de software. Quando os detalhes dos planos mudam diariamente, todos precisam ter um modo de descobrir o que todos os outros fazem.

Quando comecei na programação, o relatório semanal de status era suficiente. Aqui está o que fiz esta semana, aqui está o que penso fazer na próxima. Agora, pressione duas vezes a tecla de avanço rápido, e o relatório semanal de status torna-se tão estranho quanto um debate sobre os méritos relativos da linguagem de montagem e da linguagem de nível mais elevado. Na coordenação dos planos de mudança de um grande grupo, distribuído, trabalhando em um sistema de evolução e implantação constantes, você precisa de atualizações mais freqüentes. Em algum momento, (e aqui entra a mudança qualitativa) todos teriam que, teoricamente, gastar todo o tempo informando o andamento realizado, caso não estivessem gastando todo o tempo informando sobre o andamento realizado.

Uma saída para o dilema do relatório é parar de dizer às pessoas o que você está fazendo, explicitamente. Em lugar disso, confie nas suas ferramentas para inferir as suas intenções de suas atividades e informe isso para você.

Isso parece meio Big Brother, mas eu vejo uma diferença importante. Em lugar do poder controlador central de Orwell, a transparência é uma escolha que você faz para oferecer credibilidade aos seus colegas de equipe. Uma equipe transparente pode coordenar as suas atividades de modo mais efetivo e barato para realizar as metas compartilhadas. Agir de modo transparente envia um sinal que diz aos outros que você é confiável. A confiança, quando percebida, reduz o atrito do desenvolvimento na medida em que as pessoas se concentram mais no que realizam juntas e menos em escapar da culpa. Assim como o desenvolvimento dirigido a teste (TDD, Test-driven development) me permite confiar no meu código e fazer mais com ele, a confiança em uma equipe permite aos seus membros experimentar mais e ser mais inventivos.

Há muitos anos, venho experimentando várias formas de transparência. O primeiro nível de transparência foi ser transparente comigo mesmo. Monitorei o meu uso do JUnit e descobri que durante o desenvolvimento dirigido a teste eu executei testes a cada minuto ou dois, na maior parte do tempo. Estendi essa idéia para um repositório aberto da atividade de desenvolvimento de software, o DevCreek. Ser transparente consigo mesmo traz benefícios inesperados. Ao usar os próprios dados de desenvolvimento, por exemplo, descobrimos que para dar suporte à reunião semanal de status, estávamos praticamente interrompendo o desenvolvimento por um dia inteiro.

A transparência pode ser uma grande guinada pessoal para desenvolvedores. O nosso desenvolvimento em JUnit é projetado de modo transparente no DevCreek. Estranhamente, eu resisti em deixar o JUnit transparente. Depois de refletir melhor, vi que tinha medo de as pessoas não lhe darem o devido valor porque o desenvolvimento tinha sido muito rápido. Todavia, até hoje, não perdemos nenhuma venda em decorrência disso. Eu só precisava me acostumar à idéia de dizer às outras pessoas exatamente o que eu estava fazendo.

A tendência em relação à maior transparência para público cada vez maior continuará. Talvez seja difícil desfazer-se de hábitos e crenças, mas num mundo em que as informações fluem livres e amplas, manter segredos é uma posição de fraqueza. Nunca se sabe quando seremos descobertos. A transparência é a nova força.

Mapa de prática da ferramenta

O desenvolvimento ágil depende de ferramentas, especialmente quando aquelas ferramentas estão ajustadas para um ritmo de desenvolvimento diferente. Aqui está um mapa de relacionamentos entre algumas práticas comuns para o desenvolvimento ágil e algumas das ferramentas que suportam essas práticas:

Cada linha deste diagrama conta uma história. Por exemplo, o projeto incremental exige uma ferramenta de construção contínua para revelar rapidamente incompatibilidades introduzidas por modificações do projeto. Seriam necessárias mais palavras para contar todas essas histórias do que estas que compartilho com vocês neste artigo, mas o que é importante notar é que cada ferramenta suporta várias práticas, cada prática exige várias ferramentas e as práticas e ferramentas se suportam mutuamente. A força desta complexidade traduz-se em aproveitamento: uma ferramenta ou modo melhor de trabalho pode ter impacto predominante.

Fica ridículo falar de desenvolvimento ágil de software sem ferramentas. Tanta coisa acontece em um projeto ágil a cada dia, tantas etapas antes manuais, agora repetidas rapidamente, que ter as ferramentas adequadas é essencial.

Desde que as ferramentas não sejam o que se considera de última geração, para um projeto de ciclo mais lento. Os post-it pendurados na parede podem ser uma super ferramenta de planejamento e transparência, quando as alternativas informatizadas não são projetadas para transmitir mudanças freqüentes de movo efetivo. Os post-it na parede têm graves limitações, mas são melhores do que uma ferramenta que dificulta as mudanças. Os construtores têm o desafio de produzir ferramentas superiores de acordo com as novas dimensões: tempo de transição, adaptação de acordo com as mudanças, transparência. O desafio dos construtores de ferramentas é fazer uso efetivo de subconjuntos adequados de suas ferramentas atuais, contentar-se com substitutos de baixa tecnologia quando necessário e comunicar as suas necessidades aos fornecedores, claramente.

Isso nos leva à atividade de ferramenteiro, comum em equipes ágeis. Como quase sempre as demandas exigidas das ferramentas são diferentes daquelas para as quais elas foram projetadas, as equipes quase sempre passam mais tempo adaptando ou inventando ferramentas. Pode ser melhor investir em uma ferramenta rudimentar compatível com o trabalho do que adaptar uma ferramenta refinada para um estilo diferente de trabalho. Com o tempo, espero que haja mudança nesta tendência, na medida em que houver mais ferramentas destinadas a suportar mudanças e transições freqüentes.

Previsões

O desenvolvimento ágil já influencia as ferramentas dos programadores. Na última década, testes de unidade, projeto incremental e construção contínua ficaram popular na área de ferramentas. Entretanto, isso é apenas o início das mudanças. Aqui estão mais quatro mudanças que, acredito, acontecerão:

Transições estáveis entre atividades

Escopo ampliado para os testes automatizados

Transparência

Colaboração em tempo real

A tendência que continuará a influenciar as ferramentas de software são os ciclos de lançamento cada vez mais apertados. Nos casos em que os lançamentos que antes levavam anos, uma quantidade crescente de produtos de software fará o lançamento em produção de novas funcionalidades a cada mês, semana, dia ou até com mais freqüência.  As ferramentas que implicitamente assumem fases seqüenciais darão lugar a ferramentas que suportam atividades paralelas (alternando-se de modo realmente rápido). A tendência para suportar transições mais freqüentes entre as atividades continuará. Mais atividades serão suportadas sem grandes mudanças de contexto.

Testes manuais pós-desenvolvimento só podem ser compactados um tanto, antes de perder a sua eficiência. Com mais freqüências, os testes manuais duplicam o esforço e os riscos desviam o enfoque e a atenção aplicados aos testes.

Uma alternativa baseada em ferramenta é dispersar o esforço de verificação do sistema com testes automatizados, por todo o desenvolvimento. Na medida em que as equipes obtém experiência com as novas ferramentas e estilo de trabalho, diminui o valor adicional dos testes manuais pós-desenvolvimento. Em algum momento, os resultados de software que podem ser lançados de cada ciclo de testes automatizados:

Atualmente, apenas um subconjunto de projetos possui as ferramentas a experiência, os frameworks, as técnicas de projeto e as estruturas sociais para suportar tal transformação. No decorrer do tempo, sistemas maiores e mais complexos precisarão passar para testes automatizados e, assim, fazer lançamentos mais freqüentes.

As ferramentas precisam suportar, ao mesmo tempo: mudança rápida, transições freqüentes entre atividades e, ainda, ajudar a equipe a manter-se concentrada em metas de grande escala e longo prazo. É na manutenção da perspectiva global que o tipo de transparência discutido anteriormente adquire valor. Quando os ciclos ficam suficientemente curtos, você não tem tempo de esperar receber informações importantes. As informações precisam ser irradiadas imediata e automaticamente para toda a equipe.

Em dez anos, a transparência será a regra no desenvolvimento de software. Agrupar análises detalhadas de atividades e resultados permitirá a desenvolvedores, gerentes e clientes monitorar a integridade dos projetos e de organizações inteiras. Não espero que a transição ocorra sem sobressaltos. Numa oportunidade, perguntei numa sala cheia de programadores de uma empresa de grande porte: "O que aconteceria se as suas avaliações de software aparecessem no relatório anual?" “Os defeitos informados cairiam para zero”, foi a resposta. É compreensível que as pessoas sintam-se amedrontadas sobre escolher publicar ativamente informações sobre programação, pela primeira vez, mas grande parte das informações tão ciosamente guardada já é, de certa forma, de conhecimento público. Os clientes já sabem quantos defeitos você produz: são eles que os relatam.

Por fim, dou aqui uma previsão com base na minha experiência. Gastei de 5 a 10 horas a cada quinzena programando remotamente, usando compartilhamento  de tela e uma conexão de vídeo. De qualquer forma, o hoster do ambiente de desenvolvimento, seja quem for, tem uma grande vantagem. O retardo que acontece quando sou o usuário remoto é suficientemente lento para afetar o meu estilo de programação. Eu prevejo que a colaboração em tempo real, refinada, será comum nas ferramentas da próxima década. As minhas investigações ao longo destas linhas me convenceram que a programação em par exige edição local de programas com alguma forma de reconciliar as colisões, quando elas ocorrem. Entretanto, depois que essa alteração for adotada, desconfio que acionará outras mudanças na medida em que aprendermos como dar suporte a grandes equipes distribuídas, trabalhando de modo transparente, para produzir com freqüência a funcionalidade valiosa para o negócio.

Sobre o autor

Kent Beck é o fundador e diretor do Three Rivers Institute (TRI). Durante a sua vida profissional combinou prática em desenvolvimento de software com reflexão, inovação e comunicação. A sua biografia pode ser encontrada neste endereço http://www.threeriversinstitute.org/Kent%20Beck.htm