O que você deve incluir em um documento de abordagem de desenvolvimento? [fechadas]

Estou no meio da co-produção de um documento de "abordagem de desenvolvimento" para recursos externos, à medida que eles se aproximam do nosso projeto.

O documento mais recente (semelhante) que nossa empresa utilizou tem mais de 80 páginas e não inclui documentos de normas / convenções de codificação.

Minha preocupação é que este documento não seja consumível e, portanto, falhe.

O que deve estar em um documento de abordagem de desenvolvimento? Existem diretrizes decentes sobre esse tópico?

EDIT: O documento da abordagem de desenvolvimento deve detalhar as práticas e técnicas que serão usadas pelos desenvolvedores de software enquanto o software é projetado, construído e testado.

Em uma das empresas em que trabalhei, tínhamos toda essa abordagem orientada ao processo com muitos documentos (a maioria deles foi solicitada pelo gerente de projeto). No entanto, apesar do comprimento e das explicações, percebi que isso dificilmente ajudava as pessoas - os verdadeiros desenvolvedores.

Então eu decidi me recompor com um objetivo específico de "ajudar os desenvolvedores". A coisa mais importante que comecei é coletar as perguntas mais básicas - as verdadeiras perguntas frequentes.

O que eu aprendi é que seguir é importante para a maioria das pessoas quando elas querem adotar certo processo, e muitas coisas que elas talvez não tenham idéia prévia, mas que apreciariam imediatamente se entenderem a lógica.

Aqui estão os principais tópicos que essa documentação deve ajudar:

1. O processo de desenvolvimento para implantação - Como o código deve ser organizado, compilado e publicado (na forma de DLLs, bibliotecas, executáveis, instaladores, páginas da Web e como eles serão implantados e testados)?

2. Como devemos fazer o controle de versão? (e por que se houver novatos). Entenda como a estrutura do repositório, o código de conduta - quando um check-in é aceitável e quando não, quando uma versão / tag é anunciada, como o patch, as mesclagens serão aplicadas e quais são as expectativas de limpeza quando um patch ou liberação é declarada concluída

3. Executando a metodologia - somos ágeis, desenvolvemos projetos iniciais, qual metodologia usamos? Agora, considerando isso, pode ser um conserto para uma determinada empresa. Agora, para a maioria das pessoas, elas querem saber como vamos implementá-lo para o projeto em questão. Isso é muito específico sobre o projeto que permitirá que as pessoas visualizem marcos diferentes e o que é potencialmente importante. Em um projeto orientado para a pesquisa - gostaríamos de indicar "sempre valide algoritmos críticos antes de construir sobre ele" em um resumo, enfocarei a correção e a importância dos recursos.

4. Responsabilidades de comunicação - Definir como você faz a comunicação formal - isso não é feito com relação ao fato de pessoas específicas poderem conversar entre si - mas as pessoas devem ter uma noção do que é importante o suficiente (problemas, decisões de design, congelamento de recursos) para anunciar ou até debatido antes de prosseguir com a implementação.

5. Finalmente, todos nós devemos ter um entendimento comum da qualidade do código, do padrão de codificação e, em geral, do que achamos que está ok ou abaixo do nível de higiene.

Eu gostaria de começar todos os projetos com esses documentos - no entanto, não é tão fácil. Mas o importante é resolver todos os problemas relacionados ao comportamento diário e às escolhas dos desenvolvedores. Isso ajuda bastante quando várias liberações no mercado precisam ser entregues.

Finalmente, eu também sugeriria que tentasse ser o mais informal possível. Geralmente, o pessoal orientado ao processo não gosta muito de documentos informais que podem ser mal interpretados fora do contexto. No entanto, isso deve ser feito de maneira a conectar os desenvolvedores.

O que você está chamando de "documento de abordagem de desenvolvimento" geralmente é chamado de Plano de Gerenciamento de Projetos de Software . (Também ouvi dizer que ele se chama Plano de Projeto de Software ou Plano de Desenvolvimento de Software .) Com esses termos, você poderá procurar no Google algumas amostras disponíveis. Como Victor Hurdugaci e Donal Fellows mencionaram, o plano de gerenciamento de projetos de software que você escrever será (1) adaptado às suas necessidades e (2) atualizado como um documento vivo à medida que a situação evoluir. Dito isto, escrever um do zero pode ser difícil se você nunca o escreveu antes e não sabe o que mais deve fazer.

