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
Mariana de Souza Mendes	20/11/2018	Correção de português e adiciona uma justificativa ao papel de scrum	0.0.6
Adrianne Alves	22/11/2018	Adição de metodologia e conclusão	0.0.7
Mariana Mendes	23/11/2018	Pequena correção no Resultado	0.0.8

Sumário

1. Introdução
2. Metodologia
3. Scrum
   3.1. Definição
   3.2. Recursos Incorporados
   3.3. Justificativa
   
4. Kanban
   4.1. Definição
   4.2. Recursos Incorporados
   4.3. Justificativa
   
5. EXtreme Programming
   5.1. Definição
   5.2. Recursos Incorporados
   5.3. Justificativa
   
6. RUP
   6.1. Definição
   6.2. Recursos Incorporado
   6.3. Justificativa
   
7. Resultado

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.

2. Metodologia

Acordou-se dentro da equipe a necessidade da participação de todos os membros a fim de levantar as práticas e metodologias a serem utilizadas. Assim, a primeira atividade consistiu em relacionar todas as metodologias apresentadas na disciplina e selecionar os aspectos considerados propícios ao contexto da equipe, no que diz respeito a tempo e dinâmica do semestre e rítmo da disciplina. Abaixo, seguem a relação e definições das metodologias escolhidas.

3. Scrum

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

3.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 da 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.

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

4. Kanban

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

4.2. Recursos Incorporados

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

4.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;

5. Extreme Programming (XP)

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

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

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

6. Rational Unified Process (RUP)

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

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

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

7. Resultado

Apesar do planejamento das práticas a serem utilizadas de acordo com as metodologias abordadas na disciplina, é preciso explicitar que a equipe não utilizou todas as abordagens durante o processo de desenvolvimento. Com relação ao SCRUM:

• Daily Scrum: * Foi desenvolvido um bot conectado ao slack, por meio do qual os membros iriam enviar diariamente os relatos da seu trabalho diário. Isso foi feito pelo membro Sconetto. Entretanto, com o rítmo corrido da disciplina, no que diz respeito ao processo de avaliação, esse rito foi negligenciado por vários dos membros da equipe.

• Product Backlog: * O product backlog foi gerado pela equipe após o estabelecimento de uma baseline de requisitos, entretanto, no curto prazo de desenvolvimento, não houveram tantas alterações e revisões desse artefato.

• Sprint Backlog: A cada uma das sprints realizadas, foi definido um sprint backlog, cuja priorização se deu por meio das reuniões, isso é possível ver através do planejamento documentado na aba do lado direito para cada sprint.

• Papeis SCRUM: Apesar de relatar que haveria a presença de papéis scrum dentro da equipe, esses papéis não foram praticados, assim, todos os membros desempenharam o papel de Development Team.

• Práticas de avaliação e planejamento da sprint: Foram realizados o planejamento e revisão da sprint. Entretanto, como possuíamos poucas reuniões na semana, por conta da disponibilidade dos membros, a revisão foi feita de uma maneira um pouco diferente da planejada. Algumas foram feitas via hangouts, antes de levantar o que seria feito na próxima dinâmica ou sprint, a equipe revia o que havia sido feito anteriormente. Entretando, as vezes não era possível fazer essa reunião e para que a equipe não ficasse perdida sobre o que foi e não foi feito, era informado via Slack e a partir dai a equipe conseguia se planejar sem que haja conflitos.

Sobre o Kanban como recurso: Apesar de constar no planejamento, o kanban não foi utilizado pela equipe, de modo que o maior controle das tarefas se deu por meio das atas de reunião. Sendo definidos durante ela o a fazer, o que está sendo feito e o que foi terminado durante a sprint.

Sobre o uso do XP:

• Planning Game: De fato, foram definidas as histórias de usuário, por meio da equipe, mas não foi realizada a pontuação nem a estimativa de tempo para implementação da história. Esse aspecto foi negligenciado pela necessidade de poucas reuniões e tempos reduzidos.

• Small Releases: A equipe não conseguiu manter esse recurso, uma vez que devido o atraso para preparação com a prova, o desenvolvimento iniciou tardio.

• Pair Programming: Prática amplamente utilizada pela equipe, que auxiliou devido ao desnível de conhecimento da equipe, indo de componentes com nenhuma ou pouca experiência a pessoas com muita experiência com as tecnologias utilizadas. A partir dessa técnica foi possível a passagem de conhecimento entre os membros.

• Coding Standards: Houve um grande esforço por parte do Sconetto e Mariana na definição de um padrão de desenvolvimento, incluindo o uso do git-flow para padronizar os commits. Entretanto, na correria, em muitos casos esses padrões foram violados. Entretanto, os templates de issue e nome das branches foram preservados.

Sobre o RUP:

• Documento de visão: Foi elaborado a contento pela equipe e auxiliou na definição do escopo do trabalho.

• Documento de arquitetura: Foi elaborado pela equipe e houve um grande esforço para atualizá-la de acordo a identificação de novos aspectos.