Chiunque usi il Team Software Process (TSP) e / o il Personal Software Process (PSP)? [chiuso]

TSP è stato sostanzialmente introdotto e presentato al management dai consulenti come mezzo per aiutare a raggiungere l'obiettivo della certificazione CMMI di livello 3. Potrei continuare a parlare del disastro che ne è seguito dopo che questo processo ha iniziato a essere forzato da uno staff di sviluppo di agilisti che producevano regolarmente software di alto valore per il cliente, ma invece parlerò della metodologia TSP.

TSP è un processo in incognito in cascata ... periodo. Il sistema stesso è progettato per processi ripetibili e in nessun luogo sostiene qualsiasi valore nel software che viene fornito. La sua preoccupazione principale è fare in modo che un processo venga catturato, registrato, seguito e misurato. Lo sviluppo di TSP è avvenuto perché le organizzazioni stavano lottando per soddisfare le rigorose richieste della CMMI. È stato visto come un ponte per arrivare a CMMI. È stato fondato nel mondo accademico e nella mia esperienza ha difficoltà nel campo dello sviluppo di applicazioni aziendali.

Ti piace programmare con un diario di bordo e un cronometro? È così che misuri il tuo lavoro. Si suppone che i dati siano protetti in modo che non possano essere utilizzati da singoli sviluppatori per la gestione. Ci sono voluti circa 2 mesi prima che la direzione iniziasse a chiedere al Team Leads le metriche individuali. Puoi solo immaginare come sono iniziate le metriche delle persone fantastiche dopo aver appreso che la direzione le stava esaminando.

TSP è stato presentato come un tipo di bilanciamento del carico di un processo iterativo di 3 mesi. Con ciò intendo che una serie di lavori viene presentata e concordata in anticipo con il cliente. C'è una serie di incontri cerimoniali in cui i requisiti sono disegnati nel sangue e il lavoro è pianificato. Ogni sviluppatore riceverà una pila di quel lavoro. È fondamentalmente un sistema di micro spinta. Una volta che uno sviluppatore ha esaurito il lavoro, può subentrare nel carico di altri sviluppatori che potrebbero rimanere indietro. La priorità dei requisiti non è considerata o accumulata e impilata. Tutto è considerato lavoro che deve essere fatto e da ciò deriva una struttura di rottura del lavoro. Parliamoci chiaro: il lavoro non significa programmazione. Potresti trascorrere la maggior parte del tuo tempo scrivendo i documenti di progettazione e incrociando il riferimento a tale design con le specifiche dei tuoi requisiti software. Oh, e registrando nella tua cartella di lavoro ogni fase del percorso ... ricorda di fare clic su quel cronometro.

All'interno di quel lavoro di iterazione di 3 mesi procede rigorosamente secondo un sistema a cascata. Non ci sono concetti di Test Driven Development o Emergent (simple) design. TSP segue un documento Requirements, un documento di progettazione, una codifica, un test e un approccio graduale di implementazione. Tutte queste fasi devono essere ben documentate come parte del processo e seguite rigorosamente con le liste di controllo. Tutte queste fasi sono di natura lineare e una serie di metriche sono registrate per ciascuna fase. Una volta ho visitato un altro sito in cui TSP era in fase di implementazione e mi è stato categoricamente detto che le persone non eseguono test prima o durante la codifica. Queste persone stavano praticamente operando nell'età della pietra e non avevano alcun concetto di sviluppo guidato dai test.

Ci sono vari ruoli che ogni sviluppatore deve giocare oltre al motivo per cui sono stati assunti in primo luogo. Questi ruoli sono essenzialmente un modo per imporre la capitolazione del processo al personale di sviluppo. Come avere un vicino nord coreano amante a cui piace controllarti una volta alla settimana solo per vedere come lo stai facendo. Gli sviluppatori del mio team detestavano assolutamente avere questi ruoli addizionali come l'esecutore dei processi, la pianificazione degli esecutori, l'incontro con l'esecutore, ecc. Per quanto riguarda la collaborazione tra sviluppatori ... praticamente inesistenti. Ricorda che ti è stato consegnato il tuo lavoro per i prossimi 3 mesi. Si riduce a un gruppo di persone mascherate da una squadra.

Una volta alla settimana il "team" si riunisce per rivedere le metriche che sono state registrate nelle cartelle di lavoro. I grafici dei valori guadagnati sono rivisti, i diagrammi di analisi del rischio sono minati da vicino, ma ancora più importante è una buona sessione una volta alla settimana per sfogare la frustrazione di dover seguire il processo quando tutte le persone vogliono fare un ottimo software.

Abbiamo perso molti sviluppatori di talento durante questo esperimento. Intendo alcune persone davvero talentuose. TSP è la gestione scientifica e il taylorismo racchiusi in un bel pacchetto che i tipi di gestione superiore sembrano amare. Da allora ho lasciato l'organizzazione e mi sono trasferito ad altri grattacapi, tuttavia non lavorerò mai più con TSP nella mia carriera. Penso che sia sicuro dire che molti dei miei ex colleghi hanno la stessa opinione.

Horrible. Assolutamente odiato.

L'hanno portato nel mio vecchio posto di lavoro (probabilmente la più famosa azienda di software al mondo) e ha avuto un successo variabile con esso.

