Melhorando o Entendimento “Como fazer?”

Boa tarde pessoal,

Este post trata de como podemos melhorar o entendimento das equipes no processo de “resolver” o requisito, isto é, “como fazer?”.

A melhora no entendimento “do como fazer” faz com que a velocidade de implementação da equipe melhore muito, bem como a qualidade do produto a nível de negócio e engenharia.

Exemplo - História: Cadastro de Usuário
Como usuário do sistema, desejo cadastrar uma conta para mim, para que eu possa acessar o sistema.

Com essa História temos que encontrar as tarefas, tarefas que vão resolver o negócio e tarefas que vão testar o sistema.

Ferramenta de Apoio 1 - Interface de Apoio

Ter uma tela que representa a solução do requisito ajuda em muito os profissionais que possuem dificuldade em identificar Tarefas a partir de uma História.


Com a interface é muito mais fácil identificar as Tarefas de Negócio e Tarefas de Testes.

Ferramenta de Apoio 2 – Cartão CRC
Ajuda muito no processo de mapeamento dos domínios que o nosso sistema possui. Montamos um cartão com o nome do domínio (no nosso exemplo Usuários) e perguntamos ao domínio o que ele deve conhecer.

Com este cartão conseguimos identificar as classes que fazem parte do relacionamento e até mesmo a superclasse do nosso domínio.

É uma ótima ferramenta de analise de sistemas, até mesmo porque permite um dialogo fácil com profissionais que não são da área de TI.

Material complementar: http://blogdoabu.blogspot.com/2010/02/um-cartao-de-classe-cartao-crc.html

Ferramenta de Apoio - TDD

A figura mostra o ciclo de vida da implementação de um a História em uma Sprint com a utilização de TDD.

Porem devemos lembrar que nem todas as pessoas estão familiarizadas com o processo de quebrar uma História em Tarefas e estas Tarefas possuírem Tarefas de Testes.

Tarefas

Vamos criar tanto as Tarefas de Negócio quanto as Tarefas de Testes.

Quando a nossa equipe possui um Analista de Testes, o processo de identificação das Tarefas de Testes fica muito mais fácil e a equipe aprende a pensar em testes com o Analista de Testes, melhorando em muito o processo.

Com a existência das Tarefas de Testes a equipe passa a ter um foco de ataque, isto é, ela sabe o que implementar do negócio e o que implementar de testes que validam o negócio. Devemos lembrar que os profissionais que estão familiarizados com o desenvolvimento de testes automatizados, não possuem a necessidade de criar Tarefas de Testes, eles utilizam os testes automatizados como ferramenta de apoio a arquitetura que estão implementando para resolver o requisito de negócio.

Quadro de Tarefas

Colocamos as Tarefas de Testes e de Negócio.

Ferramenta de Apoio - UML

O inicio de um projeto pede uma arquitetura minima necessária para que o nosso sistema seja desenvolvido. Um modelo MVC é um exemplo. Mas devemos lembrar que na nossa equipe nem sempre todos os profissionais tem uma visão clara de como vai funcionar o modelo MVC.

Com o passar do tempo o nosso projeto passa a ser cada vez mais padronizado com modelos arquitetônicos e os profissionais do projeto sabem o que fazer, sem o auxilio de uma arquitetura desenhada graficamente.

Mas enquanto os nossos padrões não estão claros para todos, desenhar alguns diagramas ajuda muito.

A figura mostra o processo de analise orientada a objetos chamada ICONIX.

Mas estas ferramentas não tem necessidade de serem realizadas em software, elas podem ser realizadas em papel e colocadas a visibilidade de todos. Caso o nosso projeto exija documentos em UML para documentação, eles podem ser realizados no fim da Sprint, para diminuir o retrabalho.

Fazer desenhos no fim da Sprint em software, é desenhar o que foi feito, já os desenhos no inicio da Sprint são uma intenção do que pretendemos fazer e que pode ter uma distorção ao final da Sprint, exigindo uma correção dos documentos, caso eles tenham sido realizados em software.

Ferramentas de Apoio e Sprint
Devemos lembrar que todas estas ferramentas devem ser utilizadas respeitando o tamanho da Sprint.


Abraços a todos,

Abu