Agile e equipes

Este capítulo traduz trabalho em equipe para a Oficina Costeira, de um jeito que você consegue ensaiar sozinho. A Oficina Costeira é um coletivo fictício de design em João Pessoa. Este volume tem 52 capítulos. Esta é a 48.

O exemplo está em exemplos/48-agile-equipes/. Não há software de empresa para instalar. Há ritmo, quadro, conversa clara, issues e um teste de uso com tarefas. Ciclo: ler, copiar, mudar uma coisa, prever, recarregar, conferir.

O que você vai aprender

• Ver Agile como entrega pequena e frequente, não como reunião eterna.
• Planejar um sprint de estudo com começo e fim.
• Escrever recados que outra pessoa (ou você amanhã) entende.
• Usar issues como quadro: a fazer, fazendo, feito.
• Montar um teste de usabilidade curto, com tarefas e sem humilhar.
• Simular equipe sem inventar colegas reais.

Entrega pequena, conversa cedo

Agile, neste volume, cabe em frases curtas. Você entrega um pedaço que abre no navegador. Mostra. Ouve. Ajusta. Não espera o “site perfeito” para o primeiro clique.

Ideias que importam na Oficina Costeira:

• o site de estudo já existe e cresce;
• o pedido muda (a agenda ganha um encontro fictício);
• conversa clara vale mais do que um PDF de cem páginas;
• o ritmo precisa ser sustentável: uma frente por vez.

Você não vai “implementar Scrum de empresa”. Vai usar um sprint de poucos dias: escolher três tarefas, fazer, revisar, anotar o que travou.

Tarefa boa: “Documentar o botão em padroes.html”. Tarefa ruim: “deixar o site profissional”. A ruim não termina e não se confere.

Mude só o recorte da semana: escreva em um papel (ou no README) três tarefas da Oficina Costeira. Preveja se cada uma tem um arquivo para abrir no fim. Confira. Se a tarefa não aponta para um HTML, quebre.

Erro comum: sprint de vinte tarefas “para aproveitar o fim de semana”. Nada fecha. O quadro mente.

Um sprint de estudo da Oficina Costeira cabe em três dias. Dia 1: escolher as cartelas e abrir as páginas. Dia 2: mudar o HTML ou o CSS. Dia 3: Tab, zoom, tela estreita, escrever o que ficou para o próximo ciclo. Se o pedaço não abre no navegador no dia 3, a cartela não foi para Feito. Foi para “ainda fazendo”.

O manifesto ágil fala em pessoas e em resposta a mudança. Tradução para este volume: converse cedo, mostre a página cedo, aceite que a agenda fictícia vai ganhar um item. Não reescreva o site inteiro porque o cartaz da orla mudou de tom.

Quadro: a fazer, fazendo, feito

Um quadro visual evita a lista infinita. Três colunas bastam.

Uma pessoa (mesmo que seja você) só deveria ter uma ou duas cartelas em “Fazendo”. O resto espera.

No GitHub, a issue é a cartela. Título curto. Corpo com “o que”, “como conferir”, “fora de escopo”. Etiquetas opcionais: html, css, texto.

Título: Corrigir aria-current em agenda.html

O que: o menu de Agenda deve marcar a página atual.
Como conferir: abrir agenda.html, ler o HTML do link Agenda.
Fora: não publicar; não mudar o visual do menu.

Mude só o título da issue de rascunho para incluir o nome do arquivo. Preveja: quem ler acha o caminho. Confira se o caminho existe na pasta do exemplo.

Erro comum: issue “CSS” sem dizer a página. Ninguém sabe onde terminar.

Você pode desenhar o mesmo quadro num caderno. Coluna esquerda: a fazer. Meio: fazendo. Direita: feito. Uma cartela de papel por frente. O GitHub não é obrigatório para aprender o ritmo. É um jeito de gravar o quadro se o grupo já estiver num repositório.

Mova só uma cartela por vez. Preveja o quadro depois da mudança. Confira nas páginas. Se “Foco visível no botão” foi para Feito, abra padroes.html, aperte Tab e veja o contorno de 3 px. Sem esse clique, a coluna direita é fantasia.

Comunicação que não enrosca

Equipe se perde em recado vago. Prefira:

• o arquivo (contato.html);
• o que a pessoa vê (o botão não recebe foco);
• o que você já tentou (o outline está no a, não no button);
• o que não é (não é para enviar o formulário de verdade).

Evite tom de acusação. “O menu quebrou em equipe.html depois do commit X” é útil. “Você não sabe HTML” não é processo, é briga.

Sozinho, escreva o recado mesmo assim. Amanhã você é outra pessoa. O commit também é recado: uma frase dizendo o porquê.

Não coloque dado pessoal no quadro. Personagens: Lina, Rui, Nara. Projetos: Farol da Restinga, Guia da Lagoa, Ateliê da Pedra. Tudo inventado.

Stand-up, se houver dupla, dura cinco minutos: o que abriu ontem, o que trava hoje, se alguém precisa de revisão. Não transforme isso em aula de CSS. Se o card quebrou, abra projetos.html juntos e apontem o arquivo.

Mude só um recado seu de “ajusta isso” para um recado com nome de arquivo. Preveja se um colega fictício conseguiria agir. Confira.

