Questo posto è una sintesi e una continuazione di alcune idee che sono state coperte in altri posti su questo blog: Perché gli investimenti volatili succhiano, la regola di 85/95 di direzione di progetti, e i grafici di Gantt contro base di dati PR. Se Lei ha letto tutti quei posti, allora quello che segue potrebbe averLe il senso. Se non, allora indovino che vedremo soltanto che buono uno scrittore sono. If you have read all of those posts, then what follows might make sense to you. If not, then I guess we'll see just how good a writer I am.

A muto questo giù piuttosto, userò uno dei miei dispositivi letterari preferiti: La parabola. Qui è la storia di Ploddin' Paul il direttore di progetti che è stato di fronte con una decisione di direzione molto difficile. Lui ha un'équipe di 5 progettisti, di cui tre sono progettisti più anziani e sono capaci di toccare miniprogetti per conto proprio. I loro nomi sono Genius Gary, l'Ingegnere Eric, e Liason Larry. Here is the story of Ploddin' Paul the project manager who is faced with a very difficult management decision. He has a team of 5 developers, of which three are senior developers and are capable of handling mini-projects on their own. Their names are Genius Gary, Engineer Eric, and Liason Larry.

Il progetto è un piuttosto rischioso, ma non troppo così. Lo scopo è quello di costruire un'interfaccia d'archiviazione a parecchi modelli diversi di gita in auto di nastro in modo che i clienti che registrano sul giornale di bordo in una base di dati abbiano la scelta di lasciare i loro dati in linea, salvandolo a una gita in auto di nastro, o il restauro dei dati da nastro. Certamente, c'è numero di altre caratteristiche e progetta requisiti. Il progetto è quello di esser consegnato in 6 mesi. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

L'équipe ha tre scelte: 1) Scriva che il codice da graffio 2) Rielabora alcun codice esistente che fu prodotto nella casa o 3) il Lavoro con un'interfaccia di programmazzione dell'applicazione di terzi che promette di consegnare la gran parte della funzionalità (pubblicato da un venditore chiamato Babooza).

"Gli APIs di Babooza succhiano grande e volta, lo facciamo il diritto. Scriva il codice dalla terra su in C #," dice Genius Gary, che è il programmatore migliore della grande quantità, ma ha l'atteggiamento per andare con questo.

"La strada meno rischiosa è quella di rielaborare la nostra base di codice esistente," dice l'Ingegnere Eric. "Già sappiamo come difficile questo deve lavorare con i guidatori per i dispositivi di nastro. Sì, ci sono capelli nella base di codice vecchia ma questo è il diavolo che conosciamo." Yeah, there's hair in the old code base but that's the devil we know."

"In sei settimane, Babooza dice che loro consegneranno un'interfaccia di programmazzione dell'applicazione che ha cura di la maggior parte di questo." dice Liason Larry. "Perché fanno alcuno di questo se quei tipi lo faranno per noi?" "Why do any of this if those guys will do it for us?"

"Babooza Fiduciario? Lei è pazzo. E la nostra base di codice vecchia succhia. Tutti sanno questo. Vada nuovo." And our old code base sucks. Everybody knows that. Go new."
"Fui d'accordo con Lei su Babooza. Ma Lei vuole saltare via in acqua profonda senza lifejacket. Vada vecchio." Go old."
"Ma che se Babooza consegna qualcosa funzionale? La volontà poteva fare i nostri progettisti aggiungere più caratteristiche e GUI veramente buono invece prendere un granchio intorno a prova facciamo le gite in auto di nastro archiviare.""

In questo punto nella conversazione, quasi quando i progettisti sono su funzionare al loro desktop e sistemare la questione giocando un deathmatch in "Torneo Irreale," Ploddin' Paul parla su:

"Larry, che pensa Lei le probabilità è di Babooza la consegna dell'interfaccia di programmazzione dell'applicazione in tempo e questo essere usuable?"

"Ah, io dunno, forse il 50 %"

Sia Eric sia Gary fanno rumori e Paul prende nota di questo al 25 % nella sua testa.

"Gary, se e altro progettista azionano su edificio di che abbiamo bisogno da graffio, pensa Lei che possiamo spedire in tempo?" chiede Paul.

"Naw, troppo lavoro, avrei bisogno di almeno altro tipo."

"Che se Le diedi un tipo tre mesi in? Forse due.""

"Va bene, la probabilità del 80 % di esser fatto in tempo."

