Criação da Proposta de Melhoria

[joaopaulonsoares]

Processo de Desenvolvimento

• [x] Reunião Diária
• [x] Papéis (P.O, Team, Scrum Master)
• [x] Pareamento
• [x] Integração contínua ( API não possui )
• [x] Padronização do código

Requisitos

Qualidade

• [ ] Fazer GQM
  • [ ] Template de objetivos
  • [ ] Folha de abstração GQM
  • [ ] Nível conceitual (objetivos)
  • [ ] Nível operacional (questões)
  • [ ] Nível quantitativo (métricas)

[joaopaulonsoares]

Todos os resultados devem ser inseridos no documento correspondente a fase de Proposta de Melhoria , onde os mesmos devem ser documentados seguindo os templates estabelecidos no mesmo.

[joaopaulonsoares]

Atribuições dos Membros:

Processo de Desenvolvimento

• [x] Reunião Diária [ Pedro Ivo ]
• [x] Papéis (P.O, Team, Scrum Master) [ Thiago ]
• [x] Pareamento [ Jonathan ]
• [x] Integração contínua ( API não possui ) [ Igor ]
• [x] Padronização do código [ Allan ]

Requisitos

Qualidade

• [x] Fazer GQM [ João Paulo e Roger ]
  • [ ] Template de objetivos
  • [ ] Folha de abstração GQM
  • [ ] Nível conceitual (objetivos)
  • [ ] Nível operacional (questões)
  • [ ] Nível quantitativo (métricas)

[thiagonf]

O estado atual dos papéis no processo de desenvolvimento foi verificado que o mesmo se encontra não definido e não implementado. O recomendado a ser feito para melhorar tanto o entendimento do processo quanto a própria atividade seriam os seguintes pontos: 1 - Separar por raias de papéis o processso, facilitando assim o entendimento de onde cada papel entra e verificar qual atividade está atribuida a quem. 2 - Definição em um documento formal sobre o que é cada papel para caso de dúvida durante o processo sobre o que são suas atribuições e deveres ter um local de fácil acesso para recorrer. 3 - Definição em um tópico da atividade de retrospectiva de sprint quem foi alocado para cada papel, facilitando a identificação de quem deve responder pelas atividades atribuidas ao processo.

[freemanpivo]

Reunião Diária

Conforme estabelece o SCRUM e foi definido pelo processo da Equipe GoHorse+, há a necessidade de realizar reuniões em paralelo com as atividades de desenvolvimento. É esperado que as atividades da Organização utilizem o que a literatura prevê como melhores práticas. Devido à reunião diária ser de difícil realização porque é impossível que as equipes se encontrem diariamente no mesmo horário e no mesmo local, a Organização pensou em duas abordagens que não estão previstas na literatura, mas podem se adequar ao contexto do trabalho interno.

A primeira opção determina a utilização de um canal no slack exclusivamente para a equipe de desenvolvimento, e estes membros devem realizar a reunião por tal ferramenta nos períodos de segunda a sexta-feira, abstraindo como dias úteis de trabalho. Essa opção prevê que os integrantes deêm o feedback do que foi implementado, as dificuldades, alinhamento de ideias, dentre outras discussões, até as 21:00 do dia vigente.

A segunda opção determina a utilização da reunião periódica, presencial, nos horários de aula (14:00 às 16:00) com duração máxima de 20 minutos, em que os membros discutem o andamento do projeto, suas dificuldades, possíveis soluções, e alinhamento de ideias. Os dias da semana se restringem a terça e quinta-feiras (dias em que teoricamente os alunos devem estar em sala de aula da Faculdade da UnB - Gama). A utilização deste método, permite que a equipe de desenvolvimento tenha horários de trabalho bem definidos, foco em produção de funcionalidades, e evitaria que tarefas fossem adiadas, porque garantiria que as equipes estivessem integradas.

[joaopaulonsoares]

Fazer GQM

Recomenda-se que o processo de medição e análise da organização seja construído de acordo com as diretrizes do GQM, já que o resultado do GQM é um processo de medição bem definido. Sendo assim, se faz necessário que o processo de Medição e Análise da organização Go-horse+ seja reorganizado e refeito, de maneira realizar as fazes previstas no modelo.

Para isso, a equipe de melhoria do processo faz as seguintes recomendações:

1. Realizar uma nova modelagem do processo, onde as atividades sejam separadas de acordo com cada uma das fazes do GQM:
   1. A fase de planejamento, durante a qual um projeto da organização é selecionado para a aplicação da medição, os times do GQM são estabelecidos e treinamentos são feitos.
   2. A fase de definição, durante a qual o programa de medição é definido, sendo identificados os objetivos da organização e do projeto, as questões relacionadas a esses objetivos e as métricas que ajudam a responder essas questões, com o uso de abstraction sheets para definir métricas prováveis e fatores que impactam essas métricas para cada foco de qualidade. Além disso, é necessário produzir de o plano GQM, o plano de medição, que descreve quem irá coletar a métrica, em qual momento, e com qual ferramenta, descrevendo em detalhes as ferramentas utilizadas para a coleta, e o plano de análise, que define, com dados hipotéticos, como cada métrica deve ser analisada.
   3. A fase de coleta de dados, na qual os dados são de fatos coletados, seguindo as diretrizes definidas no plano GQM e no plano de medição.
   4. A fase de interpretação, na qual os dados coletados são processados e interpretados, fornecendo respostas para as perguntas definidas em fases anteriores e também onde são gerados os relatórios de feedback da organização..

