1. Introdução

Durante a execução do projeto para a Release 2, foram utilizadas três metodologias adaptadas de modo a atender as necessidades do time e cumprir com o que foi proposto pelas disciplinas MDS e GPP. São estas: Scrum, XP e o Kanban, detalhadas a seguir.

2. Scrum

O Scrum é um framework usado desde 1990 para resolver problemas complexos. É importante ter em mente que o Scrum não é um processo ou técnica e sim um framework que permite a inclusão de processos e técnicas.

Este framework consiste em papéis, artefatos e e eventos e tem três bases: transparência, inspeção e adaptação. Os valores do Scrum são comprometimento, coragem, foco, tranparência e respeito. Os que compõem o Time Scrum devem estar comprometidos com esses valores, além de serem auto-organizáveis - ou seja, não precisam de um gerente para dizer o que deve ser feito - e multifuncionais - isto é, possuem qualificação sufuciente para não precisarem de outras equipes para entregar o produto.

2.1. Papéis

Os papéis do Scrum são divididos em Scrum Master, Product Owner(PO) e Time de Desenvolvimento. O Scrum Master e o PO no Scrum original não fazem parte do Time de Desenvolvimento, porém, para este projeto, uma das adaptações feita foi a de que eles participariam diretamente do desenvolvimento do software para que tivessem um conhecimento maior acerca do código.

Outra adaptação é que a cada semana as responsabilidades do Scrum Master e do Product Owner eram assumidas por membros diferentes do time, assim o conhecimento acerca desses papéis foram disseminados entre o grupo.

2.1.1. Scrum Master

O Scrum Master é responsável por entender os pricípios do Scrum e garantir que todos o usem corretamente. Também é sua responsabilidade facilitar o desenvolvimento do produto, removendo os impedimentos que houver, e também atuando como mediador, quando necessário.

A medida que o projeto foi evoluindo o Scrum Master foi perdendo seu valor. Isso dentro da metodologia é algo bom, pois significa que o time foi ficando cada vez mais independente, ao ponto de não precisar de alguém que coordenasse as reuniões, já que todos já sabiam o que precisava ser dito e fazer.

2.1.2. Product Owner

O Product Owner é responsável por enteder o que o cliente precisa e priorizar as funcionalidades que devem ser desenvolvidas. Ele é a ponte entre o time de desenvolvimento e o cliente, por isso devem ser feitas reuniões de tempos em tempos.

No desenvolvimento do SAS essas reuniões ocorriam toda semana às sextas-feiras em que era apresentado à cliente quais a funcionalidades haviam sido implementadas ou estavam sendo terminadas e o cliente, por sua vez, priorizava as funcionalidades mais importantes para ele.

2.1.3. Time de Desenvolvimento

O Time de Desenvolvimento é responsável por entregar incrementos funcionais do produto até uma data limite. Ele tem autonomia suficiente para decidir como será feito seu trabalho, sendo que nem o Scrum Master tem autoridade para mudar essa decisão. O ideal, de acordo com o Scrum, é que o time tenha de três a nove integrantes, pois menos que isso a produtividade é pouca e mais do que isso pode haver desorganização.

O Time de Desenvolvimento foi composto por dez integrantes, que foram evoluindo ao decorrer do projeto como mostra o relatório das Sprints. A decisão de ser um time de dez pessoas foi uma exigência da disciplina, mas mesmo ultrapassando o limite recomendado a auto-organização não prejudicada.

2.2. Eventos

Os eventos, no Scrum, são situações que permitem o time se organizar e transparecer o que está sendo feito. Cada evento é time-boxed, isto é, tem um tempo definido.

Os eventos são a Sprint, a Reunião de Planejamento da Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint. Todos os eventos foram usados no andamento do projeto.

2.2.1. Sprint

A Sprint é o evento mais importante do Scrum, é nela que o projeto é executado e todos os outros eventos acontecem nela. O time-boxed de uma Sprint é de no máximo um mês e a cada início de Sprint o PO prioriza as tarefas que devem ser executadas. Este é o único evento que tem um tempo um tempo fixo, não podendo ser prolongada ou reduzida, exceto quando há o cancelamento da Sprint (algo raro) que só pode ser feito pelo PO. A cada término da Sprint o time de desenvolvimento entrega uma parte funcional do produtp;

No desenvolvimento do projeto não foi diferente. Cada sprint teve duração de uma semana e nenhuma precisou ser cancelada. Em algumas nem todas as tarefas foram entregues por diversos motivos. Essas tarefas que não foram entregues foram repontuadas e priorizadas para outras Sprints, não necessariamente a próxima.

2.2.2. Reunião de Planejamento da Sprint

Como o próprio nome diz esse é o evento em que a sprint é planejada, ou seja, as tarefas são pontuadas de acordo com a complexidade, o PO apresenta as que tem maior prioridade para aquela sprint e os desenvolvedores escolhem quais serão feitas.

