Cosa dovresti includere in un documento di approccio allo sviluppo? [chiuso]

In una delle aziende in cui ho lavorato, abbiamo avuto questo approccio orientato al processo completo con molti documenti (la maggior parte dei quali è stata richiesta per essere compilata dal Project Manager). Tuttavia, nonostante la lunghezza e le spiegazioni, mi sono reso conto che difficilmente veniva usato per aiutare le persone, i veri sviluppatori.

Così ho deciso di riprendermi con un obiettivo specifico di "aiutare gli sviluppatori". La cosa più importante che ho iniziato è raccogliere la maggior parte delle domande di base: le domande frequenti real .

Quello che ho imparato è che seguire le questioni per la maggior parte delle persone quando vogliono adottare determinati processi e molte cose che potrebbero non avere una precedente idea ma che apprezzerebbero immediatamente se comprendessero la logica.

Ecco gli argomenti chiave che una tale documentazione dovrebbe aiutare:

1. Il processo di sviluppo per la distribuzione - In che modo il codice deve essere organizzato, compilato, pubblicato (sotto forma di DLL, librerie, eseguibili, programmi di installazione, pagine Web e in che modo verranno distribuiti e testati)?

2. Come dovremmo fare il controllo della versione? (e perché se ci sono principianti). Comprendere come la struttura del repository, il codice di condotta - quando un check-in è accettabile e quando no, quando viene annunciata una versione / tag, in che modo verrà applicata la patch, le unioni e quali sono le aspettative di pulizia quando una patch o il rilascio è dichiarato fatto

3. Esecuzione della metodologia - siamo agili, facciamo progettazione in anticipo, quale metodologia utilizziamo? Ora dato questo, potrebbe essere un fisso per una determinata azienda. Ora, per la maggior parte delle persone, vogliono sapere come lo implementeremo per il progetto dato. Questo è molto specifico sul progetto che permetterà alle persone di visualizzare diverse pietre miliari e ciò che è potenzialmente importante. In un progetto orientato alla ricerca - vorremmo indicare "convalidare sempre gli algoritmi critici prima di crearne uno sopra" in un involucro ristretto mi concentrerei sulla correttezza e l'importanza delle caratteristiche.

4. Responsabilità di comunicazione - Definire come si fa la comunicazione formale - non si fa in modo che determinate persone possano parlarsi - ma le persone devono avere un'idea di ciò che è abbastanza importante (problemi, decisioni di progettazione, blocco delle funzionalità) essere annunciati o addirittura discussi prima di procedere all'attuazione.

5. Infine, dobbiamo tutti avere una comprensione comune della qualità del codice, dello standard di codifica e in generale di ciò che pensiamo sia ok o al di sotto del livello di igiene.

Vorrei iniziare ogni progetto con questi documenti, tuttavia non è abbastanza facile. Ma la cosa importante è affrontare tutti i problemi relativi al comportamento quotidiano e alle scelte degli sviluppatori. Questo è molto lungo quando devono essere consegnate più versioni sul mercato.

Infine, vorrei anche suggerire di cercare di essere il più informale possibile. Di solito, i ragazzi orientati al processo non amano i documenti informali che possono potenzialmente essere fraintesi al di fuori del contesto. Tuttavia, dovrebbe essere fatto in modo tale da connettere gli sviluppatori.

Ciò che chiamate il "documento di approccio allo sviluppo" è in genere chiamato Piano di gestione del progetto software . (Ho anche sentito chiamare il Piano di progetto software o il Piano di sviluppo software .) Con questi termini, dovresti essere in grado di Google per alcuni campioni che sono là fuori . Come menzionato Victor Hurdugaci e Donal Fellows, il piano di Project Management del software che scriverai sarà (1) personalizzato in base alle tue esigenze e (2) aggiornato come documento vivente man mano che la situazione evolve. Detto questo, scriverne uno da zero può essere difficile se non ne hai mai scritto uno prima e non sai che altro dovrebbe esserci.