Erro comum: discutir visual por vinte mensagens sem abrir a página. Abra 127.0.0.1, tire uma nota objetiva, volte.

GitHub como quadro, não como vitrine

Issues, projeto em colunas e pull request cobrem o ritmo. Você pode ensaiar sem conta: um arquivo QUADRO.md na pasta de estudo com as três colunas.

Se o grupo já usa GitHub, combinados:

• uma issue por frente;
• branch com nome da frente;
• pull request aponta a issue;
• revisão olha o exemplo abrindo, não só o diff.

Ninguém precisa de ferramenta paga. Ninguém precisa expor o exercício ao mundo.

Servidor de conferência:

python -m http.server 8769 --bind 127.0.0.1 --directory curso

Quem testa visita http://127.0.0.1:8769/exemplos/48-agile-equipes/. Encerre com Ctrl+C. Não use 0.0.0.0.

Mude só a coluna da tarefa “Skip-link” para Feito depois de abrir cada página e apertar Tab. Preveja o quadro honesto. Confira nas cinco páginas. Se uma falhar, a cartela volta para Fazendo.

Erro comum: marcar Feito porque o código foi escrito, sem abrir o navegador.

Teste de usabilidade em cinco tarefas

Teste de uso não é prova. É ver alguém (ou você com um roteiro) tentar tarefas e calar a boca enquanto a pessoa tenta.

Roteiro fictício da Oficina Costeira:

1. Descubra o que o coletivo faz, a partir da home.
2. Ache o projeto Farol da Restinga.
3. Veja quem é a personagem de acessibilidade.
4. Encontre a agenda.
5. Localize o formulário e perceba que ele não envia nada.

Você observa: onde a pessoa hesita, onde clica, se o menu basta, se o h1 ajuda. Anota. Agradece. Não defende o layout no meio do teste.

Depois você muda uma coisa (texto do link, ordem do menu, h1 mais claro) e testa de novo. Melhoria progressiva também vale para o processo.

Sozinho: imprima as cinco tarefas, espere um dia, execute como se não conhecesse a pasta. Ou peça a alguém da casa para clicar, sem explicar o menu antes. Não grave a pessoa. Não colete dado.

Mude só o texto do link Projetos para Nossos trabalhos fictícios. Preveja a tarefa 2 mais fácil ou mais longa. Recarregue. Peça a você mesmo para achar o Farol. Confira.

Erro comum: interromper o teste com “é só clicar ali”. O silêncio é o dado.

Equipe fictícia, você real

Lina, Rui e Nara não precisam de e-mail. Se você estuda em dupla, dividam páginas, não personalidades. Uma pessoa no HTML da agenda, outra no CSS do card, as duas conferem teclado.

Retrospectiva de dez minutos no fim do sprint:

• o que abriu no navegador;
• o que travou;
• uma mudança no quadro da próxima rodada.

Não publique o site. Não use o teste de usabilidade para expor colega. Formulário continua demonstrativo.

Abra exemplos/48-agile-equipes/index.html. Percorra as cinco tarefas. Anote um atrito. Essa anotação é o produto deste capítulo, tanto quanto o HTML.

Se estiver solo, escreva a retrospectiva num QUADRO.md da pasta de estudo, não no site publicado. O site da Oficina Costeira não precisa exibir o quadro da equipe. Visitante vê o coletivo fictício. Quem constrói vê o quadro.

Um ciclo inteiro, resumido: três cartelas, um sprint curto, um teste de cinco tarefas, uma nota do que mudou. Depois o capítulo 49 entra no JavaScript. O processo de equipe não acaba: ele só para de ser o assunto do volume.

Sirva o exemplo se quiser testar os cliques como na Web. O endereço é http://127.0.0.1:8769/exemplos/48-agile-equipes/. Encerre com Ctrl+C. Continua sendo teste local.

Atividades

1. O que torna uma tarefa de sprint conferível?
2. Por que “Fazendo” deve ter poucas cartelas?
3. Reescreva: “arruma o site” como issue útil da Oficina Costeira.
4. Durante o teste de usabilidade, você deve explicar o menu? Por quê?
5. O formulário de contato entra no teste como envio verdadeiro?

Respostas comentadas

1. Um resultado visível numa página: arquivo, comportamento, critério de pronto. “Abrir agenda.html e ver o h1 Agenda.”
2. Porque trabalho paralelo demais não termina e o quadro perde o sentido. Uma ou duas frentes por pessoa.
3. Algo como: “Em projetos.html, o h1 deve ser Projetos e a lista deve ter os três trabalhos fictícios. Conferir teclado.”
4. Não. O objetivo é ver se a página se explica. Explicar o menu esconde o problema.
5. Não. A pessoa só precisa perceber que é um exercício: validação local, sem servidor de verdade, sem dado pessoal.

Referências

• Trabalhar em equipe
• Teste de usabilidade (conceito)
• Issues no GitHub
• Pull requests

O arquivo completo

Referência do exemplo 48-agile-equipes, reproduzida aqui para que você possa conferir sem sair da página.

assets/javascript/simulacao.js

const form=document.querySelector("#simulacao");if(form){form.querySelector("button[type=submit]").disabled=false;form.addEventListener("submit",event=>{event.preventDefault();document.querySelector("#retorno").textContent="Simulação concluída. Nada foi enviado ou guardado.";});}