Comparativo entre os modelos SCRUM e XP
Publicado em 18 de fevereiro de 2011 por Vérlei Silva
INTRODUÇÃO
As metodologias de desenvolvimento que conhecemos hoje em dia como "metodologias ágeis" se baseiam nos mesmos princípios e no manifesto ágil. Sendo assim, as metodologias Scrum e XP podemos dizer que são bem parecidas em seu contexto.
SCRUM
Segundo Araujo aput Schwaber (2004), o Scrum é "uma metodologia ágil que busca uma forma empírica de lidar com o caos, em detrimento a um processo bem definido."
"A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento." (WIKIPEDIA, 2009).
Em ambientes complexos, Araujo aput Schwaber (2004), colocam que, um "processo bem definido tem sua probabilidade de sucesso drasticamente reduzida quando aplicado ao desenvolvimento de um produto." Para Schwaher (2004), uma das principais idéias do Scrum para atacar este problema é a "implantação de um controle descentralizado, que é capaz de lidar mais eficientemente com contextos pouco previsíveis."
Para tanto, segundo Araujo aput Beedle (2004), o gerenciamento é distribuiído através de três agentes independentes:
Product Owner: dito como responsável pelo retornos sobre o investimento do projetos, onde seu objetivo é garantir que os requisitos atendam o cliente;
Team Members ou Equipe: são os integrantes do projeto, ou seja, todos comprometidos em alcançar os objetivoss do projeto;
ScrumMaster: é o responsável pela equipe, ou seja, suas atribuições estão centradas em intermediar negociações entro o "Product Owner" e a equipe, bem como, ensinar e acompanhar a utilização do Scrum.
Para Araujo aput Schwaber (2004), embora a equipe tenha como principal objetivo entragar valor ao cliente, a equipe envolvida no Scrum deve utilizar de alguns métodos de apoio ao gerenciamento descentralizado e simples, sendo esses definidos como:
Product Blacklog: é uma lista de prioridades das estórias dos usuários passadas pelo Product Owner referente a que o projeto deve conter;
Sprint Backlog: é uma lista contendo as estórias mais relevantes com tempo estimado para duração, ou seja, início até o fim do sprint. Esse método é definido pela equipe com apoio do Product Owner, onde deve-se manter essa lista sempre atualizada;
Impediment List: é uma lista onde está contida todos os impedimento para a equipe alcançar os objetivos, onde tais impedimentos devem ser resolvidos pelo ScrumMaster;
Reports: são os relatórios que mostram o andamento do projeto, onde esses, são importantes para controle e tomada de decisão no projeto. Tais relatórios são definidos como: Sprint Burndown, Product Burndown, Bug History, dentre outros.
Ao término de um Sprint é entregue um Product Increment, ou seja, uma versão contendo todas estórias implementadas naquele Sprint.
Para a Teamsystem (2005) um "processo baseado em Scrum é extremamente simples e adaptativo. Em um projeto, existem basicamente as seguintes etapas":
Preparação: onde é definido o Business-Case, Product Backlog inicial dentre outras considerações ligadas ao projeto;
Sprints: são iterações realizadas, uma após a outra, para entregar gradativamento as estórias que compõem o projeto, onde dentro de cadas Sprint são realizadas algumas atividades como:
Scrum Planning Meeting: é dado como início de um Sprint, onde o Product Owner tem a possibilidade de atualizar e priorizar os itens do Product Backlog e definir junto da equipe um Product Increment que deverá ser entregue ao final do Sprint para o cliente;
Daily Scrum Meeting: é um reunião diária onde a equipe discute o projeto e seus possíveis impasses que estejam atrapalhando o processo de desenvolvimento;
Criação do Produc Increment: a finalização das estórias definidas para um determinado Sprint marca a realização de um Product Increment. Sprint Review: é apresentado pela equipe o Product Increment construído ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se atenda aos requisitos do cliente;
Sprint Retrospective: identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment, onde esse busca corrigir os problemas encontrados.
Atualização do Product Backlog: o Product Owner como responsável, tem que re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado motivado pelos mais prioritários itens.
Encerramento: é a última etapa da utilização do Scrum em um projeto, ou seja, após essa etapa, ocorre a finalização de todos Sprints onde é marcada pela entrega do projeto final.
XP (eXtreme Programming)
Segundo Kuhn, o XP é uma metodologia ágil centrada em equipes pequenas e médias onde irão ser desenvolvidos softwares com requisitos vagos e em constante mudança. Nesse modelo é adotado a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento do software.
A metodologia XP utiliza de quatro valores, como: comunicação, simplicidade, feedback e coragem, possibilitando a partir desses princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
O XP, segundo Kuhn, possui "um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar essa metodologia. Os valores já apresentados somados a estas práticas são um conjunto entrelaçado de boas atitudes", onde os pontos fracos de cada um são superados pelos pontos fortes de outros. Esse conjunto de atividades é apresentado como:
Jogo de Planejamento (Planning Game): o desenvolvimento é feito em iterações semanais, onde no início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades;
Pequenas Versões (Small Releases): é liberado pequenas versões funcionais do projeto, onde auxilia muito no processo de aceitação por parte do cliente, onde no qual, pode testar parte do sistema que está comprando;
Metáfora (Metaphor): busca facilitar a comunicação com o cliente e entender sua realidade, ou seja, buscar traduzir as necessidades do cliente para o significado que ele espera dentro do projeto;
Projeto Simples (Simple Design): é um princípio da XP onde busca atender as necessidades com a maior simplicidade possível. Um erro comum em adotar essa prática é a possibilidade de confusão dos programadores de código simples e código fácil, ou seja, nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto;
Time Coeso (Whole Team): onde é formada pela equipe de desenvolvimento e o cliente;
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;
Programação em Pares (Pair Programming): é a programação em par/dupla num único computador, ou seja, dessa forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs);
Padrões de Codificação (Coding Standards): é essencial que a equipe de desenvolvimento estabeleça regras para programar onde todos se adequem de forma a busca uma padronização para futuras manutenções no código;
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;
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;
Integração Contínua (Continuous Integration): ao produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema pois isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte.
CONCLUSÃO
Em relação as metodologias Scrum e Xp podemos dizer que as duas metodologias se completam, ou seja, práticas de desenvolvimento do XP essenciais para o desenvolvimento de um projeto de software complementam a metodologia Scrum e vice-versa.
REFERENCIAS
ARAUJO, Allan R. S.; SILVA, Juliana M.; MITTELBACH, Artur F.; Jynx Playware. Scrum: Novas Regras do Jogo. Disponível em: http://www.cin.ufpe.br/~sbgames/proceedings/files/Scrum.pdf. Acessado em: 29 ago. 2009.
BEEDLE, M Et. Al. Agile development with scrum. Editora Addsion-Wesley Press. Edição: 1ª. Ano: 2004.
KUHN, Giovane Roslindo; PAMPLONA, Vitor Fernando. Apresentado XP: Encante seus clientes com Extreme Programming. Disponível em: http://javafree.uol.com.br/artigo/871447/. Acessado em: 05 set. 2009.
WIKIPEDIA. Scrum. Disponível em http://pt.wikipedia.org/wiki/Scrum. Acessado em: 05 set. 2009.
SCHWABER, K. Agile project management with scrum. Microsoft Pressa. Edição 1ª. Ano: 2004.
TEAMSYSTEM. Scrum for Team System. Disponível em: http://www.scrumforteamsystem.com/en/default.aspx. Acessado em: 29 ago. 2009.
As metodologias de desenvolvimento que conhecemos hoje em dia como "metodologias ágeis" se baseiam nos mesmos princípios e no manifesto ágil. Sendo assim, as metodologias Scrum e XP podemos dizer que são bem parecidas em seu contexto.
SCRUM
Segundo Araujo aput Schwaber (2004), o Scrum é "uma metodologia ágil que busca uma forma empírica de lidar com o caos, em detrimento a um processo bem definido."
"A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento." (WIKIPEDIA, 2009).
Em ambientes complexos, Araujo aput Schwaber (2004), colocam que, um "processo bem definido tem sua probabilidade de sucesso drasticamente reduzida quando aplicado ao desenvolvimento de um produto." Para Schwaher (2004), uma das principais idéias do Scrum para atacar este problema é a "implantação de um controle descentralizado, que é capaz de lidar mais eficientemente com contextos pouco previsíveis."
Para tanto, segundo Araujo aput Beedle (2004), o gerenciamento é distribuiído através de três agentes independentes:
Product Owner: dito como responsável pelo retornos sobre o investimento do projetos, onde seu objetivo é garantir que os requisitos atendam o cliente;
Team Members ou Equipe: são os integrantes do projeto, ou seja, todos comprometidos em alcançar os objetivoss do projeto;
ScrumMaster: é o responsável pela equipe, ou seja, suas atribuições estão centradas em intermediar negociações entro o "Product Owner" e a equipe, bem como, ensinar e acompanhar a utilização do Scrum.
Para Araujo aput Schwaber (2004), embora a equipe tenha como principal objetivo entragar valor ao cliente, a equipe envolvida no Scrum deve utilizar de alguns métodos de apoio ao gerenciamento descentralizado e simples, sendo esses definidos como:
Product Blacklog: é uma lista de prioridades das estórias dos usuários passadas pelo Product Owner referente a que o projeto deve conter;
Sprint Backlog: é uma lista contendo as estórias mais relevantes com tempo estimado para duração, ou seja, início até o fim do sprint. Esse método é definido pela equipe com apoio do Product Owner, onde deve-se manter essa lista sempre atualizada;
Impediment List: é uma lista onde está contida todos os impedimento para a equipe alcançar os objetivos, onde tais impedimentos devem ser resolvidos pelo ScrumMaster;
Reports: são os relatórios que mostram o andamento do projeto, onde esses, são importantes para controle e tomada de decisão no projeto. Tais relatórios são definidos como: Sprint Burndown, Product Burndown, Bug History, dentre outros.
Ao término de um Sprint é entregue um Product Increment, ou seja, uma versão contendo todas estórias implementadas naquele Sprint.
Para a Teamsystem (2005) um "processo baseado em Scrum é extremamente simples e adaptativo. Em um projeto, existem basicamente as seguintes etapas":
Preparação: onde é definido o Business-Case, Product Backlog inicial dentre outras considerações ligadas ao projeto;
Sprints: são iterações realizadas, uma após a outra, para entregar gradativamento as estórias que compõem o projeto, onde dentro de cadas Sprint são realizadas algumas atividades como:
Scrum Planning Meeting: é dado como início de um Sprint, onde o Product Owner tem a possibilidade de atualizar e priorizar os itens do Product Backlog e definir junto da equipe um Product Increment que deverá ser entregue ao final do Sprint para o cliente;
Daily Scrum Meeting: é um reunião diária onde a equipe discute o projeto e seus possíveis impasses que estejam atrapalhando o processo de desenvolvimento;
Criação do Produc Increment: a finalização das estórias definidas para um determinado Sprint marca a realização de um Product Increment. Sprint Review: é apresentado pela equipe o Product Increment construído ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se atenda aos requisitos do cliente;
Sprint Retrospective: identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment, onde esse busca corrigir os problemas encontrados.
Atualização do Product Backlog: o Product Owner como responsável, tem que re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado motivado pelos mais prioritários itens.
Encerramento: é a última etapa da utilização do Scrum em um projeto, ou seja, após essa etapa, ocorre a finalização de todos Sprints onde é marcada pela entrega do projeto final.
XP (eXtreme Programming)
Segundo Kuhn, o XP é uma metodologia ágil centrada em equipes pequenas e médias onde irão ser desenvolvidos softwares com requisitos vagos e em constante mudança. Nesse modelo é adotado a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento do software.
A metodologia XP utiliza de quatro valores, como: comunicação, simplicidade, feedback e coragem, possibilitando a partir desses princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
O XP, segundo Kuhn, possui "um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar essa metodologia. Os valores já apresentados somados a estas práticas são um conjunto entrelaçado de boas atitudes", onde os pontos fracos de cada um são superados pelos pontos fortes de outros. Esse conjunto de atividades é apresentado como:
Jogo de Planejamento (Planning Game): o desenvolvimento é feito em iterações semanais, onde no início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades;
Pequenas Versões (Small Releases): é liberado pequenas versões funcionais do projeto, onde auxilia muito no processo de aceitação por parte do cliente, onde no qual, pode testar parte do sistema que está comprando;
Metáfora (Metaphor): busca facilitar a comunicação com o cliente e entender sua realidade, ou seja, buscar traduzir as necessidades do cliente para o significado que ele espera dentro do projeto;
Projeto Simples (Simple Design): é um princípio da XP onde busca atender as necessidades com a maior simplicidade possível. Um erro comum em adotar essa prática é a possibilidade de confusão dos programadores de código simples e código fácil, ou seja, nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto;
Time Coeso (Whole Team): onde é formada pela equipe de desenvolvimento e o cliente;
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;
Programação em Pares (Pair Programming): é a programação em par/dupla num único computador, ou seja, dessa forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs);
Padrões de Codificação (Coding Standards): é essencial que a equipe de desenvolvimento estabeleça regras para programar onde todos se adequem de forma a busca uma padronização para futuras manutenções no código;
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;
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;
Integração Contínua (Continuous Integration): ao produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema pois isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte.
CONCLUSÃO
Em relação as metodologias Scrum e Xp podemos dizer que as duas metodologias se completam, ou seja, práticas de desenvolvimento do XP essenciais para o desenvolvimento de um projeto de software complementam a metodologia Scrum e vice-versa.
REFERENCIAS
ARAUJO, Allan R. S.; SILVA, Juliana M.; MITTELBACH, Artur F.; Jynx Playware. Scrum: Novas Regras do Jogo. Disponível em: http://www.cin.ufpe.br/~sbgames/proceedings/files/Scrum.pdf. Acessado em: 29 ago. 2009.
BEEDLE, M Et. Al. Agile development with scrum. Editora Addsion-Wesley Press. Edição: 1ª. Ano: 2004.
KUHN, Giovane Roslindo; PAMPLONA, Vitor Fernando. Apresentado XP: Encante seus clientes com Extreme Programming. Disponível em: http://javafree.uol.com.br/artigo/871447/. Acessado em: 05 set. 2009.
WIKIPEDIA. Scrum. Disponível em http://pt.wikipedia.org/wiki/Scrum. Acessado em: 05 set. 2009.
SCHWABER, K. Agile project management with scrum. Microsoft Pressa. Edição 1ª. Ano: 2004.
TEAMSYSTEM. Scrum for Team System. Disponível em: http://www.scrumforteamsystem.com/en/default.aspx. Acessado em: 29 ago. 2009.