| layout |
|---|
post |
Manual de Procedimentos
###- Clone
###- Pull
... O registro de tarefas possibilita realizar melhores estimativas...
- Ajustes
- Requisitos Planejados
- Extras
- Outras Demandas
- Bugs (Bug é um erro de produção, uma falha não entregue ao cliente não é BUG)
- recomenda-se o uso de cronômetro
- pomodoro?
- Tarefas Atômicas
- Sempre que possível
- Evitar manter muita defasagem entre o Repositório e sua máquina.
- Não enviar a versão para o cliente sem documentar
- Apresentar as novas funcionalidades
- Se possível apresentar exemplos
- gravar no Redmine
Adotamos o modelo de User Story:
Como <ator - quem terá acesso à feature>
Gostaria de <ação - o que o usuário irá fazer>
A fim de <finalidade - define o valor da tarefa para o produto final>
Ex:
Como Administrador do sistema
Gostaria de criar um cliente
A fim de manter um registro de todos os meus clientes
Outra parte muito importante é definirmos os critérios de aceitação, ou seja, quando eu sei que a tarefa está completa e será aceita. Isso irá ajudar a:
- saber com detalhes o que é esperado
- escrever testes
- saber que terminei uma tarefa
- facilitar o trabalho do Product Owner para revisar se a tarefa está completa
Ex:
Critérios de aceitação:
- cliente deve obrigatoriamente ter: nome e idade
- cliente deve estar salvo no banco de dados
- deve haver uma lista no sistema com todos os clientes cadastrados
- a lista deve ser dividida em páginas com 15 registros por página
Resumindo, uma US completa ficaria assim:
Título: Cadastrar clientes
Como administrador do sistema
Gostaria de criar um cliente
A fim de manter um registro de todos os meus clientes
Critérios de aceitação:
cliente deve obrigatoriamente ter: nome e idade
cliente deve estar salvo no banco de dados
deve haver uma lista no sistema com todos os clientes cadastrados
a lista deve ser dividida em páginas com 15 registros por página
Olá eu sou o <fulano> represento o time de desenvolvimento no projeto <x> do seu cliente <y>/
Estamos precisando <solução> pois estamos tendo <seguinte problema>
Gostariamos de contar com sua colaboração em <seguintes aspectos>.
Qualquer dúvida estamos a disposição.
<fulano>
<developer> na Invent.to.
Encontre um erro que possa ser a causa. Analise os logs e observe os detalhes do ambiente.
- Onde ocorreu o erro?
- Qual máquina? Em todas? Apenas uma?
- Quantas pessoas relataram o caso?
- É um problema do usuário ou um erro do sistema?
Reveja o erro e descreva para você mesmo passo a passo como chegou até o problema.
Repita a sua ação e prove que a causa que descreveu é realmente o objeto de analise.
Teste possíveis soluções e reteste suas hipóteses. Caso necessário reformule ou crie novas hipóteses para validar a solução em diferentes aspectos.
Descrição das tarefas organizacionais gerais da empresa. Fluxos de processos e procedimentos para solução de problemas.
- Guias de profissão
- Manuais de instrução
- Análise do requisito
- Desenvolvimento orientado a testes
- Modelagem orientada a objetos
- Escolha e aplicação de padrões (design patterns)
- Adaptação e mantimento do modelo existente
- Conversa com cliente
- Levantamento de requisitos
- Definição de prioridades
- Prototipação de telas
- Estórias do usuário