As reuniões de planejamento do grupo ocorreram aos sábados, pela manhã ou a tarde, e tinham um time-boxed de duas horas. No início esse tempo não foi cumprido à risca, pois o time ainda estava se adaptando à metodologia. Durante essa reunião o PO da sprint anterior apresentava as terefas prioritárias e o time debatia sobre quais iriam ser implementadas e como ia ocorrer essa implementação, definindo os responsáveis por cada tarefa e como ela deveria estar ao final.

2.2.3. Revisão da Sprint

A Revisão da Sprint é quando o time discute sobre o que foi feito e o que não foi feito na Sprint e quais problemas aconteceram e como foram solucionados. Esta reunião também ocorreu aos sábados antes da reunião de planejamento com uma duração média de uma hora.

2.2.4. Retrospectiva da Sprint

Esta reunião ocorre para identificar as dificuldades que ocorreram na Sprint. Esta reunião ocorreu aos sábados, logo após a Revisão da Sprint. Nela cada um falava o que achou de bom e ruim na Sprint e o que poderia ser feito para sanar os problemas. Essa reunião também teve uma duração média de uma hora.

2.2.5 Reunião Diária(Daily)

Este é um evento time-boxed de 15 minutos que tem como objetivo esclarecer quais foram as contribuições para o projeto nas últimas 24 horas , o que será feito até a próxima Daily e quais impedimentos estão ocorrendo. Essas reuniões aconteceram todos os dias durante o início do projeto, geralmente a noite e online, porém depois o time decidiu que seria melhor fazê-las toda terça e quinta às 16hrs presencialmente, pois esse é o único horário que o grupo poderia se reunir durante a semana e também por que nem todos estavam participando da reunião à noite.

2.3. Artefatos

Os artefatos do Scrum são usados para melhorar a transparência entre o grupo. Ele, também, sempre agrega algum valor ao cliente ou ao time. Os artefatos são: Backlog do Produto, Backlog da Sprint e o Incremento.

2.3.1. Backlog do Produto

O Backlog do Produto lista de tudo o que o projeto precisa, porém ele pode ser atualizado quantas vezes for necessário durante o projeto. O Backlog é de responsalidade do PO e este deve ajudar os desenvolvedores no entedimento de cada item e nas decisões. O Backlog do projeto pode ser encontrado aqui.

2.3.2. Backlog da Sprint

Este artefato é uma lista, derivada do Backlog do Produto, de tudo o que os desenvolvedores planejaram implementar em uma Sprint. O Backlog da Sprint é sempre planejado na Reunião de Planejamento da Sprint, mas pode mudar durante a Sprint - somente pelo time de desenvolvimento. Cada Backlog da Sprint pode ser encontrado nos relatórios de cada Sprint do projeto.

2.3.4. Incremento

Este é uma soma de todas funcionalidades prontas com as funcionalidades implementadas na última Sprint. Ao final de toda Sprint o time de desenvolvimento deve gerar um Incremento, independente de o PO disponibilizá-lo para o cliente.

2.4. Definição de "pronto"

Uma tarefa estar pronta significa que ela atende a um conjunto de critérios definidos pelo time. Essa definição é importante para que não haja conflitos entre o time sobre quando um incremento está pronto. No início do projeto uma tarefa pronta foi definida como funcional, devidamente validada (para impedir que o usuário informe dados inválidos), totalmente testada, sem conflitos com incrementos anteriores e sem diminuir a cobertura de teste (esta deveria no máximo ser mantida igual ao que estava antes da nova funcionalidade).

2.5. Métricas

As métricas são padrões usados para assegurar a qualidade do produto em desenvolvimento. As métricas utilizadas foram cobertura de teste, complexidade ciclomática e churn, a explicação para cada uma dessas métricas pode ser encontrada aqui e a coleta pode ser observado no relatório de cada Sprint. As métricas foram coletadas a cada final de Sprint e quando necessário era feita refatoração do código para melhorá-las. Ao final da última Sprint foi montado o seguinte gráfico com a variação total de issues (problemas) de qualidade.

