Vorrei suddividerlo in sezioni come

• Personale attuale - nomi e titoli (idealmente con le foto)
• Applicazioni, accessi a loro, dati da conoscere e richieste di autorizzazione da inviare
• Segnalibri a siti aziendali e siti chiave esterni pertinenti all'azienda
• Applicazioni che l'azienda utilizza per comunicazioni, e-mail, prenotazioni in sala conferenze, schermo in vetro
• Procedure per attività correlate alla società come Expensing Receipts, booking travel
• Impostazione della macchina per sviluppatori. Descrivi il processo di configurazione di una nuova macchina per sviluppatori in dettaglio. Solitamente, questo è "previsto" solo per un giorno, ma spesso occorrono in realtà 3-5 giorni.
• Il processo di sviluppo, il modo in cui il lavoro è tracciato, assegnato e aggiornato e quali strumenti vengono utilizzati.
• Come testare, cosa testare, quando testare, dove testare.
• Standard di codifica incluse convenzioni per la denominazione dei file e standard specifici per la lingua.
• Come gestire i bug, dove documentarli, come risolverli.
• processo di implementazione, quali sono le cose fondamentali da sapere per i push di produzione.
• Come documentare, cosa documentare, Quando documentare.
• Dove roba 'è', ad es. posizione (s) per codice, dati, standard, documentazione, collegamenti e altre attività.

Rendendolo modulare consentirà anche a te o ad altri di aggiornare i pezzi separatamente, ad esempio i nomi e le posizioni dei dipendenti cambieranno di frequente man mano che le persone vanno e vengono.

Per ogni sezione, proverei a scriverlo da un punto di vista "newbie". La cosa più importante sarà assicurarsi che abbia davvero senso per un principiante. Il tuo capo ovviamente è non la persona giusta per esaminarlo poiché non è il pubblico previsto. Ha ragione a volerlo, ma assicurati che il contenuto non venga sottoposto a test da . Anche un "principiante" ha solo "1 settimana" come novizio ... e ha solo un punto di vista. Quindi è probabile (e consigliato) che il documento venga perfezionato con ogni nuovo dipendente. In effetti, è un compito piuttosto buono assegnarle anche per la loro prima settimana, ad esempio "Aggiornare il manuale per principianti".

Per Agile / SCRUM:

La parte più difficile di Agile e SCRUM è "davvero" in corso.

Per leggere vorrei iniziare dal link e andare da lì.

Vorrei anche leggere il noto link che aggiunge peso al fatto che devi davvero abbracciare tutti gli aspetti per questo lavorare. Se devi modificare pesantemente Agile per le tue organizzazioni, è probabile che le persone desiderino i benefici, senza utilizzare i processi corretti. Questo fatto stesso dovrebbe essere presentato per scongiurare ogni mezzo assenso.

Sembra che dovrai introdurre alcune pratiche prima di documentarle!

a) Controllo del codice sorgente: come immagazzini i tuoi sorgenti e controlli di revisione

b) Gestione e tracciamento dei rilasci - come si fa una build, una release, si confronta un candidato alla release corrente con una versione precedente

c) Gestione dei problemi: come tenere traccia dei bug nelle versioni.

Queste sono cose piuttosto semplici ma possono impiegare molto tempo (e possibilmente costare) per implementarle.

Argomenti che includerei nel manuale di uno sviluppatore:

• Ruoli / posizioni all'interno del dipartimento e relative responsabilità
• Requisiti del software della macchina per sviluppatori (vale a dire l'ambiente di sviluppo richiesto)
• Dove e come accedere al repository del codice sorgente
• Strumenti di sviluppo utilizzati (ad es. IDE)
• Stile di codifica / standard
• Standard di documentazione
• Processo di test
• Processo di compilazione
• Processo di distribuzione
• Supporto ed elaborazione del processo di gestione
• Dove trovare la versione più aggiornata di questo manuale

Tieni presente che questo manuale dovrebbe contenere solo elementi specifici per lo sviluppo e non informazioni a livello aziendale (che dovrebbero essere contenute in un manuale del dipendente).

Uso del controllo del codice sorgente

• Quale strumento di controllo del codice sorgente stai utilizzando.
• Sintassi di comandi / strumenti comuni nell'IDE.
• Strategia di ramificazione / fusione.
• Quale dovrebbe essere l'unità di un commit? Quanto tempo è troppo lungo per avere un file estratto / non impegnato?
• Quale livello di "doneness" indica un commit / check-in? Compila? I test unitari passano? Inviato?
• Cosa dovrebbe essere incluso nelle note per un commit / check-in.
• Procedure di rollback.