Há algumas orientações no IEEE Standard 1058 (IEEE Standard for Software Project Management Plans, 1998). Há uma cópia do padrão postada aqui . Acho esse plano bastante pesado, mas é um local decente para se obter idéias - e você pode precisar de um peso extra, se quiser tudo por escrito para uma equipe que está no exterior. Também há um esboço muito bom - e uma ótima narrativa sobre como planejar projetos de software - em um livro que recorro frequentemente aos projetos de software tradicionais (não ágeis): Gerenciamento de Projetos de Software de Qualidade por Futrell, Shafer e Shafer.

Um documento de abordagem é um documento 'Nem aqui nem ali' . Este é um documento geralmente solicitado pelos gerentes de projeto (gerentes de fornecedores) das organizações comerciais dos gerentes de projeto (gerentes de desenvolvimento de software) das organizações de desenvolvimento de aplicativos de software.

O objetivo deste documento varia de acordo com as necessidades do PM da organização comercial.

Pode conter arquitetura hw, funções do sistema, planos de comunicação, planos de configuração, planos de carregamento de recursos, pilha de tecnologia, arquitetura de aplicativos e assim por diante.

novamente, a lista acima é variável com base nas necessidades .. :)

ainda estou para ver literatura formal sobre esse documento. se houver algum dos autores padrão Pressman etc. compartilham ..

Ou eu estou esquecendo de alguma coisa.

O documento mais recente (semelhante) que nossa empresa utilizou tem mais de 80 páginas e não inclui documentos de normas / convenções de codificação.

Como você já possui alguns documentos, esse é o seu ponto de partida. Pergunte a si mesmo:

1. O que é útil neste documento?
2. O que está faltando?
3. Por que (não) eu usaria este documento?

Depois de obter as respostas, corte o que não é desejado e adicione as peças que faltam.

O conteúdo real do documento depende dos recursos disponíveis e acredito que seja difícil especular usando as informações fornecidas.

Apenas uma dica: você deseja ajustar este documento ao longo do tempo, para não escrever muito;)

As práticas de desenvolvimento mudam com o tempo, à medida que seus requisitos mudam e com o conjunto de idiomas, bibliotecas e estruturas que você usa. Essa mudança é inevitável e significa que qualquer coisa que você colocar no papel ficará desatualizada (quase) imediatamente. A maneira de lidar com isso? Mantenha tudo em um wiki e incentive todos da sua equipe - internos e externos - a ajudar a mantê-lo atualizado e relevante.

Depois de dar o passo de um documento morto para um documento vivo, o debate sobre o que colocar se torna menos urgente: você apenas coloca o que pode pensar agora e volta a ele posteriormente. (O bom é que você não precisará entender tudo para escrever o documento em primeiro lugar.) Você também pode querer propagar tudo isso com o conteúdo desatualizado do antigo documento de 80 páginas; isso lhe dará um monte de material básico, nada mais, o que evita que você tenha que pensar em escrever um monte de coisas chatas.

Mantenha o documento curto. Use a estrutura do estilo de jornal - comece com detalhes de alto nível e siga com detalhes. Em vez de incluir práticas padrão - basta referenciá-las e detalhar os desvios da norma.

1: Se você já está realizando projetos em sua empresa, participe desse processo. Talvez até subcontrate o gerenciamento do desenvolvimento do seu projeto para eles. Não reinvente a roda.

2: Se você ainda não desenvolve o desenvolvimento internamente, insista para que o contratado que você está usando tenha uma boa metodologia que eles usam para projetos. Então use essa metodologia.

Confie mas verifique. Você está tentando eliminar o lixo a longo prazo. Portanto, não deixe que eles façam nada, siga qualquer processo com apenas entregas no final. Insista para que a entrega antecipada seja feita e verificada antes de prosseguir.

Além disso, eu basicamente diria no @Dipan