Cadastrar

Esqueceu a senha?

Perdeu sua senha? Por favor, indique o seu endereço de e-mail. Você receberá um link e criará uma nova senha por e-mail.

Sorry, you do not have permission to ask a question, You must login to ask a question.

Sorry, you do not have permission to add a post.

Please briefly explain why you feel this question should be reported.

Explique brevemente por que você acha que essa resposta é inadequada ou abusiva.

Please briefly explain why you feel this user should be reported.

Por que você deve usar diagramas como documentação principal

Por que você deve usar diagramas como documentação principal

Vou lhe contar um segredo… os empresários odeiam escrever documentação. Ok, talvez isso não seja um segredo. Aceitamos de má vontade a necessidade de documentação como parte de nossos principais produtos e estratégias, quando na verdade uma boa diagramação dos dados com um fluxograma, organograma ou mesmo um mapa conceitual é fundamental.

Embora reclamemos sobre a documentação atrapalhar o “trabalho real”, entendemos a necessidade fundamental da documentação (especialmente quando somos nós que estamos procurando informações adicionais sobre uma parte da empresa que é nova para nós).

As estimativas de tempo adequadas para resolver os problemas devem incluir o tempo adequado para a documentação a fim de promover a saúde e a sustentabilidade da aplicação a longo prazo.

Uma área frequentemente negligenciada da documentação do empresário são os diagramas. Essa negligência acontece por vários motivos. Diagramas úteis levam mais tempo para serem criados do que algumas frases.

Os diagramas podem ser vistos mais como uma função de gerenciamento de projetos ou analista de negócios. Mesmo algo tão simples como a falta de consenso sobre as melhores ferramentas a serem usadas para criar, modificar e compartilhar diagramas pode desencorajar os desenvolvedores a criá-los.

Então, por que um desenvolvedor deveria se preocupar com diagramas e considerá-los como documentos vivos pelos quais são responsáveis?

Expansão, contração e reestruturação da equipe

Cada empresário escolhe um novo membro da equipe, geralmente várias vezes, durante sua carreira. Aqueles primeiros dias como o novato são normalmente um turbilhão de obter acesso adequado à rede e às ferramentas, configurar um ambiente de desenvolvimento de trabalho e ler (potencialmente) copiosa documentação de aplicativos.

Embora a maior parte do esforço seja frequentemente dedicada à documentação escrita, não seria ótimo se uma boa documentação visual estivesse disponível?

Falando por experiência própria, a resposta é um sonoro SIM !!! Quer sejam arquiteturas de sistema, layouts de pacote, diagramas ER ou uma miríade de outros pontos de diagrama em potencial em um sistema, ter fontes visuais de registro disponíveis ajuda os novos membros da equipe a se familiarizarem rapidamente.

Em ambientes de desenvolvimento Agile modernos, permitir que os desenvolvedores se tornem conhecedores e produtivos com mais rapidez é a chave para projetos de sucesso.

Não temos mais o luxo de deixar novos membros da equipe entrarem na piscina durante alguns meses, como fazíamos com os modelos mais antigos do Waterfall. Diagramas em constante evolução são uma necessidade nesses ambientes.

Na outra ponta do pipeline, os desenvolvedores deixarão os projetos. Seja devido à mudança para outra equipe, à reestruturação da equipe quando o aplicativo vai para a produção ou à exploração de outras oportunidades, a composição da equipe variará. Uma boa documentação garantirá que o conhecimento do sistema não seja perdido.

A dedicação aos diagramas brilhará aqui. Em muitos casos, é mais fácil transmitir o estado por meio da mídia visual do que confiar na documentação escrita. Isso é especialmente importante porque pode não haver ninguém a quem fazer perguntas enquanto os membros da equipe partem. Aqueles que ficarem para trás ficarão gratos por seus esforços em manter diagramas vivos.

Mitigação e solicitações das partes interessadas nos diagramas

A próxima parte se enquadra na categoria de gerenciar seu gerente. Aos olhos da maioria dos desenvolvedores, o reino da gestão são as reuniões… muitas e muitas reuniões. E os slides da apresentação são o pão com manteiga das reuniões.

Infelizmente, não estamos isentos dessa parte do gerenciamento de aplicações. Além de sermos puxados para as reuniões, dificultando o que os desenvolvedores veem como “trabalho real”, frequentemente somos encarregados de criar slides (ou pelo menos material a ser incluído nos slides) para as reuniões.

Quanto mais conhecido você se tornar por sua experiência de gestão e percepções arquitetônicas, maiores serão as solicitações por sua contribuição.

Manter bons diagramas irá aliviar seu fardo. Você poderá direcionar os PMs e outras partes interessadas aos diagramas, em vez de ter que montar algo no último minuto (como muitas dessas solicitações são).

Dependendo dos detalhes colocados em seus diagramas, você pode evitar participar inteiramente de muitas reuniões. Dadas as ferramentas de diagramação avançadas disponíveis, seus diagramas costumam contar uma história completa com pouca ou nenhuma entrada adicional de sua parte.

Uma consideração secundária de diagramas para desenvolvedores é seu papel persuasivo. Torna-se muito mais fácil convencer o gerenciamento de certas direções e decisões, como uma mudança para AWS, inclusão de um cluster Redis ou viabilidade de recursos solicitados com bons diagramas para apoiar seus argumentos.

Isso é especialmente verdadeiro com diagramas detalhados que podem mostrar a progressão histórica lado a lado com resultados previstos e arquiteturas propostas. Usar diagramas vivos como parte de suas justificativas para decisões o ajudará a chegar a um consenso com o gerenciamento mais rapidamente.

Concluindo

Esses são apenas alguns motivos pelos quais a produção e manutenção de bons diagramas são importantes para você como empresário. Você deve ter notado que não usei o termo “auxílio visual” ao falar sobre diagramas. Embora esse termo seja frequentemente usado ao se referir a diagramas, ele define um contexto ruim.

O termo geralmente traz à mente algo que não se sustenta por si mesmo, uma parte tributável que não é necessária ao todo. Você nunca deve pensar em seus diagramas de desenvolvedor dessa maneira. Os diagramas são aspectos vitais de sua documentação principal. Eles devem ser fortes o suficiente para se destacarem, contando histórias completas e convincentes.

You must login to add a comment.

Posts relacionados