Adesso è Eric e giro di Larry di fare rotolare i loro occhi. Allora Paul prende nota delle probabilità al 40 % nella sua testa.

"Eric?"

"Il C'mon Paul, mi dia l'équipe intera e il novanta percento sicuro che questo sta per esser consegnato."

"Più peloso che il dorso di un gorilla," dice Gary a una bassa voce forte a Larry. "Pensi spaghetti.""

"Eric, se Lei sta soltanto rielaborando il codice, come mai Lei ha bisogno di headcount di cinque?"

"Avanzi, più il più allegro. Ci sta per essere molta messa a punto.""

"Lei riceve un tipo per adesso, con forse più in tre mesi. Allora sono Lei il percento ancora del 90 % sicuro?""

"Ah, nessuna promessa," dice Eric

Paul mentalmente prende nota delle probabilità a 50-50. Lui ha dato un'occhiata al codice. È terribile. It's terrible.

Paul prende la sua decisione. "Tutti vanno via e fanno la loro cosa. Ritorneremo in tre mesi e rassegna." Tutti fanno un cenno col capo la loro testa e vanno via. Questo assomigliò sempre che, con Paul prende che mai una decisione sul sentiero finale per fare efetto fino al momento possibile ultimissimo. Questo guidò alcuni progettisti completamente pazzi qualche volta, con il brontolio strano che il gruppo sempre sembra di essere sul bordo d'anarchia completa. Ma Paul PROPRIO ha permesso tutti di provare la loro strada la maggior parte del tempo, allora la gente fu la più felice. Soltanto sembrò così inefficiente... We'll come back in three months and review." Everybody nods their head and walks off. It was always like that, with Paul never making a decision on the final path to take until the very last possible moment. It drove some of the developers completely nuts sometimes, with the odd grumble that the group always seem to be on the verge of complete anarchy. But Paul DID let everybody try their own way most of the time, so people were most happy. It just seemed so inefficient...

***************************************************************************

Così, su primo letto, questo assomiglia a Paul sta violando una delle regole d'oro di direzione di progetti che è sempre il lavoro forte per cambiare i Suoi 85 con 95 (cioè, sempre provi a sul Suo strano di successo, non importa che incrementale può essere). Paul sta abbandonando alcuni sentieri che promettono una probabilità di percento del 90 % di successo e affitto di progettisti di perseguire alcuni approcci del rischio alto. Anche, devo dire che quest'approccio assomiglierebbe a merda se Lei lo lanciò in aria su un grafico di Gantt: Invece di piccolo bar pulito mostrando cinque progettisti che lavorano insieme come un'équipe verso un obiettivo comune, Lei ha tre bar che lavorano in parallela verso lo stesso scopo. In alcun punto nel grafico, Lei deve concludere due di quei compiti, con tutto lo spreco per risorse che implica (In caso di Paul, il punto di decisione è di mezzo nel progetto o tre mesi). Also, I have to say that this approach would look like crap if you threw it up on a Gantt chart: Instead of clean little bar showing five developers working together as a team towards a common objective, you've got three bars working in parallel towards the same goal. At some point in the chart, you've got to end two of those tasks, with all the waste of resources that implies (In Paul's case, the decision point is halfway into the project or three months).

Riassumere: I progettisti non pensano che Paul è un direttore decisivo di progetti, e certamente, se il capo di Paul visse e morì dal grafico di Gantt, lui si chiederebbe perché Paul sprecava risorse con tutto il redundacy.

Ma ancora una volta, la matematica lavora per Paul, perché in sviluppo di software, i sentieri paralleli con una probabilità ragionevole di successo sono un migliore che un sentiero con una probabilità alta di successo. Annoti che il sentiero di parallele significa che Lei aggiunge le percentuali insieme, non si moltiplicano come in una successione:

Un sentiero: il 90 % di successo.
Tre sentieri: il 25 % + il 40 % + il 50 % = il 115 % di successo!!!

Certamente il 115 % non significa che il progetto è assolutamente sicuro di esser completato con successo e in tempo. Queste percentuali sono percentuali di giocatore d'azzardo, significando che la somma è l'aggiunta di una serie di scommesse per un saldo dato. Una storia metaforica potrebbe fare cose più chiare. A metaphorical story might make things clearer.

