Template é um formulário que é usado para facilitar a criação padronizada de um documento ou artefato. Deveria ser um instrumento de trabalho que levasse o analista a realizar o seu trabalho com sucesso.
Tenho percebido que os templates, algumas vezes, se transformam em um problema para o sucesso de um projeto. Vou explicar relatando um episódio que ocorreu comigo, na ocasião em que eu estava aplicando um processo de coaching em um projeto.
Um analista estava tendo alguns problemas na descrição de um caso de uso, porque era grande e complexo, com muitos fluxos alternativos, fluxos de exceção e regras de negócio. Percebia claramente que o analista não conseguia definir corretamente os fluxos alternativos e de exceção. Para resolver o problema sugeri que ele elaborasse um diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso e, a partir desta visão pudesse definir corretamente os fluxos de eventos.
Surpreendi-me quando ele disse-me que não iria fazer o diagrama porque não era obrigatório e também não estava elencado como um produto contratado. Argumentei que embora não fosse um entregável, era importante para que ele produzisse uma descrição do caso de uso com precisão e qualidade.
Posteriormente o gerente entrou na discussão alegando que a elaboração deste diagrama não estava previsto no cronograma e que a sua elaboração iria consumir um tempo que não tinha sido planejado e pediu-me, portanto, que eu não insistisse sobre o diagrama de atividades.
A conclusão dessa história é que o caso de uso foi descrito de uma forma altamente imprecisa, incompleta, não retratando o comportamento esperado. O tempo que aquele analista gastou para descrever aquele caso de uso foi, no mínimo, três vezes maior do que ele gastaria se estivesse elaborado o tão popular diagrama de atividades.
Para concluir a história, quando a equipe de design foi realizar aquele caso de uso, criando o modelo de design com o diagrama de classes e diagrama de sequência, não conseguiram concluir o trabalho, porque o caso de uso não estava claro, era impreciso e muitas coisas não faziam sentido. Com isso, aquele analista teve que fazer vários ciclos de alterações na descrição até que tivesse totalmente pronto para atender aos rigores da equipe de desenvolvimento.
É interessante notar que além do tempo excessivo que o analista gastou na descrição inicial do caso de uso, gastou ainda muito mais tempo para fazer as correções exigidas pelos desenvolvedores, além do tempo que a equipe de desenvolvimento gastou para entender e sugerir correções para o analista.
Lembra-se do gerente do projeto? Aquele que disse que não havia tempo para gastar com o diagrama de atividades? Coitado, passa maior parte do tempo atualizando cronogramas e levando pancada do cliente, que reclama que ele não consegue cumprir o planejamento inicial.
Porque tudo isso aconteceu? Porque tanto o gerente do projeto quanto o analista de negócio/requisitos, trabalham orientados à template. Para eles, o importante é preencher os campos do template. Esquecem-se de que os diagramas da UML poderiam ser de grande ajuda para se obter o entendimento do problema e para a definição adequada de uma solução. Esses diagramas possuem a excelente propriedade de oferecer múltiplas visões da solução idealizada. Essas visões irão colaborar para uma descrição clara, precisa, consistente e não ambígua dos casos de uso.
Não tenham medo de gastar tempo na elaboração do diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso. Certamente você irá ganhar tempo no cômputo geral do projeto. Além do que você irá evitar perda de tempo da equipe de design e de implementação.
Template é um excelente instrumento de trabalho, mas antes de preenchê-lo, pense, mas pense usando os excelentes diagramas da UML.