![Graph_quality_issues] (https://raw.githubusercontent.com/wiki/fga-gpp-mds/2016.2-Time05-SalasFGA/img/quality_issues.jpeg)

O eixo horizontal do gráfico representa as Sprints e o vertical a quantidade de issues. Pode ser observado que nas primeiras quatro Sprints a quantidade de issue subiu e nas duas próximas diminuiu consideravelmente. Isso aconteceu por que nas primeiras Sprints o foco era entregar os Incrementos e nas últimas além do Incremento também foi priorizado a refatoração do código para melhorá-lo. A duplicidade de código (em azul no gráfico) se dá pelo semelhança entre o código e não significa que o código está exatamente igual em diferentes métodos.

3. XP

3.1. Automatização

• Para os testes de aceitação automatizados foi utilizado o software Selenium na versão 2.53.6.

• Este tipo de teste simula a utilização do sistema por um usuário, abrindo cada página no navegador e inserindo dados como se uma pessoa o estivesse fazendo. Ele é escrito na linguagem do dia a dia (em inglês, para este sistema) com base nos critérios de aceitação informados pelo P.O. após diálogo com o cliente.

• Para executá-los, basta inserir o seguinte comando: $ python manage.py harvest

Exemplo de teste de aceitação escrito
![Acceptance_test] (https://raw.githubusercontent.com/wiki/fga-gpp-mds/2016.2-SAS_FGA/img/aceeptance_test.jpg)

• Em alguns casos, é necessário escrever steps (passos) em linguagem de programação que transformam o que foi escrito em um conjunto de ações no sistema.

Exemplo de step
![Step] (https://raw.githubusercontent.com/wiki/fga-gpp-mds/2016.2-SAS_FGA/img/step.jpg)

• Para os testes unitários automatizados, a própria framework Django já disponibiliza um ambiente para tal, criando um banco de dados exclusivo deste ambiente de testes, que é destruído após sua execução e utilizando bibliotecas nativas do Python. Utilizando a classe unittest, foram escritos testes de cada funcionalidade.

• Para executá-los, basta inserir o seguinte comando: $ python manage.py test

Exemplo de teste unitário
![Unit_test] (https://raw.githubusercontent.com/wiki/fga-gpp-mds/2016.2-SAS_FGA/img/unit_test.jpg)

3.2. Programação em pares

• Durante essa fase do projeto foi definido que todas as issues seriam feitas por pareamento. Priorizando sempre formar pares de pessoas com mais conhecimento com pessoas com menos conhecimento na linguagens e/ou ferramentas que seriam utilizadas para realizar a issue, para dessa forma poder disseminar a maior quantidade possível de conhecimento dentro da equipe.

Quadro de Pareamento após a Sprint 0:

Quadro de Pareamento após a Sprint 6:

3.3. TDD

• Apenas a Sprint 3 foi realizada inteiramente em TDD. Basicamente era necessário escrever os testes automatizados, teste unitário e teste aceitação, de uma melhoria ou nova funcionalidade. Em seguida, o código da funcionalidade seria desenvolvido, em baby-steps, para validar a funcionalidade criada.

• Após esta sprint, ficou a cargo de cada dupla se utilizar-se-ia TDD ou não, adaptando-se a realidade de cada uma (conhecimento da técnica, facilidade, etc.).

• Essa sprint resultou em uma significativa melhora do time em testes de aceitação e testes unitários.

Quadro de Conhecimento após a Sprint 2:

Quadro de Conhecimento após a Sprint 3:

3.4. Integração Contínua

• Para a integração contínua foi utilizado o software Travis CI, para assim, verificar se o sistema ainda funcionava normalmente após a implementação de uma nova funcionalidade e junção deste novo código ao código principal. Logo, após a junção destes códigos é criada uma nova build do sistema e se testa-a, garantindo a integração entre as funcionalidades e seu funcionamento.

Exemplo de resultado da integração contínua após build e testes
![CI] (https://raw.githubusercontent.com/wiki/fga-gpp-mds/2016.2-SAS_FGA/img/travis.jpg)

3.5. Teste de Aceitação

• Para cada User Story deveriam ser feitos testes aceitação para a validação do sistema e para o cliente entender como será o funcionamento da US
• As para o finalizamento da issue é necessário que os teste de aceitação estivessem funcionando corretamente.

3.6. Refatoração

Para refatoração foram utilizadas as métricas geradas pelo cloud climate em relação a: folha de estilo (pep8), duplicação e complexidade de código. Arquivos com nota F tiveram criadas estórias técnicas de refatoração no repositório, para que suas qualidades aumentassem. Outros arquivos também foram melhorados a medida que se produzia código e o time percebia uma possível melhora, não sendo necessário estar trabalhando numa estória relacionada ao método refatorado. Os exemplos a seguir mostram issues que auxiliam na orientação da refatoração.

4. Kanban

Para organização do fluxo de trabalho do time, montou-se um quadro kanban:

Cada coluna representa, respectivamente:

• Backlog: Contendo todas as issues ainda não entregues do produto.

• TODO (Sprint Backlog): Contendo todas as issues ainda não entregues da sprint.

• DOING: Contendo todas as issues que são trabalhadas no momento.

• Test: Contendo todas as issues que estão em fase de teste.

• Done: Contendo todas as issues já entregues.

Em cada issue é possível consultar os responsáveis por esta, sendo que o responsável não precisa realizá-la sozinho, podendo recorrer a qualquer membro do time para auxiliá-lo. Caso haja mais de um responsável, o pareamento deve ser priorizado entre os responsáveis, porém não é obrigatório, podendo da mesma forma realizá-la com outros membros.

Na issue também é possível consultar suas respectivas tags, que podem ser alteradas por qualquer membro do time, caso seja necessário. Abaixo estão representadas as tags utilizadas.