Abordagem

Histórico de Revisões

Autores	Data	Descrição	Versão
Maria Luiza	25/08/2018	Definição, Recursos incorporados e Justificativa do Scrum e Introdução	0.0.1
Adrianne Alves	25/08/2018	Revisão de escrita e adição de um tópico de justificativa	0.0.2
João Pedro Sconetto	25/08/2018	Adição e definição do componente relacionado ao kanban, e confecção dos tópicos de XP	0.0.3

Sumário

1. Introdução
2. Scrum
   2.1. Definição
   2.2. Recursos Incorporados
   2.3. Justificativa
   
3. Kanban
   3.1. Definição
   3.2. Recursos Incorporados
   3.3. Justificativa
   
4. EXtreme Programming
   4.1. Definição
   4.2. Recursos Incorporados
   4.3. Justificativa
   

1. Introdução

Este documento tem o propósito de explorar as metodologias selecionadas para compor a abordagem que será utilizada neste projeto. Assim, serão relacionadas as definições de cada uma delas, destacando os recursos incorporados ao projeto e a justificativa dessa escolha. A fim de definir um processo de desenvolvimento para o projeto.

2. Scrum

2.1. Definição

O Scrum é um framework de gerenciamento incremental proveniente da metodologia ágil que colabora na organização e planejamento em um projeto de software. O maior benefício dele deve-se ao trabalho complexo que envolve criação e colaboração de conhecimento, como novos produtos desenvolvimento, onde há uma proximidade com o cliente.

Seu gerenciamento é incremental, com ciclos semanais chamados de Sprint que podem variar de 1 a 4 semanas. A Sprint representa um Time in Box em que um conjunto de tarefas devem ser executadas e concluídas no tempo determinado, entregando uma funcionalidade que seja significativa para o cliente.

Durante a Sprint são feitas reuniões diárias, Daily Scrum ou Daily Meeting, para que a equipe esteja alinhada quanto ao que está ocorrendo com cada tarefa. Todas as funcionalidades com as tarefas que a equipe deve realizar durante a Sprint deve estar no Product Backlog, no formato de uma "lista". Desta são escolhidas tarefas a serem realizadas na sprint, compondo o Sprint Backlog.

A metodologia define três papéis: Scrum Master, exercendo a liderança do processo, através da solução de entraves, e garantindo os valores do projeto; Product Owner, podendo ser o cliente ou um representante que conheça bem o domínio e requisitos do projeto e; Team Scrum, todo o time de desenvolvimento.

O Scrum ainda emprega algumas práticas de reuniões como a Sprint Planning Meeting, que consiste em reuniões de planejamento com o Product Owner, o Sprint Review Meeting, correspondente à revisão da Sprint com todo o time e a Sprint Retrospective ou restrospectiva da Sprint, que fornece a oportunidade ao time de destacar os pontos fortes e fracos daquela Sprint.

2.2. Recursos Incorporados

• Scrum Master
• Product Backlog
• Sprint Backlog
• Sprint
• Sprint Retrospective
• Sprint Review Meeting

2.3. Justificativa

• O Scrum é uma metodologia que preza por entregas contínuas que agregam valor ao produto;
• Diminuição de risco no projeto, pois o desenvolvimento é dividido em ciclos curtos com a colaboração entre a equipe;
• Resposta rápida a mudanças de planejamento, devido a adoção dos rituais de revisão e constante acompanhamento da evolução do software;
• Entregas incrementais, o que visa a maior qualidade do produto;
• Compartilhamento de conhecimento, devido à Sprint Retrospective e Sprint Review Meeting;
• Aumento da produtividade e;
• Ser adaptável ao projeto e a outras metodologias.

3. Kanban

3.1. Definição

(do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.

3.2. Recursos Incorporados

• Backlog
• To Do
• Doing
• Testing e Q&A (sendo este uma adaptação para o projeto)
• Done

3.3. Justificativa

• Fornece uma visão ampla do projeto do que tem para ser feito, em que etapa se encontra, etc, trazendo certa previsibilidade;
• Permite a gerência do fluxo de trabalho de forma mais eficaz;
• Facilita a recepção e fornecimento de feedbacks;
• Colabora para a elaboração do fluxo de execução de tarefas de forma transparente e simples;

4. Extreme Programming (XP)

4.1. Definição

Programação Extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.

4.2. Recursos Incorporados

• Planning Game - Definição das user stories e estimar o tempo ideal necessário para execução das estórias definidas
• Small Releases - Conforme as interações são concluídas, o cliente recebe pequenas versões/releases do sistema, visando com que seja colocado em prática e validado aquilo que está sendo implementado.
• Pair Programming - Todo código de produção é desenvolvido por duas pessoas trabalhando em conjuntos, e às vezes com o mesmo teclado, o mesmo mouse e o mesmo monitor, somando forças para a implementação do código.
• Coding Standards - Todo código é desenvolvido seguindo um padrão, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe terão a mesma visão do código.

4.3. Justificativa

• O conhecimento técnico é uniformemente distribuído entre a equipe;
• As user stories planejadas são acordadas entre cliente e equipe, e consequentemente, são mais concretas e fáceis de serem rastreadas e gerenciadas;
• O código segue um padrão único e uma arquitetura definida, facilitando no processo de refatoração e manutenção;
• Versões do sistemas são lançadas a cada iteração, provindo ao cliente features num processo mais curto e ágil.