Manifesto da Equipe
Introdução
As equipes da ISE trabalham com uma nova equipe de desenvolvimento em cada envolvimento com o cliente, o que requer uma fase de introdução e transferência de conhecimento antes de iniciar um envolvimento.
A conclusão desta fase de quebra-gelos e discussões sobre os padrões leva tempo, mas é necessária para começar a aumentar a curva de aprendizado da nova equipe.
Um manifesto da equipe é um documento ágil de uma página entre os membros da equipe que resume os princípios e valores básicos da equipe e visa fornecer um consenso sobre as expectativas técnicas de cada membro da equipe para entregar um resultado de alta qualidade no final de cada envolvimento.
O objetivo é reduzir o tempo na definição das expectativas corretas sem organizar reuniões mais longas de “leitura de documentos da equipe” e fornecer um consenso entre os membros da equipe para responder à pergunta - “Como a nova equipe desenvolve o software?” - abrangendo todos os tópicos fundamentais de engenharia e excelência, como processo de lançamento, codificação limpa, testes.
Outro objetivo principal de escrever o manifesto é iniciar uma conversa durante a “sessão de construção do manifesto” para detectar quaisquer diferenças de opinião sobre como a equipe deve trabalhar.
Ele também serve da mesma forma quando um novo membro da equipe se junta à equipe. Novos integrantes podem se atualizar rapidamente sobre os padrões acordados.
Como Construir um Manifesto da Equipe
Pode-se dizer que o melhor momento para começar a construí-lo é na fase muito inicial do envolvimento, quando as equipes se encontram umas com as outras para swarming ou durante a fase de preparação.
É recomendado manter o manifesto da equipe o mais simples possível, então, de preferência, um documento simples de uma página que não inclui quaisquer referências ou links é um bom formato para ele. Se houver necessidade de fornecer conhecimento sobre certos tópicos, a forma de fazer isso é realizar sessões brown-bag, katas técnicas, práticas de equipe, documentações e outros posteriormente.
Alguns pontos importantes sobre o manifesto da equipe:
- O manifesto da equipe é construído pela própria equipe de desenvolvimento
- Deve cobrir todos os pontos técnicos de engenharia necessários para a excelência, bem como itens de mentalidade de agilidade comportamental que a equipe considera relevantes
- Visa dar um entendimento comum sobre a expertise, práticas e/ou mentalidade desejadas dentro da equipe
- Com base nas necessidades da equipe e nos resultados da retrospectiva, ele pode ser modificado durante o envolvimento.
Na ISE, buscamos qualidade em vez de quantidade, e software bem elaborado, bem como um ambiente confortável/transparente onde cada membro da equipe possa alcançar seu maior potencial.
A diferença entre o manifesto da equipe e outros documentos da equipe é que ele é usado para dar um breve resumo das expectativas em torno da forma técnica de trabalhar e da mentalidade apoiada na equipe, antes que os sprints de code-with comecem.
Abaixo, você pode encontrar alguns tópicos que muitas equipes abordam durante os envolvimentos,
| Tópico | Sobre o que é? |
|---|---|
| Propriedade Coletiva | A equipe possui o código em vez de indivíduos? Qual é a expectativa? |
| Respeito | Qualquer declaração preferida sobre ser um valor “obrigatório” da equipe |
| Colaboração | Qualquer declaração preferida sobre como a equipe deseja colaborar? |
| Transparência | Uma simples declaração sobre ser um valor “obrigatório” da equipe e, se preferir, como isso é fornecido pela equipe? reuniões, retrospectivas, mecanismos de feedback, etc. |
| Expertise em Ferramentas de Desenvolvimento | Quais ferramentas, como Git, VS Code LiveShare, etc., estão sendo usadas? Qual é a definição do uso esperado delas? |
| Dimensionamento de PR | O que a equipe prefere em PRs? |
| Branching | Estratégia e padrões de branches da equipe |
| Padrões de Commit | Formato preferido nas mensagens de commit, regras e mais |
| Código Limpo | A equipe segue princípios de código limpo? |
| Programação em Par/Enxame | A equipe aplicará programação em par/enxame? Se sim, quais estilos de programação são adequados para a equipe? |
| Processo de Lançamento | Princípios em torno do processo de lançamento, como portões de qualidade, processo de revisão…etc. |
| Revisão de Código | Qualquer regra para revisão de código, como número mínimo de revisores, regras da equipe…etc. |
| Prontidão para Ação | Como o backlog será refinado? Como garantimos uma clara Definição de Concluído e Critérios de Aceitação? |
| TDD | A equipe seguirá TDD? |
| Cobertura de Teste | Existe algum número, porcentagem ou medida esperada? |
| Dimensões em Testes | Testes necessários para software de alta qualidade, por exemplo: unitários, integração, funcionais, desempenho, regressão, aceitação |
| Processo de Construção | Construir para todos? ou não; A declaração clara de onde o código e sob quais condições o código deve funcionar? por exemplo: SO, DevOps, dependência de ferramenta |
| Correção de Bugs | As regras para correção de bugs na equipe? por exemplo: pessoas de contato, anexando PR ao problema, etc. |
| Dívida Técnica | Como a equipe gerencia/segue isso? |
| Refatoração | Como a equipe gerencia/segue isso? |
| Documentação Ágil | A equipe deseja usar diagramas e tabelas mais do que artigos detalhados do KB? |
| Documentação Eficiente | Quando é necessário? É um pré-requisito para concluir tarefas/PRs etc.? |
| Definição de Diversão | Como nos divertiremos para relaxar/desfrutar do espírito de equipe durante o envolvimento no projeto? |
Ferramentas
Geralmente, sessões de equipe são suficientes para construir um manifesto e chegar a um consenso em torno dele, e se houver necessidade de melhorá-lo de forma estruturada, existem muitos blogs e ferramentas online, qualquer ferramenta de retrospectiva pode ser usada.