Desenvolvendo uma Infraestrutura #2
Olá pessoas!
Neste artigo continuarei falando das técnicas de levantamento e detalhamento de requisitos, pois é um assunto de ordem, você atuando ou não como analista de requisitos. É muito útil conhecer as técnicas básicas com um exemplinho aqui e ali, existem muitas e sua utlização vai da sua necessidade.
Você sabe o que são histórias de usuário?
Bueno, uma história de usuário é uma técnica que serve para descrever uma funcionalidade a ser desenvolvida do ponto de vista da pessoa que utilizará ou não determinada funcionalidade (pode ser um cliente, um usuário do sistema, um stakeholder, etc.).
Uma história de usuário é geralmente descrita em um cartão com um pequeno texto identificando o requisito a ser desenvolvido de forma simples e serve para o desenvolvedor ou para o time poder opinar e discutir sobre o requisito.
Não entrarei em maiores detalhes porque existe material prolixo na rede sobre o assunto (vale a pena dar uma lida), mas basicamente um cartão de história ou estória de usuário deve apresentar:
1) Título da história: "Logar no sistema"
2) Ator: "Como um usuário cadastrado..."
3) Quero/Preciso/Desejo: "Eu quero me logar no sistema"
4) Para: "Acessar os menus e funionalidades pertimitidas ao meu perfil"
Esta é uma técnica muito simples de expor de forma rápida uma funcionalidade do ponto de vista do usuário ao time de desenvolvimento.
...mas sua simplicidade abre para análise discussões sensíveis ao time quanto a necessidade de quebra em funcionalidades menores deste requisito.
Então vamos analisar e quebrar este épico em histórias menores através das considerações abaixo.
1) O usuário deve estar cadastrado: Então deve existir ser implementado:
- Cadastro de usuários; Cadastro e controle de senha; Cadastro e alteração de senha criptografada, exigências de tamanho mínimo, presença de caracteres em maísculo, numéricos ou especiais, já pensando em um nível de segurança adequado a corporação;
2) O usuário deve acessar somente as funcionalidades e menus permitidos ao seu perfil: Então temos de desenvolver uma cadastro de perfil que permita localizar este usuário vinculado a uma estrutura de acesso:
- Empresa(s) e Estabelecimento(s);
- Grupo para definição de perfis (ao invés de você definir as atuações e os horários de acesso usuário a usuário, crie um grupo e atribua as atuações e horários a esse grupo, depois trate as exceções a regra em cada usuário se necessário) ;
- Vincular atuação do Usuário ou do Grupo em Estabelecimento(s);
- Cadastro e controle de menus disponíveis ao usuário ou ao Grupo.
Mas repare, estas são técnicas de trabalho e evolução de requisitos sensíveis ao time, a decisão de usar ou não determinada técnica depende muito do time, mas conhecê-las e aplicá-las pelo menos uma vez é uma obrigação de todo time de desenvlvimento ágil. Mas quando você se depara com um quadro repleto de histórias de usuário é quase certeza que o time ou qualquer integrante que entre na metade do jogo irá rapidamente integrar-se.
Veja como ficaria o quadro das histórias de usuário quebradas (nas histórias logo abaixo), e repare que o grau de detalhemento pode variar, ou seja, não é preciso colocar no texto da história toda regra de negócios necessária para implementar uma funcionalidade. Se necessário utilize o verso do cartão para colocar detalhes do requisito. Mas sem dúvida, utilizando este método o processo de mapeamento de requisito ficará mais fácil e transparente, já a evolução deste requisito tecnicamente podemos deixar para o momento adequado.
A história de usuário é uma excelente forma de elucidação, mas não é o formato ideal para você descrever por exemplo um defeito. Temos 5 técnicas principais de levantamento de requisitos que vale a pena buscar na internet: 1.Observação do cenário; 2.Entrevista com stakeholders; 3.Workshop de requisitos; 4.Testes de mesa; 5.Estudo de mercado.
Terminada a fase de requisitos.
O time já se reuniu, rolou o planning poker, depois do cartiado discutiram muito sobre a sprint e as deliberações das tarefas.
A boa notícia é que todos sobreviveram.
Agora estão no Kanban com as demais tarefas a "Modelagem de dados" em progresso.
Tá, mas peraí!!!
Pôxa, mas quem está "tocando" está tarefa?
Qual o número de horas ou pontos definidos para a tarefa mesmo?
Este questioamento é básico ao se olhar o quadro, que tal melhorar a identificação da tarefa, nesta hora vale a criatividade, existem times que utiliam avatares personificando as pessoas do time, mas vamos propor um formato mais conservador.
Que tal asssim?
Assim ficamos com o quadro deste jeito, com a primeira tarefa em andamento e identificada.
Já as raias do Kanban podem partir de um "to do, in progress e done" para um "a fazer, análise, em progresso, impedido, em homologação, pronto e em produção".
Porque não?
Todo o processo, técnica e metodologia foram pensadas para atender a você e não você as metodologias.
Conto com a sua companhia no próximo artigo e desde já agradeço por suas opiniões e críticas. Isso fica feliz em ser útil!
Abraços!