XP vs tradizionale buona gestione dei progetti [chiuso]

Question

Sono stato nel settore IT per 10 anni ma ho lavorato in "tradizionalmente" team di progetto gestiti (sia ben gestiti che mal gestiti).

Ho sentito parlare di " nuovo " Scrum o XP tipo di project management e desideroso di far parte di uno (come gente s / w ci piace sempre qualsiasi cosa nuova immagino) ma non ho avuto l'opportunità.

La mia domanda è questa: quali sono le tue esperienze nel passaggio al " nuovo " modo - era significativamente migliore o peggiore o non diverso? C'è stato qualche miglioramento del tasso di successo del progetto quando si utilizza XP way of development o è lo stesso di qualsiasi progetto tradizionale ben gestito?

Questa non dovrebbe essere una domanda politica, ma solo le tue esperienze mentre ti sei trasferito nel nuovo mondo o hai vissuto almeno una volta e ritorno.

Grazie in anticipo

Answer 1

Prima che avessi mai sentito parlare di XP, avevo un ottimo manager (Mike) in un lavoro iniziale che avevo. Era abituato a gestire gli ingegneri e passò alla gestione del software. Dopo alcune brutte esperienze lavorative ho ripensato al suo stile rispetto al tipico project management che avevo prima e dopo aver lavorato con lui.

• Ho incontrato tutti almeno una volta al giorno ma ci ha dato spazio per lavorare
• Ha usato una lavagna con due colonne, le persone che lavorano e ciò su cui stanno lavorando possono guardare quella lavagna e vedere se qualcosa è stato fatto o è stato fatto
• Hanno fatto incrociare tutti quanti. Ho imparato rcs e poi cvs lì e come usare make files
• Ran produttivo "post mortum" quando un'attività è stata completata. Farebbe una domanda del tipo "avrebbe aiutato se X" fosse o " la prossima volta, possiamo provare a ... "
• Continuava a lavorare su compiti brevi e gestiva il nostro tempo, quindi lavoravamo sempre su qualcosa ma non avevamo mai accumulato un sacco di cose

Mike ha fatto tutto sulla carta. Avrebbe tenuto con sé quaderni e schede. Insisteva affinché tutto ciò che gli era stato chiesto dalla direzione venisse convertito in compiti gestibili, spesso scritti su schede. Si rifiutava di far lavorare chiunque su qualsiasi cosa che non potesse essere spiegata chiaramente o che avesse un obiettivo chiaro. Chiederebbe ai VP "che cosa intendi per più veloce?" " Quali tipi di metriche devono essere mostrate dai rapporti? " " Perché questa dovrebbe essere una priorità? " Sembrava avere quasi infinita pazienza nello scrivere ciò che doveva essere fatto e cosa si intendeva con "fatto"

Quando ho letto per la prima volta il libro su XP, sono rimasto sorpreso da quanto mi fosse familiare il modo in cui Mike ha lavorato "

Sembra che Agile stia semplicemente implementando una serie di buone pratiche e valutando come funzionano nel proprio ambiente. Quando non funzionano, cambiali. Quando funzionano, attenersi a loro.

Penso che il vero problema con la tradizionale gestione dei progetti sia che il più delle volte non esiste davvero. Sono sorpreso da quanti negozi affermano di utilizzare RUP o Code Complete o addirittura Agile e in realtà non hanno nulla di riconoscibile come project management. Certo, ci sono incontri. E le persone chiamavano project manager. Ma fai una domanda semplice come "cosa è stato fatto sul progetto X" o "cosa resta da fare sul progetto Y" e nessuno ha una risposta. Devono scavare attraverso e-mail o puntare a un file di progetto MS comicamente impreciso.

Se una persona ha affermato di essere a dieta e non ha potuto rispondere a domande su ciò che stava mangiando o su come si stava esercitando; accetteresti che erano davvero a dieta?

Answer 2

Porta con te il tuo vecchio bagaglio quando vai. Ciò significa che eventuali cattive pratiche di gestione del progetto che hai avuto in precedenza permarranno ancora.

Tuttavia, dirò che le cose sono migliorate notevolmente quando abbiamo iniziato a chiudere il circuito tra noi e il cliente. Feedback e prototipazione sempre più frequenti e con il cliente significano molti meno momenti in cui il cliente dice "Questo non è quello che volevo".

Answer 3

Ho usato (leggermente modificato) Scrum prima al lavoro e qui sono i miei pensieri:

• Gli incontri quotidiani e il burn-down hanno fornito la motivazione per fare progressi sui compiti.
• Il nostro manager potrebbe parlare con i colleghi attraverso lo stagno e mostrare loro " questo è ciò su cui stiamo lavorando questo mese. "
• Sapevi esattamente quali compiti dovevi svolgere e avevi già stimato il tempo necessario per il completamento.
• Quando le priorità sono cambiate (nuove attività, importanti bug aggiunti), c'è stato un processo ben definito per gestire l'aggiunta di loro allo sprint o semplicemente spingendoli nel backlog.

Answer 4

Queste sono risposte adorabili, ma penso che tutti confondano la gestione dei progetti con metodologie di sviluppo / progettazione.

Answer 5

Faccio parte di un team che ha avviato Scrum alcuni mesi fa e sembra che stiamo facendo le cose più velocemente e con molto meno "spreco". (progetti che vengono demoliti). Solo le mie osservazioni dal nostro piccolo team (4 sviluppatori).

Answer 6

