Cosa aggiungerebbe in questo elenco di controllo per i progetti di sviluppo software? [chiuso]


14

Sono un grande fan delle liste di controllo. C'è una lista di controllo di viaggio , una lista di controllo mobile e persino una lista di controllo Scrum .

Contesto : sei stato assunto da una grande azienda e ti è stata affidata la missione di impostare l'intero ambiente di sviluppo del software, i processi, il team, ecc. Hai "carta bianca". Sarai responsabile della creazione degli incrementi di funzionamento del software. Dimensione del progetto: 2000 uomini / giorni.

Quali elementi aggiungerei alla seguente lista di controllo (intenzionalmente piccola e incompleta):

  • Installa un server di integrazione continua
  • Scrivi un DoD
  • Scrivi linee guida per la codifica di una pagina
  • Crea un backlog di prodotto
  • Installa un sistema di tracciamento dei bug
  • Pianifica il Face Time regolare

Risposte:


10

* 1.) Parla con gli sviluppatori per vedere di cosa hanno davvero bisogno! *

2.) Scopri una soluzione per visualizzare rapidamente più ambienti (pensa a istanze cloud pubbliche o private o macchine virtuali vecchio stile se non sei conforme alle parole d'ordine)

3.) Controllo sorgente / versione

4.) Sistema di revisione del codice (Crucbile / Fisheye come esempio)

5.) Muro Kanban (o qualcosa di simile)

6.) Protocolli di comunicazione (la chat in tempo reale è un grande vantaggio), i wiki incoraggiano anche la collaborazione. Questo riguarda anche le pubbliche relazioni interne: come interagirai con i proprietari delle tue attività, il personale di supporto tecnico e altri gruppi?

7.) Lavagne elettroniche

8.) Ambiente confortevole per gli sviluppatori (divani, tavoli, aree relax, buon WiFi ecc.)

9.) Ottimo caffè !!!


cofee fa la differenza:) + 1
RBA

quali sono le lavagne elettroniche che usi?

@Pierre 303 - Stampa i risultati di una sessione di lavagna bianca a (la foto di alta qualità farà lo stesso trucco, immagino).
Martijn Verburg,

