O pessoal da 37signals prefere manter a qualidade sempre fixa (num patamar alto) e substituiu a qualidade pelo escopo no triângulo dos projetos. Eles também recomendam que devemos sempre fixar prazo e custo de um projeto e sempre flexibilizar o escopo.

Vou explicar como isso faz sentido usando como exemplo um projeto recente que tivemos aqui na Locaweb, o projeto de reescrever o site.

site da Locaweb antes do projeto de reescrever o site

Em novembro de 2008 decidimos que já havia passado da hora de termos um novo site que estivesse mais em linha com tudo o que temos estudado sobre experiência do usuário, design centrado no usuário, arquitetura da informação, design de interação e conceitos de web 2.0 com maior participação do visitante do site. Decidimos também o prazo, na primeira quinzena de março de 2009 esse site deveria estar no ar. E o custo também estava fechado: não íamos contratar ou pegar empresatado de outra equipe ninguém a mais para tocar esse projeto.

Tomada a decisão, começamos a desenhar o escopo do projeto. Dentre os vários requisitos do projeto tivemos:

• navegação simples e intuitiva
• manter o código bem enxuto
• aplicar SEO em todo o site
• minimizar o uso de flash
• design visual leve, para dar importância à informação contida nas páginas
• rever a arquitetura de informação de todo o site, revendo todo o conteúdo

Fizemos o planejamento para 6 sprints de duas semanas cada. Numa determinada altura percebemos que não ia dar para fazer tudo para lançar na primeira quinzena de março. Ficamos então pensando se íamos aumentar o prazo ou se podíamos cortar algo do escopo desse projeto.

A entrega de uma projeto é muito importante, tanto para a equipe que trabalhou no projeto, que fica com a sensação de “dever cumprido”, quanto para o cliente do projeto, que irá usufruir dos benefícios de ter o projeto pronto. Com isso em mente, decidmos diminuir o escopo, descobrir alguma coisa que pudéssemos cortar do projeto a fim de entregá-lo no prazo. Dentre as opções de redução de escopo, escolhemos não rever a arquitetura de informação de todo o site, mas apenas das áreas mais importantes.

Com isso conseguimos entregar a tempo e os visitantes do site - principal “cliente” desse projeto - puderam usufruir de seu novo layout e de sua nova organização.

site da Locaweb depois do projeto de reescrever o site

De uma certa forma, redução de escopo e redução de qualidade são parecidos, mas têm uma diferença fundamental. Podemos reduzir qualidade de duas formas:

• fazer tudo o que foi planejado, só que fazer mal feito, ou;
• fazer menos do que foi planejado, só que bem feito.

Já quando falamos em redução de escopo, não damos margem para interpretação: é sempre fazer menos do que foi planejado, mantendo o trabalho bem feito. E muitas vezes quando fazemos e entregamos menos, percebemos que o menos que entregamos já é suficiente e que o produto final de nosso projeto ficou melhor com menos do que o que foi originalmente planejado.

Então da próxima vez que você pensar em reduzir a qualidade de seu projeto para poder entregá-lo no prazo e dentro do orçamento, pense se não seria melhor reduzir o escopo. Você e seu cliente poderão sair ganhando com a redução de escopo!

A apresentação completa pode ser vista em:

http://www.infoq.com/presentations/managers-in-scrum

Quem quiser ver só os slides, pode baixá-los aqui.

Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:

Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:

Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:

E, por último, um resumo:

Vale conferir essa apresentação.

• Agile development is more culture than process
• Creating The Culture For An Agile Environment

Pesquisando na Wikipedia, encontrei as definições abaixo:

• Cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.
• Processo é um cojunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.

Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.

Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.

É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.

E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …

A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/

Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.

Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.

Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.

Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:

• por que esses princípios são importantes para nosso time?
• o que tem sido feito para seguir esses princípios?
• onde não seguimos esses princípios e por que?

Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.

Aconteceu entre os dias 06 e 09 de abril a Semana da Tecnologia da FATEC de Jundiaí, onde estou cursando Informática para Gestão de Negócios. No dia 09/04, a convite do Prof. Demerval (Teoria da Administração) , fiz uma apresentação sobre desenvolvimento ágil com Scrum e XP num dos mini cursos que faziam parte do evento.

A participação dos alunos foi muito legal e, o melhor de tudo, acredito ter conseguido despertar no pessoal o interesse pelo desenvolvimento ágil.

No mesmo dia, o Fernando, fez a apresentação com o tema “Introdução a TDD“. Na terça, 07/04, o Reinaldo, nosso gerente na área de comércio eletrônico da Locaweb, mostrou como é fácil criar uma loja ou um site de sucesso utilizando boas ferramentas disponíveis no mercado, com destaque para a Loja Pronta e o Pagamento Certo, com o tema “Não reinvente a roda, pegue uma pronta”.

Estamos procurando fazer nossa parte para disseminar o conhecimento e tentar tornar o mundo do desenvolvimento de software um lugar melhor

Os slides da apresentação de Desenvolvimento ágil com Scrum e XP para ver ou baixar:

Ao final do artigo Kniberg faz um resumo das semelhanças e diferenças entre as duas metodologias. Algumas das principais diferenças que identificamos na nossa experiência de Kanban na Locaweb são:

O interessante do artigo é observar a sua imparcialidade. Em nenhum momento o autor pende para uma das duas metodologias, dizendo qual delas é a melhor. Na prática, a melhor alternativa ainda é adotar um bom mashup de metodologias - iterações de duas semanas com histórias sendo consumidas via Kanban através de práticas XP

Um detalhe interessante é que fazendo 100 pontos você ganha um “You’re awesome! No further improvement needed“, sendo que a pontuação máxima de cada item é 99 pontos (”improvement possible“). E isso em Agile faz todo o sentido

Link para a pesquisa: http://www.abetterteam.org/new

DDD - Domain Driven Design em Teatro from Locaweb on Vimeo.

“Kanban system physically limits the work-in-progress (…) It’s not a real Kanban system unless it physically limits the work-in-progress. Sticky notes on a white board doesn’t work unless you add a limit to the amount of work-in-progress. Because if there isn’t a limit there isn’t a pull system.”

A íntegra da apresentação - pouco mais de uma hora de duração - está em A Kanban System for Software Engineering.

Acho que vale refletir sobre essa lista. Por um lado, é provável que vários itens dessa lista seu time já tenha resolvido, mas pode ser que ainda falte um ou outro item:

In no particular order, you know you’re not doing agile if:

1. The team is co-located, but people are not sitting within the length of a school bus to each other.
2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.
3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.
4. If no user has seen real running software inside the last month.
5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.
6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.
7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.
8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.
9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.
10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Introdução a Domain Driven Design (DDD) from Locaweb on Vimeo.

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage,  uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software usando técnicas de Orientação a Objetos. O seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um certo contexto(1), um problema(2) e uma solução(3)

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk.  Quando se fala em Orientação a Objetos, pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas essência de Orientação a Objetos também tem coisas como:

• Alinhamento do código com o negócio
• Favorecimento de reutilização
• Mínimo de acoplamento
• Independência da Tecnologia

Todas essas coisas são bem exemplificadas e mostradas na forma de vários padrões em DDD. Mas o livro também mostra muitos padrões que não dizem respeito a código ou modelagem. Aparecem coisas que estão mais ligadas a processos (como Integração Contínua) ou a formas de relacionamento entre times que fazem parte do desenvolvimento de um sistema complexo.

Eric Evans dividiu o livro em quatro partes:

1 - Colocando o modelo de domínio para funcionar

Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua. Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código. Isso significa que, se durante uma conversa com um cliente do sistema de cobrança, por exemplo, ele disser: “Temos que emitir a fatura para o cliente antes da data limite“, vamos tem no nosso código alguma coisa do tipo

• uma classe para a entidade Cliente
• uma classe para a entidade Fatura
  
• Algum serviço que tenha um método emitir
• algum atributo que chame data limite

Essa linguagem ubíqua deve ser compreendida por todos e não podem haver ambigüidades. Toda vez que alguém perceber que um determinado conceito do domínio possui várias palavras que o represente, essa pessoa deve tentar readequar tanto a linguagem falada e escrita, quanto o código.

Outra forma de colocar o modelo para funcionar é utilizando Model Driven Design (MDD), conforme explicado no vídeo abaixo:

2 - Blocos de construção do Model Driven Design (MDD)

O Model Driven Design possuí vários Padrões, que são os blocos de construção que fazem a representação do modelo abstrato. Esses blocos podem ser:

• Entidades - classes de objetos que necessitam de uma identidade
• Objetos de Valores - objetos que só carregam valores, mas que não possuem distinção de identidade
• Agregados - conjuntos de Entidades ou Objetos de Valores que são encapsulados numa única classe
• Fábricas - classes responsáveis pela criação de Agregados ou Objetos de Valores
• Serviços - classes que contém lógica de negócio que não pertence à nenhuma Entidade ou  Objetos de Valores
• Repositórios - classes responsáveis por administrar o ciclo de vida dos outros objetos e de prover, alterar, e eliminar instâncias destes
• Módulos - abstrações que têm por objetivos agrupar classes por um determinado conceito do domínio

3 - Refatorando para compreender profundamente o modelo

Depois de elaborar um modelo de dados que reflete o seu domínio, usando os blocos de construção do MDD, o processo de aperfeiçoamento do modelo continua. O modelo deve ser refatorado na medida em que se compreende mais e mais novos conceitos do domínio. Muitas vezes alguns conceitos do domínio estão implícitos no código. Nosso trabalho é tentar identificar esse conceitos implícitos e torná-los explícitos. Alguns padrões podem ajudar a compreender mais profundamente o modelo:

• Interface de Intenção Revelada - usar nomes de métodos ou classes que dizem exatamente o que essas classes e métodos fazem, mas não como elas fazem. Dizer como quebra o encapsulamento.
• Funções sem Efeitos-Colaterais - tentar deixar o código com o maior número possível de métodos que não alteram o estado dos objetos, concentrando esse tipo de operação (alteração de estado) em Comandos.
• Asserções - para os Comandos que alteram estados, criar testes de unidade, ou colocar asserções no código que validem, após a chamada dos comandos, as alterações de estado esperadas.
  

  

4 - Projeto estratégico

Além de ter uma Linguagem Ubíqua, usada na elaboração de um modelo consistente e adequado para o domínio, precisamos de algumas estratégias para lidar com sistemas complexos, onde vários pedaços de softwares (desenvolvidos por vários times) interagem entre si. Precisamos delimitar em que contexto cada time trabalha e qual será o grau de interação entre esses times e esses contextos. Para isso os padrões:

• Contexto delimitado - um traçado perfeito sobre o que pertence e o que não pertence a um contexto
• Mapa entre Contextos - uma forma de documentar claramente termos usados para um mesmo conceito em vários contextos (p. ex. no contexto do sistema de cobrança usamos o termo “Fatura”, que significa a mesma coisa que o termo “Nota Fiscal” no contexto do sistema de faturamento)



• Núcleo Compartilhado - Quando dois times alteram uma mesma base de código em comum
• Produtor-Consumidor - Quando os times possuem uma relação bem clara de Cliente-Fornecedor
• Conformista - Caso não seja possível alterar ou pedir alterações  de uma parte do sistema mantida por outro time

• Camada Anti-corrupção - quando temos um sistema legado, com código muito bagunçado e uma interface complexa, e estamos escrevendo um sistema novo com o código razoavelmente bem feito, criamos uma camada entre esses dois sistemas. O nosso sistema novo e bem feito falará com essa camada, que possui uma interface bem feita. E a camada anti-corrupção é responsável por traduzir e adaptar as chamadas para o sistema legado, usando uma fachada interna.

Conclusões

Estes são apenas alguns padrões de Domain Driven Design. A razão pela qual falamos desse assunto no Blog Ágil é que desenvolvimento de software ágil está muito ligado a boas práticas de Orientação a Objetos e outros padrões de comunicação entre sistemas contidos no livro do Eric Evans. Obviamente não é possível entender DDD apenas lendo esse artigo. Nós, da Locaweb, estamos estudando todos esses conceitos e começando a aplicar esses Padrões no software que desenvolvemos. Nosso objetivo é ter, cada vez mais, um serviço de qualidade, baseado em sistemas seguros e fáceis de dar manutenção. Com isso poderemos atender nossos clientes com rapidez sem assumir nenhum tipo de débito técnico que possa inviabilizar nosso crescimento.

Aguardamos muitas sugestões e dúvidas sobre o assunto. Estamos mutio interessados em falar e aprender mais sobre DDD.