Ho trovato molto positivo il passaggio complessivo alle pratiche Agile / XP, in molti modi che carica la qualità nel processo di progetto / sviluppo. Avrai bisogno di buy-in dalla direzione e dal team per vedere davvero il successo ... alcuni suggerimenti:

• prova qualsiasi cambiamento con un piccolo progetto (2-3 persone)
• capisci in quali aree il tuo attuale team può migliorare di più (qualità? produttività? time-to-market?) e incorporare alcuni processi Agile / XP / Scrum (qualunque cosa) in ... non incorporarli tutti in allo stesso tempo e capire quali processi affrontano quali problemi prima di qualsiasi modifica
• se possibile - traccia le aree che stai cercando di cambiare e confrontale con un altro progetto in esecuzione allo stesso tempo (il semplice obiettivo di migliorare qualcosa spesso è sufficiente per migliorarlo, c'è uno studio / termine per questo, ma dimentico di cosa si tratta)
• a volte vedrai un calo delle prestazioni quando inizi un nuovo processo, questo fa parte della curva di apprendimento
• non dare mai per scontato che un buon cambiamento oggi rimarrà un buon cambiamento domani, rivedi sempre le aree del tuo progetto ed essere pronto a cambiare qualsiasi processo in qualsiasi momento
• nessuna modifica rimane valida per sempre, proprio come il codice di refactoring, refactoring dei tuoi processi
• assicurati di ricevere acquisti dal team e dalla direzione, non puoi forzare il successo

Answer 7

Mi piacciono alcune delle cose che fanno gli approcci agili, ma apprezzo anche alcune delle cose che fanno gli approcci tradizionali.

Entrambi possono funzionare, così come una miscela dei due, che è ciò che trovo funzioni meglio per il mio team ora. Ho implementato lo sviluppo incrementale e ci aiuta davvero; lo sviluppo iterativo è un po 'più difficile e ci stiamo ancora lavorando. Tuttavia, abbiamo una varietà di componenti e molti dei nostri stakeholder (e PM) preferiscono manufatti e pietre miliari tradizionali. Quindi dobbiamo continuare a trovare il giusto equilibrio.

Ho anche scoperto che ancor più importante della metodologia sono le persone che la implementano. Le brave persone trovano un modo per fare un buon lavoro e fare le cose indipendentemente dalla metodologia, anche se certamente la metodologia può avere effetti sull'efficienza (e sul morale :)). Risorse scarsamente allineate, tuttavia, possono utilizzare la migliore metodologia e trovare modi per ottenere scarsi risultati.

Answer 8

Per gli sviluppatori, le grandi lezioni di XP & amp; Co. sono cicli di rilascio più brevi e un approccio più evolutivo, nel senso che il cambiamento dei requisiti è accettato come parte naturale di qualsiasi progetto. Inoltre, i clienti suggeriscono soluzioni, ma i progettisti e gli sviluppatori devono comprendere i problemi.

Lezioni per manager: gli sviluppatori non sono convertitori da codice a codice scambiabili, i loro punti di forza e di debolezza possono fare una differenza di produttività di 10 o più per un determinato argomento. Conoscenza ed esperienza sono le competenze più preziose nel tuo team e gli sviluppatori possono insegnare ad ogni altro. I gestori non devono comprendere cosa fanno gli sviluppatori per imporre i risultati desiderati.

---

XP e amp; Co. di solito mescolano soluzioni a queste con il problema di apportare un cambiamento alla società . L'eroico consulente XP che salva da solo un progetto condannato, ritardato e deragliato funge in larga parte da buffer tra sviluppo e gestione. Ma se stai cercando cosa imparare, devi separare questi aspetti.

Quello che ho imparato negli ultimi anni è che i bug non sono un difetto di personalità e che il cielo non cade quando cambiano le specifiche. Ho imparato che mentre gli errori di progettazione sono ancora i più costosi da fare, non esiste un unico "perfetto" design. Invece di ottenere una cosa giusta, dobbiamo implementare delle garanzie che di tutti i molti dettagli nessuno va storto - e ho imparato a usare il margine tra "giusto". e "non sbagliato" a nostro vantaggio.

Answer 9

La mia esperienza è stata che preferisco usare Scrum rispetto agli approcci tradizionali in quanto non è capitato spesso che i requisiti potessero rimanere invariati per la durata di un progetto in cui di solito i progetti sembrano correre almeno 6 mesi a quello attuale che è oltre un anno.

Può esserci anche un caso in cui non esiste alcuna gestione del progetto e tutti si affrettano a "farlo funzionare". quindi avere una struttura formale va bene per niente. C'è qualcosa alla domanda su quanto bene la squadra si riunisce e gli ego raramente compaiono in quanto non è il codice di qualcuno ma piuttosto il codice della squadra e c'è una specie di gruppo che pensa dove mentre ogni persona ha il suo punto di vista, nessuno cerca di far vedere a tutti gli altri in questo modo.

A volte mi sembra che alcuni approcci Scrum e Agile che ho usato finiscano per essere come rapide invece che una grande cascata. Ciò che intendo è che il ciclo di raccolta dei requisiti - Analizza e progetta - Implementa - Test - Distribuisci e ottieni requisiti aggiornati sembra essere ripetuto più volte in modo che ciò che esce alla fine sarebbe estremamente difficile da dichiarare all'inizio del progetto a meno che lo sponsor del progetto non possa fornire requisiti molto dettagliati che non cambierebbero mai.