Requisitos de comunicação
- Clientes do sistema comunicam ao gestor do sistema:
- necessidades de desenvolvimento do sistema
- necessidades de evolução do sistema
- nível de satisfação com o sistema
- características do sistema que surpreenderam positivamente
- problemas observados no sistema que deveriam ser corrigidos
- Gestor do sistema comunica ao time:
- visão do sistema
- objetivo da próxima liberação
- prioridade dos itens do backlog do sistema
- detalhes dos itens do backlog do sistema, conforme demanda, incluindo: especificação, critérios de validação, resultado da validação e nível de satisfação
- Time comunica ao gestor do sistema:
- estimativa dos itens do backlog do sistema, conforme demanda
- dúvidas e riscos identificados
- sugestões aos critérios de validação
- testes de aceitação automatizados
- itens do backlog do sistema prontos para validação
- Gestor do sistema comunica aos clientes do sistema:
- itens do backlog do sistema incorporados à última liberação
- agenda de treinamentos, quando oportuno
- indisponibilidade temporária, substituição ou desativação do sistema
Engajamento do time
- Explicitar desde o primeiro dia, relembrando sempre que oportuno, o regime interno do time que deve conter os valores e princípios (profissionais, sociais, éticos) defendidos pelo time. Isso gera atitude positiva e proporciona uma evolução adequada das práticas do time.
- Reunir o time semanalmente em uma sala de conferência para realizar tarefas conjuntas, exercitando e discutindo as práticas atuais do time. Membros de outros times podem acompanhar.
- Um líder deve promover a transparência e a responsabilidade do time com relação a tudo o que for produzido. Accountability é bom para o time.
- Durante o planejamento semanal:
- o gestor do sistema apresenta sua expectativa de consumo do backlog do sistema
- o time apresenta sua expectativa de melhoria do processo (ex: introdução/substituição de práticas) ou do sistema (ex: refatoração de código)
- o time apresenta a estimativa do esforço necessário para atender cada uma das expectativas
- com base nas expectativas e estimativas apresentadas, firmam-se por consenso as expectativas a serem realizadas ao longo da semana
- com base nas expectativas firmadas, os membros do time definem e estimam as tarefas a serem alocadas ao longo da semana
- deve haver uma margem de tolerância ou folga na carga planejada para que os membros do time possam pensar, discutir decisões, avaliar impactos, etc.
Indicadores para melhoria de processo
- Indicadores baseados na clientela:
- Satisfação da clientela.
- Nível de serviço.
- Duração do atendimento.
- Valor agregado à clientela.
- Indicadores baseados na estrutura de atendimento:
- Alocação de recursos.
- Duração de tarefas alocadas em progresso.
- Volume de tarefas alocadas em progresso.
- Custo do atendimento.
Todo indicador deve ser avaliado. Seguem questões extraídas do framework de avaliação proposto por Kaner e Bond:
- Qual o propósito da medida?
- Qual o escopo da medida?
- Que atributo estamos tentando medir?
- Qual a escala natural do atributo a ser medido?
- Qual a variabilidade natural do atributo?
- Qual é a métrica (função que associa um valor ao atributo) e qual o instrumento usado para medir?
- Qual a escala natural para a métrica?
- Qual a variabilidade natural de leitura do instrumento?
- Qual a relação entre o atributo e o valor da métrica?
- Quais são os efeitos colaterais naturais e previamente conhecidos do uso do instrumento?
Acervo de práticas
- Práticas do pessoal de negócio.
- Mapear comportamento do sistema aos objetivos de negócio, através da escrita (incremental) de casos de uso no nível compreensível pelo usuário. Os casos de uso ágeis são descrições em forma de histórias breves (com fluxos de até nove passos) que explicitam os objetivos a serem atendidos pelo sistema aos diversos atores do sistema.
- Especificar comportamento esperado do sistema através de cenários e exemplos concretos, denominados testes de aceitação. Segundo a técnica ATDD, o trabalho do pessoal de desenvolvimento deve ser guiado pelos testes de aceitação existentes, que devem ser escritos com a participação do cliente do sistema.
- Medir progresso de projetos de desenvolvimento, usando métrica Running Tested Features e/ou modelo de governança de Alistair Cockburn
- Práticas do pessoal de desenvolvimento.
- Sempre que possível, automatizar testes de aceitação antes de desenvolver o código necessário para atendê-los. Soluções interessantes: Concordion e FitNesse.
- Desenhar esquemas e diagramas em quadros brancos ou cartazes para comunicar elementos arquiteturais e de design sistema. Segue um exemplo real: quadro de controle arquitetural.
- Gerar a documentação necessária a partir de fontes normalizadas para facilitar sua manutenção, conforme diretrizes de modelagem ágil.
- Dominar práticas de desenvolvimento de software, incluindo as indicadas em Elementary practices.
- Conhecer, na medida do possível, as terminologias, padrões e recomendações técnicas publicadas para a área de software. Segue uma pequena compilação: Referências técnicas.
- Práticas comuns.
- Coletar indicadores para subsidiar as reuniões de retrospectiva e outras oportunidades de melhoria de processo.
Processo de desenvolvimento