Antes, vale uma introdução ao tema.

Kanban (literalmente “cartão visual”) é uma metodologia de produção que utiliza controles visuais (cartões) como sinalizadores de estoque ou status de uma determinada etapa do processo. Os cartões podem ter diversos significados: problemas, atenção, quantidades em falta ou em excesso etc. É o Kanban que permite a aplicação dos conceitos de Just-In-Time (produção somente do necessário, na quantidade necessária e no momento necessário, sem estoques ou desperdícios) da metodologia Lean. Um bom exemplo de Kanban aplicado ao dia-a-dia é o apresentado por David Anderson: em uma visita a um lugar turístico no Japão, Anderson observou que na entrada eram distribuídos cartões em branco, sem nenhuma instrução ou número de controle. Esses cartões eram recolhidos na saída, e re-aproveitados para nova distribuição. A explicação: mais do que controlar a quantidade total de pessoas que entram, os cartões eram usados para controlar a quantidade de pessoas que estavam no lugar naquele exato momento - ou seja, a falta de cartões indica que há muitos turistas visitando o lugar e que deve-se diminuir o fluxo de entrada.

Na área de software, esse conceito está sendo usado para o mesmo propósito - controlar o fluxo de funcionalidades (histórias) em desenvolvimento.

Quadro de Kanban

O primeiro passo é definir a ferramenta a ser usada para a aplicação do Kanban. Com um simples quadro branco e post-its ou cartões já é possível criar um controle de fluxo de histórias buscando 100% de eficiência. O quadro deve conter colunas para identificar os diversos status de uma história (ex: Não Iniciado, Em Andamento, Impedimento, Em Publicação, Concluído). Observação: quanto menos status houver, mais fácil de manter o quadro; adicionem somente os status que não dependem da própria equipe resolver (ex: equipe não tem acesso de publicação em produção).

Antes de começar a falar sobre Kanban, vale fazer um comparativo: é muito comum equipes usarem planilhas ou sistemas para controle dos sprints. Apesar de serem boas ferramentas, muitas vezes não temos feedbacks visuais de como o sprint está andando. Com isso, é possível não percebermos que o sprint está dessa forma:

O primeiro passo é definir uma ordem de prioridade das histórias, deixando claro de alguma forma qual é a história mais importante que deve ser a primeira a ser desenvolvida.

Em seguida, ao primeiro dia do sprint, a equipe puxa a primeira história e a coloca como Em Andamento:

Na figura acima notem que adicionamos um traço que delimita o tamanho do espaço Em Andamento. Essa limitação é na verdade o segredo de todo o processo: como nesse espaço cabem um e somente um post-it, na prática limitamos a uma e somente uma única história em desenvolvimento. O simples fato de criarmos essa limitação física faz com que eliminemos alguns dos principais desperdícios Lean - trabalho não terminado, troca de tarefas etc.

Impedimentos

Uma boa metáfora para um quadro de Kanban é compará-lo com uma máquina qualquer, que transforma matéria-prima (histórias) em produtos (funcionalidades). Quando a máquina tem algum problema, normalmente uma luz vermelha é acesa, indicando qual é o problema e que algo deve ser feito para resolvê-lo.

Da mesma forma, podemos transpor essa ideia para o quadro. Caso haja algum problema que impeça o andamento da história, a equipe pode “acender a luz vermelha” com um post-it vermelho acima da história para indicar a todos que o problema existe e ainda não foi solucionado. Além disso, é importante movimentar a história para a coluna Em Impedimento - a razão disso é liberar espaço para a equipe puxar uma nova história Em Andamento enquanto o impedimento não for resolvido. Importante: esse procedimento só deve ser feito se o impedimento for algo que depende de terceiros e não pode ser resolvido no momento; se a própria equipe puder resolvê-lo, a história deve continuar Em Andamento.

De forma análoga, o status Em Publicação segue a mesma ideia: só deve ser usado se a publicação em produção depender de terceiros; se a própria equipe tiver acesso à produção, a história deve continuar Em Andamento. Uma observação: caso as histórias devam ser armazenadas para a publicação de um release futuro, é importante mostrar isso no quadro, aumentando o limite de acordo com a necessidade; muitos post-its armazenados podem indicar que o release está com muitas funcionalidades e que talvez deva ser publicado antes do previsto.

Feedback Visual

Com o Kanban em funcionamento, é possível começar a ler algumas informações. No exemplo abaixo, as três histórias que estavam no backlog no início foram consumidas pela fila, e os espaços em branco indicam que a equipe parou o sprint por falta de novas histórias.

O exemplo abaixo mostra uma situação crítica no Kanban: a história Em Andamento deveria ser movida para Em Publicação (ou Em Impedimento), mas não há espaço para esse movimento:

A solução para essa situação é publicar a história Em Publicação, ou remover o impedimento o mais rápido possível. Caso nenhum desses dois seja possível realizar no momento, vale reunir a equipe e analisar o sprint - por que o impedimento não pode ser resolvido naquele momento? Por que a história não pode ser publicada naquele momento? O que fazer para que a máquina não pare novamente? Devemos repensar esses limites (ex: duas histórias na fila de publicação)?

Com o impedimento resolvido, é importante guardá-lo em um espaço reservado, para analisar qual a raiz daquele problema e o que deve ser feito para que não ocorra novamente. Na prática, qualquer informação que passar pelo quadro serve como pauta para a Reunião de Retrospectiva de Sprint.

Eis um exemplo de um Kanban com problemas:

Os problemas que podemos identificar:

• Muitas histórias em andamento, gerando desperdícios;
• Muitas histórias em publicação, gerando atraso e acúmulo de trabalho;
• Nenhuma história foi finalizada ainda, apesar de todo o trabalho em andamento;
• Muitas atividades off-sprint, o que indica que a equipe está ocupada com atividades gerais (chamados, correções de bugs em produção etc);
• Muitos impedimentos - O que fazer para evitá-los?
• Histórias canceladas - Por que foram canceladas? Por que eram prioritárias antes? Como fazer para evitar essa situação? Como fazer para identificar histórias que deveriam ter sido canceladas e acabaram sendo implementadas, gerando desperdícios e complexidade?

Por fim, o quadro de Kanban pode ser usado para diversas outras informações que a equipe achar relevante:

Estamos implantando essas ideias em diversas equipes na Locaweb, e o resultado tem sido excelente. Em um próximo post daremos algumas dicas do que andamos observando. Até lá!

• Fábio Kon, professor do IME/USP, e Paulo Cheque, da AgilCoop, fizeram uma palestra introdutória falando um pouco da história, tipos e técnicas de testes. Ficou evidente a importância que estes dois profissionais dão a este assunto, por acreditarem que escrever e automatizar testes são aliados da qualidade. Destaque para a iniciativa (divulgada pelo Fábio Kon) de formação do Centro de Competência em Software Livre pela USP.
• Ricardo Lemke falou sobre os diversos tipos de testes. Foi uma palestra muito importante por detalhar tipos pouco conhecidos, distingüi-los e desfazer alguns enganos conceituais.
• Hugo Corbocci, também da AgilCoop, fez uma palestra prática a respeito de BDD (Behaviour Driven Development). Hugo observou o comportamento do Registro de Domínio no site da Locaweb e reimplementou esta funcionalidade utilizando o famoso framework RSpec. Um detalhe interessante da palestra é que ela foi realizada no formato de um Dojo Kata, e todos nós pudemos ver, passo a passo, que é possível escrever testes desde a camada de apresentação e como as técnicas de “test first”, “baby steps” e design incremental contribuem para a modelagem e construção de uma aplicação bem testada e com código limpo.
• Depois do almoço, eu moderei uma sessão de Dojo, agora no estilo Randori. O objetivo era incentivar a participação nas duas sessões semanais que estamos organizando há cerca de 2 meses aqui na Locaweb. Escolhemos um problema e programamos em turnos de 7 minutos, entrecortados por interessantes discussões a respeito de design e TDD.
• Maurício De Diana fez a palestra entitulada “Lidando com Sistemas Legados”. Foi interessante ouvir a respeito das técnicas e boas práticas recomendadas para aqueles que precisam lidar com sistemas já em funcionamento.
• Daniel Cukier falou sobre injeção de dependências e testes com dublês. É impressionante perceber como muitas vezes confundimos mocks com stubs ou não utilizamos a técnica correta para cada tipo de teste.
• E para finalizar o evento, tivemos outra apresentação do Maurício De Diana, desta vez falando a respeito de boas práticas de design. Toda vez que discutimos conceitos como SRP (Single Responsability Principle), OCP (Open-Closed Principle), etc aprendemos ou pensamos em alguma coisa nova a respeito de design de software.

Se quiser ver mais fotos do nosso evento, fique à vontade para nos visitar no Flickr.

E vocês, o que fazem para compartilhar conhecimento e melhorar a comunicação das suas equipes?

http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html

A idéia é bem simples (o destaque é meu):

The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass deploy to the cluster. If the deploy succeeds, repeat.

Our tests suite takes nine minutes to run (distributed across 30-40 machines). Our code pushes take another six minutes. Since these two steps are pipelined that means at peak we’re pushing a new revision of the code to the website every nine minutes. That’s 6 deploys an hour. Even at that pace we’re often batching multiple commits into a single test/push cycle. On average we deploy new code fifty times a day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

O Passado

No final de 2006, a equipe que desenvolve o Pabx Virtual começou a usar Programação Extrema como metodologia de desenvolvimento. Por ser uma equipe pequena, nova e independente das outras, todas as práticas da metodologia puderam ser adotadas gradualmente e o produto foi um sucesso.

Em agosto de 2007, a Locaweb resolveu estender as práticas ágeis para todas as equipes de desenvolvimento e promoveu um treinamento para todos os 80 programadores da época. A partir daí todos adotaram Scrum. Depois de 6 meses de adoção, já pôde ser percebida o aumento de produtividade da nossa área de tecnologia.

Em maio de 2008 o Joca inaugurou o blog ágil com o objetivo de compartilhar nossa experiência com todos os clientes. Escrevemos vários posts no ano de 2008, muitos deles introdutórios e básicos:

• Como tudo começou - uma pequena introdução aos primórdios dos M.A.
• Scrum - os primeiros ensinamentos sobre a metodologia que virou moda em 2008.
• Histórias de Usuários, como escrevê-las de várias maneiras.
• Fizemos WebCasts sobre Métodos Ágeis, Scrum e XP.
• Falamos das práticas de XP, refatoração.
• Como estimar de forma ágil, estimar jogando e acompanhar os resultados do sprint.

No meio do ano de 2008, por volta de agosto, percebemos que nosso público já havia entendido os princípios dos Métodos Ágeis e começamos a abordar temas mais avançados. Participamos da conferência internacional Agile 2008 e resumimos os melhores momentos. Além desse evento, o final do ano foi marcado por uma maratona de encontros da comunidade ágil.

Em outubro tivemos o Encontro Ágil, promovido pela Agilcoop da USP. Foi um evento de muita qualidade, principalmente pelos debates e discussões, com nomes importantes como Fabio Kon, Dairton Bassi Juan Bernabó. No mesmo mês ainda tivemos o Rails Summit Latin America promovido pela Locaweb, com vários membros da comunidade rails e ágil internacional, como Chad Fowler, Fábio Akita, Danilo Sato, Fábio Kung. E no final de outubro ainda tivemos o Falando em Agile, organizado pela Caelum, onde Daniel Cukier fez uma palestra contando das técnicas que usou para ajudar a introduzir métodos ágeis na Locaweb. Foi realmente uma maratona, mas valeu muito a pena, não só para aprimorar os conhecimentos em assuntos Ágeis, como para conhecer melhor quem são as pessoas que estão fazendo a diferença em matéria de desenvolvimento de software, no Brasil e no mundo.

Mais para o final do ano começamos a falar de Lean, introduzindo alguns conceitos como Teoria das Restrições, Investimento em Opções, e voltamos ao XP falando de pareamento e tópicos de como integrar Ágil com UX.

A adoção de Métodos Ágeis na Locaweb não foi feita do dia para a noite e o processo foi demorado e muito suado. Para conseguir convencer as pessoas de que Ágil era uma boa idéia, usamos Padrões para Introduzir Novas Idéias. Apresentamos alguns padrões para que nossos leitores pudessem usá-los e facilitar a adoção de Ágil em suas empresas.

Em novembro, participamos da QCON em São Francisco, uma das maiores e melhores conferências de software do mundo. Fizemos alguns artigos sobre o evento:

• BDD Behaviour Driven Design com Dan North
• Agilistas e Arquitetos: aliados, não adversários
• Como montar um time a qualquer hora
• Programação poliglota e multi-paradigmas

Em dezembro iniciamos uma série de vídeos sobre vários assuntos ágeis como Integração Contínua, Refatoração, e Padrões para Introduzir Novas Idéias e terminamos o ano com um post sobre bíblia dos sistemas, outro sobre o case AG2 e mais outro sobre a análise da causa raíz.

O Futuro

Apesar de termos caminhado bastante, sabemos que desenvolver software é um processo de melhoria contínua. Isso significa que sempre teremos coisas novas para aprender. Enquanto os Métodos Ágeis estavam restritos ao pequeno grupo que criou as metodologias, era fácil manter os conceitos claros e bem entendidos por todos. Na medida em que mais e mais gente começa a tomar conhecimento do assunto, bifurcações começam a acontecer e algumas vezes as pessoas acabam esquecendo dos princípios. É muito possível que hoje já exista gente dizendo que é ágil, mas que não segue o Manifesto Ágil.

Se formos pensar em todo universo de desenvolvedores de software, ainda tem muita gente que nunca ouviu falar de XP ou Scrum. Talvez alguns estejam mais antenado, quem lê blogs, quem acompanha a InfoQ, essas pessoas como você, que são uma minoria. Temos que lembrar que temos uma massa de programadores que ainda seguem os métodos antigos ou não seguem método nenhum. São pessoas que não tiveram acesso ao conhecimento e nosso papel é ajudá-los.

Vamos contar nossas experiências, nossos casos de sucesso, nossos casos de fracasso. Vamos ensinar à massa como se desenvolve software de qualidade, como se elimina desperdício, como se garante um custo de manutenção baixo e constante ao longo do tempo.

Vamos lembrar que pessoas e as interações entre elas são mais importantes que processos e ferramentas. Isso significa que, não é a linguagem de programação que você usa, o sistema operacional que você gosta, NÃO é isso que MAIS importa. Vamos valorizar as pessoas, fazer com que elas interajam de forma saudável, que trabalhem bem e em paz. Que sejam produtivas, mas que sejam felizes também e se divirtam, que possam crescer profissionalmente. Quem defende a bandeira ágil, defende o interesse das pessoas, todas elas em harmonia: os clientes, os programadores, os gerentes, os designers, os times operacionais e de suporte e todos que fazem parte de um grupo de pessoas interessadas em criar e usar bons produtos de software.

O próximo ano será não só de muitos desafios, mas também de oportunidades. A crise do ano passado serviu para avaliarmos nossa posição. Fizemos a reflexão. O que foi ruim e precisamos melhorar? O que foi bom e desejamos manter? Agora que a reflexão foi feita é hora de agir. Tem muito software para ser escrito e muito legado para receber manutenção e melhoria. Vamos escrever muitos testes automatizados, vamos continuar refatorando nosso código antigo, continuar fazendo nossos planejamentos cíclicos, entregando antes o que é mais importante, entregando com qualidade e de forma incremental, trabalhando juntos e pareados, ao lado do cliente.

Por último, vamos lembrar da verdade sobre a qual os Métodos Ágeis se baseiam: MUDANÇA! Tudo está o tempo todo mudando, nada é permanente. Ser ágil é se adaptar o mais rápido possível às mudanças. Kent Beck já disse isso desde o título do primeiro livro de XP (Embrace Change). Com certeza em 2009 teremos muitas mudanças e se somos realmente ágeis, vamos saber lidar com todas elas de forma positiva. Que esse ano seja cheio de agilidade, mudanças e sucessos para todos!

Mais uma fonte para quem se interessa pelo papel de PO do Scrum e sente falta de referências na literatura especializada. Aproveitem!

http://www.rgalen.com/publications.html

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

• Agile Development Projects and Usability: Jakob Nielsen descreve maneiras de garantir que a qualidade da usabilidade não seja ameaçada pela adoção de metodologias ágeis.
• Agile / Scrum Product Development Process: Marty Cagan propõe uma forma de integrar UX e Scrum.
• Extreme Programming vs. Interaction Design: Entrevista com Kent Beck e Alan Cooper sobre design de interação e XP. Nessa entrevista, chamada por alguns de “duelo de titãs”, Beck defende o desenvolvimento do design de interação de forma incremental, enquanto Cooper defende que o desenvolvimento de software não deve começar antes de todo o trabalho de design de interação ser concluído.
• UX Agile: um blog totalmente dedicado à questão de integrar UX aos times de desenvolvimento que usam metodologias ágeis.

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!

XP tem uma meia dúzia de práticas raramente lembradas. Uma das mais interessantes e mais esquecidas é a análise de causa raiz.

A análise de causa raiz tem por objetivo encontrar e ajudar a atacar a verdadeira causa de um problema, e não seu efeito. Quando não se resolve um problema na raiz a tendência é que outros efeitos semelhantes (ou o mesmo) apareçam no futuro. São raras as vezes em que ao “apagar um incêndio” resolvemos a causa raiz do problema.

Por exemplo, imagine que sua empresa definiu que toda comunicação via webservice deve ser feita com encoding UTF-8. Agora imagine que você escreveu uma aplicação que usa um webservice específico, mas ao testá-la você percebe que a comunicação falha pois o encoding das respostas devolvidas pelo webservice é ISO-8859-1. Você pode simplesmente mudar o seu código para que ele use o mesmo encoding e passe a se comunicar com o webservice. Mas essa medida não resolve a raiz do problema, que é o fato de o webservice ter quebrado o padrão definido. É ele que deveria ter sido alterado.

Nesse momento percebe-se a importância de resolver a causa raiz dos problemas. Imagine agora que você adote a opção de mudar o seu cliente. Algumas semanas depois alguém precisa consumir o mesmo serviço e também ignora o padrão definido pela empresa e também adapta seu código para usar ISO-8859-1. E se depois de algum tempo aparecer mais alguém precisando chamar esse webservice, e reclamar que ele está fora do padrão? Pode ser que a raiz seja ignorada mais uma vez e digam para o programador que agora é tarde, já há clientes consumindo o webservice e portanto ele não pode mais ser alterado. Ou então é criada uma segunda versão com o encoding correto, mas agora há duas versões a serem mantidas. Pior ainda se o consumidor em questão também for um webservice que, ao se adaptar ao encoding errado, propaga para seus clientes a quebra de padrão.

É fácil perceber, mesmo através de um exemplo simples como esse, como a análise de causa raiz pode facilitar a manutenção de sistemas. E quando se pensa em situações menos óbvias, essa análise passa a ser ainda mais poderosa, chegando a indicar problemas organizacionais que vão além do desenvolvimento de software. O livro Extreme Programming Explained apresenta um bom exemplo disso:

1. Por que não notamos esse defeito? - Porque não sabíamos que o balanço poderia se tornar negativo de um dia para o outro.
2. Por que não sabíamos? - Porque só a senhora Crosby sabe e ela não é parte da equipe.
3. Por que ela não é parte da equipe? - Porque ela ainda dá suporte ao sistema velho e não tem mais ninguém que possa fazer isso.
4. Por que mais ninguém sabe? - Porque não é uma prioridade da gerência ensinar ninguém.
5. Por que não é prioridade da gerência? - Porque eles não perceberam que um investimento de $20.000 poderia ter nos economizado $500.000.

A técnica de análise de raiz usada acima é uma das mais simples e mais comuns, criada por Taiichi Ono da Toyota e conhecida como os 5 Porquês. Ela consiste basicamente em se perguntar “por que” recursivamente 5 vezes para se atingir a causa. Nada impede que se mais (ou menos) do que 5 perguntas sejam feitas, o número 5 vem da observação de Ono de que esse número costuma ser suficiente para se chegar a causa raiz.

Alguns criticam essa técnica, acusando-a de ser simplista. Existem diversos modelos mais complexos, mas para a maioria dos casos em que se está procurando a causa de um bug, por exemplo, ela é mais do que suficiente.

E já que o assunto é software especificamente, vale comentar o processo de correção de bugs apresentado no mesmo Extreme Programming Explained:

1. Escreva um teste de aceitação automatizado que reproduza o problema, e que demonstre qual o comportamento esperado.
2. Escreva um teste unitário que reproduza o problema.
3. Conserte o código de forma que o teste unitário passe. O teste de aceitação também deve passar se o problema foi arrumado. Caso isso não tenha acontecido, volte para 2.
4. Assim que o problema for arrumado, faça a análise de raiz para descobrir porque ele aconteceu e não foi percebido antes.

O processo acima apresenta uma sutileza que vale ser comentada: a análise de causa raiz ocorre depois que o bug foi consertado. Isso significa que não é necessário se conhecer a raiz para se consertar o bug? Na maioria das vezes não. A análise de causa raiz busca entender porque o bug ocorreu, e não qual a sua causa técnica necessariamente. E isso faz bastante sentido, em especial quando o bug está atrapalhando o uso do sistema em produção, ou seja, há alguma pressa em fazer com que as coisas voltem a funcionar como deveriam. Consertar o bug e resolver o problema na raiz são coisas diferentes. Em inglês, usa-se o termo fix para indicar a solução superficial ou emergencial do problema e o termo resolve para indicar a solução na raiz.

Vale notar que a análise de raiz não é uma técnica exata. Os resultados podem ser diferentes dependendo de quem faz a investigação. Pode ser que alguém fazendo a análise citada acima concluísse que o problema não foi a falta de treinamento, mas sim a demora para se livrar do sistema antigo, que fez com que a senhora Crosby ficasse sobrecarregada. Nesses casos é interessante que a equipe fazendo a análise levante essas diferenças.

Por último, é importante deixar claro que nem sempre é possível resolver a causa raiz. Por exemplo, pode-se perceber que a causa dos problemas é a dependência do sistema de um fornecedor que não tem como ser substituído. Nesses casos o melhor a fazer é deixar essa causa raiz documentada, e tentar resolver o item anterior a ela na cadeia de causas.

[LW] Você poderia nos contar o que é a AG2 e que tipo de desenvolvimento vocês fazem?
[AG2] A AG2 Agência de Inteligência Digital S.A. é uma agência digital de soluções completas para grandes corporações. Atuante em nível nacional, é líder de mercado na Região Sul e uma das 5 maiores do país. Suas linhas de serviços proporcionam um ciclo de atendimento completo, tendo capacidade de resposta às necessidades de toda a cadeia de valor do negócio. A AG2 suporta seus clientes na definição de opções estratégicas e tecnológicas, desenvolve sistemas web sob medida para as mais diversas aplicações, bem como ações de comunicação interativa, provendo ainda toda a gestão operacional da presença digital. Com mais de 150 colaboradores nas suas bases de São Paulo, Porto Alegre e Pelotas, a AG2 atende empresas como Embraer, Bradesco, General Motors, Grupo Silvio Santos, Bunge, C&A e Vulcabras.

[LW] Quantos desenvolvedores trabalham na AG2?
[AG2] A AG2 conta com aproximadamente 30 colaboradores envolvidos diretamente no desenvolvimento de sistemas, como codificadores HTML, analistas de sistemas, DBAs, desenvolvedores .Net e analistas de testes e 40 nas disciplinas relacionadas a arquitetura de informação e interface, como analistas e projetistas de interface, diretores de arte, web designers, programadores Flash, além de profissionais de análise de negócios, criação e gerenciamento de projetos.

[LW] Vocês decidiram usar Scrum recentemente. Quando foi isso e por que vocês decidiram seguir esse caminho?
[AG2] Começamos a estudar Scrum pelo fato de ser mais uma metodologia de desenvolvimento de projetos, inicialmente mais em tom investigativo e para conhecer os conceitos do que efetivamente objetivando alterar nossos métodos. Durante o estudo notamos que vários aspectos dela poderiam se encaixar muito bem no que fazemos, agregando muito com relação a agilidade e velocidade de desenvolvimento que ela proporciona. Devido principalmente aos prazos sempre apertados que temos para desenvolver e o teor de alguns projetos começamos a fazer alguns testes em alguns projetos.

[LW] Você utilizam só Scrum, ou usam outras metodologias também como o XP?
[AG2] Apenas Scrum.

