Uma das perguntas que mais respondo na minha vida é “Como é que você fala tanto sobre Agilidade e dá cursos de UML?!?!”. Um dos pontos que defendo muito nos meus artigos e também nos meus cursos é que Agilidade não exclui modelagem. De fato vejo muitos agilistas modelando bastante seja nos “whiteboards”, no papel ou em ferramentas UML.
Nosso amigo Adail Retamal postou na lista Agile-Brasil um excelente artigo de Scott W. Ambler e Celso Gonzalez publicado na Better Software. Segue o link:
http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0608/
No artigo citado os autores dizem que a modelagem ocorre principalmente na concepção ágil, no planejamento da iteração e homeopaticamente durante o desenvolvimento. Modelar é uma atividade em grupo focada principalmente na comunicação. Modelar algo sozinho não faz sentido na maioria das vezes.
Será que modelar está tão fora de moda assim? E a UML? O que podemos dizer sobre ela?
Creio que a UML injustamente ganhou uma má fama por causa aquela famosa “fase de modelagem” do waterfall ou do “o analista modelou assim então codifica”, etc… Porém, sem dúvida, aplicada da maneira certa e no momento certo é uma execelente ferramenta.
De pronto veio na minha cabeza que UML é a C como modelagem ágeis são a DSLs.
Me parece que UML agora não tem muita utilidade porque as pessoas descobriram que para modelar um sistema não se precisa de uma segunda linguagem, tudo pode ser modelado na linguagem do domínio.
Entendo que a UML dentro de um contexto de metodologias ágeis deve ser usada como uma ferramenta de comunicação e também para ajudar clarear as idéias sobre algum tópico de discussão do time.
Lembro em um projeto de estar com o time rabiscando um quadro montando caixas e tentando entender o melhor fluxo para montar uma arquitetura.
Os rabiscos eram com um diagrama de componentes e diagrama de classes.
Uma outra experiência… gosto muito de um documento com a metáfora do sistema e neste documento gosto de ter um diagrama com o contexto da aplicação, algo como um diagrama de deploy, para entender o contexto não funcional da aplicação sendo desenvolvida. Mais: http://c2.com/xp/SystemMetaphor.html
È o que eu costumo chamar de movimento intuitivo! A UML deve ser dosada de acordo com a necessidade e viabilidade da equipe! (DA EQUIPE). Uma UML ágil! 😛
O problema é que muita ACHA que sabe utilizar a notação UML, fazendo diagramas sem sentido que não servem de nada após a segunda semana de desenvolvimento.
Creio que adotando na medida certa e de maneira intuitiva pode auxiliar e muito.
Mais um ponto: tem muito cliente que exige documentação completa do projeto, incluindo N diagramas UML. O jeito é fazer.
Pingback:Débito Técnico » Blog Archive » Behavior-Driven Development e o Jogo da Memória