Agile Development: XP e Scrum em uma Abordagem Comparativa

Scrum

O SCRUM é uma metodologia ágil de trabalho onde é usada para estabelecer conjuntos de regras e práticas de gestão para conseguir o sucesso de um projeto. Com o foco no trabalho em equipe, ocorre uma melhora na comunicação e maximiza o apoio de todos, fazendo com que todos do time se esforcem e se sintam bem com que estão fazendo e isso acaba gerando mais para frente um aumento de produtividade.

Jeff Sutherland colocou em prática a primeira concepção do SCRUM na Easel Corporation em 1993 e em 1995, Ken Schwaber pegou essa metodologia e refinou baseando-se com sua experiência em desenvolvimento de sistemas e processos.

As principais características do SCRUM são:

• é um processo ágil para gerenciar e controlar o desenvolvimento de projetos;
• é um wrapper para outras práticas de engenharia de software;
• é um processo que controla o caos resultante de necessidades e interesses conflitantes;
• é uma forma de aumentar a comunicação e maximizar a cooperação;
• é uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto;
• é escalável desde projetos pequenos até grandes projetos em toda empresa.

O modo de organização no SCRUM é feito da seguinte forma (Figura 1):

1. Cria-se o backlog onde tem a lista de todas as funcionalidades que precisam ser desenvolvidas durante todo o projeto, junto com o stakeholder, onde precisa ser bem definido e detalhado no começo, listado e ordenado por prioridade do que é mais importante;
2. Com o backlog pronto, cria-se o sprint backlog, onde se decide o tempo necessário (dentro dos 30 dias) para criar a funcionalidade requisitada;
3. Depois de todo o planejamento, os itens do backlog são divididos nas equipes e entra no sprint que pode durar de 2 a 4 semanas.
4. A cada 24 horas tem uma reunião com os membros de equipes e questões devem ser respondias como:
   - O que você fez desde a última reunião?
   - O que te impede de continuar?
   - O que vai fazer até a próxima reunião?
5. Ao termino do sprint as funcionalidades requisitadas são demonstradas.

Figura 1. Descrição do processo scrum

O SCRUM, como é um método ágil, e os métodos ágeis acabam tendo várias semelhanças, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles têm a raiz fundamentada em um manifesto ágil.

XP - eXtreme Programming

XP foi criado por Kent Beck quando trabalhava na Chrysler Comprehensive Sistema de Compensação (C3) no projeto da folha de pagamento. Quando Beck tornou-se C3 líder do projeto em março de 1996, ele começou a refinar o método de desenvolvimento usado no projeto e logo em seguida ele escreveu um livro. E em outubro de 1999, a Extreme Programming foi publicada. Em fevereiro de 2000, a Daimler-Benz adquiriu a Chrysler e acabou cancelando o projeto C3.

O XP é uma metodologia ágil de desenvolvimento de softwares focada na agilidade de equipes e na qualidade dos projetos e tem como seus valores a simplicidade, o feedback, a comunicação, a coragem, o respeito.

O XP tem como seus princípios básicos o feedback rápido, a simplicidade, a ideia de abraçar mudanças, fazer um trabalho de qualidade e aceitar mudanças incrementais.

Uma frase onde Vinícius Teles fala na TDC 2008 é muito interessante onde ele demonstra claramente que a simplicidade é fundamental no projeto, e a frase que ele diz é:

"Na hora do desenvolvimento do software, para aplicar os princípios e valores, o XP sugere uma série práticas porque há uma grande confiança na união entre elas pois os pontos fracos de cada uma são cobertos pelo ponto forte das outras."

Segundo Kent Beck, as práticas são as seguintes (Figura 2):

