Padrões de Desenvolvimento: Processos e Tecnologias

Padrões de desenvolvimento:
processos e tecnologias
Este documento descreve padrões adotados na Fábrica de Software do CEULP para
tecnologias e processos e serve como guias para o desenvolvimento de novos projetos.
1.0.0 - agosto de 2018

Padrões de desenvolvimento 1
Sumário
Processos 3
Tecnologias 6
Artefatos 7
Introdução - Git e GitLab 8
Clonando repositórios do GitLab 8
Linha de comando 8
Interface gráfica 9
Branchs e Desenvolvimento controlado 10
Linha de comando 10
Interface Gráfica 10
Versionamento - Add e Commit 12
Linha de Comando 12
Atualizando o repositório remoto 16
Linha de comando 17
GitLab - Issues e Milestones 19
Gitlab - Issue Board 21
Primeiro acesso 21
Criando uma nova lista 22
Adicionando issues a lista 25
Movendo uma issue entre listas 27
Referências 27
Gitlab - Estimativas de Tempo 29
Fábrica de Software - CEULP/ULBRA

Por que estimar? 29
Visão geral 29
Como inserir os dados 30
Inserindo Estimativas 30
Adicionando Tempo Gasto 30
Configurações das Unidades de Tempo 30
Mas como estimar? 31
E como acompanhar o tempo gasto? 32
REFERÊNCIAS 32
Documentação do código-fonte 34
Projetos Angular com códigos-fontes em JavaScript/TypeScript 34
Projetos Python ou Django 34
Projetos PHP 34
Guias gerais 34

Processos
O desenvolvimento de projetos na Fábrica de Software segue a metodologia SCRUM e
utiliza a ferramenta Gitlab como suporte. Desta forma, o processo de desenvolvimento deve
seguir as seguintes etapas:
1. definição de participantes (devs, stakeholder, scrum master)
2. reunião de entendimento (todos)
a. stakeholder apresenta suas necessidades para a equipe
3. reunião de entendimento (devs e scrum master)
a. sugestão: aplicar técnica de brainstorm para ampliar as possibilidades de

solução do problema apresentado pelo stakeholder
b. sugestão: utilizar BPMN para modelagem dos processos do negócio em duas

versões: atual (como está) e futura (incluindo o software)
c. sugestão: definir a arquitetura do software (não apenas em termos de

tecnologia, mas também necessidades para atendimento de requisitos
não-funcionais) e as tecnologias que serão utilizadas
i. se necessário, reservar um tempo para nivelamento da equipe

(entendimento da tecnologia utilizada no projeto)
d. sugestão: criar protótipo de baixa fidelidade (telas; em papel)
e. sugestão: repetir a reunião de entendimento até que o entendimento do

modelo de negócio (atual e futuro) esteja suficientemente claro
4. criação do projeto no Gitlab (com definição de funcionalidades para os usuários)
5. definição do product backlog (versão inicial, com dev e scrum master)
a. o resultado é uma lista de features (funcionalidades) que devem ser

cadastradas como issues no projeto do Gitlab
b. sugestão: a descrição da issue deve ter o maior nível possível de

detalhamento, indicando tanto o comportamento do software (lógica) quanto
a interação com o usuário (interface gráfica)

6. definição das estimativas das features utilizando pontuação por complexidade

(aplicar planning poker, com dev e scrum master)
a. ideal é que as issues sejam atualizadas com estimativa de tempo para

conclusão
7. definição das sprints (todos)
a. o resultado é o agrupamento das features em sprints, que são representadas

por milestones no projeto do Gitlab (devem ser definidas as datas para
conclusão das milestones)
8. reunião de revisão com stakeholder (validar sprints e estimativas das features)
a. sugestão: definir plano de lançamento de versões (utilizar versionamento

semântico)
9. desenvolver por sprint
a. utilizar kanban (ex.: quadro de tarefas com: a fazer, fazendo, corrigindo,

concluídas)
b. iniciar branch por milestone ou conjunto de issue (ex: feature/sprint-1)
c. fazer push diariamente (sem corromper o repositório remoto com código que
não funciona)
i. mensagens de commits devem referenciar issues
ii. ideal é indicar o tempo gasto (real) para cada issue
d. sugestão: documentar código-fonte (explicar, tecnicamente, a nível de classe,

atributo e método)
i. utilizar a sintaxe de documentação de código conforme a plataforma

(ex.: para Angular, usar JSDoc e compdoc; para Django, usar
Docstrings e Sphinx)
e. sugestão: utilizar TDD (testes unitários e E2E)
f. reunião de revisão ao final da sprint (validar issues implementados e atualizar

kanban)
i. reservar um tempo para os devs apresentarem o resultado da sprint