Vi sono alcune linee guida attraverso lo standard IEEE 1058 (Standard IEEE per i piani di gestione dei progetti software, 1998). C'è una copia dello standard pubblicato qui . Trovo che questo piano sia piuttosto pesante, ma è un posto decente per avere idee - e potresti aver bisogno di un peso in più se vuoi tutto per iscritto per una squadra che è al largo. C'è anche uno schema abbastanza buono - e una buona narrativa su come pianificare i progetti software - in un libro mi rivolgo spesso ai progetti software tradizionali (non agili): Gestione dei progetti software di qualità di Futrell, Shafer e Shafer.

Un documento di approccio è un documento "Né qui né là" . Questo è un documento generalmente richiesto dai Project Managers (Vendor Managers) di organizzazioni aziendali da Project Managers (Software Development Manager) di Software Application Development Organizations.

Lo scopo di questo documento varia in base alle esigenze del PM dell'organizzazione.

Può contenere l'architettura hw, le funzioni di sistema, i piani di comunicazione, i piani di configurazione, i piani di caricamento delle risorse, lo stack tecnologico, l'architettura dell'applicazione e così via.

di nuovo, l'elenco precedente è variabile in base alle esigenze ..:)

Devo ancora vedere la letteratura formale su un documento del genere. se ce ne sono degli autori standard, Pressman, ecc. condividi ...

o mi manca qualcosa.

The most recent (similar) document our company has used is over 80 pages, and that does not include coding standards/conventions documents.

Dato che hai già alcuni documenti, questo è il tuo punto di partenza. Chiediti:

1. Che cosa è utile in questo documento?
2. Cosa manca?
3. Perché (non) uso questo documento?

Dopo aver ottenuto le risposte, taglia ciò che è indesiderato e aggiungi le parti mancanti.

Il contenuto effettivo del documento dipende dalle risorse disponibili e credo sia difficile speculare usando le informazioni fornite.

Solo un suggerimento: ti consigliamo di regolare questo documento nel tempo, quindi non scrivere troppo;)

Le pratiche di sviluppo cambiano nel tempo man mano che cambiano le tue esigenze e cambiano il set di linguaggi, librerie e framework che usi. Questo cambiamento è inevitabile e significherà che tutto ciò che metterai su carta sarà (quasi) obsoleto immediatamente. Il modo di affrontare questo? Mantieni tutto in un wiki e incoraggia tutti i membri del team, interni ed esterni, a mantenerlo aggiornato e pertinente.

Una volta che hai preso il passaggio da un documento morto a uno vivente, il dibattito su cosa mettere diventa meno urgente: ti basta inserire ciò a cui puoi pensare ora e tornare ad esso in un secondo momento. (La cosa buona è che non dovrai capire tutto per scrivere il documento in primo luogo.) Potresti anche voler seminare tutto con il contenuto obsoleto dal vecchio documento di 80 pagine; questo ti darà un sacco di materiale di contorno se non altro, risparmiandoti di dover pensare di scrivere enormi quantità di cose noiose.

Mantieni il documento breve. Usa la strutturazione dei giornali - inizia con dettagli di alto livello e segui le specifiche. Invece di includere le pratiche standard, basta fare riferimento a esse e dettagliare le deviazioni dallo standard.

1: Se stai già facendo progetti all'interno della tua azienda, sali a bordo con questo processo. Forse anche subappaltare la gestione del tuo sviluppo del progetto a loro. Non reinventare la ruota.

2: Se non fai già lo sviluppo in casa, insisti che l'appaltatore che stai utilizzando ha una buona metodologia che usano per i progetti. Quindi utilizzare questa metodologia.

Fidati ma verifica. Stai cercando di estirpare la spazzatura nel lungo periodo. Quindi non lasciare che facciano nulla, segui qualsiasi processo con solo deliverable alla fine. Insistere affinché i primi deliverable siano eseguiti e controllati prima che si spostino.

Oltre a ciò, fondamentalmente lo dico su @Dipan