• Jogos de Planejamento(Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
• Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.
• Metáforas (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
• Projetos Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.
• Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.
• Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.
• Ritmos Sustentáveis (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
• Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
• Posses Coletivas (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
• Programações em Pares (Pair Programming): É a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
• Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
• Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.
• Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;
• Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Figura 2. Práticas do XP

Comparação entre scrum e eXtreme programming

O SCRUM, como é um método ágil, e os métodos ágeis acabam tendo várias semelhanças, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles tem a raiz fundamentada em um manifesto ágil.

O SCRUM é uma forma de gestão ampla para projetos que não depende da área de conhecimento. Já o XP tem sua aplicação mais restrita, focada basicamente no mundo de desenvolvimento de sistemas de softwares.

Entretanto, quando usamos o SCRUM como forma de gestão e para criação de sistemas de software, muitas das práticas contidas no XP são de grande competência, como por exemplo a criação de testes automatizados ou o uso de refatoração de código para que um trecho de código funcional seja alterado buscando um ganho de qualidade e garantindo que a manutenção futura seja simplificada.

Execução de um Projeto com Scrum

A empresa em que foi aplicado o estudo de caso se enquadra no ramo de desenvolvimento de software. É uma entidade civil sem fins lucrativos que se orgulha por ser uma das referências nacionais em qualidade e eficiência na área de tecnologia da informação e comunicação. Possui ISO 9001:2008 e CMMI nível 5 e busca a melhoria contínua dos seus processos. O projeto na qual foi desenvolvido era para a plataforma de hardware Windows XP profissional, a ferramenta de desenvolvimento era o Microsoft Visual Studio 2008, a ferramenta de banco de dados SQL Server 2005, a ferramenta de análise e projeto o Enterprise Architect, ferramenta de acompanhamento de bugs JIRA, sedo o mesmo produzido para a plataforma desktop. O projeto possuía 221 pontos de caso de uso técnicos (TUCP) e era enquadrado na modalidade de Fábrica de Solução, na qual são projetos em que a equipe do projeto trabalha com a equipe do cliente desde a etapa inicial de avaliação de necessidades e concepção de requisitos, ajudando o cliente a gerar uma solução de alto valor agregado para seu negócio.

Visando a necessidade da melhoria no gerenciamento dos projetos resolveu-se aplicar Scrum em um projeto e analisar o desempenho de produtividade do projeto com o emprego desta metodologia.

Aplicar Scrum traz várias mudanças, principalmente culturais na empresa. Para o início da utilização do Scrum, como primeiro passo aplicou-se um treinamento para todos os colaboradores para que todos pudessem conhecer as atividades a serem desempenhadas na nova metodologia de gerência de projeto e assim nivelar o conhecimento adquirido.

No treinamento foram repassados os conhecimentos acerca do ciclo do Scrum e mostrado em detalhes cada evento a ser executado com o emprego da metodologia ágil, assim como as vantagens e facilidades proporcionadas pelo Scrum.

O segundo passo foi realizar o planejamento inicial do projeto. Cada Sprint teve sua duração definida em três semanas, assim a cada rodada tinha que ser entregue uma parte incremental do produto testado e funcionando. No total, foram definidas cinco Sprints para a conclusão do projeto.

A princípio, foram definidas as seguintes atividades a serem realizados no projeto e estas foram enquadradas no Backlog:

• Levantamento dos requisitos.
• Especificação dos requisitos.
• Análise e Projeto.
• Especificação de testes.
• Revisão técnica.
• Implementação.
• Testes.
• Correção.
• Entrega.

Em seguida, o plano do projeto foi montado e apresentado ao cliente. O cliente foi envolvido inicialmente com participação ativa de forma remota para a definição das prioridades das atividades. Para cada Sprint realizou-se um Sprint Planning Meeting, ou seja, uma reunião para planejamento da Sprint, de modo que pudesse definir dentre as atividades do Backlog aqueles que seriam executadas na Sprint. Além disso, a cada início do dia o gerente do projeto realizava a Daily Meeting, ou seja, a reunião diária para acompanhamento das atividades do projeto (atividades a fazer, atividades finalizadas, atividades em andamento), assim como para a identificação dos impedimentos ocorridos no dia anterior para que fossem resolvidos o mais rápido possível. Estas reuniões tinham duração de no máximo 15 minutos.

O próximo passo foi executar cada Sprint. A cada entrega, ou seja, decorridos três semanas, o time realizou a reunião de revisão (Sprint Review) para apresentação do produto realizado na Sprint. Após esta reunião fazia-se uma reunião de retrospectiva (Sprint Retrospective) para demonstrar as lições aprendidas. Nestas reuniões, foi possível identificar os principais desafios enfrentados pela equipe. Além disso, ao final de cada Sprint, o gerente realizou as medições dos indicadores de desempenho de produtividade do projeto.

Resultados Práticos do Uso do Scrum

DESEMPENHO DOS INTEGRANTES

Os resultados form satisfatórios, obteve um satisfação por todos os integrantes do projeto na aplicabilidade do Scrum. O projeto foi entregue dentro do prazo e do orçamento melhor do que os previstos.

Constatou-se uma maior participação do cliente no processo de desenvolvimento do software proporcionando um acompanhamento em alto nível do andamento das atividades realizadas. Além disso, observou-se a satisfação do cliente na solicitação das modificações dentro de prazo hábil para realizá-las, além do recebimento de funcionalidades totalmente implementadas no final das Sprints. Um fator característico do Scrum que apresentou-se satisfatório para o cliente trata-se do tempo fixo estimado para as Sprints.

A equipe evoluiu profissionalmente se tornando mais segura com relação à capacidade de estimativa e autogerenciamento, descartando a necessidade de atribuição de tarefas pelo gerente. Esse crescimento foi gradativo no decorrer das Sprints.

Aumentou também a segurança no que estava desenvolvendo e no conhecimento dos requisitos. Isto proporcionou um menor retrabalho por não desperdiçar tempo no desenvolvimento de requisito confuso. O aumento da segurança aumentou o comprometimento e o foco com o projeto. Além do mais, a equipe, depois de experimentar o Scrum, quer sempre que possível, seguir esta prática nos novos projetos.

O gerente apontou a facilidade em solucionar os impedimentos do projeto, haja vista que os mesmos eram identificados precocemente e não apresentava impactos nas demais atividades. Todos os integrantes tinham conhecimento do impedimento e através de uma ação em conjunto o impedimento era solucionado o mais rápido possível. Além disso, o gerente relatou a facilidade de extrair informações gerenciais do projeto através dos quadros adotados pela metodologia ágil, pois conforme é relatado por Schawber (2004) o Scrum oferece um framework e um conjunto de práticas que guardam tudo visível. Isto permite aos participantes do Scrum saber exatamente o que está acontecendo e fazer no local os ajustes para manter o projeto na direção dos objetivos desejados.

INDICADORES DE DESEMPENHO DE PRODUTIVIDADE DO PROJETO

Como mencionado anteriormente, o gerente realizou o acompanhamento do desempenho da produtividade do projeto. A Figura 3 a seguir apresenta a tabela de produtividade da equipe no projeto.

Figura 3. Produtividade da equipe

A figura ilustra os principais processos de engenharia executados no desenvolvimento do software e a produtividade planejada e realizada para cada um desses processos. Além disso, são expressos valores de produtividade para “Produtividade dos processos com retrabalho” que retrata a produtividade do projeto contando o esforço gasto com o retrabalho de alguma atividade; “Produtividade dos processos sem retrabalho” que representa a produtividade do projeto sem considerar o esforço gasto com o retrabalho das atividades; e “Produtividade geral” que significa a produtividade do projeto expressa em um único valor.

Por normas de sigilo, a forma como é calculada a produtividade não foi divulgada pela empresa. No entanto, alguns fatores nos permitem a análise destes dados.

A produtividade planejada representa o nível de produtividade planejado pelo gerente de acordo com as características do projeto e representa o limite máximo a ser atingido.

Quando a produtividade realizada é expressa abaixo da produtividade planejada, significa dizer que a equipe apresenta boa produtividade e que está realizando suas atividades com um esforço inferior ao planejado. Deste modo, quando menor a produtividade realizada, melhor está sendo a produtividade da equipe.

Como se pode constatar pela análise da Tabela 1 acima representada, em todos os processos a equipe apresenta uma boa produtividade, haja vista que todos os valores expressos na “Produtividade realizada” são inferiores aos valores da “Produtividade planejada”. Uma análise a respeito da diferença entre “Produtividade planejada” e “Produtividade realizada” é apresentada na Figura 4.

Figura 4. Gráfico da Produtividade da equipe

No gráfico acima representada, é possível verificar que além da produtividade realizada apresentar-se inferior a produtividade planejada em todos os processos, o processo de “Análise e Projeto” apresenta uma melhor produtividade se comparado o valor aos demais processos. Em contrapartida, o processo de “Testes” apresenta uma boa produtividade, no entanto, bem próxima a produtividade planejada.

Com o aumento da produtividade da equipe, ou seja, a execução das atividades em menor tempo que o estimado, o projeto foi entregue em tempo menor que o planejado. No geral, foram planejados 5 meses para a execução total do projeto e o projeto foi realizado em 4 meses. Isto proporcionou uma maior satisfação do cliente assim como o aumento do lucro da empresa.

Na Figura 5 temos o ciclo de vida dentro do XP.

Figura 5. Ciclo de vida

Através desta pesquisa e análise podemos concluir a importância da utilização destas ferramentas que auxiliam no desenvolvimento de projetos garantindo sua eficácia e alta qualidade.

Podemos notar que devido a evolução da tecnologia esses processos se tornaram complemento um do outro tornando-se ótimas ferramentas de trabalho, sendo que o XP é utilizado para desenvolvimento e o SCRUM para um framework.

Scrum é um processo de desenvolvimento iterativo para gerenciamento de projetos, usando para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer.

É um processo eficaz pois pode ser aplicado em qualquer projeto no qual um grupo de pessoas necessita trabalhar em grupo para atingir um objetivo em comum, além disso, permite a criação de equipes auto organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estarão envolvidas no projeto.

Para garantir o sucesso na realização do processo e projeto deve haver um planejamento de sprint onde o Product Owner, o Scrum Master e a Equipe irá decidir no que irá trabalhar, planejando a arquitetura e o design de como backlog deverá ser implementado. É importante que ocorram todas as etapas do processo como todas as reuniões de planejamentos diários, as de revisão, as retrospectivas momento em que todos refletem sobre a sprint passada.

Já a metodologia de desenvolvimento XP consiste em usar métodos simples, onde o trabalho é feito em duplas utilizando aplicações simples, design simples focando apenas no que o cliente necessita neste momento, não havendo importância com futuras modificações do sistema, as mudanças tem que ser feitas por partes , quando o aplicativo se torna obsoleto não se refaz o mesmo, simplesmente desenvolve-se um novo sistema. Existe também um respeito entre a equipe onde todos são valorizados da mesma forma, sendo assim um incentivo para o desenvolvimento de alta qualidade.

Cada parte do código é testada antes de passar para o próximo recurso, verifica-se que o requisito é realmente o que o cliente deseja. A comunicação entre o cliente e o programador no planejamento, o feedback onde a cada parte do desenvolvimento é testado e se o cliente desejar fazer alguma modificação, os programadores adicionam tempo extra para concluir o projeto.

São através destes processos que é possível entregas frequentes e intermediárias de funcionalidade 100% desenvolvidas, diminuição de riscos desenvolvidos pelas equipes, transparência no planejamento e desenvolvimento, garantindo eficiência e evolução na realização do projeto.