0

Metodologias ágeis

Marcelo Silva
Marcelo Silva

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):


   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;

   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;

   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.

   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?

   Ao termino do sprint as funcionalidades requisitadas são demonstradas.


descrição do processo scrum

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";


   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.


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.




Referências


   Bissi, W. (jan/jun de 2007). SCRUM - METODOLOGIA DE DESENVOLVIMENTO ÁGIL. Fonte: Grupo Integrado

   Desenvolvimento Agil. (2013-2014). Extreme Programming. Fonte: Desenvolvimento Agil

   Enucomp. (2012). Gestão de Projeto com Scrum: Um Estudo de Caso. Fonte: Enucomp

   Ferreira, D., Costa, F., Alonso, F., Alves, P., & Nunes, T. (S/Data). SCRUM - Um Modelo Ágil para Gestão .

0
27

Comentários (0)

None

Brasil