Processo de Desenvolvimento

Descrição

Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.

Sumário

• Git Workflow
• Matriz de Responsabilidade
• Plano de Comunicação
• Plano de Riscos

Git Workflow

Branches

Ambientes

• master: Conterá sempre a versão de PRODUÇÃO (a versão mais estável possível). Não é permitido fazer commits diretamente na branch master, sendo a única forma de adicionar código nessa branch através de um merge request.
• development: Conterá sempre a versão de DESENVOLVIMENTO (a próxima versão de lançamento). Não é permitido fazer commits diretamente na branch master, sendo a única forma de adicionar código nessa branch através de um merge request.
• feature: Conterá sempre a versão de desenvolvimento. É utilizada para desenvolvimento das tarefas descritas nas user stories. É permitido fazer commits livremente nas branches do tipo feature.
• bugfix: Conterá sempre a versão de desenvolvimento. É utilizada para aplicação de correções de eventuais bugs que tenham passado pela branch feature. É permitido fazer commits livremente nas branches do tipo bugfix.

Nomes

Como padrão para nomes de branches, foi decidido o seguinte:

<númeroDaIssue>-<nomeDaTarefa>

Portanto, um exemplo de nome para branch:

01-tela-login

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development antes de criar uma branch nova:

git pull origin development

Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um push para garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push

Salvando Localmente

Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m 'descrição da tarefa em português'

Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch dev);
3. Selecione Compare branches and continue
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
7. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
8. Em Milestone selecione a Sprint em que a tarefa foi realizada;
9. Em Labelsselecione qual é o tipo de tarefa que foi realizada;
10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Airtable.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

Divisão de User Stories em tarefas

A técnica SMART é muitas vezes utilizada para guiar na construção de tarefas alcançáveis. O SMART nos diz que uma tarefa tem cinco características:

Specific: tarefas precisam ser específicas para que todos do time entendam como elas se conectam e como juntas elas contribuem para atingir os critérios de aceitação da user story.

Measurable: uma tarefa é mensurável quando pode ser marcada como “concluída”, seguindo os critérios técnicos do time. Por exemplo, com os testes escritos e o código refatorado.

Achievable: as tarefas devem ser alcançáveis pelos seus responsáveis. Aqui entra a capacidade do time de identificar pontos fortes, fracos e oportunidades de melhoria dos membros. Neste critério , por exemplo, o time pode optar pelo pair programming, para desenvolver habilidades e alcançar seu objetivo.

Relevant: todas as tarefas devem ser relevantes. As histórias são quebradas em tarefas para auxiliar o desenvolvimento, mas o Product Owner ainda espera que todas elas sejam explicáveis e justificáveis.

Time-Boxed: todas as tarefas precisam ter um tempo definido para serem concluídas. Não é necessário fazer uma estimativa formal em horas ou dias, mas deve haver uma expectativa de conclusão ou de quando será necessário pedir ajuda ao time. Quando uma tarefa se torna maior do que esperado, o time precisa saber o momento certo para tomar uma ação para que seja concluída.

Matriz de Responsabilidade

Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.

• I: Deve ser informado
• C: Deve ser consultado
• R: Responsável
• A: Aprova

Plano de Comunicação

Plano de Riscos