Os vários documentos, artefatos e processos relacionados à sua geração são alguns dos principais símbolos do Cascata modelo. Pegando emprestado do Lean, o Agile considera uma grande quantidade de documentação como “desperdício” que precisa ser erradicado para otimizar o ciclo de desenvolvimento.
Para muitos gerentes de projeto, não é um grande esforço entender como as fases em cascata são transformadas em sprints - o mesmo trabalho é realizado; é apenas organizado de uma maneira diferente. No entanto, a remoção da maior parte da documentação é uma pílula mais difícil de engolir, pois destaca uma forma completamente diferente de trabalhar. Requer afrouxar as rédeas do controle, abraçar o desconhecido e capacitar a equipe de entrega para tomar decisões no local.
Na metodologia em cascata, muito tempo é gasto na documentação dos requisitos do projeto e no detalhamento das soluções. Esse processo funciona quando os requisitos estão completamente claros e temos certeza de que nada mudará do que foi capturado e definido como base. No entanto, as experiências da maioria das empresas nas últimas décadas mostraram que isso quase nunca é verdade. No mundo de hoje, o ritmo de mudança é tão dinâmico que as necessidades do cliente mudam consideravelmente no momento em que concluímos a fase de documentação.
O foco do Agile é fazer as coisas e agregar valor às partes interessadas. É construído de forma que o modelo desestimule o trabalho em periféricos e em atividades que não agreguem valor direto e imediato para o cliente.
Cada empresa possui um nível diferente de documentação, que pode diferir até mesmo no nível do projeto. Mas aqui está a aparência dos procedimentos de documentação típicos em projetos em cascata e Agile:
Cascata | Ágil |
A documentação é obrigatória na maioria das vezes. Nenhum trabalho progride a menos que a documentação esteja completa. | Recomenda-se apenas a documentação básica para entender o suficiente para começar o trabalho. |
Os documentos passam por um longo processo de revisão e devem ser aprovados por várias partes. | Não há um processo formal de revisão e aprovação e o gerente de projeto é o principal tomador de decisões. |
Modelos padronizados precisam ser seguidos. | Não existem modelos formais para documentação; as melhores práticas são usadas em seu lugar. |
Vários tipos de documentos são necessários em diferentes fases: termo de abertura do projeto, declaração de visão, documento de requisitos de negócios, requisitos funcionais e não funcionais, documentos de design de alto nível (HLD) e design de baixo nível (LLD), etc. | Apenas os documentos necessários para fornecer funcionalidade no próximo sprint são necessários. |
Mudanças na documentação são difíceis porque todos os documentos estão interligados. | Mudanças na documentação são muito mais fáceis. |
É necessário um sistema ou processo para gerenciar um grande número de documentos. | A documentação é mínima, portanto fácil de gerenciar. |
O Waterfall promove uma abordagem muito mais rígida da documentação, o que pode parecer excessivo. Mas antes de descartar isso como “desperdício”, aqui estão vários benefícios de ter procedimentos de documentação sólidos.
Aqueles que falham em planejar, planejam falhar. A documentação força um gerente de projeto a sentar e pensar sobre as coisas e, em seguida, apresentar as melhores soluções. Às vezes, as pessoas interpretam erroneamente o valor Agile do software funcional em relação à documentação abrangente, o que significa que nenhuma documentação é necessária. Em seguida, eles correm para o mercado, um movimento Paul Adams, vice-presidente de produto da Intercom, descreve como jogando coisas na parede e vendo o que gruda. Projetar soluções, criar planos, deliberar ações - essas atividades criam valor ao economizar tempo em não desenvolver todas as ideias de recursos que vêm à mente.
À medida que as empresas passam de poucos fundadores para centenas ou milhares de funcionários, muitas equipes diferentes começam a trabalhar no mesmo produto ou em produtos relacionados. A equipe A pode pensar que o que eles estão trabalhando não está relacionado ao que a equipe B está trabalhando, mas para o usuário final, é tudo o mesmo produto. Em vez de equipes multifuncionais fazerem suas próprias coisas, uma documentação clara sobre a experiência do usuário e os níveis funcionais evita um fluxo de usuário desarticulado.
Em Waterfall, muito tempo é gasto detalhando as soluções e como elas serão usadas. Imagens de designs de alta fidelidade são criadas para desenvolvedores front-end. Todos esses ativos requerem menos trabalho para serem convertidos em guias de usuário internos ou externos do que criá-los do zero.
Um fator que sempre aparece como desculpa para exigir a documentação é a rotatividade de funcionários. Os gerentes temem perder o conhecimento institucional quando as pessoas saem e novos ingressam para substituí-los. Como eles saberão o que foi implementado e como funciona? Quanto tempo eles levarão para alcançá-los? A equipe atual terá largura de banda para acomodar novos membros da equipe?
A esperança é que uma boa documentação faça com que os novos funcionários que trabalham principalmente de forma independente rapidamente se adaptem. No entanto, o Agile inerentemente reduz a necessidade de documentação por meio de técnicas de colaboração que, ao mesmo tempo, reduzem o tempo de integração. Aqui estão algumas maneiras como o Agile reduz a necessidade de documentação.
o Manifesto Ágil promove “indivíduos e interações sobre processos e ferramentas”. Como os requisitos tendem a mudar durante um projeto e novas ideias surgem, o Agile garante o esclarecimento dos requisitos diretamente da fonte, em vez de depender de artefatos escritos que precisam de atualização constante.
A preparação do backlog e o planejamento do sprint dividem os recursos em partes específicas e implementáveis que são facilmente compreendidas e podem ser trabalhadas de forma independente. Isso cria uma oportunidade para os novos contratados serem produtivos desde o início, embora ainda não tenham um entendimento completo do panorama geral do projeto.
O formato simples de histórias de usuários permite que os gerentes de projeto capturem os requisitos mínimos básicos que criam um entendimento compartilhado entre todos os membros da equipe. Mesmo que uma história de usuário não se transforme em um sprint, o desperdício de criar esse artefato de documentação é muito baixo. Conforme as histórias de usuário se movem para os sprints, elas podem ser aprimoradas e complementadas com outras informações necessárias, como wireframes, designs, critérios de aceitação, etc. Este processo fornece uma entrega de documentação muito eficiente, altamente descartável e produzida nos estágios de desenvolvimento mais adequados.
Técnicas como programação em pares e revisão de código criam oportunidades constantes para disseminar o conhecimento técnico por toda a equipe, especialmente para novos membros. O feedback constante leva a um entendimento compartilhado que também tem a flexibilidade de se adaptar a novas circunstâncias em vez de se tornar rapidamente desatualizado em um documento em algum lugar.
Levantamentos diários, revisões de sprint e retrospectivas criam amplas oportunidades para resolver problemas e tomar decisões cara a cara em vez de depender de e-mail e documentos. O tempo limitado de todas as cerimônias garante que apenas as informações mais importantes sejam priorizadas, em vez de gastar tempo documentando tudo, mesmo que provavelmente nunca seja usado.
Todos os itens acima reduzem direta ou indiretamente a documentação e priorizam a entrega das metas do projeto, garantindo que nada seja realmente perdido por falta de documentação.
Algumas empresas ainda preferem ter alguma documentação, mesmo em um ambiente Agile. O Agile não é prescritivo, porque cada projeto é diferente e tem um conjunto único de circunstâncias que precisam ser abordadas.
Abaixo estão alguns exemplos de como o Agile pode ser combinado com métodos de documentação mais demorados.
Considere o uso de uma linguagem de modelagem padrão, como Unified Modeling Language ( UML ) que é muito estruturado e tem entidades definidas para visualizar um sistema. Isso ajuda a manter o conteúdo muito simples e focado no que é necessário e garante o uso mínimo da linguagem escrita. Ferramentas como StarUML e Draw.io , entre muitos outros, são opções convenientes.
Outra abordagem é garantir que o código seja muito mais legível, introduzindo comentários mais estruturados e detalhados como parte dos detalhes da classe, detalhes do método, uso de parâmetro, dependências e assim por diante. Existem muitas ferramentas que automatizam o processo de geração de documentos úteis a partir do código-fonte e são chamadas geradores de documentação . Eles variam de genéricos a específicos de linguagem de programação.
Definir requisitos usando wireframes, mockups, diagramas de fluxo do usuário, diagramas de sequência, etc. ajuda a simplificar os fluxos do projeto, bem como deixar explicitamente claro para a equipe técnica o que precisa ser desenvolvido. Os documentos de design são uma ótima maneira de ter um nível variável de documentação mais rígida. Existem vários wireframing e UX ferramentas para escolher para essas tarefas.
Mais poderoso gerenciamento de projetos e ferramentas relacionadas tal como JIRA , Confluência , Asana , e Campo de base fornecem uma maneira de manter todas as informações relacionadas ao projeto em um só lugar. As tarefas podem ser vinculadas, marcadas, aninhadas e atribuídas a diferentes membros da equipe, que podem deixar comentários e relatar quaisquer problemas. Todas essas ações, junto com a flexibilidade para adaptar essas ferramentas, podem criar uma quantidade substancial de documentação com pouco ou nenhum esforço.
Além disso, historicamente, parte das necessidades de documentação decorre de requisitos de relatórios. As partes interessadas desejam acessar o desempenho da equipe ou outras métricas relevantes. As ferramentas de gerenciamento de projetos facilitam a automatização de painéis e visualizações personalizados que refletem o progresso do projeto e vinculam de volta à documentação relevante dentro da ferramenta.
Os criadores do Manifesto Ágil escrevem que valorizam “software funcional em vez de documentação abrangente”. No entanto, eles também adicionam uma isenção de responsabilidade de que “embora haja valor nos itens à direita, [eles] valorizam mais os itens à esquerda”. Agile não sugere remoção todos documentação, porque alguma documentação obviamente fornece valor; simplesmente sugere que a prioridade deve ser no software funcional e adicionar documentação apenas conforme necessário, dependendo das circunstâncias do projeto e sem impedir fortemente o progresso do desenvolvimento.
Os gerentes de projeto precisam atingir um equilíbrio entre gastar menos tempo com documentação e mais tempo entregando software funcional e realmente descobrir onde alguma forma de documentação é necessária para o sucesso a longo prazo.
O Agile normalmente tem alguma documentação necessária para manter um projeto estável. No entanto, o Agile promove a colaboração em vez da documentação como forma preferencial de compartilhamento de conhecimento.
Ágil às vezes significa ausência de documentação se a equipe for capaz de compartilhar conhecimento de maneira eficaz por outros meios. Normalmente, isso só é possível em equipes pequenas e alguma documentação é inevitavelmente introduzida à medida que a empresa cresce para dezenas ou centenas de pessoas.
Não há documentos predefinidos que devem ser produzidos de acordo com o Agile. As equipes devem decidir por si mesmas que quantidade de documentação é necessária e não impediria o progresso do desenvolvimento.
O principal objetivo da documentação é reter o conhecimento institucional e criar um entendimento compartilhado entre os membros da equipe e quaisquer outras partes interessadas relevantes.
Um processo de documentação é um conjunto de ações predefinidas que explicam como e quais tipos de documentos são criados em vários estágios de um projeto.