A metodologia aplicada netes projeto será uma metodologia híbrida baseada nos frameworks Scrum, Extreme Programming e Kanban. Abaixo segue a descrição de quais técnicas serão aplicadas e como cada uma deve ser seguida.

Papéis

Scrum Master

São responsabilidades deste papel:

  • Garantir a dissiminação do conteúdo por meio da aplicação de técnicas que constam nesse plano de metodologia. Ex.: Pareamento;
  • Remover obstáculos do desenvolvimento e minimizar os riscos do projeto;
  • Definir, monitoriar e melhorar a produtividade por meio de métricas coletadas sobre o projeto;
  • Garantir a execução da metodologia conforme está definido neste plano.

Product Owner

São responsabilidades deste papel:

  • Levantar os pontos importantes que mais agregam valor ao produto do ponto de vista dos stakeholders;
  • Definir os critérios de aceitação para uma issue;
  • Garantir a boa usuabilidade do que está sendo implementado.

DevOps

São responsabilidades deste papel:

  • Verificar e aceitar os pull requests de acordo com os critérios definidos pelo Scrum Master e o PO;
  • Garantir o disponibilidade dos ambientes de desenvolvimento, homologação e produção;
  • Configurar integração e deploy contínuo;
  • Registrar o gitflow.

Arquiteto

São responsabilidades deste papel:

  • Organizar e modelar a arquitetura do sistema;
  • Acompanhar o processo de desenvolvimento para garantir que a arquitetura está sendo seguida.

Desenvolvedor

São responsabilidades deste papel:

  • Desenvolver a história;
  • Testar sempre as soluções. visando mantes no mínimo 90% da corbetura do código;
  • Seguir os padrões e técnicas de programação adotados pelo Scrum Master.

Rituais

Sprints

  • Duração de 7 dias
  • Todas as sprints se iniciaram na quarta-feria e terão seu término na terça-feira da semana seguinte.
    • Sprints que antencedem as releases poderão ser: encurtadas para sprints de 4 dias ou emendadas com a sprint anterior, gerando sprints de 11 dias. Será responsabilidade do Scrum Master, avaliar previamente, conforme andamento da equipe, qual a melhor opção será aplicada.

Daily Meeting

  • Duração Máxima: 15 minutos
  • Realizadas diariamente às 15:45h
  • A ausência destas reuniões deverá ser previamente comunicada pelo membro da equipe e justificada. Sendo obrigação do mesmo informar o andamento das duas atividades neste dia pelos meios de comunicações definidos pela equipe.

Sprint Review

  • Duração Máxima: 1,5 horas
  • Ocorrerão toda terça-feira, tendo início as 18h

Sprint Restropective

  • Duração Máxima: 30 minutos
  • Ocorrerão toda terça-feira, tendo início as 19h

Sprint Planning

  • Duração Máxima: 2 horas
  • Ocorrerão toda quarta-feira, tendo início as 16hh

Técnicas de Planejamento

Issues

  • As issues serão aplicadas para representar os mais diversos tipos de tarefas que o projeto demandar.

  • Devem ser classificadas por meio das labels. Seguindo o seguinte padrão:

    • Responsável
      • Labels identificadas pelo número 0.
      • Possíveis valores:
        • Arquiteto
        • Time de Desenvolvimento
        • Scrum Master
        • Product Owner
        • Devops
        • Integra App.
    • Tipo de atividade
      • Labels identificadas pelo número 1.
      • Possíveis valores:
        • API
        • Frontend
        • Feedback
        • Documentação
        • Infraestrutura
        • Integração (Integração entre frontend, backend e outros serviços)
        • Product Backlog
        • Protótipo
        • Tarefa
        • Treinamento
    • Especificação da atividade
      • Labels identificadas pelo número 2.
      • Possíveis valores:
        • Comunidade de Software
        • Deploy Contínuo
        • Integração contínua
        • Desing
        • Marketing
        • Métricas e Indicadores
        • Funcionalidade
        • Abertura do Projeto
        • Especificação do Projeto
        • História Técnica
        • Viabilidade técnica
    • Status da issue na sprint
      • Labels identificadas pelo número 3.
      • Possíveis valores:
        • Adicionada
        • Planejada
        • Débito
    • Análise sobre a issue
      • Labels identificadas pelo número 4.
      • Possíveis valores:
        • Duplicada
        • Invalida
        • Removida
        • Dúvida
        • Não será resolvida

    Outras labels podem ser adicionadas ao projeto conforme a necessidade que for surgindo;

  • Para termos de organização, as issues serão classificadas como planejadas ou adicionadas em cada sprint:
    • Issues planejadas: são aquelas previstas no durante o Sprint Planning para desenvolver durante aquela sprint;
    • Issues adicionadas: são aquelas que não foram previstas no Sprint Planning, mas foram desenvolvidas naquela sprint devido a alguma justificativa identificada pelo Scrum Master.

