Non è spesso che un libro di management del progetto software arriva che è pratico, facile da leggere e impilato pieno di pronto per l'uso degli script di processo. Andrew Stellman e Jennifer Greene hanno fatto solo che con il recente libro Applied Software Project Management.
Ci sono troppi libri sulla gestione dei progetti software o software engineering asciutta, eccessivamente complesso e noioso, ma questo libro non è uno di loro. E ' stata una gioia a leggere perché il loro stile di scrittura è chiaro senza essere semplicistica e gli autori descrivono le cose in appena la giusta quantità di dettaglio. Sembra che capiscono il loro pubblico e a scrivere in un modo estremamente utile e pratico. Certamente hanno raggiunto questo.
Prima parte del libro copre strumenti e tecniche che possono essere applicati su progetti. Pianificazione, valutazione, pianificazione, recensioni, requisiti di progetto, design e programmazione e test ciascuno hanno loro proprio capitolo. La seconda parte è sull'utilizzo di project management in modo efficace e capitoli sul cambiamento di comprensione, di gestione e di leadership, gestione di un miglioramento di processo e di progetto di outsourcing.
Un filo chiaro in tutto il libro è una descrizione del team del progetto tipici problemi software faccia – prescrizioni inadeguate, gestione dei cambiamenti, mancanza di garanzia della qualità in ogni fase di un progetto, infiniti test e bug-fixing cicli, tensioni e incomprensioni tra ingegneri del software e gli utenti aziendali. Nessuno di questi problemi sono di natura tecnica, ma sono di carattere organizzativo e gestionale. Stellman & Greene offrono consigli pratici per risolvere questi problemi basati sulla loro esperienza su progetti simili.
Stellman & Greene certamente sembrano sapere molto su problemi che devono affrontare squadre di software. Già l'introduzione che descrivono la necessità di superare i problemi cronici e questo tema è continuato per tutto il libro. Per ogni problema, c'è sempre almeno una soluzione proposta. Ad esempio, descrivono uno scenario comune per cui dirigenti non si fidano le stime del team tecnico, in qualche modo credere che il team di tecnici sono volutamente over-estimating al fine di dare loro qualche tempo slack. La soluzione proposta è coinvolgere questi manager nel processo di stima in modo che possano vedere le stime effettuate in modo trasparente e sistematico. Poi vai per descrivere in dettaglio come eseguire una sessione di stima Wideband Delphi e fornire esempi di modelli e documenti che possono essere utilizzati durante tali sessioni. Essi forniscono inoltre uno script processo prezioso per le squadre da seguire.
Capitoli successivi riguardano pianificazione, programmazione, recensioni, requisiti, progettazione e test. Mentre la maggior parte di questi capitoli coprono ogni argomento in dettaglio ragionevole, la sezione sul design è carente nel dettaglio e fornisce alcuna descrizione su che tipo di risultati finali design non potrebbe essere prodotta, né potrebbe contenere qualsiasi descrizione dettagliata di ciò che questi risultati finali del design. Questo è in contrasto con il capitolo di requisiti che contiene gli script di processo per elicitazione dei requisiti e analisi, nonché una descrizione dettagliata dei casi d'uso e documenti di specifiche esigenze software.
Un altro aspetto bello del libro è le liste di controllo che compaiono dopo aver affrontato uno dei temi principali del progetto gestione o ingegneria del software. Liste di controllo sono importanti tecniche di garanzia della qualità che gli autori giustamente devono essere utilizzati in tutti i progetti software come un modo per catturare errori all'inizio. Ad esempio, se una lista di controllo applicate alle specifiche esigenze del software rileva il fatto che un requisito fondamentale è mancante o ambigui, quindi l'errore può essere corretto durante la fase di analisi. Gli autori spiegano che da catturare e correzione degli errori all'inizio, il costo è piccolo rispetto al costo di correzione degli errori trovati più tardi in un progetto. La loro enfasi sulle tecniche di garanzia della qualità applicato in tutto il progetto con esempi di liste di controllo da applicare sono quindi molto pratico e utile.
Gli autori potrebbero voler riconsiderare alcuni esempi che utilizzano. Essi descrivono il processo di refactoring del codice al fine di rendere più gestibile e uso un esempio di alcuni Java code che hanno gradualmente refactoring sopra diverse iterazioni. Alla fine di questo processo che dicono perché refactoring sarebbe applicabile in situazioni dove il codice è simile a spaghetti. Questo va bene, tranne per il fatto che utilizza un esempio di codice Java molto ONU-spaghetti-come effettuare il refactoring. In questo modo mi sembra che cadono in una trappola di programmatori comuni di abbellimento di codice dove programmatori trascorrono tempo dalla pianificazione iterativamente miglioramento del codice che funziona bene per scrivere il codice 'perfetto', classe o oggetto. Ho visto questo accadere su progetti in cui non c'era semplicemente il tempo nel calendario per permettere questo, e certamente non ha portato alcun beneficio aggiuntivo business agli stakeholder. Tuttavia questo è un piccolo cruccio.
Sarebbe piaciuto avere visto più pagine dedicate alla gestione del rischio. Volta, non di gestione dei rischi è citata come una ragione perché i progetti falliscono. Gli autori descrivono la gestione del rischio in modo superficiale, ma il libro dovrebbe beneficiare di una migliore descrizione di come e perché la gestione del rischio dovrebbe essere fatto durante tutto il progetto, non solo nelle prime fasi di pianificazione del progetto.
Una cosa che ho pensato che il libro che mancavano era uno sguardo dettagliato di metodi iterativi. Il presupposto implicito in tutto è che il progetto del software dovrebbe seguire il metodo della cascata. Io sarei d'accordo. Ci sono state alcune importanti alternative per il metodo a cascata che sono state sviluppate negli ultimi 20 anni soprattutto quelli basati su approcci iterativi. La rovina principale con l'approccio a cascata è il presupposto che tutto ciò che riguarda i requisiti è noto all'inizio di un progetto.
Approcci iterativi invece supporre che requisiti cambierà durante il progetto sia perché gli utenti acquisire una migliore comprensione di che cosa hanno bisogno, o a causa di cambiamenti nell'ambiente di affari. Basato su questo presupposto, metodi iterativi sono progettati per gestire meglio questo ambiente in continua evoluzione. Con approcci di cascata, cambiamenti nei requisiti richiedono spesso il progetto di rivedere le fasi precedenti, con un corrispondente aumento dei costi e sforzo. Gli autori passano a malapena una pagina su Rational Unified processo (RUP) e gli autori dovrebbero esaminare più da vicino come loro consigli pratici e processi potrebbero essere utilizzati su approcci alternativi iterativi all'approccio della cascata.
Infine, ritengo che il libro ha cercato di essere troppo ampia, facendo appello a tre diversi gruppi di persone. In primo luogo, una parte si rivolge a coloro che sono coinvolti in un team software (project manager, analisti, programmatori e tester). La seconda parte si rivolge a consulenti assoldati per migliorare le pratiche di gestione del progetto e project manager che hanno bisogno di gestire progetti di outsourcing del software. Il libro sarebbe stato meglio aveva si è concentrata esclusivamente su coloro che sono coinvolti nel team software.
Occupano il penultimo capitolo di gestione di un progetto di outsourcing è affrontato in maniera superficiale, quasi come se gli autori ritenuto che hanno bisogno di parlare perché l'outsourcing è tale una priorità di business in questi giorni. Il capitolo finale process improvement è anche troppo breve per gestire in modo efficace con un soggetto così grande. Singoli libri trattano esclusivamente questi problemi sarebbero stato più appropriati.
Non sopportare questi punti, questo libro è una guida eccellente per quelle persone coinvolte in progetti software, sia i responsabili di progetto e team tecnico membri alike. Essi troveranno molto che possono essere applicati direttamente sui propri progetti.
Vorrei raccomandare questo libro a chi lavora in un team di sviluppo software, perché il libro ha così tanto consigli pratici per aiutare le persone a migliorare la loro capacità di fornire la qualità del software. Vieni a pensarci bene, vorrei anche raccomandare e ai senior manager di aziende che hanno una visione negativa del proprio team di sviluppo software. Forse poi senior manager potrebbe capire perché commettere le risorse per elaborare il miglioramento è uno dei migliori investimenti che possono fare.
No comments:
Post a Comment