Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.
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.
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.
4 comentários:
Presto serviço para uma empresa que não obriga a entrega do diagrama de casos de uso, só precisa da descrição do caso de uso. Resultado, a maioria dos analistas aqui não sabem a diferença entre um <> e um <>. Como disse o post, a causa disso foi a insistência dos proficionais em trabalhar somente com os entregáveis obeigatórios. Se esquecem de usar uma rica ferramenta q sâo os diagramas da UML, q podem ser usado para benefício próprio a fim de organizar as idéias antes de sair descrevendo os casos de uso.
Parabéns pelo post. Ótimo assunto.
Comentado do celular.
foi mal pessoal, no meu comentario eu coloquei as palavras INCLUDE e EXTEND com as tags de estereótipo <<>>. Mas o site entendeu errado. Portanto, no meu comentário, entendam << >> como INCLUDE e EXTEND. abraçâo a todos.
Eu conheço bem essa empresa... :) Conheço uma história parecida também. Não sabia Evandro, que vc tinha twitter!
Estou te seguindo professor :)
Ah sim, eu ia dizer outra coisa. O problema não é o uso do template em si, mas ignorar todo o resto em razão do template.
Conheço uma empresa aí que além de não saber o q é include e extend, também não sabe diferenciar requisito de regra de negócio... Mas daí, já é outro assunto, né?
Postar um comentário