[LW] Como foi a implementação do Scrum? Foi em toda a equipe de desenvolvimento ao mesmo tempo? E qual foi a receptividade? Todos gostaram ou houve alguma resistência?
[AG2] Começamos a implementar o Scrum de forma bem “comportada”. Inicialmente montamos alguns workshops para apresentar a metodologia para a equipe e discutimos bastante os benefícios e os possíveis problemas que poderíamos enfrentar com esse nova metodologia. Uma vez conversado entre o time de desenvolvimento, observamos a possibilidade de aplicarmos Scrum em um projeto especifico e assim o fizemos. Ou seja, não saímos alterando nossos métodos e processos do dia para a noite. Queríamos fazer nossos próprios testes e tirar as nossas conclusões. A receptividade dos envolvidos foi ótima! Tendo em vista que o Scrum prima pela multidisciplinaridade e o envolvimento completo do time do projeto, todos os integrantes envolvidos no piloto passaram a se sentir mais presentes e agregadores ao projeto. Não tivemos praticamente nenhuma resistência na implementação da metodologia.

[LW] Como foi feita a divisão dos times? Quantas pessoas por time? Como vocês fazem para integrar todos os times?
[AG2] Os times que montamos (e ainda estamos montando) tem em média 9 integrantes. Para cada time optamos por colocar diferentes disciplinas de desenvolvimento, de forma que um time tenha capacidade de desenvolver qualquer tipo de demanda e seja auto-gerenciável. Ou seja, temos Desenvolvedores .Net junto com Diretores de Arte, sentados lado a lado em locais físicos específicos para o time. Com relação a “sintonia fina” das equipes, outra coisa que fizemos na montagem dos times foi agrupá-los por cliente. Isso faz com que a cultura de cada um dos clientes seja absorvida de forma mais visceral pelo time, resultando em projetos bem mais aderentes aos objetivos de nossos contratantes.

[LW] Como responsável pela gestão de projetos, quais as vantagens que você vê em usar metodologias ágeis de desenvolvimento em comparação com modelos mais tradicionais de gestão de projetos?
[AG2] Creio que todos os modelos de gerenciamento de projetos tem as suas vantagens e estas são exponencializadas de acordo com os projetos propriamente ditos. Aqui na AG2 desenvolvemos alguns projetos usando modelos mais tradicionais em cascata e outros usando Scrum. Decidimos o modelo de gestão para um projeto específico baseado nas características de cada um deles. Se vislumbramos algo com escopo razoavelmente definido e altíssimo grau de complexidade talvez optemos por um modelo mais clássico de desenvolvimento, pois talvez um modelo ágil não seja o mais adequado para esta ocasião. Ao passo que, se nos deparamos com uma possibilidade de desenvolvimento onde temos uma variável de tempo muito curta e muitas indefinições, a metodologia ágil tende a aumentar muito as nossas chances de sucesso. Então, creio que quem dita as vantagens realmente são os projetos.

[LW] As metodologias ágeis prevêm a presença do cliente junto da equipe de desenvolvimento. Vocês conseguem ter o cliente por perto durante o desenvolvimento?
[AG2] A grande maioria de nossos clientes são extremamente participativos no decorrer de todo o desenvolvimento. Nestes casos envolvemos o cliente do inicio ao fim explicando os benefícios de seu envolvimento no processo de tomada de decisões e no processo produtivo como um todo. Isso sempre se mostra uma excelente forma de aumentar a possibilidade de sucesso do projeto. Reuniões de definições de prioridades para desenvolvimento e aprovações acontecem durante todo o projeto e as indesejáveis surpresas deixam de acontecer. Quando é mais difícil agregar o cliente ao processo elegemos alguém que represente o cliente em nossa estrutura, geralmente o profissional de Atendimento. Dessa forma tentamos aproximar ao máximo as percepções do cliente ao nosso dia a dia de trabalho.

[LW] Um grande questionamento que existe é sobre como encaixar o design visual no processo de desenvolvimento de sistemas usando metodologias ágeis. Como vocês conseguiram combinar o design visual com o desenvolvimento?
[AG2] A forma que estamos utilizando para desenvolver o design juntamente com a parte de programação inserido na metodologia ágil é tentar mantê-las independentes o máximo de tempo possível. No inicio do projeto tentamos definir o Backlog de cada Sprint de forma que os desenvolvedores de sistema possam programar as funcionalidades que são totalmente independentes da Interface, ao passo que o pessoal do design possa se preocupar com a arquitetura da informação, navegabilidade e estética do projeto. Em Sprints subseqüentes, devido ao aumento do conhecimento de toda a equipe assim como a melhoria da definição do projeto começamos a aproximar as áreas para que a integração entre elas ocorra sem problemas.

[LW] A adoção de metodologias ágeis é um processo de constante aprimoramento. Quais são os seu próximos objetivos?
[AG2] Estamos engatinhando ainda no que diz respeito a metodologias ágeis. Nossos próximos passos são realmente comprovar a eficácia com relação a rentabilidade e performance dos projetos e aumentar a cultura destes métodos na AG2. Treinamentos e workshops são as medidas imediatas para que todos sintam-se confortáveis e confiantes com o uso delas. A partir desse ponto veremos o que o futuro nos apresenta…

Se você também quer compartilhar a sua experiência, mande um email para joaquim ponto torres arroba locaweb ponto com ponto br.

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Fuçando um pouco descobri que esse John Gall, um pediatra, escreveu em 1978 um livro chamado “Systemantics, How Systems Really Work and Especially How They Fail” com um conjunto de leis que regem quaisquer tipos de sistemas, que podem ser desde programas de computador até o corpo humano, o universo, uma cidade, uma empresa, etc.

O livro é uma espécie de paródia ou crítica à teoria de sistemas que foi criada por Ludwig von Bertalanffy, um biólogo austríaco, no início do século passado.

Systemantics teve uma segunda edição, “Systemantics: The Underground Text of Systems Lore”:

E na terceira edição foi rebatizado como “The Systems Bible: The Beginner’s Guide to Systems Large and Small”:

Apesar de ser uma paródia, no estilo das Leis de Murphy, ou mesmo por ser uma paródia, as leis de Systemantics fazem refletir, principalmente quando as lemos pensando em desenvolvimento de sistemas e produtos de internet.

Além da citação do início desse post, gosto particularmente das leis abaixo, que refletem muito a forma de pensar das metodologias ágeis:

• The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
• The mode of failure of a complex system cannot ordinarily be predicted from its structure.
• The larger the system, the greater the probability of unexpected failure.
• Colossal systems foster colossal errors.
• Choose your systems with care.

As 5 primeiras leis são bem interessantes também:

• The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
• The Fundamental Theorem: New systems generate new problems.
• The Law of Conservation of Anergy [sic]: The total amount of anergy in the universe is constant. (”Anergy” = ‘human energy’)
• Laws of Growth: Systems tend to grow, and as they grow, they encroach.
• The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)

Uma lista mais completa das leis pode ser encontrada em:

http://en.wikipedia.org/wiki/Systemantics

E nos links abaixo há a lista de leis com alguns comentários:

http://www.laetusinpraesens.org/docs/systfail.php
http://www.draftymanor.com/bart/systems1.htm
http://www.ece.osu.edu/~fasiha/systemantics

Fecho esse post com uma lei específica sobre evolução que é bem apropriada aos sistemas desenvolvidos usando metodologias ágeis:

As evolution is the only system known to produce intelligent behaviour, it is to be preferred.

Semana passada fiz também uma apresentação sobre esses Padrões aqui na Locaweb e gostaríamos de compartilhar esse conhecimento com todos vocês. O vídeo está dividido em 6 partes, sendo que na parte final fizemos um pequeno debate sobre os conceitos apresentados. Aguardamos os seus comentários.

• Não existe um paradigma de programação que funcione bem para todos os tipos de aplicação
• Não existe uma linguagem ideal para todos os tipos de domínio

Segundo Dean o maior problema daquilo que definiu como monoculturas é que geralmente há mais código do que o necessário - o que ele definiu como the pervasive IT problem – e que a razão para isso é o uso de linguagens ou paradigmas não ideais para o problema sendo resolvido.

Ele então apontou quatro problemas considerados comuns em monoculturas, analisou seus principais sintomas e definiu estratégias para solucioná-los através de polyglot and poly-paradigm programming:

Problema 1: Necessidade de maior extensibilidade e agilidade

Sintomas:
- Novas funcionalidades levam muito tempo para ser implementadas
- Reação lenta a mudanças

Solução:
Aplicação = Componentes + Scripts