Una sezione della società (l'app dell'app dev) era la cavia (dove ero), l'altra sezione (lo sviluppo del prodotto) l'ha appena buttata fuori, fuori controllo.

Per me, a livello di sviluppatori, tutto ciò che ha fatto è stato introdurre troppo processo.

Ogni incontro di "livello superiore", i manager presenterebbero tutti questi grafici parlando di bassi conteggi degli errori, riducendo nel tempo ecc. ecc., quando in realtà i progetti erano altrettanto buggati / ritardati di qualsiasi altro progetto normale, era solo l'essere vestita bene da Dev leads.

Suppongo che si possa dire che si tratta di un fallimento delle squadre piuttosto che del sistema, ma sono state più le squadre che cercavano di aggirare un sistema che non gli piaceva e che ritenevano effettivamente ostacolato il loro progetto.

Sono passati diversi anni, ma le 2 cose che sono rimaste intatte sono state l'incredibilmente terribile strumento per fogli di calcolo Excel che hai dovuto usare, e l'analoga "costruzione di una casa" analoga ai corsi di formazione.

Con PSP, devi monitorare le metriche sulle funzioni piccole, medie e grandi che scrivi e tracciarle nel tempo ecc. ecc.

Il mio problema con questo e l'analogia della casa è che mi sto spostando dalla tecnologia alla tecnologia, dalla versione alla versione, quindi non ho visto come funzionerebbero le metriche su quanto tempo mi ci vuole per fare qualcosa.

Ciò di cui nessuno di voi sviluppatori si rende conto è che tramite TSP e PSP voi come sviluppatori potete scrivere il vostro curriculum personale con prove (dati) per eseguirne il backup. Anche i tuoi dati sono i tuoi dati personali e come Coach TSP non possiamo discutere i tuoi dati con nessuno tranne il proprietario di quei dati ... Sì, c'è un processo che deve essere rispettato e certamente ogni sviluppatore deve essere disciplinato a cattura i dati.

TSP ha aiutato la nostra organizzazione a ottenere le nostre stime in modo più accurato, ma per far ciò è necessario essere disciplinati come sviluppatori per acquisire dati accurati; spazzatura nella spazzatura. TSP / PSP non porta nulla di nuovo alla tavola, solo il fatto che c'è un processo che molti di noi hanno imparato durante i nostri corsi.

Dall'avvento delle lingue 4GL, tutte queste discipline sono volate fuori dalla finestra e il compilatore è diventato il modo di testare il codice. TSP riporta i vecchi modi di fare le cose producendo un design (specifiche del programma) e poi una recensione personale e una peer review. Quindi lo codifichi e, una volta fatto, rivedi il tuo codice e poi fai rivedere i tuoi pari; tutto questo è scaduto e i difetti registrati.

Quindi per le persone a cui piace lavorare nel caos questa non è la strada da percorrere.

Devi essere disposto a cambiare e imparare come vedrai dai tuoi dati dove puoi migliorare.

Ho seguito il corso PSP e sono stato coinvolto nella creazione di formazione online per questo. Ho visto una serie di implementazioni di successo di TSP / PSP nelle aziende - ad es. Intuit, Adobe, HP. La premessa è strong: usa dati storici accurati della tua performance come sviluppatore (in termini di tempo e, forse ancora più importante, di difetti), analizzalo (ti vengono dati gli strumenti per farlo) e basi le previsioni future del tuo rendimento su questo (è la PSP), e poi arrotolalo con i dati dei membri del tuo team per creare proiezioni per le prestazioni della tua squadra (è il TSP). Laddove i team "acquistano", è straordinariamente efficace nel migliorare la pianificazione e ridurre i tassi di difetti: sono stati pubblicati molti studi di casi e rapporti.

La privacy dei dati è una preoccupazione che viene considerata ad un certo punto da tutti coloro che guardano la PSP. Il principio della PSP è che i tuoi dati personali non vengono mai condivisi. Quando viene riavvolto con gli altri nella tua squadra, il team può accedere ai dati recuperati. Se lavori per un'azienda che viola questo principio, è probabile che tu abbia messo alla prova i tuoi problemi di privacy.

Gli sviluppatori spesso hanno la possibilità di registrare il tempo contro le loro attività. La chiave di questo è una dimostrazione efficace del vantaggio di tenere un registro, imparare ad analizzare i dati e applicare le lezioni apprese per scrivere codice meno difettoso nel tempo che hai detto che avresti fatto. L'esperienza di questo è abbastanza interessante.

Dai un'occhiata a:

link Mi è consentito solo 1 hyperlink nel mio post, quindi sarà il mio; -)

Guarda anche i siti Web per le pagine TSP di Software Engineering Institiute, i loro procedimenti Symposium annuali e la voce di Wikipedia per PSP (è più completo della pagina TSP).

TSP ti offre solo bellissimi grafici e dati artificiali per fare belle presentazioni e rallentare il progetto alla grande. Può essere venduto solo perché la gestione non è uno sviluppatore e non sa come gli sviluppatori fanno il loro lavoro. Se, fortunatamente, un'azienda ha una gestione che sa qualcosa sullo sviluppo, la società non utilizzerà mai il TSP o abbandonerà il processo come il cestino.