Métodos agéis scrum, xp e cascata

by - 16:18



METODO ÁGIL SCRUM
O que é Scrum?
É um método ágil para Gerenciamento de Projetos. Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). 
Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna concebeu, documentaram e implementaram o Scrum, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. 
Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

Como funciona?
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 necessite 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.
Mesmo que idealizado para ser utilizado em gestão de projetos de desenvolvimento de software ele também pode ser usado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.


Pontos Positivos?
O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint.
 O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. 
Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.
Scrum 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 estão envolvidas no projeto.
Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". 
Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Pontos negativos?
Um dos grandes defeitos do Scrum, porém, é a abordagem de "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Informações Extras
Características:
Cada sprint é uma interação que segue o (ciclo PDCA) e entrega incremento de software pronto.
Um backlog é conjunto de requisitos, priorizado pelo Product Owner (cliente);
Há entrega de conjunto fixo de itens do backlog em série de iterações curtas ou sprints;
Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros do time geralmente ficam em pé para não prolongar a reunião).
Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

Backlog de produto e backlog de sprint
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. 
O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. 
O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. 
O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos.


Planejamento de sprint
Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. 
O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. 
A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. 
A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. 
Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.


Scrum simplificado
Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível ("stealth"), usando os três passos:
Agende uma demonstração do software com seu cliente em um mês a partir de agora;
Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.


MÈTODO AGIL XP
O que é XP?
O XP é um conjunto bem definido de regras, que vem ganhando um grande número de adeptos e por oferecer condições para que os desenvolvedores respondam com eficiência a mudanças no projeto, mesmo nos estágios finais do ciclo de vida do processo, devido a quatro lemas adotados por seus seguidores, que correspondem a quatro dimensões a partir das quais os projetos podem ser melhorados. 
São eles: Comunicação, Simplicidade, FeedBack e Coragem.

Como funciona?
As Práticas do XP:
Para aplicar os valores e princípios durante o desenvolvimento de software, o XP propõe uma série de práticas. 
Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

