A Importância da Revisão de Requisitos
Não adianta, por mais que uma analista de requisitos estude, a única forma de ele escrever requisitos melhores é através de revisões de requisitos e o feedback que as mesmas podem propor.
Mão estou dizendo que o Analista de requisitos não deve estudar técnicas e patterns de Requisitos, mas sim que somente através da revisão que será possível evoluir suas habilidades de desenvolvimento de requisitos.
Além de assuntos pertinentes a revisões de requisitos irei descrever duas práticas ágeis para o desenvolvimento de requisitos.
Por que Revisar?
Afinal, essa tarefa não é barata e tempo é um luxo que ninguém possui. Pois é se vocês se lerem o post anterior. Está claro a importância do investimento em requisitos. Ao realizarmos revisões de requisitos estaremos ganhando em:
Mão estou dizendo que o Analista de requisitos não deve estudar técnicas e patterns de Requisitos, mas sim que somente através da revisão que será possível evoluir suas habilidades de desenvolvimento de requisitos.
Além de assuntos pertinentes a revisões de requisitos irei descrever duas práticas ágeis para o desenvolvimento de requisitos.
Por que Revisar?
Afinal, essa tarefa não é barata e tempo é um luxo que ninguém possui. Pois é se vocês se lerem o post anterior. Está claro a importância do investimento em requisitos. Ao realizarmos revisões de requisitos estaremos ganhando em:
- Clareza de informações
- Remoção de ambiguidades
- Possíveis problemas que teríamos com modelagem
- Além de outras anomalias( Requisitos duplicados, requisitos não identificados)
A revisão de requisitos pode e deve se dar de duas formas. Da forma formal e dá forma informal. Assim é possível marcar uma reunião de revisão de requisitos de 15 em 15 dias ou em um tempo maior dependendo da qualificação dos analistas de requisitos.
Abuse da informalidade
Digo por experiência, se você não tiver muitas conversas informais entre uma revisão e outra, dependendo da qualificação dos analistas vão ter muitos problemas na reunião de revisão. Por isso é sempre bom conversar diariamente se possível sobre requisitos. Metodologia ágeis como o Scrum podem ajudar nesse processo. Pois através do Scrum Dally Meeting é possível levantar alguns possíveis pontos de alinhamentos sobre requisitos.
Chame os Product Champions
Colocar os Product Champions nas revisões formais de requisitos pode ser uma ótima idéia. Por que com esse contato fica muito fácil do PC acompanhar o andamento dos requisitos e esclarecer qualquer mal entendido sobre os requisitos.
Cada PC tem o seu tempo, esse tempo de resposta e assimilação deve ser respeitado. Porem deve ser deixado bem claro para o PC qual o foco da reunião e devemos deixar os requisitos sem dúvidas de fora.
Preparação para reunião
É imprescindível que os participantes leiam os requisitos antes da reunião. Pois senão muitas questões podem passar batidas. Eu já participei de revisões sem leitura previa dos requisitos e o nível de assimilação do requisitos e detecção de falhas foi bem menor.
Envolvimento de Q.A ?
Fundamental. Fazer um check-list com os principais erros e pontos relevantes é uma boa idéia também. A medida que as revisões forem avançando é possível aplicar métricas em cima dos check-lists das revisões e ver se os analistas estão passando o check-list de fato.
Na reunião também é muito interessante loggar todas as mudanças nos requisitos em um log. Isso também pode ser utilizado em estatísticas para determinação de taxa de erros em desenvolvimento de requisitos.
Não posso revisar tudo
Muitas vezes não é possível revisar todos os requisitos. Nesse caso podemos partir para uma abordagem baseada em riscos. Sendo que os requisitos revisados serão os requisitos que representam mais risco para o projeto.
O ideal seria revisar todos os requisitos. Mas podemos utilizar essa abordagem dirigida a riscos para as reuniões formais e para as reuniões informais dos analistas com a equipe técnica e dos analistas com os PC tocar um número mais de requisitos.
Como você já sabe o investimento em requisitos sempre trás bons frutos. Ainda assim é possível utilizar técnicas ágeis para o desenvolvimento de requisitos como: Mapas mentais e Rotação de escrita.
Mapas Mentais
Essa técnica foi criada em 1970 Tony Buzan e uma ferramenta open source para utilização de mapas mentais muito legal é o Free Mind. Não confunda o mapa mental com a árvore de decisão. Na verdade a tecnica de mapa mental é bem mais apurada. Você pode utilizar em diversos momentos no desenvolvimento de requisitos como:
Abuse da informalidade
Digo por experiência, se você não tiver muitas conversas informais entre uma revisão e outra, dependendo da qualificação dos analistas vão ter muitos problemas na reunião de revisão. Por isso é sempre bom conversar diariamente se possível sobre requisitos. Metodologia ágeis como o Scrum podem ajudar nesse processo. Pois através do Scrum Dally Meeting é possível levantar alguns possíveis pontos de alinhamentos sobre requisitos.
Chame os Product Champions
Colocar os Product Champions nas revisões formais de requisitos pode ser uma ótima idéia. Por que com esse contato fica muito fácil do PC acompanhar o andamento dos requisitos e esclarecer qualquer mal entendido sobre os requisitos.
Cada PC tem o seu tempo, esse tempo de resposta e assimilação deve ser respeitado. Porem deve ser deixado bem claro para o PC qual o foco da reunião e devemos deixar os requisitos sem dúvidas de fora.
Preparação para reunião
É imprescindível que os participantes leiam os requisitos antes da reunião. Pois senão muitas questões podem passar batidas. Eu já participei de revisões sem leitura previa dos requisitos e o nível de assimilação do requisitos e detecção de falhas foi bem menor.
Envolvimento de Q.A ?
Fundamental. Fazer um check-list com os principais erros e pontos relevantes é uma boa idéia também. A medida que as revisões forem avançando é possível aplicar métricas em cima dos check-lists das revisões e ver se os analistas estão passando o check-list de fato.
Na reunião também é muito interessante loggar todas as mudanças nos requisitos em um log. Isso também pode ser utilizado em estatísticas para determinação de taxa de erros em desenvolvimento de requisitos.
Não posso revisar tudo
Muitas vezes não é possível revisar todos os requisitos. Nesse caso podemos partir para uma abordagem baseada em riscos. Sendo que os requisitos revisados serão os requisitos que representam mais risco para o projeto.
O ideal seria revisar todos os requisitos. Mas podemos utilizar essa abordagem dirigida a riscos para as reuniões formais e para as reuniões informais dos analistas com a equipe técnica e dos analistas com os PC tocar um número mais de requisitos.
Como você já sabe o investimento em requisitos sempre trás bons frutos. Ainda assim é possível utilizar técnicas ágeis para o desenvolvimento de requisitos como: Mapas mentais e Rotação de escrita.
Mapas Mentais
Essa técnica foi criada em 1970 Tony Buzan e uma ferramenta open source para utilização de mapas mentais muito legal é o Free Mind. Não confunda o mapa mental com a árvore de decisão. Na verdade a tecnica de mapa mental é bem mais apurada. Você pode utilizar em diversos momentos no desenvolvimento de requisitos como:
- Para agrupar requsitos
- Para quebrar um fluxo de execução de cenário a procura de incosistencias
- Para detectar requisitos semelhantes ou ambiguos
- Para atividades de engenharia reversa
Entre tantas outras utilizações. De fato o Free Mind é uma ferramenta muito ágil e proporciona ao desenvoledor de requisitos uma velocidade bem superior do que no MS Word.
Rotação de Escrita
Essa técnica deve ser executada com pelo menos 2 analistas de requisitos. Não se trata do Pair Programming da analise. :) Bem essa técnica funciona assim:
Bom por hoje é só. Até a próxima.
Rotação de Escrita
Essa técnica deve ser executada com pelo menos 2 analistas de requisitos. Não se trata do Pair Programming da analise. :) Bem essa técnica funciona assim:
- Setamos um tempo de 10,15 ou 20min
- Cada análista escrever um seu computador, notebook ou em um Wiki
- Após o tempo passar eles trocam de lugar
- Assim cada análista devem continuar o trabalho de onde o outro parou
Bom por hoje é só. Até a próxima.