Também é recomendado que se descreva, nas atividades do processo, o papel responsável por desempenhar e executá-la.

Ao final das fases de planejamento e definição, o plano GQM e seus artefatos derivados devem, em conjunto, conter, pelo menos, as seguintes seções finalizadas:

• Template de Objetivos;
• Folha de abstração;
• Nível conceitual (Goal - Objetivos);
• Nível operacional (Question - Perguntas);
• Nível quantitativo (Metric - Métricas);
• Plano de Medição

[igor-gme]

Integração Contínua (api)

De acordo com as boas práticas do XP, recomenda-se que todo o incremento de código deva passar por uma build automatizada para verificar, de forma fácil e mais rapidamente, se o novo código que foi desenvolvido quebrou ou não o que já estava funcionando, para que assim, seja possível arrumá-lo rapidamente.

Na auditoria para verificar o estado atual do processo de desenvolvimento, foi identificado que não há nenhum documento que defina o uso da integração contínua (CI). Recomenda-se, para que fique evidenciado que a integração contínua deve ser utilizada, a criação de uma política de desenvolvimento que especifique a importância da utilização desse recurso. Observando o processo de desenvolvimento, esta política pode ser associada tanto na atividade de Desenvolver quanto na de atividade de Testar.

[JonathanRufino]

Pareamento

Outra prática recomendada pelo XP, é a programação em pares. Esta prática auxilia no desenvolvimento de soluções de software com maior qualidade em comparação ao seu desenvolvimento por uma única pessoa. Essa maior qualidade se da por alguns benefícios listados abaixo:

• Detecção de bugs devido as diferentes percepções dos desenvolvedores envolvidos, já que a pessoa que está em posse do teclado tem uma percepção do código diferente de quem está apenas observando, permitindo assim que o observador pense em situações problemáticas que seu parceiro não percebu.
• Simplicidade do código devido à colaboração mútua entre os desenvolvedores que permite a otimização e escolha da melhor solução para o problema
• Maior produtividade devido ao tempo de foco na atividade se manter constante pelo fato da atividade ser desenvolvida em dupla, diminuindo o tempo de distrações como por exemplo checar emails e outras distrações.
• Disseminação do conhecimento, apontada como uma das principais características do pareamento. Esse benefício é proveniente da rotatividade no pareamento, já que um desenvolvedor trabalha com outro desenvolvedor B e num momento posterior com o desenvolvedor C. Neste segundo momento é explicado o que foi realizado anteriormente e assim o conhecimento rotaciona rapidamente.

Durante a análise entre o processo ideal e o processo atual foi identificado que esta técnica não está descrita no processo mas está Implementada em grande parte. Para que fique claro que a técnica deve ser utilizada durante o desenvolvimento recomenda-se a criação de uma política de desenvolvimento contendo as diretrizes básicas para desenvolvimento, sendo uma delas possíveis técnicas a serem utilizadas, como o pareamento, e que esta política esteja associada com as atividade de Desenvolver e Testar que fazem parte do processo de desenvolvimento.

Recomenda-se ainda que seja estipulado um mínimo de pareamentos a ser realizado durante a sprint para que se garanta a utilização da técnica, e quando possível realizar o planejamento dos pareamentos ao iniciar a sprint.

Já para que seja evidenciado a utilização do pareamento os commits que foram realizados em pares devem fazer o uso do recurso Co-authored-by para registrar os desenvolvedores envolvidos.

[maugustoo]

Padronização de código

Segundo o estado desejado e a literatura, a padronização de código é necessária pelo fator de diferentes pessoas mexerem e adicionarem incrementos ao código ao mesmo tempo, e então essa padronização auxilia no entendimento do mesmo.

No estado atual está definido que a padronização de código está Não documentada (ND) e Implementada em grande parte (IG), pois por mais que não exista uma documentação que comprove como deve ser essa padronização o pode-se ver uma padronização em grande parte do sistema.

Dado essa visão de como está sendo feito a padronização do código, é necessário definir uma política no processo de desenvolvimento que diga que uma folha de estilo para o sistema front-end e outra para o back-end para então termos um modelo de padronização de código a seguir.

Essa política pode ser definida como uma política na atividade do processo Planejamento da release, deixando bem explícito que os incrementos de código gerados devem seguir a folha de estilo determinado pela equipe de desenvolvimento.

[freemanpivo]

A proposta de melhoria, de fato aprovada, encontra-se nesse link: Proposta de Melhoria APROVADA.

A sidebar da Wiki também já foi atualizada com o link da Proposta aprovada em reunião do dia 17 de Maio de 2018.