1 - Jogo de Planeamento (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 Planeamento. 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 projecto é 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 colocadas em produção.

2 - Pequenas Versões (Small Releases):
A liberação de pequenas versões funcionais do projecto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.
As versoes chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

3 - Metáfora (Metaphor):
Procurar 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 de tempo real, como controle de tráfego aéreo.
É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.


4 - Projecto Simples (Simple Design):
Simplicidade é um princípio do 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 projecto.
Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.


4 - Projecto Simples (Simple Design):
Simplicidade é um princípio do 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 projecto.
Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.

5 - Time Coeso (Whole Team):
A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

6 - Testes de Aceitação (Customer Tests): 
São testes construídos pelo cliente em conjunto com analistas e testadores, para aceitar um determinado requisito do sistema.

7 - Ritmo Sustentável (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.

8 - Reuniões em pé (Stand-up Meeting):  
Reuniões em pé para não se perder o foco nos assuntos de modo a efetuar reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

9 - Posse Coletiva (Collective Ownership): 
O código fonte não tem dono e ninguém precisa ter permissão concedida para poder modificar o mesmo.
O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

10 - Programação em Pares (Pair Programming):  
É a programação em par/dupla num único computador. Geralmente a dupla é criada com alguém sendo iniciado na liguagem e a 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. Dessa forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs).
Com isto, procura-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

11 - Padrões de Codificação (Coding Standards): 
 A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras.
Dessa forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a  equipe possui 10 ou 100 membros.

12 - 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.

13 - Refatoração (Refactoring):
É um processo que permite a melhoria contínua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente.
Refactorizar melhora a clareza (leitura) do código, divideo em módulos mais coesos e de maior reaproveitamento, evitando a duplicaçao de código-fonte.

14 - Integração Contínua (Continuous Integration):
Sempre que realizar uma nova funcionalidade, nunca esperar uma semana para integrar na versão actual do sistema.
Isto só aumenta a possibilidade de conflitos e a possibilidade de erros.

Pontos Positivos?
Seguindo os requisitos expostos, anteriormente, o XP poderá trazer inúmeros benefícios ao mercado, de forma que o processo de  desenvolvimento se torne mais ágil e flexível.
Um desses benefícios é a agilidade no Planejamento (Planning Games) de não definir uma especificação completa e formal dos requisitos, ao contrário das metodologias tradicionais.
Outro é a produção de sistemas simples que atendam aos atuais requisitos, não tentando antecipar o futuro e permitindo atualizações freqüentes em ciclos bastante curtos.
A comunicação com o cliente, no XP, mostra-se mais intensa que nos métodos tradicionais, devendo o cliente estar sempre disponível para tirar as dúvidas, rever requisitos e atribuir prioridades, utilizando-se de sistemas de nomes, em vez de termos técnicos para facilitar a comunicação.
O código é sempre escrito em duplas, visando a melhorar a qualidade do código por um custo muito baixo, às vezes menor do que o desenvolvimento individual.
O código deve estar padronizado, para que todos na equipe possam entender o que está sendo escrito e possa ser validado durante todo o desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se saber se os requisitos estão ou não sendo atendidos.

Pontos negativos?
No entanto, o XP não deve ser aplicado a qualquer tipo de projeto.
O grupo de desenvolvedores deve formar uma equipe de 2 a 10 integrantes, que devem estar por dentro de todas as fases do desenvolvimento.
É necessário realizar vários testes, às vezes, alterar o projeto em decorrência destes.
A equipe tem de ser bastante interessada e pró-ativa, para assegurar a alta produtividade, e o cliente deve estar sempre disponível para tirar dúvidas e tomar decisões em relação ao projeto.

MODELO CASCATA
O que é Cascata?
O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüência pré-planejada e restrita.
O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros.
O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração.
Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.

Como funciona?
No modelo em cascata original de Royce, as seguintes fases são seguidas em perfeita ordem:

  • Elicitação de requisitos
  • Projeto
  • Construção (implementação ou codificação)
  • Integração
  • Teste e depuração
  • Instalação
  • Manutenção de software

Para seguir um modelo em cascata, o progresso de uma fase para a próxima se dá de uma forma puramente sequencial. Por exemplo, inicialmente completa-se a especificação de requisitos — elaborando um conjunto rígido de requisitos do software, embora as especificações dos requisitos reais sejam mais detalhados, em um procedimento para projeto.
O software em questão é projetado e um blueprint é desenhado para implementadores seguirem — este projeto deve ser um plano para implementação dos requisitos dados.
Quando e somente quando o projeto está terminado, uma implementação para este projeto é feita pelos codificadores.
 Encaminhando-se para o próximo estágio da fase de implementação, inicia-se a integração dos componentes de software construídos por diferentes times de projeto.
(Por exemplo, um grupo pode estar trabalhando no componente de página web da Google e outros grupos pode estar trabalhando no componente servidor da Google. Estes componentes devem ser integrados para juntos produzirem um sistema como um todo).
Após as fases de implementação e integração estarem completas, o produto de software é testado e qualquer problema introduzido nas fases anteriores é removida aqui.
Com isto o produto de software é instalado, e mais tarde mantido pela introdução de novas funcionalidades e remoção de defeitos.

Pontos Positivos?
O desenvolvimento é estruturado com sequência nas fases, todas as atividades são fundamentais e estão na ordem certa.
Um dos pontos fortes do modelo cascata está na ênfase dada a uma abordagem disciplinada, está na definição da documentação liberável em cada fase e está na recomendação de que todos produtos de cada fase sejam formalmente revisados.
Inerente a cada fase estão os procedimentos de verificação e validação (incluindo testes).
Grande parte do sucesso do modelo cascata está no fato dele ser orientado para documentação. No entanto deve-se salientar que a documentação abrange mais do que arquivo do tipo texto. Abrange representações gráficas e mesmo simulação.

Pontos negativos?
A principal desvantagem do modelo cascata é a dificuldade de acomodação das mudanças depois que o processo está em andamento. Uma fase tem de estar completa antes de passar para a próxima.
O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata.
Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses.
Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.

Referencia Bibliografia
SCRUM - http://www.oficinadanet.com.br/artigo/1971/metodos_ageis_scrum

XP - http://intranet.fia.edu.br/acesso_site/fia/academos/revista3/6.pdf

CASCATA-  http://www.refatorar.arquiweb.com.br/index.php?/Desenvolvimento/desenvolvimento-agil.html
http://pt.wikipedia.org/wiki/Modelo_em_cascata
http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html

You May Also Like

0 comentários