em funcionamento e validar (testes funcionais)
g. lançar tag (release) e mesclar com o branch master quando necessário

i. descrever itens adicionais, corrigidos ou removidos no CHANGELOG
h. reunião de validação com a presença do stakeholder, quando necessário
10. reunião de finalização (todos)

Tecnologias
O ideal é que um projeto [novo] não fique preso a um conjunto específico de tecnologias e
que sejam estudadas as necessidades de integrações com outros projetos. Entretanto,
seguem alguns conjuntos de tecnologias mais utilizadas:
1. Banco de dados: PostgreSQL, MySQL (também pode-se utilizar SQLite ou MySQL

no desenvolvimento)
2. Cache: Redis, Memcache
3. Fila de mensagens: Celery
4. Plataforma/framework de desenvolvimento: Python, Java, PHP, Django (front-end

+ back-end), Django REST Framework (back-end/REST), Laravel (front-end,
back-end), Lumen (back-end/REST), Angular (front-end), Bootstrap (UI no front-end)
5. Servidor web de produção: Apache, Nginx
As integrações entre projetos também podem determinar as tecnologias utilizadas. É

importante que as integrações entre projetos sejam pensadas e projetadas em níveis:
● nível de dados: neste nível os projetos podem utilizar plataformas de

desenvolvimento diferentes, mas devem utilizar a mesma tecnologia de banco de
dados
● nível de plataforma: neste nível os projetos devem utilizar a mesma plataforma de

desenvolvimento, devem ter a sua integração pensada no nível de UI/UX
(interface/interação com o usuário), mas podem utilizar tecnologias de bancos de
dados diferentes
● nível de fila de mensagem: neste nível os projetos podem utilizar plataformas e

tecnologias de bancos de dados diferentes, mas a mesma tecnologia de fila de
mensagens (que será utilizada como um mecanismo de interoperabilidade de dados)

Artefatos
Ao descrever projetos, produzir os seguintes artefatos (não necessariamente nesta ordem):
1. sugestão: modelo de processos do negócio (diagrama BPMN)
2. arquitetura do software ou visão geral
3. product backlog (lista de funcionalidades)
4. plano de entrega do produto (milestones)
5. diagrama de banco de dados relacional (se necessário)
6. diagrama de classes da UML
7. descrição do comportamento do produto por funcionalidade
a. eleger um conjunto de funcionalidades consideradas mais importantes e

descrever seu comportamento utilizando os recursos:
i. print da tela
ii. descrição do funcionamento do software (no contexto da tela)
iii. descrição da interação com o usuário (interface gráfica)
iv. descrição de trecho de código-fonte (se necessário destacar

comportamento do software a nível de código-fonte ou interação entre
componentes do software)
8. documentação técnica (gerada a partir do código-fonte)
a. sugestão: ao utilizar as ferramentas indicadas, gerar um site e torná-lo

disponível

Introdução - Git e GitLab