Milestones

  • As milestones serão aplicadas para identificar cada sprint. Entende-se que cada sprint representa uma entrega significativa de novas funcionalidades, caracterizando-se assim como macros do projeto.
  • Toda issue planejada ou adicionada para ser executada durante aquela sprint deve ser mapeada com a milestone referente.

Épicos

  • Issues referentes a um mesmo módulo dentro do projeto devem estar associadas a épicos, como forma de mapear melhor o desenvolvimento daquele épico em específico.
  • Épicos também podem ser usados para representar issues muito grandes, com alto grau de dificuldade. Assim, quebra-se essas issues complexas em issues menores facilitando o desenvolvimento.

User Stories

  • Serão aplicadas na estimativa de tempo para planejamento da sprint;

  • Deverão seguir o seguinte template:

    Eu como [usuário do sistema] desejo [ação a ser executada] para [justificativa para a ação].
  • Este template deve estar mapeado em uma Issue Template;
  • Cada user story deve possuir um conjunto de critérios de aceitação definidos pelo PO, os quais deverão ser verificados antes de afirmar a tarefa como concluída.

Technical Stories

  • Techinical Stories devem ser aplicadas quando surgir alguma demanda não funcional durante o andamento do projeto.
  • Deverão seguir o mesmo templete definido para as user stories.

Planning Poker

  • Deverá ser aplicado para estimar a dificuldade de trabalho do projeto e auxiliar no planejamento das sprints, conforme nota-se a capacidade de produção da equipe;
  • Os pontos estimados para uma issue devem estar registrados na mesma por meio do ZenHub;
  • Os valores considerados deverão ser: 0, 1, 2, 3, 5, 8, 13 e 21.
  • Issues com mais de 13 pontos devem ser transformadas em Épicos e quebradas em issues menores, para facilitar o desenvolvimento do projeto.

MosCow

O backlog deve ser priorizado utilizando o método MosCow, o qual está disposto abaixo:

Must have Tem que ter
Should have Deveria ter
Could have Pode ter
Would have Seria bom ter

Kanban

O Kanban será aplicado visando monitorar o fluxo de trabalho da equipe.

  • O Kanban deverá contar com os quadros Product Backlog, Icebox, Sprint Backlog, Em progresso, Revisão e Terminados;
  • É de responsabilidade de cada membro da equipe atualizar o Kanban diariamente com o status de cada atividade;
  • O Kanban estará disponível por meio da ferramenta ZenHub.
  • Acessar o Kanban.

Técnicas de Gerenciamento

Velocity

  • O velocity deve ser medido ao final de cada sprint e utilizado no planejamento da próxima sprint como parâmetro para avaliar a capacidade da equipe de desenvolvimento.

Burndown

  • O burndown deve ser aplicado sobre cada sprint com o intuito de monitorar a entrega das atividades planejadas.
  • É responsabilidade do Scrum Master acompanhar o gráfico durante a sprint e tomar ações para garantir as entregas ao final da sprint.
  • O gráfico de burndown será gerado automaticamente pela ferramenta ZenHub a medida que o KanBan é atualizado pela equipe.

Técnicas de Codificação

Programação em Pares

  • Os pares da sprint deverão ser definidos durante o Sprint Planning;
  • O Scrum Master é responsável por formar os pares;
  • O quadro de conhecimentos deve ser o indicador de maior peso na formação dos pares, sendo que desenvolvedores com mais experiência em determinada área deve parear com quem possui menos conhecimento na mesma.

Integração Contínua

  • As branchs master e devel estarão submetidas ao processo de integração contínua, devendo respeitar o mínimo de 90% da cobertura de testes;
  • Todo pull request realizado para branch devel estará sujeito ao processo de integração contínua.

Padrões de Codificação

  • O código deve ser formato seguindo os padrões de estilo e técnicas de programação adotadas pela equipe, visando assim garantir a qualidade do código gerado.

Técnicas de Design

Simplicidade

  • Ao manusear o código a equipe deve priorizar sempre a solução mais simples que atenda as necessidades do problema.

Refatoração

  • Ao manusear o código, sempre que houver dificuldade para compreensão do mesmo a equipe deve se organizar para refatorá-lo.
  • A refatoração deve ser realizada antes de fazer qualquer alteração na funcionalidade, visando garantir a integridade do código.

Outros Documentos