Proposta de Melhoria

1. Estabelecendo Proposta de Melhoria

De acordo com o Processo Ideal, a equipe está na Fase de Estabelecimento, a qual demanda que uma Proposta de Melhoria do Processo seja desenvolvida. Essa proposta deve:

• Apresentar os GAPs alvos (priorizados) desse ciclo de melhoria, encontrados na fase de Diagnóstico;
• Explicitar como esses GAPs serão traduzidos para melhorias no processo definido;
• Expor uma estratégia macro de aplicação das melhorias;

A fase de Estabelecimento compreende o período de 16 de Maio até 17 de Maio, onde esta será a data de apresentação da proposta para toda a equipe do Projeto.

A fase de Ação, onde as melhorias serão aplicadas, deve compreender o período do dia 18 de Maio ao dia 21 de Maio, de modo que o processo melhorado seja "rodado" (seguido), possibilitando que a Fase de Lições seja executada, observando os resultados obtidos através da execução deste processo melhorado.

2. GAPs priorizados

GAP	Completude	Observações
Reunião Diária	Completamente Definido (CD)	Foi estabelecido que a reunião diária encontra-se como (CD) mas ela na verdade encontra-se como Parcialmente Definida (PD), pois não há definições de locais, horários da reunião periódica
Papéis	Não definido (ND) e não implementado (NI)	---
Fazer GQM	ND	Esse GAP compreende um conjunto de GAPs do processo de medição e análise
Integração Contínua (api)	ND	---
Padronização de código	Não documentada (ND) e Implementada em grande parte(IG)	É difícil encontrar uma área do processo para alocar essa tarefa
Pareamento	Não definido	Não definido (ND) e implementado em grande parte (IG)

3. Proposta de Melhoria

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

3.2 Papéis

Conforme estabelece o SCRUM e foi definido pelo processo da Equipe GoHorse+, existe a necessidade de se definir os papéis no processo. É esperado que a Organização siga os papéis definidos pelo SCRUM, tais como: Product Owner, Scrum Master e Time.

De acordo com 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 processo, facilitando assim o entendimento de onde cada papel entra e também a verificação de qual atividade está atribuída a qual papel.
2. Definir as atribuições de cada papel em um documento formal, facilitando então a compreensão dos papéis durante o processo de desenvolvimento.
3. Definição em um tópico da atividade de planejamento da sprint quem foi alocado para cada papel, facilitando a identificação de quem deve responder pelas atividades atribuídas ao processo.

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

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

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

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

4. Estratégia de Aplicação das Melhorias

A aplicação das melhorias será feita do dia 18 ao dia 21 de Maio, de modo que todos os GAPs priorizados devem ser corrigidos no processo de acordo com a proposta de melhoria aceita. Essas correções devem ser todas aplicadas neste período de tempo para que no dia 22 de Maio o processo melhorado seja executado.

Dessa forma, a estratégia de aplicação de melhorias será moldada por "ciclos de melhorias" e com períodos de ação definidos pela equipe de processo; deve haver também uma data fixa para que o processo melhorado comece a ser executado.