As instruções presentes neste documento têm como referência o fluxo de trabalho e
desenvolvimento de projetos da Fábrica de Software. Serão abordadas algumas
funcionalidades de ferramentas usadas no gerenciamento e desenvolvimento de projetos. O
Git será usado no versionamento; GitKraken como interface gráfica para repositórios; e o
GitLab como um sistema para compartilhamento de projetos e controle de atividades
(Criação de issues, IssueBoard e estimativas de tempo).
Git é um sistema de controle de versão gratuito e open source, desenvolvido para gerenciar
o versionamento de projetos grandes ou pequenos. Este documento é destinado a
apresentar algumas dicas rápidas e fluxos de trabalho para o desenvolvimento usando essa
ferramenta. Para informações mais completas sobre utilização a documentação está
disponível em https://git-scm.com/docs.
Além do sistema do Git para versionar projetos, são usados sistemas web para colaboração
e compartilhamento, isso permite que várias pessoas trabalhem no mesmo projeto de forma
remota. GitHub e GitLab são exemplos de softwares com esse objetivo. Nos exemplos a
seguir será usado o fluxo para o desenvolvimento usando GitLab (http://gitlab.bitstudio.io/),
a documentação oficial pode ser acessada em https://docs.gitlab.com/ee/user/index.html.
O gerenciamento de repositórios Git será exemplificado usando também uma interface

gráfica. Os exemplos deste documento serão feitos usando a ferramenta GitKraken, existem
outras disponíveis, algumas já integradas a IDE’s como PhpStorm e Visual Studio Code ou
softwares que tem o objetivo único de realizar o controle de repositórios locais e remotos
como, GitHub Desktop. Para mais detalhes sobre todas as funcionalidades do GitKraken,
elas estão disponíveis em https://support.gitkraken.com/start-here/interface.
Recomendamos a novos usuários que consultem as documentações de cada ferramenta
para um entendimento mais profundo.
Clonando repositórios do GitLab

No início de cada projeto é preciso que exista um repositório no GitLab, na Fábrica de
Software o desenvolvimento é feito atraves de uma hospedagem própria, o URL para
acesso é http://gitlab.bitstudio.io/, caso não exista um pronto, a criação pode ser feita na
aba Projects > Your Projects. Todo projeto possui uma URL que é usada para clonar
(Baixar) o repositório do site do GitLab (Remoto) para o computador (Local).
Linha de comando
O Git disponibiliza opções para que possam ser executados processos pertinentes ao
sistema através da linha de comando. Para clonar o repositório usando a linha de comando
(Terminal, Command Prompt. PowerShell, etc), é preciso abrir o shell e executar o seguinte
comando:

git clone <URL do projeto no GitLab>
O URL do repositório é o mesmo disponibilizado na tela do projeto do GitLab. O comando

para clonar gera uma pasta com o nome do projeto e todos os arquivos no diretório atual de
execução do shell.
Interface gráfica
Para esse exemplo será utilizado o GitKraken, que possui uma versão gratuita com algumas
limitações.
Obs.: Alunos têm acesso a funções da versão PRO do GitKraken ao logar com uma conta
premium de estudante do GitHub.
Para clonar um repositório remoto do GitLab para o computador usando a interface do

GitKraken, é preciso que primeiro a partir do menu no canto superior esquerdo seja
selecionado: File > Clone Repo. Isso deve abrir a interface para clonar (Baixar) o projeto do
GitLab para o computador. A Figura 1 mostra interface para clonagem de repositório.
Figura 1 - Interface para Clonar projetos com o GitKraken
Nessa tela através da opção “Clone with URL”, o repositório do GitLab será baixado, é
preciso informado para qual diretório o projeto deve ser clonado e a URL do projeto. O
repositório clonado se comporta como um repositório Git local, ou seja, o estado de todos

os arquivos e da pasta do repositório serão guardados, isso garante que será mantido um
controle sobre quais arquivos novos foram inseridos e/ou alterados.
Branchs e Desenvolvimento controlado

Além do controle de de versionamento nativo do Git (Feito através de commits), é feito um
controle de fluxo de desenvolvimento em branchs. O repositório inicial sempre será visto
como o branch Master, nesse branch é mantido o código final e deverá ser atualizado
apenas com autorização do gerente ou responsável do projeto. Outro branch importante é o
de desenvolvimento (Develop), nesse branch é mantido todo o código funcional, mas que
ainda não é parte do projeto final.
No desenvolvimento de novas funcionalidades ou modificadas, o fluxo correto é criar um

branch a partir do branch Develop e só então fazer as alterações necessárias. A seguir será
exemplificado a criação e utilização de branchs.
Linha de comando
Para criar e usar um novo branch existem alguns comandos do Git que podem ser usados
direto da linha de comando do shell. O primeiro é usado para criar um novo branch.
git checkout -b <nome do branch>
O nome do branch deve conter o nome o tipo da funcional (feature, Hotfix), seguido de barra
e o nome da funcionalidade (sis_financeiro, login, cadastro), também é informado a qual
sprint (Milestone) aquela funcionalidade está ligada, (sprint-1, sprint-2…), um exemplo de
nomenclatura de branch seria: feature/sis_financeiro/sprint-1. Qualquer modificação nesse
novo branch não irá afetar diretamente outros branchs do repositório. No comando abaixo
está o comando para alterar entre branchs.
git checkout <nome do branch>
É comum que seja criado vários branchs que referenciam o desenvolvimento de novas
funcionalidades, correção de bugs, etc. Isso faz com que o desenvolvimento seja mais
organizado e seguro.
Interface Gráfica
A interface gráfica também auxilia no controle e acompanhamento de branchs, pois
apresenta visualmente os branchs do repositório. Para criar um novo branch com o
GitKraken o usuário deve clicar no menu de projeto na parte superior central no botão
Branch, essa ação vai abrir uma caixa de texto para que seja inserido o nome do novo

branch, após colocar o nome e dar enter o GitKraken irá criar um novo branch e usá-lo
como branch atual.
Figura 2 - Opção de criação de Branch no menu de ferramentas
Na lateral esquerda da interface do GitKraken os branchs disponíveis no projeto são

listados. A figura abaixo mostra o menu de Branchs.

Figura 3 - Menu de seleção de Branch
Com dois clicks é possível alterar entre branchs do repositório.
Versionamento - Add e Commit

Para salvar alterações feitas e atualizar o branch em uso no repositório local, é preciso
realizar algumas ações que informam o Git sobre quais alterações devem ser salvas.
Linha de Comando
Antes de realizar o commit e salvar as alterações realizadas no branch atual, é preciso
adicionar os arquivos alterados na “Área de arquivos para salvar”, todos os arquivos que
estiverem nessa “área”, serão incluídos no próximo commit. Existem dois comandos para
realizar essa ação, eles estão exemplificados abaixo:
git add <file | pasta>
Esse primeiro comando adiciona um arquivo ou pasta para ser salvo no próximo commit.

Abaixo é demonstrado outro comando com que também pode ser usado para enviar
alterações em arquivos para serem comitados (Salvos).
git add .
Colocando um Ponto fará com que todas as alterações em arquivos do repositório sejam
inseridas na área de arquivos a serem comitados.
O próximo passo é realizar o commit (Salvar alterações). Cada commit possui um código
identificador, e serve como um ponto de controle, para que seja possível voltar o estado dos
documentos para commits passados (Caso aconteça algum problema com o projeto em
edição, queira recuperar algum código, etc). Abaixo o comando para realizar o commit de
alterações do branch atual no repositório local.
git commit -m <”Mensagem”>
A mensagem do commit é um elemento importante e deve ser algo significativo que informe
sobre as mudanças e implementações feitas. As issues criadas no GitLab que funcionam
como um cronograma de atividades também deve ser mencionado na mensagem, a sintaxe
de menções de issues é #<numero da issue>, por exemplo a mensagem do commit para o
issue 001 deve conter a referência #001.
Após realizar o commit as alterações estarão salvas no repositório local (Apenas na

máquina), no próximo passo é exemplificado como enviar as atualizações locais para o
GitLab.
Interface Gráfica
O GitKraken faz um controle de todas as modificações realizadas no repositório. Na próxima
Figura é demonstrado como adicionar as alterações para serem salvas localmente no
próximo commit (o mesmo do comando add).
Na lateral direita todas as alterações ocorridas no repositório desde o último commit.

Clicando na opção Stage all changes, todas as mudanças serão inseridas na área de
Staged files (Arquivos que estarão no próximo commit).

Figura 4 - Interface para adicionar todos os arquivos para próximo commit
Caso seja selecionado apenas um dos arquivos, a aplicação disponibiliza a opção para
enviar apenas o arquivo selecionado para o área de arquivos que estarão no próximo
commit.

Figura 5 - Adicionar apenas um arquivo para o próximo commit
Para completar e commitar as alterações de forma local é preciso inserir a mensagem do

commit, é importante sempre referenciar na mensagem para qual a issue aquele commit
está relacionado, o GitLab usará isso pra relacionar o commit com a issue, facilitando o
controle de quais commits foram feitos para aquela atividade.

Figura 6 - Interface de commit
Atualizando o repositório remoto

Por fim é preciso realizar a atualização do repositório remoto, isso fará com que a situação
do repositório local seja enviada para o GitLab, também é importante manter esse
repositório remoto atualizado diariamente. Tanto para o controle das alterações e versões
do projeto, como para eventuais problemas de hardware. Além de enviar atualizações locais
para o repositório do GitLab sempre são feitas atualizações para o repositório local, isso é
necessário pois o Git levantará um erro caso o repositório remoto possua alterações que
ainda não estão presentes localmente.

Linha de comando
É importante que o repositório local sempre esteja atualizado com o repositório remoto do
GitLab, para baixar alterações do GitLab para o repositório local é preciso realizar um Pull.
Essa ação vai garantir que caso alguma alteração presente no repositório remoto, não
esteja presente no repositório local, ela será baixada e as alterações de arquivos serão
mescladas aos arquivos do repositório local. O comando para realizar um pull é:
git pull
O próximo comando atualiza o estado dos documentos do repositório remoto, enviando as

alterações para o GitLab. Apenas alterações que estão salvas em commits serão enviadas
para o repositório remoto. O comando Git para enviar atualizar repositório remoto é:
git push
Interface Gráfica
No menu de ferramentas são disponibilizados botões de ação com as opções para realizar
Pull e Push, a Figura 7 exemplifica o processo para enviar atualizações do repositório local
para o GitLab através do Pull.
Figura 7 - Opção no menu de ferramentas para Pull

Na Figura 8 está a ação para realizar a atualização do repositório remoto e com isso enviar
arquivos e alterações locais para o GitLab.
Figura 8 - Opção no menu de ferramentas para Push

GitLab - Issues e Milestones

Além das funcionalidade de compartilhamento e versionamento, o GitLab também é usado
para o gerenciamento de atividades e cronograma. Isso é possível devido a algumas
funcionalidades que ajudam a gerenciar o desenvolvimento (as exemplificações deste
documento estão de acordo com a metodologia do Scrum). As funcionalidade que tornam
isso possível são as Issues e as Milestones.
Issues são atividades que podem ser cadastradas no GitLab, elas representam uma
funcionalidade ou partes de uma funcionalidade a serem implementadas, as issues
funcionam também como uma forma de organizar o cronogramas de desenvolvimento da
equipe. Cada issue recebe automaticamente uma numeração como forma de identificação
(Essa identificação deve ser referenciada nos commits). Nas próximas sessões é
demonstrado mais algumas funcionalidades configuráveis para cada issue como estimativas
de tempo e como utilizar o Issue board. É recomendavel seguir a documentação original
para mais detalhes sobre essa funcionalidade do GitLab, o material está disponível em
https://docs.gitlab.com/ee/user/project/issues/index.html#doc-nav.
Milestones são uma forma abstração do conceito de Sprints. Após a reunião de definição da
Sprint e de quais funcionalidades serão implementadas, uma milestone deve ser criada,
geralmente as milestones tem o prazo de uma semana (O prazo também é definido na
criação). As funcionalidades (features) a serem desenvolvidas, que foram selecionadas para
a sprint são então cadastradas como Issues e devem ser vinculadas a milestone que
representa a respectiva sprint. De forma sucinta a issue é uma funcionalidade (ou parte de
uma funcionalidade), e uma milestone é um conjunto de issues que representa a Sprint. Na
documentação oficial do GitLab estão informações mais detalhadas sobre as Milestones,
https://docs.gitlab.com/ee/user/project/milestones/.

Gitlab - Issue Board

A Gitlab Issue Board é uma ferramenta de gerenciamento de projetos de software usada
para planejar, organizar e visualizar um fluxo de trabalho para um recurso ou release de
produto. Pode ser usado como um Kanban ou Scrum Board.
Primeiro acesso
Para acessar o board procure navegar através do sidebar do projeto e encontre o Issues >
Board.
Figura 9 - Sidebar do gitlab
A primeira vez que você abrir o Issue Board, será apresentado uma lista contendo o
Backlog, onde você encontrará todas as issues do projeto, assim como uma lista de Issues
fechadas.

Figura 10 - Interface do primeiro acesso à issue board do gitlab
Criando uma nova lista

Também é apresentado uma mensagem de boas-vindas que lhe dará a opção de adicionar
listas padrão ao seu Issue Board, ou se optar por criar as próprias clique em “Add list” no
canto superior direito do Issue Board.
Figura 11 - Adicionar lista na issue board do gitlab

Escolha uma label para criar uma lista. A nova lista será inserida no final das listas, antes da
lista de issues fechadas.
Figura 12 - Interface com lista inserida na issue board do gitlab
Para mover e reordenar, basta arrastá-las. Para criar uma lista de um label que ainda não
existe, basta criar o label escolhendo a opção “Create new label”.
Figura 13 - Opção de criação de label

Definir um nome e uma cor para representar a label.
Figura 14 - Criando label

Adicionando issues a lista

Para adicionar uma issue em uma lista clique em “Add issues”, no canto superior direito da
Issue Board.
Figura 15 - Interface para adicionar issues em uma lista
Isso abrirá uma janela modal na qual você poderá ver todos os problemas que não
pertencem a nenhuma lista. Selecione uma ou mais issues clicando nos cards e, em
seguida, clique em “Add issues” para adicioná-los à lista selecionada. Você pode limitar as
issues que deseja adicionar à lista, filtrando por author, assignee, milestone and label.

Figura 16 - Opção de filtro para as issues
Após adicionar uma issue à lista, a Issue Boar será apresentada dessa forma.
Figura 17 - Interface com issue inserida em uma lista

Movendo uma issue entre listas

Comunique o seu progresso movendo uma issue entre duas listas para ajustar seus planos.
Quando terminar de trabalhar em uma issue, basta mover o card para a lista de issues
fechadas. O label será removido e a issue será fechada automaticamente.
Figura 18 - Interface com issue fechada na issue board do gitlab
Referências
PANDYA, Kushal. Issue Boards. 2018. Disponível em:
<https://docs.gitlab.com/ee/user/project/issue_board.html>. Acesso em: 14 ago. 2018.


Gitlab - Estimativas de Tempo

Como parte da etapa 6 no processo de desenvolvimento na Fábrica de Software, a
definição das estimativas das features é muito importante. O ideal é que, ao cadastrar uma
issue no Gitlab, seja informada uma estimativa de tempo para a conclusão dela.
Por que estimar?

Estimar e acompanhar o tempo gasto em uma issue é importante porque:
● Não estar consciente acerca do tempo necessário para resolver uma tarefa pode
acarretar em atrasos na entrega do produto;
● Acompanhando o tempo gasto em relação às tarefas desenvolvidas, é mais fácil

antecipar e corrigir problemas com prazos antes que estes se tornem graves;
● Documentar o tempo gasto com as tarefas pode te ajudar a criar uma base de
conhecimento.
Visão geral
O Gitlab oferece algumas funções de rastreamento de tempo em issues, merge requests e
milestones. Com elas, é possível estimar o tempo, bem como, adicionar o tempo gasto em
determinada issue.
Você não precisa indicar uma estimativa de tempo para informar um tempo gasto e vice
versa. Os dados sobre o rastreamento de tempo são exibidos no menu lateral da issue,
como mostra a figura a seguir.

Como inserir os dados

O rastreamento de tempo no Gitlab possui 2 comandos principais. São elas /spend e
/estimate. Você pode usar esses comandos na descrição de uma issue ou de um merge
request e em um comentário de ambos.
Ao utilizar o comando /estimate, você indica (usando sintaxe melhor descrita a seguir)
quanto tempo estima que precisará para finalizar determinada issue. O comando /spend é
utilizado para indicar o tempo gasto.
Inserindo Estimativas
Na Fábrica de Software, por padrão, informamos o tempo estimado ao cadastrar uma issue
(no campo Descrição). Portanto, esse processo ocorre apenas 1 vez no “ciclo de vida” de
uma issue.
Para cadastrar uma estimativa é utilizado o comando /estimate seguido do tempo. Por
exemplo, se você estima que precisará de 2 dias, 3 horas e 20 minutos para concluir uma
issue, você utilizará o comando /estimate 2d 3h 20m. Toda vez que uma nova estimativa é
cadastrada, qualquer estimativa anterior é sobrescrita. Por isso, para manter uma base de
registros confiáveis e entender quando há acertos e erros na estimativa cadastramos a
estimativa uma única vez.
Para remover completamente uma estimativa, utilize o comando /remove_estimate.
Adicionando Tempo Gasto

Adicionamos o tempo gasto em uma issue (por meio de Comentário) à medida em que
trabalhos nela. Para adicionar, por exemplo, 1 dia, 4 horas e 20 minutos ao tempo gasto em
uma issue você pode utilizar o comando /spend 1d 4h 20m. Sempre que o comando
/spend é utilizado, o tempo informado é adicionado ao tempo total atual da issue. É
possível remover uma quantidade de tempo gasto informando um valor negativo como
parâmetro, por exemplo, para remover 7 horas de tempo gasto, utilizamos o comando
/spend -7h. Para remover todo o tempo gasto de uma vez, utilize o comando
/remove_time_spent.
Configurações das Unidades de Tempo

As seguintes unidades de tempo são disponíveis:

● semana (w)
● dias (d)
● horas (h)
● minutos (m)
As taxas de conversão padrão são:
● 1 semana = 5 dias
● 1 dia = 8 horas
Como boa prática, recomendamos não criar issues com longa duração de tempo (por
exemplo de mais de 1 dia). Em vez disso, sugerimos “quebrar” essa issue em partes
menores.
Mas como estimar?

Uma técnica bastante recomendada e que utilizamos na Fábrica de Software é de
Estimativa de Três Pontos (PERT). Utilizando essa técnica, você considera a possibilidade
de percalços no desenvolvimento e coloca uma “gordurinha” na sua estimativa, evitando
erro no prazo estimado.
O uso da técnica PERT consiste em calcular a duração média de uma tarefa utilizando uma
estimativa otimista (O), uma mais provável de acontecer (MP) e outra pessimista (P) e
aplicando o seguinte cálculo:
P ERT = (O + 4 x M P + P ) / 6
Com isto, se você tem, por exemplo, uma tarefa/issue X com estimativa otimista de 3h, mais
provável de 6h e pessimista de 12h, o resultado seria uma média de 6h 30m para realizá-la:
X = (O + 4 x M P + P ) / 6 = (3 + 4 x 6 + 12 ) / 6 = 6h 30m

E como acompanhar o tempo gasto?

Na Fábrica de software nós utilizamos o WakaTime que é um plugin para métricas de
programação automatizadas. O passo a passo para utilizar o plugin para rastrear o tempo
gasto programando pode ser descrito da seguinte forma:
● Criar uma conta no WakaTime (caso ainda não tenha)
● Selecionar a opção IDEs Suportadas no menu lateral
● Escolher a IDE/Editor que utiliza (ex: Pycharm)
● Seguir as instruções da própria ferramenta
● Acompanhar o tempo gasto através da Dashboard do WakaTime
Exemplo de Dashboard no WakaTime
REFERÊNCIAS
DEVMEDIA. Estimativa de tempo em gerência de projetos de software. 2012.
Disponível em:
<https://www.devmedia.com.br/estimativa-de-tempo-em-gerencia-de-projetos-de-software-re
vista-engenharia-de-software-magazine-51/25757>. Acesso em: 16 ago. 2018.

PAGANI, Talita. Como estimar o esforço de desenvolvimento de software e por que

isso é tão difícil?: Parte 2. 2018. Disponível em:
<https://medium.com/@talitapagani/como-estimar-esforco-desenvolvimento-software-parte-
2-c60a60cb01d3>. Acesso em: 16 ago. 2018.
PAGANI, Talita. Como estimar o esforço de desenvolvimento de software e por que

isso é tão difícil?: Parte 1. 2018. Disponível em:
<https://medium.com/@talitapagani/como-estimar-esforco-desenvolvimento-software-parte-
1-2ab28c271943>. Acesso em: 16 ago. 2018.
GITLAB. Time Tracking. 2018. Disponível em:

<https://docs.gitlab.com/ee/workflow/time_tracking.html>. Acesso em: 16 ago. 2018.

Documentação do código-fonte
A documentação do código-fonte é uma etapa importante do processo. Projetos
desenvolvidos na Fábrica de Software do CEULP/ULBRA devem ser devidamente
documentados de acordo com cada caso.
Projetos Angular com códigos-fontes em JavaScript/TypeScript

Códigos-fontes em JavaScript/TypeScript devem ser documentados seguindo o padrão
JSDoc (http://usejsdoc.org/). A ferramenta Compodoc (https://compodoc.app/) pode ser
utilizada para gerar um site com a documentação completa do projeto1.
Projetos Python ou Django

Códigos-fontes em Python, de projetos puramente Python ou Django, devem ser
documentados seguindo o padrão de programação do Google para python
(https://github.com/google/styleguide/blob/gh-pages/pyguide.md) inclusive para
2
documentação de código, usando docstrings . Ao utilizar esse padrão pode ser utilizada a
ferramenta Sphinx (http://www.sphinx-doc.org/en/master/) para gerar um site com a
documentação completa do projeto.
Projetos PHP
Códigos-fontes em PHP devem ser documentados seguindo o padrão PHPDoc
(https://www.phpdoc.org/). A ferramenta, também disponível no site do padrão de
documentação, gera um site de documentação completa do projeto.
Guias gerais
As guias gerais a seguir devem ser seguidas na documentação de códigos-fontes:
● nos métodos, descrever lógica, parâmetros e estrutura esperada do retorno (ex.:

atributos do objeto do retorno)
● descrever atributos das classes e a sua utilidade (para que servem em seus
contextos)
1
Exemplo: Documentação do projeto "Noticias Angular", software da disciplina LPWEB, ministrada
pelo prof. Jackson Gomes: https://jacksongomesbr.github.io/webdevbook-noticias-angular/
2
Exemplo de código-fonte seguindo o guia de estilo do Google:
http://www.sphinx-doc.org/pt_BR/stable/ext/example_google.html

Padrões de Desenvolvimento: Processos e Tecnologias

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Padrões de Desenvolvimento: Processos e Tecnologias

Enviado por

Direitos autorais:

Formatos disponíveis

Padrões de desenvolvimento:

1.0.0 - agosto de 2018

Introdução - Git e GitLab 8

Clonando repositórios do GitLab 8

Branchs e Desenvolvimento controlado 10

Versionamento - Add e Commit 12

Atualizando o repositório remoto 16

GitLab - Issues e Milestones 19

Gitlab - Issue Board 21

Criando uma nova lista 22

Adicionando issues a lista 25

Movendo uma issue entre listas 27

Gitlab - Estimativas de Tempo 29

Fábrica de Software - CEULP/ULBRA

Por que estimar? 29

Como inserir os dados 30

Adicionando Tempo Gasto 30

Configurações das Unidades de Tempo 30

Mas como estimar? 31

E como acompanhar o tempo gasto? 32

Projetos Angular com códigos-fontes em JavaScript/TypeScript 34

Projetos Python ou Django 34

Fábrica de Software - CEULP/ULBRA

1. definição de participantes (devs, stakeholder, scrum master)

2. reunião de entendimento (todos)

a. stakeholder apresenta suas necessidades para a equipe

3. reunião de entendimento (devs e scrum master)

a. sugestão:​ aplicar técnica de brainstorm para ampliar as possibilidades de

b. sugestão:​ utilizar BPMN para modelagem dos processos do negócio em duas

c. sugestão:​ definir a arquitetura do software (não apenas em termos de

i. se necessário, reservar um tempo para nivelamento da equipe

d. sugestão:​ criar protótipo de baixa fidelidade (telas; em papel)

e. sugestão:​ repetir a reunião de entendimento até que o entendimento do

4. criação do ​projeto ​no Gitlab (com definição de funcionalidades para os usuários)

5. definição do product backlog (versão inicial, com dev e scrum master)

a. o resultado é uma lista de features (funcionalidades) que devem ser

b. sugestão:​ a descrição da issue deve ter o maior nível possível de

Fábrica de Software - CEULP/ULBRA

6. definição das estimativas das features utilizando pontuação por complexidade

a. ideal é que as issues sejam atualizadas com estimativa de tempo para

7. definição das sprints (todos)

a. o resultado é o agrupamento das features em sprints, que são representadas

8. reunião de revisão com stakeholder (validar sprints e estimativas das features)

a. sugestão:​ definir plano de lançamento de versões (utilizar versionamento

9. desenvolver por sprint

a. utilizar ​kanban (ex.: quadro de tarefas com: a fazer, fazendo, corrigindo,

b. iniciar ​branch​​ por milestone ou conjunto de issue (ex: feature/sprint-1)

i. mensagens de commits ​devem referenciar issues

ii. ideal é indicar o tempo gasto (real) para cada issue

d. sugestão:​ documentar código-fonte (explicar, tecnicamente, a nível de classe,

i. utilizar a sintaxe de documentação de código conforme a plataforma

e. sugestão:​ utilizar TDD (testes unitários e E2E)

f. reunião de revisão ao final da sprint (validar issues implementados e atualizar

i. reservar um tempo para os devs apresentarem o resultado da sprint

g. lançar ​tag (release)​​ e mesclar com o branch ​master​​ quando necessário

Fábrica de Software - CEULP/ULBRA

i. descrever itens adicionais, corrigidos ou removidos no ​CHANGELOG

h. reunião de validação com a presença do stakeholder, quando necessário

10. reunião de finalização (todos)

Fábrica de Software - CEULP/ULBRA

1. Banco de dados​​: PostgreSQL, MySQL (também pode-se utilizar SQLite ou MySQL

2. Cache​​: Redis, Memcache

3. Fila de mensagens​​: Celery

4. Plataforma/framework de desenvolvimento​​: Python, Java, PHP, Django (front-end

a. sugestão: aplicar técnica de brainstorm para ampliar as possibilidades de

b. sugestão: utilizar BPMN para modelagem dos processos do negócio em duas

c. sugestão: definir a arquitetura do software (não apenas em termos de

d. sugestão: criar protótipo de baixa fidelidade (telas; em papel)

e. sugestão: repetir a reunião de entendimento até que o entendimento do

4. criação do projeto no Gitlab (com definição de funcionalidades para os usuários)

b. sugestão: a descrição da issue deve ter o maior nível possível de

a. sugestão: definir plano de lançamento de versões (utilizar versionamento

a. utilizar kanban (ex.: quadro de tarefas com: a fazer, fazendo, corrigindo,

b. iniciar branch por milestone ou conjunto de issue (ex: feature/sprint-1)

i. mensagens de commits devem referenciar issues

d. sugestão: documentar código-fonte (explicar, tecnicamente, a nível de classe,

e. sugestão: utilizar TDD (testes unitários e E2E)

g. lançar tag (release) e mesclar com o branch master quando necessário

i. descrever itens adicionais, corrigidos ou removidos no CHANGELOG

1. Banco de dados: PostgreSQL, MySQL (também pode-se utilizar SQLite ou MySQL

2. Cache: Redis, Memcache

3. Fila de mensagens: Celery

4. Plataforma/framework de desenvolvimento: Python, Java, PHP, Django (front-end

5. Servidor web de produção: Apache, Nginx

● nível de dados: neste nível os projetos podem utilizar plataformas de

● nível de plataforma: neste nível os projetos devem utilizar a mesma plataforma de

● nível de fila de mensagem: neste nível os projetos podem utilizar plataformas e

1. sugestão: modelo de processos do negócio (diagrama BPMN)

a. sugestão: ao utilizar as ferramentas indicadas, gerar um site e torná-lo