Fingiamo che siamo in casino, piuttosto che in un ambiente di sviluppo di software. Lei ha 500$ nella Sua tasca e il premio è... Oh, io dunno... una marca nuovo Ipod (La versione migliore, quel che con 40 calessini. Quel che mia moglie non mi permetterà di comprare 'la causa non ho un lavoro, sebbene questo mi faccia veramente, veramente felice se io possa).Oh, I dunno... an brand new Ipod (The best version, the one with 40 gigs. The one my wife won't let me buy 'cause I don't have a job, even though it would make me really, really happy if I could).

Lei può mettere tutti i Suoi soldi su una scommessa e avere una probabilità del novanta percento di vincita. O Lei può fare una serie più complicata di scommesse come Paul fece: Lei posa 100$ e ha una probabilità del 25 % di vincita. Lei anche contemporaneamente posa 200$ e ha la probabilità del 50 % di vincita e posa altri 200$ per avere una probabilità del 40 % di vincita. You put down $100 and have a 25% chance of winning. You also simultaneously put $200 down and have 50% chance of winning and put down another $200 to have a 40% chance of winning.

E qui è dove il divertimento entra: Con la prima scommessa, c'è una rotazione della ruota e Lei sa se Lei è un vincitore o un perdente. Se la stima dello sviluppo è corretta, Lei è un vincitore nove volte di dieci. If the estimate of the development is correct, you are a winner nine times out of ten.

Ma con il tre scenario di scommessa, Lei ha tre rotazioni della ruota, e se una delle rotazioni arriva un vincitore, Lei riceve la metà dei Suoi soldi indietro dalle altre due scommesse. Ad esempio, se una delle scommesse di 200$ arriva un vincitore, Lei riotterrebbe 150$ (il 50 % di 100$ e 200$). Cioè, se l'approccio di Gary spera di essere un vincitore dopo di tre mesi nel progetto, allora Lei può abbandonare l'approccio di Eric e Larry. That is to say, if Gary's approach looks to be a winner after three months into the project, then you can abandon Larry and Eric's approach.

Ma che avviene se nessuna delle scommesse arriva un vincitore? Ah, bene se questo avviene, il casino Le permetterà di piegare la Sua scommessa e rotazione di nuovo, prendendo la metà della somma totale delle Sue scommesse (250$) e permettendoLe di girarsi di nuovo (Con le probabilità di successo non sanno fino a dopo che le 3 prime rotazioni siano completate). Cioè, se dopo di tre mesi, l'interfaccia di programmazzione dell'applicazione da Babooza completamente succhia, e l'équipe di Gary non può perfino fare un quotidiano costruisce senza il compilatore che entra in crisi isterica, allora Paul può prendere la decisione per lanciare tutti su progetto di Eric di rielaborare la base di codice vecchia. That is to say, if after three months, the API from Babooza totally sucks, and Gary's team can't even do a daily build without the compiler going into hysterics, then Paul can make the decision to throw everybody on Eric's project to rework the old code base.

In corto il complesso, l'allocazione quasi caotica di risorse in un ambiente di sviluppo di software tiene conto di una probabilità migliore di un progetto completato, e per un uso più efficiente di risorse di progettista. Inciampai attraverso questa scoperta per lo più per caso, quando mi lagnavo dell'inadeguatezza di grafici di gantt per descrivere esattamente quello che veramente entra in un ambiente di sviluppo true. Di sicuro, non ho aspettato trovare una prova matematica per il comportamento che vidi nel PWS (il software) la divisione di Creo. For sure, I didn't expect to find a mathematical proof for the behavior that I saw in the PWS (software) division of Creo.

Anyways, per me questo è una scoperta veramente fresca, perché convalida tutti diretti intorno a e fa la Sua cosa e prendere una decisione più tardi si avvicinano. Bene, voglio dire che la matematica convalida la teoria. Hmmm, non so se ero per provare a "vendere" quest'approccio in un colloquio di lavoro o qualcosa come così. Hmmm, I don't know if I would to try to "sell" this approach in a job interview or something like that.

Acclamazioni, Disc-jockey

P.S. Se, in letteratura di sviluppo di software, qualcuno si è imbattuto in idee similiar a questi presentati sopra, per favore mi lasci cadere una posta elettronica allora posso collegarmi a lei. È abbastanza possibile (forse perfino probabile) che questa "Anarchia è la Buona" teoria è stato già scoperto e sono soltanto ignorante in questo. Thx. It's quite possible (maybe even probable) that this "Anarchy is Good" theory has already been discovered and I am just ignorant of it. Thx.

Il contenuto per questo sito web è provvisto da www.bluebutterfly