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
Adrianne Alves	25/08/2018	Adição do kanban	0.0.3
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.4
Mariana de Souza Mendes	25/08/2018	Adição e definição do componente relacionado ao RUP	0.0.5
Diego França	25/08/2018	Revisão do texto	0.0.6

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
   
5. RUP
   5.1. Definição
   5.2. Recursos Incorporado
   5.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 planejamento e organização em projetos de software. O maior benefício dele é facilitar o trabalho complexo que envolve a criação e compartilhamento de conhecimento de novos produtos desenvolvidos, mantendo proximidade com o cliente nesse processo.

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

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

A metodologia define três papéis:

• Scrum Master: exerce a liderança do processo, através da solução de impedimentos e garantindo que os ritos ágeis do processo seguido pela equipe estejam sendo entendidos e seguidos;
• Product Owner: é o responsável por gerenciar o Product Backlog e maximizar o valor do produto sendo desenvolvido, podendo ser o cliente ou um representante que conheça bem o domínio e requisitos do projeto;
• Development Team: são os responsáveis por desenvolverem o produto, sendo todo o time de desenvolvimento.

O Scrum ainda emprega algumas práticas de planejamento e avaliação da Sprint:

• Sprint Planning: consiste em reuniões de planejamento entre o Product Owner e o Development Team, para determinar quais itens do Product Backlog irão para o Sprint Backlog e a pontuação das estórias de usuário da Sprint. Nesta reunião, os requisitos das estórias são levantados e esclarecidos na medida do necessário para o Development Team;
• Sprint Review: correspondente à revisão da Sprint com todo o time, tendo como objetivo mostrar o que foi produzido na Sprint;
• Sprint Retrospective: ou restrospectiva da Sprint, 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
• Resultados da Sprint
• Daily Meeting

OBS: O papel de Scrum Master foi adaptado ao contexto nossa equipe e do trabalho. Ao invés de associar esse papel à apenas um membro, foi definido que todos poderiam exercer esse papel e que tudo seria conversado e definido em equipe.

2.3. Justificativa

• É uma metodologia que preza por entregas contínuas e incrementais que agregam valor e qualidade ao produto e aumentam a produtividade do Development Team;
• Diminui riscos no projeto, pois o desenvolvimento é dividido em ciclos curtos com constante comunicação entre a equipe e revisões ao final de cada Sprint;
• Resposta rápida à necessidade de mudanças de planejamento devido à adoção dos rituais de Sprint Review e Sprint Retrospective, além do constante acompanhamento da evolução do software;
• Compartilhamento de conhecimento através da Daily Meeting, Sprint Retrospective e Sprint Review;
• Ser adaptável às necessidades dos projetos e ao acréscimo de práticas e artefatos de 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 conjunto, 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 que deve ser seguido por toda a equipe. 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.

5. Rational Unified Process (RUP)

5.1. Definição

O RUP, de propriedade da IBM, é um framework de processo da engenharia de software que fornece práticas testadas na indústria de software e gerência de projetos. Por ser um framework de processo, pode e deve ser customizado conforme as necessidades organizacionais e do projeto. Dessa forma, pode-se trabalhar um RUP mais “leve e ágil” ou “mais pesado”.

O RUP permite que a equipe do projeto escolha as atividades e os artefatos a serem produzidos reduzindo, assim, o excesso de documentação para torná-lo mais ágil. Outra característica interessante dele é a aplicação do modelo de ciclo de vida iterativo e incremental. Na metodologia iterativa, em cada iteração, parte do software é desenvolvida, sendo os artefatos da nova iteração superiores aos iteração anterior. O desenvolvimento iterativo e incremental permite aos desenvolvedores o aprendizado em relação ao software possibilitando, assim, a localização de futuros problemas em fases iniciais.

O RUP é descrito a partir de três perspectivas. Na perspectiva dinâmica, o RUP identifica o ciclo de desenvolvimento do projeto em quatro fases sequenciais sendo, cada fase, finalizada por um marco principal. As fases do RUP são iniciação, elaboração, construção e transição. A Figura 1 apresenta as fases do RUP.

5.2. Recursos Incorporados

• Documento de Visão: O objetivo desse documento é definir todos os requisitos e o escopo inicial do projeto, selecionando os pontos principais que deverão ser abordados durante sua primeira parte. Este documento define as necessidades dos usuários, do projeto e da equipe, especificando a importância do projeto para as partes envolvidas e também pontuando suas restrições e dificuldades;
• Documento de Arquitetura: O objetivo desse documento é apresentar uma visão geral da arquitetura do software a ser desenvolvido no projeto. A finalidade é expôr as decisões arquiteturais tomadas em relação ao software, tais como características da organização do sistema, da portabilidade, da confiabilidade e o desenho relacionado, guiando os desenvolvedores na construção da aplicação.

5.3. Justificativa

• Possibilita o melhor entendimento da equipe de desenvolvimento e do cliente;
• Tanto o Documento de Visão quanto o de Arquitetura procuram estabilizar o projeto/produto;
• Design de software com artefatos mais estáveis e de fácil entedimento ao cliente.