8
  • Configurazione della toolchain : IDE, server CI, server di qualità del codice, controllo del codice sorgente, server web, database, tracker dei problemi, ecc.
  • Backup : che ruolo ha ogni persona nel team? Quali processi / moduli "possiede" e chi è il suo backup?
  • (Accettazione dell'utente) Impostazione dell'ambiente di prova - Non solo integrazione continua w. unit test, ma test di integrazione per coprire cose davvero brutte, piattaforme multiple, application server, VM, ecc.
  • Impostazione dei test delle prestazioni - Quanto prima è meglio, dal momento che saranno necessari dati storici per rispondere "Con quale caratteristica / pietra miliare le prestazioni sono diminuite così tanto?"
  • (Utente finale) Schema della documentazione - Cosa ci sarà nella documentazione? Quali tipi di documentazione sono necessari?
  • Canali di marketing - Come vengono annunciati i traguardi interni e le versioni esterne? Hai un bel nome per il software, un logo, i colori, i termini ecc.?
  • Comunicazione interna - In che modo i colleghi di altri team verranno informati dei cambiamenti? Come viene fatta la collaborazione? Wiki? Diritti di accesso?
  • Garanzia della qualità di persone e di processo - Chi sta per verificare che cosa, con quale frequenza e con quali criteri?
  • Processo di rilascio : quando, quanto spesso, come, chi lo sta facendo, chi sta ricevendo il rilascio ecc.
  • Gestione del rischio - Scenario peggiore (da un progetto mgmt pov e da un pov di runtime, ad esempio 'il cliente sta perdendo denaro perché il software non è riuscito nel modulo X, qual è il piano di backup?)
  • Protezione dell'ambiente di sviluppo principale, ad esempio virtualizzazione per l'impegno
  • Location per incontri formali e informali
  • Formazione o introduzioni per tutte le persone, in modo che sappiano cos'è tutto il setup, a cosa serve ogni parte e come la usano.
  • Identificare il custode e dargli tutte le cose (ad esempio i permessi) di cui ha davvero bisogno per prendersi cura di quando le cose vanno male

+1 per i backup e la formazione
Liviu T.

backup, anche se penso che parte di questo sia stravagante.
BlackICE,

5

Recensioni post-mortem - Dato che stai lavorando a blocchi, pianificherei una revisione di una o due ore (a seconda delle dimensioni del team) per avere un incontro faccia a faccia (se possibile) in cui tutti vanno in giro e dicono cosa è stato fatto bene, cosa potrebbe essere fatto meglio e ciò che non era necessario. Essere in grado di imparare presto dai propri errori nel processo di sviluppo significa che è possibile evitare di farli in seguito quando non si ha molto tempo con cui lavorare.


4

Cominciamo con l'assunzione di una buona squadra dei professionisti giusti per il tuo progetto. In una tipica app aziendale è necessario assumere almeno uno sviluppatore di database e un dba, un addetto al controllo qualità, un amministratore di sistema, un analista aziendale, uno sviluppatore di applicazioni, uno specialista dell'interfaccia utente e un team leader. DBA, Amministratore di sistema, analisti aziendali e QA dovrebbero essere in una catena di reporting separata dal team di sviluppo. Lo specialista del database di sviluppo dovrebbe riferire allo stesso lead tecnico degli sviluppatori dell'applicazione e dello specialista dell'interfaccia utente.

Imposta lo spazio ufficio. Gli uffici privati ​​sono fantastici se riesci a ottenerli (ti auguro tanta fortuna con questo), ma in un minimo hai bisogno di scrivanie, telefoni, computer, lavagne e un paio di sale conferenze dedicate. Assicurati che ci sia un posto per le pause pranzo, un frigorifero, bevande analcoliche, snack e caffè disponibili. Bevande analcoliche gratuite e caffè ancora meglio.

Configurare i server dev / qa / staging e prod sia per l'applicazione che per i database. I database non dovrebbero mai trovarsi sullo stesso server delle applicazioni. A seconda delle dimensioni e dell'ambito del progetto, potrebbero essere necessari più server o SAN, ecc. Per ciascun ambiente.

Non appena i server sono impostati, pianificare i backup del sistema di file, del database e dei registri delle transazioni del database. Fallo il primo giorno in cui le cose sono impostate. Assumi un'azienda come Iron Mountain per eseguire backup fuori sede settimanalmente.

Impostare un sistema di controllo del codice sorgente e creare un documento che descriva come verrà utilizzato. Non dimenticare di insistere sul fatto che TUTTE le modifiche strutturali del database e gli inserimenti di dati per le tabelle dei tipi di ricerca si trovano negli script nel controllo del codice sorgente. Ciò renderà più semplice la distribuzione.

Acquista software commerciale o scarica software open source per il set di strumenti che hai deciso di utilizzare con le licenze per tutti gli utenti interessati.

Acquista macchine sviluppatore che stanno urlando velocemente e hanno due monitor. Acquista almeno una macchina utente di prova che si lamenta lentamente e tipica di ciò che gli utenti avranno sui loro desktop.

Allena i tuoi nuovi sviluppatori a come vuoi che le cose vengano fatte. Se hai un team abbastanza grande da avere alcuni sviluppatori junior, allora pianifica una formazione extra per loro e includi il tempo nella pianificazione del tuo progetto. Monitorare i ragazzi da vicino per almeno tre mesi. Monitorare attentamente tutti i nuovi dipendenti per il primo mese. Sbarazzarsi di deadwood e sviluppatori disonesti il ​​prima possibile.

Determina cosa deve essere fatto in quale ordine (il percorso critico). Non assegnare le attività alla fine del percorso critico fino al completamento delle attività da cui dipendono.

Creare piani di test e requisiti.

Organizzare regolarmente incontri programmati con i clienti. Meritano di sapere cosa stai facendo e quali sono i blocchi stradali. Non mancare di dire loro quando le cose saranno in ritardo. Se mancano tre settimane a una scadenza e sai già che ti mancherà, quel deficit non scomparirà magicamente prima di doverlo dire al cliente. Assicurarsi che il cliente sappia che i requisiti aggiuntivi significano costi e tempi aggiuntivi e che ogni requisito aggiunto dovrà far cadere altre attività o la scadenza cambierà in base alla quantità di ore nelle nuove attività. Renderlo chiaro fin dall'inizio farà risparmiare molto dolore e ore di straordinario e costi eccessivi assorbiti dal tuo gruppo e non dal cliente.

Configurare un ambiente per il test delle prestazioni, non solo la velocità di un utente, ma uno in cui è possibile testare il numero previsto di utenti simultanei. Non aspettare per fare questo test fino al giorno prima di andare in diretta.

Nella pianificazione del progetto, supponiamo che il QA trovi i bug e che ci vorrà del tempo per risolvere. Non programmare il QA per un solo giorno alla fine.

Creare dati di test approssimativamente della dimensione che si ritiene sarà il database. Fai in modo che tutti gli sviluppatori testino il loro codice con il database di queste dimensioni. Non consentire agli sviluppatori di svilupparsi solo su un piccolo database sui loro computer personali. Questa è una causa frequente di codice che funziona bene fino a quando non raggiunge la produzione.

Pianifica i premi nel budget. Demotiva le persone quando lavorano per mesi e solo i manager ricevono dei bonus. Inoltre, ringrazia di frequente e per iscritto.

Potrebbe essere necessario un sistema di gestione del progetto o almeno impostare fogli di calcolo per tenere traccia di ciò che è necessario tenere traccia. Quando si esegue la pianificazione del progetto, assumere non più di sei ore al giorno nel piano. Questo aiuta a tenere conto del tempo che non verrà speso per il progetto, come vacanze, periodi di malattia, ferie, riunioni delle risorse umane, revisioni delle prestazioni, ecc. Se si conosce che il progetto si trova in un periodo di elevata indisponibilità (ad esempio un progetto in corso dal 1 ° novembre al 1 ° gennaio negli Stati Uniti), potrebbe essere necessario concedere ulteriori indennità per più ferie e ferie. Non è giusto aspettarsi che gli sviluppatori rinuncino a ferie e ferie e nessuno può prevedere quando accadranno cose come il tempo di malattia, il dovere della giuria, il lutto, ecc. Supponiamo che accadranno al tuo team in questo progetto.


Penso che la macchina dell'utente di prova dovrebbe essere "lamenti lenti", non "urla lenti";) Elenco molto bello.
BlackICE il

@david, mi piace il tuo suggerimento e l'ho modificato nel testo.
HLGEM,

Ottima risposta: i punti elenco o i nomi delle sezioni potrebbero essere di aiuto.
JBR Wilkinson,

3

Alcune cose che non vedo nella domanda e nelle risposte successive:

  • Piano di ripristino di emergenza. Come si esegue il backup delle caselle di sviluppo, messa in scena, test ecc.? Ogni sviluppatore ha ciò di cui ha bisogno per lavorare da casa nelle occasionali giornate di neve? Eccetera.

  • Piano di allenamento. Quante settimane di allenamento hanno bisogno i tuoi sviluppatori per rimanere in forma? Qualcuno lo sta rintracciando? (Un foglio di calcolo può essere sufficiente per la maggior parte dei team.) Avere un meccanismo per loro di riferire (inviando a qualcuno un'e-mail che dice di aver visto 2 ore di webcast su "qualunque cosa sia probabilmente sufficiente") e per la gestione da pianificare - ad esempio chi dovremmo inviare a cosa conferenza quest'anno.

  • una posizione dell'utensile. È questo un "tipo di posto che ti diamo un abbonamento MSDN; ti preghiamo di non installare nient'altro sul tuo computer" tipo di luogo o un "vogliamo il tuo codice ma non ci interessa cosa usi per modificarlo, compilarlo e testarlo "tipo di posto. Prendi e registra la decisione.

  • più ALM integrato che puoi sopportare o permettersi. Di solito il motivo della "mancata corrispondenza dell'impedenza", della doppia entrata, della sovrapposizione dell'utensile e dell'integrazione dell'applicazione della sedia girevole è che il sistema è cresciuto a pezzi. Partendo da zero, vuoi mostrare che le persone possono rimanere in un unico strumento per tutto il ciclo. Non digitare il codice in X, compilare con Y, testare con Z, modificare lo stato dell'elemento di lavoro / attività con A, riportare il loro tempo trascorso con B, dire alla persona che stava aspettando che ora possono procedere con C, cercando di capire cosa fare dopo con D, misurando i progressi complessivi con E, ecc.


2

Negozia più giorni-uomo.

È un evento raro quando le persone allocano abbastanza inizialmente.

[Più tardi ... ri-negoziare ancora di più ...]


Visto che bisogna sempre negoziare più giornate lavorative non è una cosa che consiglierei, preferirei fornire stime accurate e affidabili sulla durata di un lavoro o di un progetto.
NimChimpsky,

@NimChimpsky Di recente si è discusso qui se la capacità di stimare in modo affidabile fosse un mito nei progetti informatici. A meno che il lavoro non sia molto noto e non contenga ricerche, è intrinsecamente difficile prevedere l'ora. Anche se puoi prevedere il programma della tua squadra, prevedere fattori esterni e ritardi è quasi impossibile. Quindi stime "accurate e affidabili" non sono qualcosa che credo esista in generale.
Orbling

@Orbling esistono dove lavoro. Un rivenditore nazionale elencato ftse 250 nel Regno Unito. Alcuni progetti sono in ritardo, ma non così tardi, e fanno eccezione.
NimChimpsky,

@NimChimpsky È possibile ottenere una stima relativamente accurata se si ha il pieno controllo di tutti i risultati finali all'interno di un progetto, se non si viene bloccati dagli esterni e l'attività a portata di mano non prevede alcuna ricerca. Fornire il budget si estende a un'analisi approfondita prima della stima del tempo. Nella maggior parte delle aziende, il budget non è lì per indagare completamente prima dell'inizio.
Orbling

@orbling È possibile che richiedere sempre più tempo sia puramente arbitrario e non si basi affatto su prove, risultati, analisi o budget.
NimChimpsky,

2

Visto che ho avuto il maggior problema con le librerie di terze parti e il loro utilizzo:

  1. Determina le librerie e le versioni che utilizzerai.
  2. Crea il processo di integrazione degli aggiornamenti delle librerie per il tuo progetto.
  3. Assicurati che gli sviluppatori siano tutti a bordo delle scelte della biblioteca.
  4. Creare un canale utile per una discussione aperta sulle tecnologie utilizzate.

Perché? Non posso dirti quante volte le librerie di terze parti (proprietarie) hanno avuto bug fastidiosi che ci hanno inviato settimane di tempo di sviluppo perché non avevamo alcun processo per spostarci su o giù. O hai a che fare con gli sviluppatori che dicevano "quale versione hai usato? Perché hai usato funzioni contrassegnate come obsolete?"


1

Un grosso costo per le organizzazioni non sta assegnando un budget alla sicurezza durante l'intero ciclo di vita dello sviluppo, questo significa che la sicurezza di solito finisce per essere messa in atto dopo il fatto inefficace, costoso insieme di attività o controlli messi in atto troppo tardi per fare molto bene.

Ottieni la sicurezza integrata dal piano di progetto iniziale, con le pietre miliari chiave, lo stesso che faresti con tutti gli altri aspetti dello sviluppo e usa un processo iterativo per mantenere aggiornate le linee guida sulla sicurezza. La firma finale dalla sicurezza dovrebbe essere una verifica senza sorprese che tutti i controlli di sicurezza siano stati implementati come da progetto.

Altrimenti finirai per eseguire la sicurezza dopo l'implementazione - dove potrebbe costare 8-10 volte di più (cifre di Gartner, IBM e altri), sconvolgerai le persone poiché è probabile che la funzionalità venga compromessa e potrebbe essere troppo tardi per impedire lo sfruttamento e danno.


Sono curioso, questo dovrebbe far parte dell'elenco di controllo per l'impostazione del progetto? Lo inserisco come parte dello sviluppo del software, ma non conosco la configurazione del progetto. Lo metterei con le pietre miliari dello sviluppo, ma non penso che questo sia ciò che l'OP stava chiedendo, potrei sbagliarmi.
BlackICE,

David - forse hai ragione sul fatto che questo livello di dettaglio non dovrebbe essere presente, ma penso che dovrebbe esserci almeno un elemento pubblicitario per la sicurezza. Meglio?
Rory Alsop,

1

1. Portalo alla squadra

Chiedi ai programmatori! Davvero, questa è la cosa più importante. Incontrerai molta resistenza se gli sviluppatori non sono direttamente coinvolti in questo cambiamento. Dopo tutto, è su come essi funzionano, non tu. Va da sé, ma cercare di forzare metodi e strumenti sulle persone di solito è controproducente.

2. Ispezionare e adattare

Chiedi al team di capire il modo migliore di lavorare, usando la tua esperienza per aiutarli delicatamente a salire sulla pista scelta. Quindi, regolarmente e in modo collaborativo, guarda indietro a come stai (loro) e adatta il processo per renderlo migliore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.