Reuniões de Melhoria das Especificações II

Primeiros resultados:

Aplicando-se todas estas diretivas, colhemos alguns resultados da primeira reunião.

1. Avaliação do Template (o que agiliza? o que atrapalha?)

O pessoal avaliou o estado do template e dizem que não têm tido grandes problemas. Foi incluído como anexo (opcional) uma tabela para mapeamento de campo de tela (cujo nome estará também no protótipo) com a ‘tabela.coluna’ do banco de dados. Se esta tabela for usada no Caso-de-Uso, exclui-se a necessidade de incluir a validação dentro do texto do Fluxo.

Nome Campo Tipo Obrigatório? Campo no BD
Tipo de Endereço select box* Sim endereco.tipo
Endereço text field** Sim endereco.descricao

*ou ‘campo seleção’ *ou ‘campo texto’
2. Retirada de Informação desnecessária do Caso-de-Uso (o que tem sido burocrático demais?)

Foi excluída a seção ‘Restrições’ dado que já existe no Caso-de-Uso um espaço para serem colocadas as pré e pós-condições.
3. Desmembramento dos passos de acordo com o Fluxo de Tela (clarificação dos passos)

Foi definido que cada verbo deriva um passo, e em cada quadro do ‘ping-pong’ podem existir um ou mais passos. Obs: cada verbo que signifique uma “ação”.
4. Regras de Validação do Campos (informações necessárias como tipo de campo: ‘text field’, ‘text area’, ‘select box’, ‘radio button’ e restrições de valores como numérico inteiro, decimal, etc..)

Ficou decido que não serão incluídas informações de telas nos textos dos passos de cada fluxo, ou seja, o nome de Campos e de Botões da tela. Mas o tipo de item de tela a ser utilizado pode ser indicado. Exemplo: ‘O sistema deve exibir uma tela com os campos: 1. Tipo de endereço: (campo de seleção); 2. Endereço (campo texto, obrigatório); […] ‘
5. Inclusão de Requisitos Funcionais e Não-Funcionais no UC: Sim ou Não?

Ficou em aberto para ser decidido na próxima reunião porque isto vai exigir uma avaliação no tempo disponível para isto, no formato que irão ser registrados os requisitos, etc…
6. Geração de Protótipo (apresentação de uma solução prática pelo Adriano)

Foi apresentada rapidamente a ferramenta ‘Pencil’, sugerida pelo Alessandro, e a equipe entrou num consenso que a ferramenta se mostrou prática e fácil de ser manuseada. A confecção de protótipos foi votado por todos como item obrigatório.
7. Casos de Uso que possuem dependência entre si.

Foi definido que será colocado dentro do próprio caso-de-uso qualquer referência que ele tenha a outro Caso-de-Uso.

Pauta para a próximas reunião (ainda não fechada):

  1. Feedback de todos em relação ao que foi definido e o que foi realmente aplicado, esforço necessário e benefícios
  2. Quais as informações devem vir do cliente para melhorar a precisão das estimativas?
  3. Diagrama de Classes: qual ferramenta utilizar até que a proposta da Mariana com o EA esteja pronta? Obs: Tínhamos discutido que ficariam nos anexos.
  4. Nomenclatura padrão para as especificações de todos os projetos.
  5. (…)

Reuniões de Melhoria das Especificações I

Fizemos duas reuniões para melhorias das Especificações, elas seguiram mais ou menos o modelo abaixo:

Objetivo

  • Enxugar o Caso-de-Uso
  • Adicionar informações válidas
  • Diminuir dependência do Desenvolvedor ao Analista
  • Diminuir dependência do Tester ao Analista

Papéis e Responsabilidades

Cada colaborador deve levantar os pontos que achar que podemos melhorar na Especificações prestando atenção também ao feedback dado pelos desenvolvedores e ao feedback dado pelo cliente na entrega do produto final.

O papel do Analista de Qualidade no grupo será de apenas dar sugestões defendendo os interesses da equipe de Qualidade. Além de motivá-los a discutir os assuntos levantados que são de profundo interesse da Área de Qualidade.

O papel dos Analistas de Sistemas será em função de agilizar seu próprio trabalho e prover os dados necessários para o desenvolvimento sem que o desenvolvedor precise perder tempo em analisar o negócio (ele deve apenas entender de que forma o sistema deve se comportar em relação a eventos de tela, fluxo de dados, lógica envolvida, estrutura de dados no banco, regras de negócio a serem implementadas, etc. ). Isto para, no futuro, o desenvolvedor não precisar perder tempo com o entendimento do negócio, apenas implementar de acordo com o definido.

Então os próprios Analistas de Sistemas devem sugerir melhorias em função deste objetivo comum: prover melhorias que facilitem o trabalho sem burocratizar, ou seja, máxima eficácia com mínimo esforço.