O processo Agile: como e o que deve ser documentado?

Há algum tempo, a empresa em que trabalho havia terceirizado um projeto de desenvolvimento para terceiros. Eles empregaram práticas ágeis no desenvolvimento da solução. No entanto, quando solicitados para documentação, eles apenas diziam que era necessário, pois foi incorporado em um wiki ou como parte de seus sprints.

Eles saíram na conclusão do projeto, com todos, exceto um da equipe do projeto. O site wiki do projeto foi encerrado após o vencimento da assinatura anual.

Quando eles partiram, levaram a maior parte do conhecimento e entendimento do que foi desenvolvido com eles.

Então, eu tenho 2 perguntas principais;

1. Isso é normal para o ágil ou apenas uma desculpa para não querer escrever?
2. Qual é a norma da indústria para documentação em projetos ágeis para registrar requisitos de desenvolvimento, projetos, decisões importantes e contexto?

Isso é normal para o ágil ou apenas uma desculpa para não querer escrever?

Minha teoria é que é por isso que o ágil se espalha tão rápido, especialmente o scrum . Já vi muitas equipes desejando agilidade para se proteger (em vez de toda a empresa). O problema é que, em muitos casos, a metodologia é usada contra eles pela gerência (porque eles também querem se proteger!).

Isso significa que o ágil não funciona? Claro que não, isso significa apenas que o ágil ajuda você a resolver alguns problemas comuns, mas você ainda está no comando de todos os outros. E, em muitos casos, o agile simplesmente não é adequado para essa equipe naquela empresa.

Qual é a norma da indústria para documentação em projetos ágeis para registrar requisitos de desenvolvimento, projetos, decisões importantes e contexto?

Para ser breve:

A equipe deve definir quanta documentação eles precisam

Eles conhecem o domínio, são os especialistas e, mais importante, constroem a coisa!

É isso que significa trabalhar com documentação abrangente no Agile Manifesto .

Eles deixaram para você um conjunto de testes TDD, testes de aceitação ou outros testes de unidade? Eles fazem um bom trabalho ao documentar como um aplicativo funciona e espera-se que ele funcione, além de fornecer uma implementação de exemplo de como usar o que foi desenvolvido.

Embora eu não seja um especialista em Agile, aqui está minha tentativa de resposta:

1. Havia uma história / requisito solicitando documentação específica? Caso contrário, isso faz parte do problema, à medida que você obtém o que é solicitado até certo ponto. É uma desculpa e eu poderia me perguntar o que você quer dizer com "normal" aqui. É apenas a maioria daqueles que seguem os princípios do Agile que torna algo normal ou faz parte do processo geral que deveria ser esperado? Essas são as duas visões que eu pude ver. Edição: Duvido que exista algo que a maioria das equipes faça da mesma forma quando se trata de documentação, mas isso é um palpite da minha parte.

2. Alguns links que podem ser interessantes são o melhor que eu poderia fazer sobre isso:

   • Práticas recomendadas para documentação Agile / Lean
   • Documentação técnica e ágil

O Agile tem alguns pontos específicos no manifesto , onde eu indicaria este junto com a nota:

Software que trabalha sobre uma documentação completa

Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda.

Eles são simplesmente horríveis. Não acredito que agile signifique nenhuma documentação. Eles devem ter, pelo menos, acompanhado a descrição do aplicativo. Obter uma exportação de seu wiki seria bom ou permitiria que outra pessoa pagasse a taxa de serviço.

Pode não ser tão detalhado quanto uma tentativa. A teoria é que, quando em uma crise de tempo, as especificações não correspondem mais ao código de qualquer maneira. Portanto, você tem documentação suficiente para escrever o código e não tentar defini-lo em detalhes (mais ou menos como escrever o código em algum texto pseudo-verbalizado / código do diagrama e depois no código real).

Seu problema não tem nada a ver com o Agile. Eles deveriam ter produzido a documentação que você solicitou. O projeto foi mal gerenciado.

Deve haver alguma descrição dos recursos, histórias do usuário e casos de teste em algum lugar , no mínimo. A TI pode estar nos arquivos Leia-me nos projetos, nos comentários do código-fonte, nos documentos de design; pode ser tudo o que precede ... ou pode ser MIA!

Na minha experiência, sempre há muitas pessoas exigindo documentação (eu fui uma delas), mas na prática ninguém realmente tem tempo ou vontade de criá-las. Ocasionalmente, existem esforços, mas a documentação criada geralmente desatualiza-se muito rapidamente e desincronia com o funcionamento real do sistema. Isso leva a uma situação em que, mesmo que você tenha documentação, ninguém realmente se incomoda em verificá-la, porque simplesmente não confia na sua precisão.

Para precisão real e informações confiáveis, tudo se resume à capacidade de ler códigos e testes. Um cliente que deseja (re) descobrir o que seu sistema faz sempre pode entrevistar e consultar um programador que pode apresentar (com alguma investigação) fatos sobre o sistema.

Criar uma boa documentação não é trivial e pode ser bastante caro. Em segundo lugar, pode-se perguntar sobre o público, para quem é a documentação e o que ela pretende fornecer?