3 Passos para um bom discovery

No dia a dia de um consultor ou profissional de tecnologia ao iniciar em um novo projeto é possível que encontremos alguns desafios para entender o contexto que estamos sendo inseridos.

Algumas perguntas vem a tona, como: “O que este software faz ?”, “ Qual problema essa empresa resolve ?”, “Quem são seus clientes ?”

Mas mesmo com essas perguntas não conseguimos mapear tudo e nem mesmo ter um norteador claro para onde iremos seguir com os passos para entendimento do cenário em que um software foi desenvolvido e nem mesmo os desafios que precisam ser enfrentados!

Minha ideia aqui é te ajudar, fazendo um roteiro de por qual caminho seguir no entendimento e discovery durante um processo de assessment ou projeto de um novo produto…

Citarei diversos recursos que nos apoiará neste processo de discovery e um deles é o DDD, o famoso conceito criado por Eric Evans.

Como DDD pode nos ajudar nisso ?

Um projeto de software normalmente surge a partir de uma necessidade de um indivíduo ou empresa.

A prática recomendada por Eric Evans, de entendimento dessa necessidade para se atingir a solução é o Design Dirigido a Modelos, ou Model Driven Design, que é a modelagem do domínio a partir da constante interação entre o time técnico e os especialistas de negócio, por meio de uma linguagem ubíqua.

O conhecido livro da capa azul “Domain-Driven Design. Ataca as Complexidades no Coração do Software”, Evans apresenta uma mudança de paradigma tão grande sobre a forma de entender e solucionar problemas complexos, que inspirou diversos outros ótimos livros sobre o assunto.

Aprendemos um modelo de análise e desenvolvimento de software semelhante a este: os analistas de negócio, em conjunto com os especialistas de negócio e/ou usuários chave, farão um levantamento funcional, e elaborarão as user storys com a especificação funcional.

O Roteiro

Aqui vou apresentar uma proposta de como seguir com o discovery de forma a entender os principais pontos e mapear desde os contextos de negócio até as decisões arquiteturais que foram ou serão tomadas no projeto.

E deixarei um roteiro de três passo, para um bom discovery. Parece aqueles comerciais de coach heim rsrs… “Três passos para o sucesso!!!” rsrs…

#1 Levantando Contextos e Entendendo o Negócio

Aqui iremos trabalhar muito com o DDD que acabamos de comentar. Ele irá nos apoiar no levantamento dos contextos e nas delimitações dos mesmo, isso te ajudará muito mais a decidir as tecnologias e modelos arquiteturais utilizados.

Vale também algumas pesquisas sobre os modelos de negócio que o software vai atender, bem como realizar pesquisas voltadas para inovações no tema. Visto que o inicio de um projeto sempre é uma ótima oportunidade para mudar alguns paradigmas, que possam agregar valor as entregas desde a primeira sprint.

É de suma importante neste momento ter aquelas conversas com os usuários chaves ou mesmo com o domain expert para entender o negócio, entender as necessidades dos usuários, pois elas nortearão o desenvolvimento e saberemos aqui os problemas que precisamos resolver.

Neste processo criaremos o dicionário de linguagem ubíqua que ajudará no alinhamento e entendimento dos termos utilizados pelo negócio durante os refinamentos e também durante o desenvolvimento. Escreva seu código utilizando este dicionário, isso te ajudará a ter um código mais semântico.

Crie um glossário com os significados de cada termo utilizado pelo negócio e divulgue este material de forma que todos os integrantes da equipe do projeto tenha conhecimento.

Outro mapa bem importante que precisará ser desenhado neste momento é o mapa de bounded contexts. O conceito de contextos delimitados vai nos apoiar em definir a utilização de um mesmo domínio em diversos contextos, porém em cada contexto o domínio poderá ter características e implementações diferentes.

É muito importante neste mapa de bounded context deixar detalhado o momento de reutilização do domínio.

Deixo também um exemplo de modelagem de um mesmo domínio, “Customer” sendo adaptado para cada bounded context que o mesmo estiver sendo utilizado.

#2 Entendendo a Solução

Para mapearmos a solução, agora falando mais “tecniquez” e menos negócio, iremos levantar os desenhos de arquitetura de solução, aquela famosa arquitetura de caixinha rsrs…

Nestes desenhos teremos visão completa do software, incluindo desde os microsserviços envolvidos no projeto, como também detalhes de infraestrutura e DevOps. Costumo incluir detalhes de implementação, ferramentas utilizadas e coisas mais…

