Metodologias Ágeis de Desenvolvimento (Locaweb)

A metodologia XP não resolve todos os problemas de uma organização. O principal foco dela é no desenvolvimento de software. A Programação Extrema não resolverá problemas das áreas de marketing, vendas ou recursos humanos. Porém a adoção dessa metodologia acarreta mudanças em toda empresa. Vamos mostrar porque isso acontece. Para isso usaremos o exemplo da Teoria das Restrições, mostrada no livro Extreme Programming Explained - Second Edition (Kent Beck).

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.

Essa semana teremos mais um webcast sobre Metodologias Ágeis, dessa vez com enfoque na Programação eXtrema (XP). Segue o post publicado no blog oficial da Locaweb:

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!

A Programação Extrema é uma das metodologias ágeis mais conhecidas. Foi criada por Kent Beck e ganhou notoriedade a partir da OOPLSA 2000 (a maior conferência internacional de Orientação a Objetos). A primeira reação a XP foi bem controversa. Alguns amaram (normalmente os programadores), outros odiaram. Em XP, o bom programador se sente mais livre para fazer o que faria se não existissem regras. Ao mesmo tempo, XP obriga o “mau” programador a se comportar de forma similar ao bom.

A Programação Extrema é baseada em cinco valores, alguns princípios e várias práticas. Ela se destina a times de até dez programadores, projetos de curto e médio prazo.

Os cinco valores de XP são:

1. Comunicação – para um projeto de sucesso é necessária muita interação entre os membros da equipe, programadores, cliente, treinador. Para desenvolver um produto, o time precisa ter muita qualidade nos canais de comunicação. Conversas cara-a-cara são sempre melhores do que telefonemas, e-mails, cartas ou fax.
2. Feedback – as respostas às decisões tomadas devem ser rápidas e visíveis. Todos devem ter, o tempo todo, consciência do que está acontecendo.
3. Coragem – alterar um código em produção, sem causar bugs, com agilidade, exige muita coragem e responsabilidade.
4. Simplicidade – para atender rapidamente às necessidades do cliente, quase sempre um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo que os programadores constróem.
5. Respeito – todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso mantém o trabalho energizado.

Em XP existem quatro papéis principais:

• Programadores - foco central da metodologia, sem hierarquia.
• Treinador (ou coach) - pessoa com mais experiência no time, responsável por lembrar os outros das regras do jogo (que são as práticas e os valores de XP). O treinador não precisa necessariamente ser o melhor programador da equipe e sim o que mais entende da metodologia XP.
• Acompanhador (ou tracker) - responsável por trazer para o time dados, gráficos, informações que mostrem o andamento do projeto e ajudem a equipe a tomar decisões de implementação, arquitetura e design. Algumas vezes o próprio coach faz papel de tracker. Outras o time escolhe sozinho quem exercerá este papel.
  
• Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às dúvidas dos programadores.

Práticas de XP

A parte principal da metodologia são as Práticas. Para descrevê-las precisaremos de alguns posts. Existem vários livros que falam das práticas de XP e podem ajudar o leitor a obter maiores detalhes. Os principais são os escritos pelo próprio criador da metodologia (Extreme Programming Explained: Embrace Change). Neste post faremos um breve resumo das práticas e em breve entraremos nos detalhes de algumas delas.

• Planejamento - assim como no Scrum, existe uma fase de planejamento, quando desenvolvedores e cliente se encontram para priorizar e estimar histórias.
• Fases Pequenas - cada fase é chamada de iteração (Sprint no Scrum). Elas devem durar no máximo 30 dias, mas o ideal é que seja 15 ou até 7 dias.
• Design Simples - seguindo o valor simplicidade, os projetos devem ser simples e atender a cada passo somente o que foi pedido. Nada de matar formigas com canhão!
• Testes - todo desenvolvimento inclui testes. Kent Beck diz que código sem teste não existe. Os testes devem ser escritos de preferência antes do desenvolvimento (TDD - test driven development) e sempre devem rodar de forma automatizada.
• Refatoração - é um conjunto de técnicas para modificar o código do sistema sem alterar nenhuma funcionalidade. O objetivo é simplificar, melhorar o design, limpar, enfim, deixar o código mais fácil de entender e dar manutenção.
• Programação Pareada - em XP dois programadores sentam juntos no mesmo computador e programam juntos. Enquanto um programador digita, o outro observa, pensa em melhorias, alternativas. Falaremos mais sobre a programação em pares e seus benefícios
• Propriedade Coletiva - O código fonte não pertence a um único programador. Todos da equipe são responsáveis. Todos alteram código de todos (mas sempre rodando os testes para se certificar que nada foi quebrado)
• Integração Contínua - depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada entre todos os desenvolvedores. Quanto mais freqüente for essa integração, menores são as chances de conflitos de arquivos que vários programadores alteram simultaneamente
• Semana de 40 horas - programar é uma atividade intensa e que não rende se o programador não estiver descansado e disposto. Por isso, 40 horas de trabalho por semana é essencial para a saúde do time.
• Cliente Sempre Presente - o cliente não é alguém de fora, mas sim um membro da equipe. Ele deve estar sempre disponível e pronto para atender às dúvidas dos desenvolvedores.
• Padronizações - se todo o time seguir padrões pré-acordados de codificação, mais fácil será manter e entender o que já está feito. O uso de padrões é uma das formas de reforçar o valor comunicação.

São muitas práticas! Para colocá-las em produção é preciso paciência e conhecimento. O ideal é começar com 2 ou 3 delas e ir inserindo lentamente as outras, sentindo as dificuldades, refletindo e avaliando as mudanças. Muitas das práticas só serão aprendidas na prática (ha ha! por isso chamam práticas). Aos poucos falaremos mais sobre cada uma delas e daremos dicas de como podem ser aplicadas em conjunto. O mais legal é que as práticas se sustentam: uma ajuda a outra a tornar o projeto mais eficiente e ágil.

Dia 26/junho às 15h farei uma palestra online sobre XP. O endereço para quem quiser se inscrever é:
http://www.locawebcast.com.br/webcast.aspx