O SCRUM é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto, a quem diga que esta mais para um framework que uma metodologia, ou até mesmo mais para atitude que um processo.

Para que o SCRUM seja utilizado com êxito, cada pessoa envolvida deve cumprir com seu papel, seguindo corretamente todos os processos, e a fim de viabilizar, utilizar como apoio algumas das ferramentas que lhe são oferecidas. Entretanto, para que seja possível seguir corretamente todos os processos, primordialmente é necessário que todos estejam de acordo com a cultura envolvida.

Segue abaixo uma breve descrição sobre os três papeis relacionados ao SCRUM:

Product Owner: responsável por garantir o retorno de investimento, este deve conhecer as necessidades do cliente;

Scrum Master: responsável por remover os impedimentos do time e garantir o uso do SCRUM;

Time (Equipe): equipe de desenvolvimento multidisciplinar e auto-gerenciável, responsável por produzir produto com qualidade e valor para o cliente.

As ferramentas como: Product Backlog, Sprint Backlog, Burndown Chart e Scrum Board são de grande utilidade durante o ciclo de vida do SCRUM. Para um melhor entendimento, segue abaixo uma breve descrição:

Product Backlog: uma lista com todos os requisitos que o Product Owner deseja, sem muitos detalhes técnicos, essa lista é ordenada por prioridade pelo Product Owner;

Sprint Backlog: contém uma lista com as tarefas decompostas sobre os itens extraídos do Product Backlog que foi definida no Sprint Planning Meeting e que deverá ser entregue ao Product Owner.  Estas atividades não devem durar mais de 2 dias ou 16 horas;

BurnDown Chart: gráfico que mostra o trabalho da equipe dia a dia, avaliando assim se o Sprint está atrasado ou não. Caso o gráfico demonstre que a equipe acabará o Sprint antes, o Product Owner é consultado e novas funcionalidades são incorporadas àquele Sprint;

Scrum Board: é um quadro onde deverá contemplar todas as tarefas que serão realizadas dentro de um Sprint e listadas de acordo com as prioridades de cada item.

Existem três tipos de cerimônias no SCRUM, Sprint Planning Meeting, Daily Scrum Meeting e Sprint Review Meeting, estes três tipos de evento caracterizam bem o ciclo de vida de cada Sprint: início, meio e fim. Segue abaixo uma breve descrição sobre as cerimônias:

Sprint Planning Meeting: encontro para planejar o que será feito no Sprint. A equipe acessa o Product Backlog e detalha de forma mais ampla as atividades que serão executadas no Sprint de acordo com suas prioridades, avaliando tempo e complexidade. Após definido o que será feito, o Sprint Backlog é gerado;

Daily Scrum Meeting: encontros diários, com duração em média de 15 minutos, a idéia de ser uma reunião em que cada membro da equipe deve responder 3 perguntas: O que fiz ontem? O que farei hoje? O que está impedindo de que alcance o objetivo? Essa reunião é liderada pelo ScrumMaster;

Sprint Review Meeting: encontro realizado quando o Sprint chega ao fim. Este encontro é dividido em duas partes, na primeira parte é demonstrado ao ProductOwner quais atividades definidas no Product Backlog foram realizadas, o Product Owner lidera esse encontro e pode chamar todos os interessados no projeto. Após a demonstração o Product Owner e os interessados no projeto atualizam e repriorizam o Product Backlog, definindo assim o próximo Sprint. Finalizada essa primeira parte o ScrumMaster toma a liderança e começa uma reunião com a equipe, onde a equipe avalia o que foi realizado positivamente e negativamente no Sprint, também avaliam o que poderia ser mudado para melhorar o próximo Sprint.

O Sprint é um conjunto de tarefas a serem executadas em um determinado tempo. A Figura 1 ilustra o ciclo de vida do SCRUM.

Ciclo de Vida do SCRUM

Extreme Programming ou XP como é chamado é um processo de desenvolvimento de software baseado em valores de simplicidade, comunicação, feedback e coragem. O objetivo do XP é assegurar que o cliente receba o máximo de valor a cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.

Os quatro valores fundamentais em que o XP se baseia são:

Feedback: fazer com que o cliente conduza o desenvolvimento diariamente a fim de garantir que a equipe direcione toda a sua atenção para aquilo que de fato irá gerar mais valor;

Comunicação: evitar o gasto de um valioso esforço na tentativa de trocar informações por meios de extensos documentos escritos que freqüentemente são interpretados de forma incorreta ou incompleta;

Simplicidade: garantir que seja desenvolvido apenas o suficiente para atender as necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial;

Coragem: devido ao XP ser uma metodologia de software que se baseia em diversas premissas que contrariam os processos tradicionais de desenvolvimento de software, é preciso que todos da equipe tenham coragem para adotá-las e acreditar que, utilizando as práticas e valores do XP, serão capazes de fazer com que o software evolua com segurança e agilidade.

O XP tem alguns pontos fortes que auxiliam no processo de desenvolvimento, a citar:

Cliente Presente: a presença objetiva viabilizar a simplicidade dos processos, facilitar a comunicação com os desenvolvedores e permitir um ciclo continuo e rápido de feedback;

Jogo do Planejamento: reunião com o cliente a cada nova release a fim de definir quais funcionalidades devem ser implementadas de acordo com suas priorizações;

Stand Up Meeting: reunir com a equipe de desenvolvimento a cada manhã para avaliar o trabalho que foi executado no dia anterior e priorizar aquilo que será implementado no dia que se inicia;

Refactoring: é utilizado para manter sempre o software o mais simples possível de ser manipulado sem que estas alterações no código possam afetar as funcionalidades que já estão implementadas;

Código Coletivo: a idéia é que o código seja comunitário a todos os desenvolvedores, permitindo assim que todos possam alterar o código quando necessário sem ter que pedir autorização de outra pessoa;

Código Padronizado: a fim de permitir que o sistema seja o mais homogêneo possível, a equipe deve estabelecer padrões de codificação, viabilizando assim a facilidade de qualquer manutenção futura;

Metáfora: técnica para transmitir idéias de formas simples, através de uma linguagem comum que é estabelecida entre a equipe e o cliente;

Ritmo Sustentável: é recomendável que os desenvolvedores trabalhem apenas 8 horas por dia a fim de garantir o máximo de rendimento e permitir a produção de software com a melhor qualidade possível;

Design Simples: optar sempre pela simplicidade do design, viabilizando a agilidade durante o desenvolvimento, dado que o feedback deve ser rápido ao cliente;

Integração Contínua: a equipe de desenvolvimento deve garantir a integração de seus códigos com o restante do sistema diversas vezes ao dia;

Releases Curtos: visa à disponibilidade de funcionalidades rapidamente ao cliente para que ele possa utilizar o software no dia-a-dia e se beneficiar dele.

Desenvolvimento Guiado pelos Testes: visa o desenvolvedor escrever testes para cada funcionalidade antes mesmos de começar a codificá-las, possibilitando eles aprofundar o entendimento das necessidades do cliente;

Abaixo a Figura demonstra as práticas e os principais ciclos do XP:

Práticas e princípios do XP

A idéia da utilização do XP é voltada para projetos cujos requisitos são vagos e mudam com freqüência, desenvolvimento de sistema orientado a objeto, equipes pequenas e de preferência até 12 desenvolvedores. Este desenvolvimento deverá atender o modo iterativo ou incremental, objetivando que o sistema comece a ser implementado logo no início do projeto e ao longo do tempo adquirindo novas funcionalidades.