Componentes: escritos em linguagem estática (Java, C#, C++, C, etc) e compilados para ter melhor performance. Possuem produtividade mais baixa.

Scripts: escritos em linguagens dinâmicas (Ruby, Python, etc…) e interpretados para ter melhor extensibilidade e agilidade. Possuem produtividade mais alta.

Problema 2: Código obscuro e de difícil manutenção

Sintomas:
- Lógica de negócio não vem à tona ao ler o código
- Traduzir regras de negócio em código é algo propenso a erros

Solução:
Domain Specific Languages - modelar uma linguagem que faça com que o código seja lido como uma frase estruturada contendo regras do domínio de negócio

Problema 3: Há código duplicado por toda parte

Sintomas:
- Há lógica de persistência em todas as classes do domínio
- Tratamento de erros e logging é inconsistente

Solução:
Programação orientada a aspectos para lidar com Cross-cutting concerns

Problema 4: A aplicação é altamente concorrente e deve estar disponível 24×7

Sintomas:
- Dificuldade em escrever código realmente Thread-safe
- O sistema “trava” ao ser submetido a grande carga

Solução:
Programação funcional: torna a programação concorrente fácil por não haver necessidade de sincronização, e portanto não há preocupação com locks, semáforos, etc.



Por fim Dean observou que muitas coisas que eram consideradas velhas estão se tornando novas outra vez, como o caso de programação funcional e de algumas linguagens dinâmicas (como Ruby e Lisp).

Encontre um parceiro e desenhe um jogo da velha, mas que ao invés de ter 3 posições por 3 posições, tenha 4 por 4. As regras do jogo são simples: cada linha ou coluna com 4 marcações suas seguidas vale 50 pontos; cada linha ou coluna com 3 marcações suas seguidas vale 40 pontos; não se conta pontos na diagonal. O objetivo também é simples: maximize sua pontuação.

E aí?! Jogou? Quantos pontos fez? 40? 50? 90? Mais? O parceiro que terminou o jogo achando que foi prejudicado e que poderia ter feito mais pontos já está vendo a problemática que o Avery quer discutir: nós somos naturalmente programados para garantir o nosso sucesso, mas no entanto não nos damos conta que estamos constantemente inseridos em situações nas quais nossa credibilidade depende do resultado do trabalho de pessoas que não controlamos.

A discussão prosseguiu em torno da diferença básica entre dois conceitos: accountability e responsibility. As duas palavras são geralmente traduzidas de forma igual, mas eu diria que accountability está mais para “prestação de contas”. E essa diferença é fundamental, pois a obrigação de prestar contas é algo que alguém nos atribui, ao passo que a responsabilidade por alguma coisa é algo que geralmente de uma forma ou de outra escolhemos ter. Além disso, há muitas situações em que queremos ser responsáveis por alguma coisa, mas não queremos prestar contas quando ela der errado.

O Avery segue a apresentação discutindo o processo pelo qual as pessoas passam quando se confrontam com um problema (a série: negação, atribuição de culpa, vergonha e resolução pela obrigação) e como se pode sair desse processo. Por fim, ele discutiu como todos esses conceitos também são aplicáveis em equipes de projeto que não sejam de software (vide o livro Mastering the Rockefeller Habits), apresentou um framework para orientação de equipes e fechou apresentando alguns resultados práticas observados. Achei uma discussão muito interessante e vale a pena baixar a apresentação da QCon e acompanhar o seu blog.

Alguns problemas foram apontados nesse tipo de abordagem:

Então Martin Fowler lembrou que metodologias ágeis se baseiam em princípios de comunicação e foco no cliente, e que portanto a função do arquiteto deve ser redefinida num contexto ágil. Explicou que nesse contexto o arquiteto assume como função principal a de colaborador, tendo como atividade primária a de mentor (similar ao coach do XP), trabalhando na capacitação do time de desenvolvimento para que ele possa lidar sozinho com assuntos cada vez mais complexos.
Desse modo, em um contexto ágil, o valor de um arquiteto se torna inversamente proporcional ao número de decisões que ele toma.

Ontem participamos da palestra do Dan North sobre Behaviour Driven Design (BDD). É um conceito que surgiu em 2006. Seus conceitos não são tão novos assim. Na verdade BDD é apenas a união de várias práticas consideradas ágeis e úteis para quem desenvolve software na indústria. O objetivo de BDD é focar em funcionalidades de alto valor e aplanar os custos de mudança. Quando você estiver fazendo:

• XP - especialmente Desenvolvimento Orientado a Testes (TDD) e Integração Contínua
• Domain Driven Design (DDD)
• Planejamento Orientado a testes de aceitação
• Uma linguagem ubíqua bem definida
• Programação Neurolinguística (no sentido de que cada palavra pronunciada tem um significado que fica na memória das pessoas e norteiam o desenvolvimento do software)

você estará no caminho de BDD. A idéia principal é que as palavras usadas no código tem um poder enorme de confundir ou de facilitar o trabalho do programador. Assim, o uso eficiente da língua deve ser feito: testes devem ter nomes que identificam o que eles estão testando de fato, ou seja, o nome dos testes devem ser frases que dizem o que o teste testa.

Para quem usa Java, Dan North escreveu o JBehave, uma ferramenta cujo objetivo é ajudar a escrever testes usando uma linguagem mais natural do que a forma como se escreve usando somente o JUnit. Para os programadores de Ruby existe o framework RSPec.

Esta semana alguns de nós da Locaweb estaremos na QCON. Viemos numa caravana de 9 pessoas, inclusive o CIO da empresa, Gilberto Mautner. O nosso objetivo é aprender o que há de mais atual e moderno em matéria de desenvolvimento de software e compartilhar o máximo desse conhecimento com os nossos clientes.

A QCON é uma das maiores conferências de Metodologias Ágeis e desenvolvimento de software do mundo, com presença de nomes como Martin Fowler, Kent Beck, Linda Rising, Eric Evans, Ralph Johnson e tantos outros. A segunda e a terça são os dias dos tutoriais, e a conferência começa a esquentar de verdade na quarta-feira. Serão mais de 100 palestras sobre dezenas de tópicos: Ruby On Rails, Cloud Computing, Scrum, Testes, Código Limpo, Java, RESTful Web Services e muito mais. 

Ontem tivemos um tutorial muito interessante sobre Padrões para Introduzir Novas Idéias. Fiz um post no meu blog com alguns vídeos sobre o tutorial. Mais material sobre assunto também pode ser encontrado lá. Também participamos de um tutorial sobre Domain Driver Design (DDD) com o Ralph Johnson. O tutorial abordou alguns padrões de interação entre equipes e sistemas, quando se trata de desenvolver software distribuído. Um dos tópicos que ficou evidente é a grande importância de se criar uma Linguagem Ubíqua (ubiquitous language), ou seja, é importante definir claramente os termos da língua com os quais os desenvolvedores e os clientes irão se comunicar. Esses termos devem ser claros para todos no time e devem ser usados de maneira única para não dar margem a ambigüidades.

Outro tutorial que assistimos foi sobre Domain Specific Languages (DSL), um trabalho recente que está sendo desenvolvido pelo Martin Fowler e pode ser visto em mais detalhes no site do autor.

Fiquem ligados nos nossos blogs! Em breve traremos mais novidades da QCON São Francisco 2008.

An Iteration Planning Meeting is all about agreeing as a team that we can deliver a certain amount of work within the upcoming iteration, and figuring out how to go about implementing that work. For me, the most important part of a successful IPM is that the whole team agrees on what is to be built, right down to detailed acceptance criteria for each story.

This part of the meeting goes a lot faster if you’ve done some of the following:

1. The Product Owner comes in with a prioritized list of user stories to be built
2. The team, or at least a few members, know what’s at the top of the list
3. The Product Owner has done a first pass at writing acceptance criteria for the stories
4. The Product Owner and a tester have discussed those stories and added negative tests (edge cases)
5. The tech lead has looked at the stories and acceptance criteria, and discussed these with the Product Owner
6. The team got the list of stories a few days before, so they’ve had some time to think about implementation

Aqui na Locaweb observei alguns casos de pequenos desperdícios durante as reuniões de planejamento. A identificação e eliminação desses desperdícios podem agilizar bastante as reuniões que duram mais tempo do que o necessário. Algumas situações comuns que identifiquei:

• Organização do Backlog durante a reunião: Vi alguns casos em que o Product Owner organiza o backlog durante a reunião de planejamento, com toda a equipe presente. Essa organização inclui desde priorizar as histórias até procurar emails com solicitações de novas histórias, passando por tirar dúvidas com solicitantes externos. Essa prática acaba tomando muito tempo da reunião e de todos os presentes, fazendo com que o foco se disperse e o resultado do planejamento fique comprometido.
• Discussões muito detalhadas: É importante discutir os detalhes necessários, mas somente os necessários. Em uma reunião recente, vi a equipe chamando um especialista de outra equipe e abrindo o Notepad para listar todas as regras de validação de um determinado campo. Perguntei se isso influenciava na estimativa em si, e descobri que a história já estava estimada. Na prática, saber que existem 3, 5 ou 13 regras de validação já é o suficiente para estimar a história, não é necessário listar e discutir cada uma delas.
• Discussões de histórias que não entraram no sprint: Em outra reunião recente observei uma história que após uma breve discussão decidiu-se por não incluí-la no sprint - faltava definir alguns detalhes funcionais, e a prioridade nem era tão alta. Antes de passar para a próxima história uma outra dúvida foi levantada. Com isso, a equipe passou os próximos minutos discutindo novamente toda a história, não para decidir se ela deveria entrar mesmo no sprint, mas já definindo detalhes para quando ela entrar em um sprint futuro.

Uma solução simples

A solução que ajuda a minimizar esses problemas é simples: O PO enviar um email listando as histórias que serão discutidas para o próximo sprint. O email deve ser enviado para a equipe, para os solicitantes externos que pedem histórias, e para os POs das outras equipes.

Essa prática ajuda a:

• O próprio PO organizar o backlog previamente;
• A equipe conhecer as histórias que serão discutidas, e já levantar alguns detalhes que podem ser importantes;
• Os solicitantes saberem se suas histórias serão discutidas, e se prepararem caso sejam acionados para esclarecer dúvidas;
• Os solicitantes saberem que outras histórias suas não serão discutidas, e repriorizá-las caso necessário;
• Os POs de outras equipes saberem se alguma história pode impactar algum produto seu, ou se existe alguma dependência que deva ser analisada;
• Divulgar a várias áreas o que a equipe está fazendo.

Em outras palavras, voltando ao artigo da Agile Commons, enviar um email com antecedência ajuda a resolver os ítens 1, 2, 5 e 6 da lista. Para os itens 3 e 4, um Definition of Done claro e preciso ajuda a resolvê-los. Ou seja, com dois passos simples é possível diminuir bastante o tempo da reunião de planejamento.

Um detalhe importante: Da mesma forma que o ScrumMaster é o responsável por eliminar impedimentos que comprometam o andamento do sprint, ele também é o responsável por eliminar impedimentos que comprometam o andamento da própria reunião de planejamento. Puxando para o Lean Thinking, o valor da reunião de planejamento é ter o sprint planejado - qualquer coisa que não ajude a equipe a atingir esse objetivo é considerado desperdício.

Se você tem uma boa idéia (como implantar XP ou Scrum na sua empresa) e essa idéia não é aceita, se você não consegue convencer as pessoas de que isso é legal, saiba de duas coisas. Primeiro: você não é o único a ter passado por isso. Segundo: quem já passou por isso identificou alguns padrões que ocorrem quando tentamos convencer as pessoas. Esses padrões são chamados de “Padrões para Introduzir Novas Idéias” e podem ser usados como uma ferramenta a seu favor.

No mês de outubro fiz, junto com o Prof. Fábio Kon,  uma apresentação no evento Falando em Agile sobre esses padrões e gostaria agora de compartilhá-los com todos essas dicas de como introduzir uma idéia.

Breve resumo do que é um padrão

Um padrão pode ser visto como um documento que descreve um problema e uma possível solução já pensada por alguém. O padrão normalmente também descreve o contexto em que o problema é encontrado e quais vantagens e desvantagens de aplicar a solução proposta num contexto similar.

Christopher Alexander definiu um padrão como uma regra de três partes que expressa a relação entre um certo contexto, um problema e uma solução. Richard P. Gabriel complementou essa definição para o ambiente de software, dizendo que cada padrão é uma regra de três partes que expressa a relação entre um certo contexto, um certo sistema de forças que ocorre repetidamente neste contexto e uma certa configuração de software que permita que essas forças se resolvam. Martin Fowler nos trouxe uma outra definição mais simples: um padrão é uma idéia que foi útil em algum contexto prático e provavelmente será util em outros.

Padrões para introduzir novas idéias

Esses padrões foram identificados (porque um padrão não é inventado e sim identificado depois que já aconteceu) pela Linda Rising e pela Mary Linn Manns e compilados no livro Fearless Change (Mudança sem Medo). Esse livro mostra 48 maneiras diferentes de se agir no objetivo de convencer as pessoas de uma idéia. São práticas que foram usadas em empresas de tecnologia e sua eficácia comprovada em contextos diferentes.

Vamos mostrar alguns exemplos aqui. Quem tiver mais interesse pode olhar o documento no site da agilcoop com o resumo de TODOS os padrões ou ouvir o podcast sobre Padrões para Introduzir Novas Idéias.

As Pessoas

Antes de mais nada, é preciso lembrar que para introduzir uma idéia iremos lidar com pessoas. Os primeiros padrões que precisamos conhecer então são os padrões relacionados a pessoas. Você deve estar preparado para saber como elas aceitarão suas idéias, quem poderá lhe ajudar e quem irá atrapalhar, como interagir com as várias personalidades que irão passar pelo seu caminho.

São 5 Padrões de pessoas:

• O Inovador (2,5%) - aceitam de imediato, só pelo fato da coisa ser nova
• Os que Adotam Cedo (13,5%) - Visionários e respeitados, ficam mais abertos depois de avaliarem de perto e perceberem que a nova idéia é uma grande descoberta
• A Primeira Maioria (35%) - são a ponte entre o velho e o novo, o primeiro grande grupo a ser convencido. Precisam ver a idéia funcionando em algum lugar antes de adotar
• A Última Maioria (35%) - Conservadores e céticos, precisam de uma certa pressão e só se convencem quando não há mais incertezas
• Os Retardatários (14%) - São os que pensam: “Pra que mudar, nós sempre fizemos assim e sempre funcionou”

Por onde Começar?

O padrão Experimente a Água diz para começar com duas ou três pequenas práticas, que não exijam muito esforço, e validar o que deu certo, tirando um Tempo para Reflexão. Outro padrão, Comemore Pequenos Sucessos, mostra que uma guerra se vence de várias pequenas batalhas. Qualquer pequeno objetivo alcançado é motivo de festa. Se não puder comemorar algo que deu certo, comemore se nada der errado! Faça as coisas no Passo a Passo, respeitando sempre o tempo da mudança. Use cada passo como uma oportunidade para aprender enquanto avança.

E em seguida?

Tenha contato e valorize os Conectores: secretárias, porteiros, copeiros, etc. Essas pessoas, que fazem parte das redes informais, se encarregarão de espalhar sua mensagem. Converse com os Conectores sobre suas idéias. Tenha o Guru ao Seu Lado, aquela pessoa cuja opinião é respeitada. Use-o como filtro, ouça sua opinião com humildade e respeito.

Mais alguns padrões

Esses Padrões foram usados no processo de adoção de métodos ágeis na Locaweb e foram muito importantes para o sucesso. É muito difícil realizar uma grande mudança sozinho. Peça Ajuda das pessoas, Envolva Todos e divida os méritos. Saiba sempre reconhecer A Hora Certa de agir. O tempo das pessoas é precioso, saiba respeitar esse tempo. Se não souber por onde começar, Simplesmente Faça: comece por algum lugar, esse é um bom começo. Você aprenderá com esse início, novas idéias irão aparecer e você saberá como prosseguir.

Para saber mais

• Resumo em Português sobre os Padrões para Introduzir Novas Idéias
• Apresentação em PDF
• Podcast (mp3) sobre o assunto

O formato clássico,

As a <type of user>
I want <some goal>
So that <some reason>

ou em uma tradução livre,

Como um <tipo de usuário>
Eu quero <uma história>
Para que <razão>

tem suas grandes vantagens:

• A primeira parte do texto, “Como um <tipo de usuário>”, deixa bastante claro quem é o principal beneficiário da história;
• A segunda parte, “Eu quero <uma história>”, é a história em si, o que deve ser desenvolvido;
• A terceira parte, “Para que <razão>”, mostra o valor da história, seu objetivo, o porquê dessa história ser feita e qual sua importância no projeto.

Na Locaweb, inicialmente trabalhávamos com um formato mais livre, onde cada PO definia seu formato ideal. Logo depois vimos alguns problemas surgirem nos planejamentos, especialmente quando a história era muito direta e pouco explicativa (”Cliente está com problema X; resolver”, “Corrigir problema Y”), com textos normalmente iniciando por verbos assertivos. Quando começamos a trabalhar com o formato clássico “As a… I want… So that…”, imediatamente vimos o valor disso, e as histórias passaram a ficar mais claras para as equipes.

Contudo, ainda vimos um problema: Em alguns casos o objetivo da história, o “Para que”, não ficava muito claro. Algumas vezes o texto era um pouco genérico, outras vezes era até omitido (”Como um cliente eu quero que o problema X seja resolvido”).

A sugestão de Chelimsky e Anderson é a melhor solução para isso. Com uma simples mudança na ordem da frase, passamos a focar mais no valor da história do que antes:

In order to <achieve some value>
As a <persona>
I want <some feature>

Ou em uma tradução livre:

Para que <um valor seja obtido>,
Como uma <persona>
Eu quero <uma história>

Nesse formato identificamos três grandes vantagens:

• Valor - O valor da história passa a ficar ainda mais claro do que no formato clássico. Primeiro identificamos o porquê dessa história, depois seu beneficiário e por fim a história em si. Além disso, o objetivo naturalmente passa a ser obrigatório no texto, sem o risco de ser omitido.
• Agrupamento Funcional - A leitura das histórias passa a ser mais funcional. Se o backlog contiver histórias começando com “Como um Cliente do sistema X, eu quero etc” e outras “Como um Analista Interno do sistema X, eu quero”, é fácil identificar um agrupamento natural de beneficiários - histórias de Clientes e de Analistas Internos. No novo formato, histórias como “Para que eu não precise abrir um chamado, eu como um Cliente quero etc” e “Para agilizar meu trabalho no atendimento a um Cliente, eu como um Analista Interno quero etc”, a leitura passa a ser mais funcional, focando nos objetivos das histórias, facilitando até o planejamento de sprints e releases. No último exemplo, em uma leitura rápida podemos definir um sprint focando nas histórias de diminuição de incidentes, e no seguinte em diminuição de tempo de atendimento.
• Personas - O uso de personas ajuda ainda mais a identificar o beneficiário da história, ao usar personagens fictícios como usuários. Para mais detalhes sobre as vantagens de se usar personas, vale ler o artigo na Wikipedia sobre o assunto.

Chelimsky sugeriu também uma variação no formato, para separar quem quer a funcionalidade de quem vai usá-la:

In order to <deliver some value>,
as a <role>,
I want that <some other role>
can <some feature>

Ou em uma tradução livre:

Para que <um valor seja obtido>,
como um <tipo de usuário>,
eu quero que <um outro tipo de usuário>
possa <ter algum benefício>

Pretendemos adotar essas idéias a partir de agora, em breve saberemos resultados.

Uma incerteza pode levar para duas direções: nos dias de hoje sabe-se muito bem como uma ação na bolsa de valores pode subir ou descer muitas vezes. Também nesse mercado existe uma forma de vender opções que garantam um preço mínimo de venda da ação (no caso de queda) ou comprar opções para um preço máximo de compra (no caso de uma alta).

Tube bem que é um pouco confuso essa coisa de misturar venda com compra, compra com venda, uma barbaridade, mas no fundo a idéia é gastar pouco agora para poder ganhar muito no futuro se a coisa der certo e, caso dê errado, como o gasto foi pequeno, perder pouco. O principal é que com isso podemos tomar as grandes decisões na hora certa, que é justamente quando a incerteza diminui.

A Microsoft fez isso com software, em 1988, quando apresentou na Comdex o DOS, uma versão do Windows, o OS/2 para IBM, uma versão do UNIX e as primeiras versões do Word e do Excel. Nessa época não se sabia qual plataforma iria prevalecer e Gates tinha a estratégia: cobrir todas as possibilidades. Ele jogou o jogo das opções e esperou o mercado emergir.

Processos de desenvolvimento de software podem ser vistos como uma forma de criar opções, permitindo que as decisões sejam adiadas para o momento em que o cliente sabe claramente o que quer. Não se pode confundir com falta de planejamento, mas com uma forma de deixar as coisas sempre prontas para se adaptarem e mudarem conforme a necessidade do cliente. A idéia é evitar tomar decisões erradas antecipadamente e ao mesmo tempo poder mudar rapidamente de rumo caso seja necessário.

Vale lembrar que pensar em opções tem seu custo: opções não garantem sucesso. Mas elas são uma excelente ferramenta em tempos de incertezas e devem ser usadas para tomar decisões olhando-se fatos, baseando-se em aprendizado e não em especulações.

Fonte: Lean Software Development - An Agile Toolkit

Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

Para ver a transcrição completa da apresentação, acesse o blog do Sylvestre Mergulhão.

Existem vários estudos científicos sobre pareamento. Uma das mais conhecidas estudiosas sobre o assunto é a Laurie Willians. Veja um vídeo que ela fez para mostrar a estudantes as vantagens de programação em pares:

Na Disneylândia, existem centenas de atores cujo único trabalho é fazer com que cada visitante tenha momentos maravilhosos. Os requisitos do que é um “momento maravilhoso” muda de visitante para visitante e o trabalho do ator é descobrir o que o visitante vê como experiência de qualidade e se certificar de que ele tenha essa experiência.

A visão de qualidade de serviço (e hoje software é serviço) leva em conta que cada cliente tem uma idéia diferente do que significa uma experiência de qualidade.

A diferença entre prover um serviço e produzir um produto é que, em serviços, atender a necessidade do cliente requer variações, enquanto que em linhas de produção variações são vistas como inimigas.

Problemas de software possuem várias soluções, em vários níveis, feitas por todos os membros do time. Não só os arquitetos estão envolvidos, mas todos os desenvolvedores. Escrever código envolve um entendimento profundo do problema, reconhecer padrões, experimentar várias abordagens, testar os resultados. Para isso, o melhor processo é aquele que consiste em ciclos curtos de aprendizado.

Fonte: Mary and Tom Poppendieck, Lean Software Development - An Agile Toolkit

Paul Glen, um consultor sobre liderança de geeks que disponibiliza vários artigos sobre o tema, escreveu um artigo entitulado “Sometimes It Takes a Tyrant to Support Collaboration” onde ele explica que muitas vezes a colaboração precisa ser defendida pelo líder em função de alguns tipos de comportamentos que são prejudiciais ao grupo. Ele dá também algumas formas de lidar com esse tipo de comportamento.

Eu gostaria de ir um pouco além e escrever sobre o que, ao meu ver, seriam as causas desses comportamentos inadequados que podem por em risco a colaboração em um time que adotou metodologias ágeis.

Há dois aspectos do trabalho de desenvolvimento de sistemas não colaborativo que tenho visto como sendo as raízes desses comportamentos inadequados:

• falsa sensação de poder: o trabalho técnico isolado dá uma falsa sensação de poder. Se somente uma pessoa sabe fazer determinado trabalho técnico, ela começa a se sentir indispensável e acredita que seu emprego está garantido. Por outro lado, gerentes não gostam de se sentir reféns. É natural que o gerente queira que mais pessoas conheçam o trabalho de outras pessoas do time para que, na ausência de uma dessas pessoas, o time não fique capenga. As metodologias ágeis pressupõem a colaboração, chegando ao ponto de usar a programação pareada. Isso é um risco para aqueles que acham que o fato de só eles saberem determinada parte do sistema é uma garantia de emprego.
• deficiências escondidas: o trabalho técnico isolado dá a oportunidade de esconder deficiências. Um desenvolvedor que tenha alguma deficiência, por não ter seu código revisto por outras pessoas pode facilmente esconder suas deficiências. Esse é outro cenário que um gerente não quer ver. Deficiênciais técnicas podem ser danosas não só do ponto de vista de produtividade, ou seja, algo demorar mais para ser feito do que deveria, mas também do ponto de vista de qualidade, pois código feito por desenvolvedores que escondem deficiências tem um potencial enorme de dar defeito. As metodologias ágeis, por meio da intensa colaboração que deve ser praticada, expõe as deficiências, o que também pode ser uma ameaça para alguns desenvolvedores.

Quando da implementação de metodologia ágil, pode acontecer de uma ou mais pessoas do time se sentirem ameaçadas pelos efeitos da colaboração em função dos aspectos acima e, numa situação como essa, acabarem optando por procurar outro emprego. Esse é um risco conhecido. Ken Schwaber, um dos criadores do Scrum, menciona que é esperado até 20% de turn over quando da implementação de metodologias ágeis. Ele também menciona que até 40% da gerência pode ir embora. Comentarei sobre o que muda na vida de um gerente quando o time adota metodologias ágeis em breve.

Por isso, apesar de soar estranho, às vezes é mesmo necessário ser um ditador para garantir que a colaboração prevaleça em seu time.

http://www.svpg.com/resources/Agile/Process.html

Dia 11 de Outubro: Encontro Ágil, organizado pela Agilcoop. O evento é gratuito e terá uma trilha básica para os iniciantes e uma trilha avançada para aqueles que já conhecem métodos ágeis e querem se aprofundar nos conceitos. Presenças confirmadas de Fábio Kon, Dairton Bassi e Vinicius Teles entre outros.

Dias 15 e 16 de Outubro: Rails Summit Latin America, organizado pela Locaweb. O foco do evento é a linguagem Ruby On Rails, mas sabemos que a comunidade Rails está fortemente ligada à comunidade ágil. Presenças de Chad Fowler, Fábio Akita, Danilo Sato, Fábio Kung.

Dias 23 e 24 de Outubro: Falando em Agile, organizado pela Caelum. O evento terá participações importantes de colaboradores da Thoughtworks, uma das primeiras empresas de consultoria a adotar métodos ágeis. Presenças de David Anderson, Alexandre Magno, Adail Retamal e Edmílson Miyasaki e muito mais.

• Automatização
• Refatoração
• Integração Contínua
• Desenvolvimento Orientado a Testes (TDD)
• Fases de Teste
• Mocks, Stubs
• Fixtures

Para falar sobre esses assuntos e todos mais que dizem respeito a testes, o QA (Quality Assurance) de uma das equipes da Locaweb criou o blog: Testes e Qualidade em ambiente ágil. Vale a pena ficar de olho nos próximos posts desse blog.

Como participante, a maior dificuldade foi escolher a melhor sessão a assistir. Em média havia 40 sessões simultâneas, sendo no mínimo umas 10 imperdíveis. A seguir alguns breves comentários sobre as sessões a que assisti:

• Expanding Agile Horizons: The Five Dimensions of Systems
  Mary Poppendieck
  Poppendieck começou questionando se Ágil pode ser somente mais uma “plank road” - uma excelente solução temporária que não sobrevive a longo prazo. Mas concluiu que até o momento não há indícios que as Metodologias Ágeis sejam temporárias - pelo contrário. Em seguida explicou as cinco dimensões que todo sistema deve ter - Propósito, Estrutura, Integridade, Tempo de Vida e Resultados.
• Introduction to Lean Software Development
  Alan Shalloway
  Shalloway descreveu as semelhanças entre o Desenvolvimento de Produto Lean e o Desenvolvimento de Software Ágil. Descreveu o Pensamento Lean, seus princípios - Valor, Fluxo de Valor, Fluxo, Puxar, Perfeição - e suas práticas - Otimizar o Todo, Eliminar Desperdícios, Construir Qualidade, Entregar Rápido.
• Agile Estimating and Planning
  Mike Cohn
  Cohn apresentou um resumo do livro Agile Estimating and Planning, uma das bíblias da Metodologia Ágil. Todos os conceitos básicos - Backlog de Produtos, Estimativas, Pontos de História, Planejamento de Sprints, Planning Poker, Velocidades, Releases etc - foram apresentados, além de algumas boas dicas para quem já aplica a metodologia.
• Embrace Uncertainty, Why In Agile Development Knowing What You Want May Be An Impediment to Getting It
  Jeff Patton
  Nessa palestra Patton mostrou como o conceito de Iteração Ágil pode ser mal interpretado ao ignorarmos incertezas. Ele demonstrou como desenvolver histórias pensando em Metas de Qualidade Iterativa - primeiro focar em Necessidade, depois Flexibilidade, depois Segurança, e por fim Luxo e Performance. Em outras palavras, se o release contiver 10 features, é melhor desenvolver o mínimo de cada uma das 10 em poucas iterações e depois melhorá-las do que desenvolver as 10 completas uma de cada vez. “Não existe iteração se você fizer uma única vez”.
• Value Stream Mapping - Extending Our View to the Enterprise
  Alan Shalloway
  Shalloway demonstrou como criar um Mapa de Fluxo de Valor - identificar as ações, identificar os tempos totais e de valor de cada ação, identificar retrabalhos, calcular a eficiência atual -, para enfim identificar o que fazer para melhorar cada ponto do processo e assim melhorar sua eficiência.
• Prioritizing Your Product Backlog
  Mike Cohn
  Cohn mostrou como priorizar histórias de produtos utilizando pesquisas de usuários aliado a diferentes técnicas de análise: Kano Analysis, Theme Screening, Theme Scoring, Relative Weighting etc.
• Defining the Role of Agile Manager - Theory and Practice
  Michael Spayd, Lyssa Adkins
  Spayd e Adkins mostraram os diferentes tipos de Liderança Ágil - Gerenciamento de Times, de Recursos, de Performance, de Resultados, de Portfolio, de Parceiros Internos, de Fornecedores -, explicaram seus papéis e responsabilidades, e sugeriram um “health check” para identificar sucessos e pontos de melhoria.
• Future Directions for Agile
  David Anderson
  Anderson questionou o quanto o próprio conceito de Agilidade se adapta e evolui com o tempo, e apresentou algumas novas tendências como Behaviour-Driven Development, Kanban Development e Real Option Theory.
• From High-Performing to Hyper-Performing Agile Teams
  Gabrielle Benefield, Jeff Sutherland, Rob Mee, Jason Titus
  Nesse debate os participantes relataram experiências de Ágil na PatientKeeper, Pivotal e Yahoo Mail, contando como melhoraram a performance de seus times e a qualidade de seus produtos.
• The Aikido of Agile Project Metrics
  Alan Goerner
  Goerner mostrou técnicas simples e eficientes para criar métricas em projetos ágeis, demonstrando indicadores de qualidade e prazo através da análise de velocidades de times e de quantidade de valor entregue.
• Energize Your Strategy Through Agility and Innovation
  Jochen Krebs
  Krebs comentou a importância da inovação através de métodos ágeis, buscando definir metas (maximização de valor, alinhamento estratégico) e evitando riscos (muitos projetos em paralelo, projetos errados em andamento, falta de visão).
• Starting a Kanban System for Software Engineering with Value Stream Maps and Theory of Constraints
  Corey Ladas
  Ladas deu dicas de como aplicar Lean em desenvolvimento de software, utilizando Kanban (cartões ou post-its), limitando trabalho em andamento e implementando um sistema puxado de atividades.
• 10 Ways to Screw Up with Scrum and XP
  Henrik Kniberg
  Kniberg apresentou as 10 “melhores” maneiras de estragar Scrum e XP: Acreditar no hype, não ter uma definição de “pronto”, não analisar velocidade, não ter retrospectivas, não ter comprometimento do time, ter débitos técnicos, não ter teamwork, não ter um product owner efetivo, mergophobia, não ter um backlog claro.

Conclusão

A oportunidade de assistir a sessões dos experts nesses conceitos foi excelente. A cada palestra assistida surgiam novas idéias de aplicação aqui na Locaweb. O ponto contra foi a enorme quantidade de palestras simultâneas, o que obrigou cada participante a abrir mão de centenas de sessões em favor de algumas poucas. Mas no geral vale a pena, e muito. O ganho que teremos na empresa com a aplicação das diversas idéias discutidas ali certamente será enorme.

Por exemplo, implantamos o Método Ágil de Remoção de Impedimentos com sucesso absoluto!

Suponha que você tenha uma lavanderia como a da figura.

Sua lavadora de roupas demora 45 minutos para limpar as roupas, a secadora 90 minutos para secar. Passar roupas demora 15 minutos. O gargalo desse processo está na secadora. Mesmo que você compre mais uma lavadora, não conseguirá ter mais roupas terminadas. Pode ser que tenha mais roupas lavadas temporariamente, mas terá que armazená-las em algum lugar durante um tempo até que a secadora termine o trabalho anterior.

A Teoria das Restrições diz que num sistema existe uma restrição (gargalo) por vez. Para melhorar o processo como um todo, você precisa encontrar onde está a restrição.

Como encontrar restrições e eliminá-las? O trabalho “empilha” nos pontos de restrição. A secadora é um gargalo. Para melhorar meu processo de lavagem, preciso aumentar a velocidade de secagem. Posso comprar uma secadora nova. Posso usar uma lavadora que centrifuga a roupa e diminui o tempo de secagem. Ou posso estender a roupa num varal:

Uma vez eliminada uma restrição,  outro gargalo surgirá no processo e deverá ser otimizado.

Em desenvolvimento de software os gargalos precisam ser identificados. No processo tradicional (cascata) temos:

Levantamento de Requisitos » Especificação » Implementação » Testes de Integração

Se existirem pilhas de funcionalidades não implementadas, o gargalo está na implementação. Se há muitas funcionalidades implementadas esperando para serem testadas, o gargalo está nos testes de integração e assim por diante. Esse modelo é conhecido como “push”. XP usa o modelo “pull”:

As histórias são especificadas em detalhes imediatamente antes de serem implementadas. Os testes são extraídos (pulled) da especificação. A interface é definida para satisfazer os testes. O código é escrito para satisfazer a interface e os testes. O design é refinado para atender às necessidades do código.

A Teoria das Restrições é interessante para ajudar a identificar qual é o seu processo. Vale ressaltar que o desenvolvimento de software é um processo humano, não uma fábrica. Não pense nas pessoas como caixas desse processo.

O uso de XP na empresa pode trocar o gargalo do processo para algum lugar fora da área de desenvolvimento de software. Por isso, XP pode afetar toda a empresa quando ela resolve adotar a metodologia. Por exemplo, se os programadores começarem a implementar mais rápido do que o time de produtos consegue especificar, o gargalo vai parar no time de produtos. Beck conta que algumas vezes equipes de software produtivas são tristemente despedidas e XP eliminado, pois traz a tona ineficiências em outras áreas da empresa. Daí a importância de ter o apoio de algum alto executivo que defenderá a metodologia perante outras áreas.

Em uma equipe ágil todos participam das estimativas tanto de histórias quanto de tarefas. Existem alguns problemas que costumam acontecer nessas situações:

• Os membros da equipe “copiam” a estimativa do desenvolvedor mais experiente, o que é equivalente ao caso clássico em que apenas o gerente de projeto ou arquiteto planejam.
• Discussões sobre a estimativa de um desenvolvedor começam antes que todos tenham dado sua opinião.
• Discussões demoradas acontecem quando todos (ou quase todos) estão concordando, mas ainda não perceberam.

Uma técnica interessante para evitar essas situações é o planning poker. A idéia soa um pouco esquisita a princípio, mas é extremamente eficaz. Nesse “jogo” cada desenvolvedor possui um conjunto de cartas com os valores possíveis para as estimativas. Existem alguns baralhos específicos para isso (como os da Crisp ou da Mountain Goat), mas é perfeitamente possível usar um baralho normal, ou até mesmo fazer o seu próprio. A estimativa de cada item se dá da seguinte maneira:

1. O item é apresentado brevemente para todos pelo moderador, que normalmente é o Product Owner ou o Scrum Master.
2. Os desenvolvedores fazem perguntas para entender melhor do que se trata o item, mas sem discutir detalhes de implementação. O foco aqui é entender o que deve ser feito, não como.
3. Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa.
4. O moderador pede para todos mostrarem as cartas.
5. Se todas as estimativas forem iguais, o que raramente acontece de primeira, a estimativa está feita e o processo volta ao início, para um novo item.
6. Se houver ao menos uma estimativa diferente, aqueles que apresentaram o(s) maior(es) e o(s) menor(es) valor(es) se justificam.
7. O processo se repete até todas as estimativas convergirem. Aqui vale o bom senso: se, por exemplo, 3 membros da equipe colocaram ‘5′ como estimativa, e um único desenvolvedor insiste em colocar ‘3′, o ideal é que ele abra mão.

A filosofia por trás desse processo é discutir os detalhes o mínimo possível (mas não menos do que isso), otimizando o tempo usado no planejamento. Todos apresentarem o mesmo valor significa que cada participante pensou em soluções muito semelhantes, portanto não há o que se debater. Quando há discrepância ouve-se apenas os extremos pois provavelmente algum deles enxergou uma solução ou uma profundidade do problema que os outros não viram. E o jogo não é simplesmente democrático (ou seja, vence a maioria) justamente por isso. Muitas vezes apenas um membro da equipe percebeu algo que os outros não viram. Ele pode saber de algo que justifique uma estimativa mais baixa que a dos outros, como a existência de um framework que torne a tarefa muito mais fácil de ser executada, por exemplo. Ou então pode ter algo que explique sua estimativa ser a mais alta como, por exemplo, ele ser o único a saber que a estrutura da base de dados legada é muito difícil de ser alterada.

Estimar não é nem de longe a atividade preferida de programadores (eles costumam preferir programar) e tempo gasto planejando é tempo que não é gasto desenvolvendo. Como planejar é necessário, qualquer técnica que agilize o processo é sempre bem vinda. Planning poker é uma técnica que atinge esse objetivo de forma surpreendente.

Nota: Quem observou os baralhos com atenção pode ter achado a escala usada nas cartas um pouco estranha. Em breve falaremos sobre ela.

Antes de mais nada, vale lembrar que o Scrum é totalmente flexível para mudanças fora do sprint (ou seja, o backlog de histórias pode ser atualizado a qualquer hora), mas durante o período do sprint, as histórias que entram em um sprint não devem ser alteradas. Contudo, sabemos que exceções acontecem, desde atrasos ou adiantamentos que requerem uma mudança de planejamento, até histórias que têm de ser re-priorizadas ou retiradas do sprint. Na prática, o ideal é a equipe e o PO analisarem cada caso para tomarem a decisão correta. Se existe algo urgente a ser feito, pode valer mais a pena a equipe desenvolver essa história e deixar de entregar outra do que seguir o plano inicial e deixar a história urgente para o sprint seguinte. Cada caso é um caso.

Vamos ver alguns exemplos. Abaixo seguem algumas situações que requerem mudanças durante o sprint, devido a atrasos, adiantamentos ou impedimentos. As situações são baseadas em um sprint imaginário de duas semanas, com um fim-de-semana no meio do sprint, tendo ao todo 100 horas. As análises serão feitas baseadas nos gráficos de burndown e burnup.

Sprint Atrasado

Situação A: A equipe está trabalhando no sprint, mas algo não está indo bem e faz com que a equipe atrase as atividades. O burndown mostra que no fim-de-semana faltavam por volta de 80 horas, ao invés das 50 previstas.

Existem duas explicações possíveis:

Explicação A1: A equipe não está trabalhando no sprint. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 20 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo - Estão recebendo tarefas fora do sprint? São urgentes? O que tem que ser feito para que a equipe volte a produzir?

Explicação A2: A equipe subestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, novas horas surgem (ex: uma atividade tinha 8 horas; equipe trabalha 4 horas e diz que ainda faltam mais 8 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo - Falta de planejamento? Falta de entendimento das histórias no dia do planejamento? Falta de experiência na linguagem ou ferramenta utilizada?

O que deve ser feito:
- As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que algumas histórias não poderão ser entregues nesse sprint, e o PO deve decidir quais podem ser retiradas. Com isso acontecendo, vemos no burndown a situação se normalizando, e no burnup a queda de horas a serem entregues.

O que não deve ser feito:
- Exigir que a equipe trabalhe mais horas sem cortar escopo: Isso oferece riscos à qualidade final do código.
- A equipe decidir quais histórias não entregar: Quem deve tomar essa decisão é sempre o PO.
- A equipe “deixar a bomba estourar” sem avisar o PO.

Sprint Adiantado

Situação B: A equipe está trabalhando no sprint, mas está indo mais rápido que o previsto e deverá terminar o sprint antes do esperado. O burndown mostra que no fim-de-semana faltavam por volta de 30 horas, ao invés das 50 previstas.

Existem duas explicações possíveis:

Explicação B1: A equipe está trabalhando mais do que o previsto. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 70 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo - Estão codificando sem seguir padrões, sem testes e sem qualidade? Estão fazendo pouco pareamento?

Explicação B2: A equipe superestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, outras horas são eliminadas (ex: uma atividade tinha 8 horas; equipe trabalha 2 horas e diz que faltam somente mais 2 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo - Falta de planejamento? Falta de entendimento das histórias no dia do planejamento?

O que deve ser feito:
- As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que o sprint está adiantado, e pedir mais histórias pra completar o sprint. Com isso, vemos no burndown a situação se normalizando, e no burnup o aumento de horas a serem entregues.

O que não deve ser feito:
- Terminar o sprint alguns dias antes: Em algumas situações pode ser aceitável, mas isso acaba quebrando a cadência da equipe, além de criar possíveis problemas de agendamento de salas, atualização de agendas etc.
- A equipe esconder a situação para trabalhar menos: Isso pode ser visto facilmente nos gráficos, e pode gerar desconfiança entre as partes envolvidas.

Mudança de Prioridade

Situação C: A equipe está trabalhando no sprint, mas um problema urgente surge e deve ser resolvido ainda durante o mesmo sprint.

O que deve ser feito:
- Conversar, sempre. A situação é tão urgente que não pode esperar 15 dias? A metodologia defende a idéia de que o sprint deve ser cancelado, já que o seu escopo está sendo alterado. Contudo, pode valer uma adaptação da metodologia: Fazendo uma renegociação, com a história urgente entrando no sprint, ao mesmo tempo em que outras histórias ainda não iniciadas saem, pode ser mais ágil do que propriamente cancelar o sprint e fazer um novo planejamento.
- Tratar a atividade como impedimento, e discutí-la na revisão de sprint: Esse problema poderia ter sido previsto e/ou evitado? Pode acontecer novamente no futuro?

O que não deve ser feito:
- PO insistir na história urgente sem negociar: “É rápido e vocês resolvem fácil…”
- Tratar a situação fora do sprint: Toda atividade realizada fora do sprint não aparece como resultado da equipe, e é importante saber se essa situação é frequente ou somente uma exceção.

Revisão de Sprint: Melhoria Contínua

Por fim, vale lembrar uma das práticas mais importantes das Metodologias Ágeis: Melhoria Contínua. Todas as situações acima devem ser discutidas na reunião de revisão de sprint, e decisões devem ser tomadas para que esses problemas não ocorram mais.

“Refatoração é uma técnica disciplinada para reestruturar um código fonte existente, alterando sua estrutura interna sem mudar o seu comportamento externo. Sua essência está em uma série de pequenas transformações que preservam comportamento. Cada transformação (chamada de refatoração) faz pouca coisa, mas uma sequência de pequenas transformações produz uma reestruturação significativa. Uma vez que cada refatoração é pequena, é mais improvável que algo dê errado. O sistema se mantém funcionando integralmente após cada refatoração, reduzindo as chances de o sistema sofrer um dano grave durante a reestruturação”

O objetivo de refatorar um código freqüentemente é manter o custo de manutenção constante ao longo do tempo. Refatorações trazem simplicidade, flexibilidade, clareza e algumas vezes desempenho ao código. Elas ajudam a manter a casa em ordem. Sem refatorações o código tende a ficar cada vez mais bagunçado e quanto maior a bagunça, mais difícil é de arrumar, ou seja, bagunça tende a gerar mais bagunça, até o limite em que o código fica ilegível. O custo de manutenção fica tão alto que a única solução é jogar tudo fora e começar do zero (isso é a última coisa que queremos num projeto de software, embora algumas vezes seja necessária).

Vale lembrar que cada refatoração é um passo trivial (ovo de colombo). O segredo está em conhecer com maestria o vocabulário das refatorações e saber aplicar cada uma delas no momento certo. Martin Fowler mantém um catálogo online de refatorações. Alguns exemplos de refatorações:

• Mudar o nome de uma variável
• Encapsular um código repetido num método
• Remover um parâmetro não utilizado em um método
• Generalizar um método (ex: raizQuadrada(float x) => raiz(float x, int indice))

Por onde começar?

Antes de começar a aplicar refatorações, é importante que seu código já tenha uma boa base de testes automatizados. Teste é uma outra importante prática da metodologia XP. Testes e refatorações são práticas irmãs. Uma refatoração pode ocasionalmente inserir um erro no sistema. Os testes ajudarão a detectar e corrigir esses erros.

Após aplicar uma refatoração você irá rodar todos os testes “apertando um botão” e terá como resultado uma luz verde (testes passaram) ou uma luz vermelha (testes não passaram).

Um pequeno exemplo

Vamos dar um pequeno exemplo de refatoração para tornar o conceito claro. Alguns outros exemplos podem ser obtidos nesses slides e no catálogo online do Martin Fowler.

O nome da refatoração que vamos usar é Substituir Variável Temporária por Busca. suponha que uma variável local está sendo usada para guardar o resultado de uma expressão. A idéia desta refatoração é trocar as referências a esta expressão por um método. Variáveis temporárias encorajam métodos longos (devido ao escopo). Com a refatoração, o código fica mais limpo e o método pode ser usado em outros locais.

Os passos para essa refatoração são:

1. Encontre variáveis locais que são atribuídas uma única vez
2. Declare temp como final
3. Compile (para ter certeza)
4. Extraia a expressão
5. Compile e teste

Exemplo de código:

double getPreco() {
    int precoBase = _quantidade * _precoItem;
    double fatorDesconto;
    if (precoBase > 1000) fatorDesconto = 0.95;
    else fatorDesconto = 0.98;
    return precoBase * fatorDesconto;
}

private int precoBase() {
    return _quantidade * _precoItem;
}

private int precoBase() {
    return _quantidade * _precoItem;
}

private int fatorDesconto() {
    if (precoBase() > 1000)
    return 0.95;
    return 0.98;
}

private int precoBase() {
    return _quantidade * _precoItem;
}

double getPreco() {
    return precoBase() * fatorDesconto();
}

private int fatorDesconto() {
    if (precoBase() > 1000)
    return 0.95;
    return 0.98;
}

private int precoBase() {
    return _quantidade * _precoItem;
}

double getPreco() {
    return precoBase() * fatorDesconto();
}

Conclusões

O uso de refatorações se torna mais e mais freqüente na medida em que o programador vai ficando mais experiente. As refatorações não devem ser usadas de qualquer modo, mas sim no momento certo e no lugar certo. Um bom programador surge só com muito trabalho e experiência. Qualquer um pode escrever código que o computador consegue entender. Bons programadores escrevem código que pessoas conseguem entender.

Uma boa dica de quando refatorar é ao identificar três repetições no código. Outro indício é quando você está tendo necessidade de escrever comentários para explicar o que um código faz. Algumas ferramentas como o Eclipse e o Visual Studio já possuem atalhos para as refatorações mais comuns como renomear método, extrair superclasse, introduzir objeto parâmetro. A experiência em refatorações trará grandes melhorias na qualidade do código de um programador. Em breve falaremos mais sobre Testes (automatizados), mais uma importante prática em que a Programação Extrema se baseia.

http://blog.seatecnologia.com.br/articles/2008/07/11/formula-scrum-no-spam

Muitos desenvolvedores detestam estimar pois às vezes eles são cobrados duramente pelas estimativas que fizeram. Alguns clientes e gerentes recebem mal a notícia de que “aquela tela de cadastro não vai ficar pronta até amanhã”. Isso normalmente acontece pois os desenvolvedores deram uma estimativa - algo como “acho que isso deve demorar 2 dias para fazer” - e, por falta de domínio em uma tecnologia ou algum mal entendido com relação ao negócio, não a cumpriram.

O erro conceitual aí é que não existe “não cumprir a estimativa”, já que uma estimativa é, por definição, um cálculo aproximado. É impossível dizer com exatidão qual o esforço envolvido em determinada atividade. E quanto mais genérica, abrangente e indefinida ela for, mais incerta será sua estimativa.

Metodologias ágeis não ignoram esse fato e por isso muitos autores sugerem diferenciar as estimativas de histórias (mais abrangentes) das de tarefas (mais específicas). Dado que histórias são breves descrições de coisas a serem feitas, a idéia é estimá-las em termos de tamanho, e não de tempo. Para isso, a primeira coisa a fazer é usar pontos de história como unidade de medida ao invés de horas. Como esse é um conceito artificial, um referencial é necessário.

Dessa forma, imagine que na primeira parte da reunião de planejamento o Product Owner apresente as seguintes histórias para a equipe:

• Um usuário se cadastra na loja virtual passando suas informações pessoais básicas (nome, RG, endereço, etc).
• Um usuário adiciona um produto a sua lista de desejos.
• Um diretor tem à sua disposição um relatório com informações consolidadas mensalmente das vendas feitas pela loja virtual.

Num primeiro momento os desenvolvedores precisam escolher uma história que servirá como base para as estimativas de todas as outras. Normalmente escolhe-se uma história que seja pequena e dá-se um valor para ela que funcionará como referência. No caso das histórias acima, um desenvolvedor pode dizer “é bem fácil fazer um cadastro desses, já fiz muitos deles, essa história vale 1 ponto”. Será então a partir dessa que as outras serão estimadas. Um outro desenvolvedor diz “acho que a história da lista de desejos é 3 vezes maior” (ou seja, ela vale 3 pontos) e outro diz que “a história para o diretor então vale 8, pois teremos que processar muitos dados diferentes, e formatação de relatórios nunca é fácil”.

Alguém pode se perguntar pra que serve estimar histórias dessa forma se isso não vai dar nenhuma noção de prazo nem de quantidade de horas a serem trabalhadas no sprint. Na verdade a função disso é mensurar, mesmo que de uma forma imprecisa, a capacidade de produção de uma equipe em cada sprint. Imagine que a equipe citada decidiu implementar as três histórias no sprint, mas só teve tempo para acabar a primeira (1 ponto) e a última (8 pontos). Isso resulta na velocidade da equipe, que nesse caso foi de 9 pontos de história. A velocidade é usada para saber o tamanho do próximo Selected Product Backlog, ou seja, ela indica quantos pontos de história a equipe provavelmente será capaz de produzir no sprint seguinte.

Imagine agora que no sprint seguinte a equipe pegou os 9 pontos de história, mas acabou tudo antes do final do sprint. Como a equipe ainda não pode começar um novo sprint, pois no Scrum o tamanho dos sprints não pode ser alterado, a única opção para que os programadores não fiquem ociosos é “puxar” mais uma história que está no backlog. Se essa nova história estiver estimada em 5 pontos, por exemplo, e for de fato finalizada, a velocidade da equipe será então 14. Essa será então a quantidade de pontos a serem colocadas no Selected Product Backlog seguinte.

Esse processo de usar a velocidade de um sprint para definir a carga do seguinte cria um forte comprometimento da equipe com a entrega das histórias de um sprint, já que ela sabe que não será cobrada nem julgada por nada além do que já foi capaz de fazer. Por outro lado, os clientes se sentem seguros, pois sabem o que podem esperar da equipe. Ou seja, a medida de velocidade é um instrumento muito valioso no desenvolvimento de uma relação de confiança mútua entre programadores e clientes.

E quanto às estimativas de tarefas? Com relação à segunda parte do planejamento não há novidades: horas são uma boa unidade de medida. Primeiramente, porque é bastante razoável um programador dizer que gastará 3 horas para criar a página de cadastro, 1 hora para escrever a query que insere os dados do cliente no banco e mais 1 hora para escrever os testes de aceitação automatizados dessa história. Depois porque são as horas que dão a carga de trabalho do sprint, sendo usadas para o traçado do burndown e do burnup.

Em breve daremos algumas dicas sobre técnicas e formas de organizar o processo de estimativa. Até lá.

No dia 27 de Junho, Sexta-feira, às 15h, faremos uma transmissão ao vivo sobre Programação eXtrema ou eXtreme Programming (XP).

O evento será apresentado por Daniel Cukier, líder de desenvolvimento de software na equipe de Telecom e autor do blog http://agileandart.blogspot.com, que falará sobre as principais vantagens dessa metodologia nas equipes de desenvolvimento de software.

A duração prevista é de 60 minutos e a participação é gratuita.

Para participar clique aqui, preencha o cadastro e faça a sua inscrição.

Se você já se cadastrou, clique na aba “Já sou cadastrado”, digite o seu e-mail e inscreva-se no evento.

Aproveite pois as vagas são limitadas!

Obs: o webcast é um projeto piloto da Locaweb e podem ocorrer instabilidades durante a sua apresentação.
Como sempre, sugestões são MUITO bem-vindas!