Desde que a metodologia SCRUM revolucionou o desenvolvimento de software, tem-se discutido sobre uma aparente incompatibilidade entre essa metodologia e os diagramas UML. Neste post, pretendemos demonstrar por que ambos podem ser adotados em um mesmo projeto. Não apenas sem gerar conflitos, mas de maneira sinergética.
Sumário
Boas práticas de SCRUM
Para uma prática frutífera de SCRUM, uma condição importante é que todos os membros da equipe conheçam o problema e a solução proposta por completo. O motivo é fazer com que todos tenham uma compreensão global e possam atuar em sua área específica. Isso, tendo em mente a solução como um todo. E, evitando desperdícios e retrabalhos nos pontos de integração.
Como escreveu Jeff Sutherland: “(…) todos os integrantes de uma equipe do Scrum precisam saber o que todos os outros estão fazendo. O trabalho que está sendo realizado, os desafios que estão sendo enfrentados e o progresso que é feito precisam ficar claros para todo mundo”1.
Contudo, colocar toda a equipe na mesma sala não garante que todos compreendam verdadeiramente o problema e a solução. Pode ser que cada membro tenha uma compreensão particular, incompatível com as dos demais. E ainda, que atue para desenvolver uma parte que não se encaixe perfeitamente na solução completa.
Identificando divergências
Muitas vezes, essas discrepâncias de compreensão são identificadas logo nas primeiras reuniões diárias. Outras vezes, porém, especialmente naqueles casos em que se trata de uma diferença bastante sutil, muito tempo de desenvolvimento pode passar. Muito esforço pode ser empenhado até que a falha seja detectada.
Em seu clássico Como Ler Livros, Mortimer Adler explica que: “Quando há ambiguidades não resolvidas na comunicação, não há comunicação, ou, na melhor das hipóteses, a comunicação permanece incompleta”2. Ainda, “Para que a comunicação seja perfeita, é necessário, portanto, que as duas partes usem as mesmas palavras com os mesmos significados – em suma, que os termos do contrato sejam mutuamente acordados. Quando isso acontece – quando a comunicação acontece – ocorre o milagre de duas mentes sustentarem um mesmo e único pensamento”3.
Na mesma obra, o autor apresenta uma solução para a compreensão dos significados na leitura de livros. Infelizmente, essa solução não pode ser aplicada ao pé da letra aos projetos de desenvolvimento de software.
Diagramas UML para aperfeiçoar o SCRUM
Nesse tipo de situação, temos que utilizar ferramentas diferentes para garantir que todos estejam conversando nos mesmos termos e que a compreensão do problema e da solução seja compartilhada por todos os membros. Não só a nível de palavras e frases, ou de objetos e funções, mas a nível de sentido. E é aí que entram os diagramas UML – como uma ferramenta de auxílio na compreensão e na elaboração de soluções. Não como um modelo rígido ao qual a realidade deve se adaptar.
Tais diagramas, contudo, não devem ser seguidos cegamente e inflexivelmente. Ao contrário, se necessário, devem ser adaptados para refletir as mudanças apontadas nos feedbacks. Além disso, não devem ser utilizados extensivamente. Apenas quando forem realmente necessários – uma boa prática de SCRUM requer um mínimo de documentação. Contudo, se utilizados na medida e nos momentos corretos, esses diagramas podem evitar muitas discussões e retrabalhos.
E não é só isso. Se todos compreenderem a solução desde o início do projeto, o foco na implementação será maior durante o desenvolvimento, e os feedbacks serão mais assertivos – todos estarão avaliando, criticando e buscando aprimorar a mesma solução.
Motivação é chave
Por fim, garantir a compreensão de todos da equipe não é só uma medida para evitar o retrabalho e aprimorar a comunicação. É também uma maneira motivar a equipe. Quantas vezes não percebemos um crescimento de ânimo na equipe durante a execução de um projeto?
Acontece que aqueles que não acreditavam inicialmente na solução em desenvolvimento começam a perceber que as peças estão realmente se encaixando e os resultados aparecendo. Se compreendessem verdadeiramente a solução desde o início, talvez estivessem tão motivados desde então.
Faça você mesmo o teste. Ao identificar um fluxo complexo, que está gerando discussão, construa um diagrama – de estado, de sequência, ou do tipo que julgar mais adequado –. Discuta os conceitos e interações contidos nele com a equipe. É importante que esse diagrama seja construído em alto nível, sem detalhes excessivos que podem facilmente ser ajustados mais tarde.
Muito provavelmente, você perceberá que nem todos tinham a mesma compreensão do fluxo. E ainda, é possível até que identifique falhas na solução desenhada. Tente imaginar, em seguida, os impactos evitados por esse momento de alinhamento.
Tenho em mente que os diagramas UML não devem ser utilizados como moldes fixos e que não se deve gastar muito tempo construindo diagramas muito detalhados. Assim, percebemos que eles podem potencializar a prática do SCRUM. Eles podem reduzir o tempo gasto com discussões e retrabalhos e contribuindo para uma maior motivação da equipe.