Gosto de representar aqui também o posicionamento dos times e os papeis que teremos nas squads, como também os stackholders.

Utilizo muito o draw.io como ferramenta para estes desenhos, e deixo aqui um exemplo de como tenho desenhado as arquiteturas de solução, que faz a união dos detalhes técnico com os detalhes de negócio que já entendemos nos passos anteriores.

Podemos achar desnecessário este tipo de desenho, mas meu amigo(a) isso aqui te ajudará demais para apresentar o macro cenário de tudo que está na sua cabeça para todo o time e não menos importante para o negócio que financia o projeto.

Está tem sido a ferramenta que me ajuda por anos a explicar para gestores que pouco conhecem de tecnologia, tudo que estamos planejando e como cada parte resolve os problemas que ele tem.

Precisamos já iniciar o levantamento dos detalhes de implementação envolvidos na aplicação, persistência, integrações, autenticação… Estes são alguns dos pontos que precisam ser entendidos, mapeados e documentados…

Já indo para o refinamento técnico das users storys funcionais, nós vamos começar a documentar as soluções técnicas que os desenvolvedores usarão para “codar”. Te recomendo o uso de documentação BPMN para retratar os fluxos, processos e funcionalidades.

Vou deixar dois exemplos aqui de como costumo documentar as funcionalidades e os componentes que precisarão ser desenvolvidos para a solução que estamos pensando.

Um ponto importante é que esta documentação costuma ser bem cansativas de se manter, por isso tento utilizar ferramentas que são mais confortáveis para mim e que são de fácil entendimento para os times de desenvolvimento.

Nestes exemplos usei tanto o draw.io quanto o miro que são minhas parceiras de todos os dias rsrs…

#3 Decisões de arquitetura

E por fim, como num passe de mágicas chegamos ao momento de documentarmos as decisões arquiteturais do projeto.

Sim meu caro leitor(a) é preciso documentar o porque foi decido as coisas como estão, precisam deixar claro o porque um anti-pattern está sendo utilizado por exemplo. Ou mesmo por qual motivo foi escolhido uma determinada tecnologia de banco de dados…

Neste mundo de desenvolvimento de software é muito importante contar o passado, pois ele ajuda entender o presente e desenhar o futuro!

São nestas documentações que as decisões futuras serão baseadas.

E deixando de falar só sobre minha opinião do porque está documentação é importante vamos a explicação técnica de tudo isso.

O ADR ou Architecture Decision Record, deve ser um documento de simples que descreva os motivos que levaram a determinada decisão.

Existem muitos modelos e você pode até criar um modelo próprio que se encaixe ao seu cenário da melhor forma. Mas de qualquer forma para ajudar a nortear vou deixar um repositório do **Github** que nos ajuda com muitos exemplos de documentos markdown onde foram descritas as decisões de arquitetura.

Uma ideia bem legal que pode ser utilizada é você criar no repositório do seu projeto uma pasta docs/adr e nela colocar todos estes documentos.

Agora talvez, você que esteja lendo este artigo e esteja passando por um discovery de um legado ou mesmo apoiando em um projeto de migração de software, possa estar se perguntando, eu preciso mesmo criar toda essa documentação ? Eu nem conheço as decisões que foram tomadas!

Sim, você se torna responsável por este documento agora. Por isso eu te recomendo a tentar buscar com as equipes se foi documentado mesmo que pro e-mail algumas das decisões tomadas no decorrer do tempo. E dai você terá conteúdo para seu ADR.

Se estas decisões não foram mesmo documentadas, tente extrai-las por um processo de entrevista com os envolvidos. O importante é tentar mapear o máximo de informações possíveis e conseguir como eu disse acima, descobrir o passado, pois ele irá ajudar entender seu presente e te ajudar no futuro.

Conclusão

Caramba, nem eu achei que este artigo teria fim rsrs…

Mas aqui estamos e com tudo isso, nestes 3 passo que deixo para vocês, eu sintetizo alguns bons anos como arquiteto e consultor, onde pude participar de muitos projetos frustrados e outros com grande sucesso que me ensinaram o caminho que precisamos traçar para chegar em um excelente resultado.

Espero que tudo isso te ajude a entender e clarear o caminho que você precisa seguir para realizar um processo de discovery com sucesso.

Sucesso galera e que possamos ser “InovationKeepers” sempre!