Dieser Posten ist eine Synthese und Verlängerung von einigen Ideen, die in anderen Posten auf diesem blog bedeckt worden sind: Warum flüchtige Investitionen, die 85/95-Regel des Projektmanagements, und Balkenpläne gegen die PR-Datenbank lutschen. Wenn Sie alle jene Posten gelesen haben, dann, was folgt, könnte Sinn zu Ihnen haben. Wenn nicht, dann glaube ich, dass wir gerade sehen werden, wie gut ein Schriftsteller ich bin. 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.

Zu stumm es unten etwas werde ich eines meiner literarischen Lieblingsgeräte verwenden: Das Gleichnis. Hier ist die Geschichte von Ploddin' Paul der Projektbetriebsleiter, der mit einer sehr schwierigen Verwaltungsentscheidung konfrontiert. Er hat eine Mannschaft von 5 Entwicklern, von denen drei ältere Entwickler sind und dazu fähig sind, Miniprojekte selbstständig zu behandeln. Ihre Namen sind Genius Gary, Ingenieur Eric, und 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.

Das Projekt ist ein etwas unsicheres, aber nicht allzu so. Die Absicht ist, eine Archivieren-Schnittstelle zu mehreren verschiedenen Modellen des Band-Laufwerkes zu bauen, so dass Kunden, die in eine Datenbank loggen, die Auswahl haben, ihre Daten online zu verlassen, es zu einem Band-Laufwerk, oder Wiederherstellung der Daten vom Band sparend. Natürlich gibt es Zahl anderer Eigenschaften und Designvoraussetzungen. Das Projekt soll in 6 Monaten geliefert werden. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

Die Mannschaft hat drei Wahlen: Schreiben Sie 1), dass der Code vom Kratzer 2) einen vorhandenen Code Nacharbeitet, der innerbetrieblich oder 3) Arbeit mit einer Dritt-API erzeugt wurde, die verspricht, viel von der Funktionalität (veröffentlicht von einem Verkäufer genannt Babooza) zu liefern.

"Die APIs von Babooza lutschen Spitzen-, wollen wir es das Recht tun. Schreiben Sie den Code vom Boden in C #," sagt Genius Gary, der der beste Programmierer des Loses ist, aber die Einstellung hat, um damit zu gehen.

"Der am wenigsten unsichere Weg ist, unsere vorhandene Codebasis nachzuarbeiten," sagt Ingenieur Eric. "Wir wissen bereits, wie schwierig es mit den Fahrern für die Band-Geräte arbeiten soll. Ja gibt es Haar in der alten Codebasis, aber es ist der Teufel, den wir kennen." Yeah, there's hair in the old code base but that's the devil we know."

"In sechs Wochen sagt Babooza, dass sie eine API liefern werden, die auf den grössten Teil davon aufpasst." sagt Liason Larry. "Warum einige davon tun, wenn jene Kerle es für uns tun werden?" "Why do any of this if those guys will do it for us?"

"Vertrauensbabooza? Sie sind Nüsse. Und unsere alte Codebasis lutscht. Jeder weiß das. Gehen Sie neu." And our old code base sucks. Everybody knows that. Go new."
"Ich stimmte mit Ihnen über Babooza überein. Aber Sie wollen von in tiefes Wasser ohne Rettungsweste springen. Gehen Sie alt." Go old."
"Aber und wenn Babooza etwas Funktionelles liefert? Wir Wille konnte unsere Entwickler mehr Eigenschaften und ein wirklich guter GUI hinzufügen lassen, anstatt um das Versuchen Mist zu bauen, veranlassen, dass die Band-Laufwerke archivieren.""

An diesem Punkt im Gespräch, so etwa wenn die Entwickler vorhaben, zu ihrer Arbeitsfläche zu laufen und die Sache durch das Spielen eines deathmatch im "Unwirklichen Turnier zu setzen," spricht Ploddin' Paul:

"Larry, was denken Sie die Verschiedenheit, ist von Babooza das Liefern der API rechtzeitig und seiner, usuable seiend?"

"Ah, ich dunno, vielleicht 50 %"

Sowohl Eric als auch Gary machen Lärm, und Paul kennzeichnet das unten zu 25 % in seinem Kopf.

"Gary, wenn und ein anderer Entwickler am Bauen arbeiten, was wir vom Kratzer brauchen, denken Sie, dass wir uns rechtzeitig einschiffen können?" fragt Paul.

"Naw, zu viel Arbeit, würde ich mindestens einen anderen Kerl brauchen."

"Und wenn ich Ihnen einen Kerl drei Monate darin gab? Vielleicht zwei.""

"O.k., 80-%-Chance, rechtzeitig getan zu werden."

Jetzt ist es Eric und die Umdrehung von Larry, ihre Augen zu rollen. So kennzeichnet Paul unten die Verschiedenheit zu 40 % in seinem Kopf.

"Eric?"

"C'mon Paul, geben Sie mir die ganze Mannschaft und sichere neunzig Prozent, dass es dabei ist, geliefert zu werden."

"Haariger als der Rücken eines Gorillas," sagt Gary in einem lauten Flüstern Larry. "Denken Sie Spaghetti.""

"Eric, wenn Sie gerade den Code nacharbeiten, wie kommt es, dass Sie headcount fünf brauchen?"

"Kommen Sie mehr das fröhlichere heran. Es ist dabei, viel Beseitigen zu geben.""

"Sie bekommen einen Kerl für jetzt, mit vielleicht mehr in drei Monaten. So sind Sie noch sicheres 90-%-Prozent?""

"Ah, keine Versprechungen," sagt Eric

Paul kennzeichnet geistig die Verschiedenheit unten zu 50-50. Er hat auf den Code einen Blick geworfen. Es ist schrecklich. It's terrible.

Paul trifft seine Entscheidung. "Jeder geht ab und macht ihre eigene Sache. Wir werden in drei Monaten und Rezension zurückkommen." Jeder nickt ihr Kopf und geht weg. Es war immer dass mit Paul ähnlich, der nie eine Entscheidung über den Endpfad trifft, um bis zum allerletzten möglichen Moment zu nehmen. Es steuerte einige der Entwickler völlig Nüsse manchmal mit dem sonderbaren Murren, dass die Gruppe immer scheint, ganzer Anarchie am Rande zu sein. Aber Paul ließ WIRKLICH jeden ihren eigenen Weg den größten Teil der Zeit versuchen, so waren Leute am glücklichsten. Es schien gerade so ineffizient... 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...

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

Also, auf erst gelesen sieht es aus, dass Paul eine der goldenen Regeln des Projektmanagements verletzt, das immer Arbeit hart ist, um sich zu ändern, Ihre 85 zu 95 (versuchen das heißt, immer zu Ihrem sonderbaren vom Erfolg, egal wie zusätzlich es sein kann). Paul verlässt einige Pfade, die eine 90-%-Prozent-Chance des Erfolgs und Lassens von Entwickler versprechen einige risikoreiche Annäherungen verfolgen. Außerdem muss ich sagen, dass diese Annäherung wie Scheiße aussehen würde, wenn Sie es auf einem Balkenplan hochwürfen: Statt der sauberen kleinen Bar, fünf Entwicklern zeigend, die als eine Mannschaft zu einem gemeinsamen Ziel zusammenarbeiten, haben Sie drei Bars, die in der Parallele zu derselben Absicht arbeiten. An einem Punkt in der Karte müssen Sie zwei jener Aufgaben mit der ganzen Verschwendung von Mitteln beenden, die einbezieht (Im Fall von Paul, ist der Entscheidungspunkt ins Projekt oder drei Monate auf halbem Weg). 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).

Zusammenzufassen: Die Entwickler denken nicht, dass Paul ein entscheidender Projektbetriebsleiter, und bestimmt ist, wenn der Chef von Paul leben würde und durch den Balkenplan stürbe, würde er sich fragen, warum Paul Mittel mit dem ganzen redundacy vergeudete.

Aber wieder arbeitet die Mathematik für Paul, weil in der Softwareentwicklung parallele Pfade mit einer angemessenen Chance des Erfolgs ein besserer sind als ein Pfad mit einer hohen Chance des Erfolgs. Bemerken Sie, dass Parallele-Pfad bedeutet, dass Sie die Prozentsätze zusammen hinzufügen, nicht multiplizieren wie in einer Folge:

Ein Pfad: 90 % des Erfolgs.
Drei Pfade: 25 % + 40 % + 50 % bis 115 % des Erfolgs!!!

Natürlich bedeuten die 115 % nicht, dass das Projekt absolut sicher ist, erfolgreich und rechtzeitig vollendet zu werden. Diese Prozentsätze sind die Prozentsätze des Spielers, bedeutend, dass Summe die Hinzufügung einer Reihe von Wetten für eine gegebene Belohnung ist. Eine metaphorische Geschichte könnte Dinge klarer machen. A metaphorical story might make things clearer.

Wollen wir vorgeben, dass wir im Kasino aber nicht in einer Softwareentwicklungsumgebung sind. Sie haben 500 $ in Ihrer Tasche, und der Preis ist... Oh, ich dunno... eine Marke neuer Ipod (Die beste Version, derjenige mit 40 Rauhmaschinen. Derjenige meine Frau wird mich 'Ursache nicht kaufen lassen, ich habe einen Job nicht, wenn auch es mich wirklich, wirklich glücklich machen würde, wenn ich konnte).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).

Sie können Ihr ganzes Geld auf einer Wette legen und eine Neunzig-Prozent-Chance haben zu gewinnen. Oder Sie können eine mehr komplizierte Reihe von Wetten wie Paul machen tat: Sie stellen 100 $ hin und haben eine 25-%-Chance zu gewinnen. Sie stellen auch gleichzeitig 200 $ hin und haben 50-%-Chance zu gewinnen und stellen weitere 200 $ hin, um eine 40-%-Chance zu haben, zu gewinnen. 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.

Und hier ist, wohin der Spaß eingeht: Mit der ersten Wette gibt es eine Drehung des Rades, und Sie wissen, ob Sie ein Sieger oder ein Verlierer sind. Wenn die Schätzung der Entwicklung richtig ist, sind Sie ein Sieger neunmal aus zehn. If the estimate of the development is correct, you are a winner nine times out of ten.

Aber mit dem drei Wette-Drehbuch haben Sie drei Drehungen des Rades, und wenn eine der Drehungen ein Sieger heraufkommt, bekommen Sie Hälfte Ihres Geldes zurück von den anderen zwei Wetten. Zum Beispiel, wenn eine der Wetten von 200 $ ein Sieger heraufkommt, würden Sie 150 $ (50 % der 100 $ und 200 $) zurückbekommen. Das heißt, wenn die Annäherung von Gary nach einem Sieger nach drei Monaten ins Projekt aussieht, dann können Sie Larry und die Annäherung von Eric verlassen. 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.

Aber was geschieht, wenn keine der Wetten ein Sieger heraufkommt? Aha gut, wenn das geschieht, wird das Kasino Ihnen erlauben, Ihre Wette und Drehung wieder zusammenzulegen, Hälfte der Gesamtsumme Ihrer Wetten (250 $) nehmend und Ihnen erlaubend, wieder (Mit den Erfolgschancen nicht zu spinnen, wissen, bis die ersten 3 Drehungen vollendet werden). Das heißt, wenn nach drei Monaten die API von Babooza völlig lutscht, und die Mannschaft von Gary nicht sogar tun kann, baut eine Tageszeitung ohne den Bearbeiter, der in hysterischen Anfall eintritt, dann kann Paul die Entscheidung treffen, jeden auf dem Projekt von Eric zu werfen, die alte Codebasis nachzuarbeiten. 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.

Kurzum der Komplex, fast die chaotische Zuteilung von Mitteln in einer Softwareentwicklungsumgebung berücksichtigt eine bessere Chance eines Projektes, das, und für einen effizienteren Gebrauch von Entwickler-Mitteln wird vollendet. Ich stolperte über diese Entdeckung größtenteils zufällig, als ich über die Unangemessenheit von Balkenplänen schimpfte, um genau zu beschreiben, was wirklich in eine wahre Entwicklungsumgebung hineingeht. Sicher nahm ich nicht an, einen mathematischen Beweis für das Verhalten zu finden, dass ich im PWS (Software) Abteilung von Creo sah. 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, für mich das ist eine wirklich kühle Entdeckung, weil er jeden umlaufen gültig macht und Ihre eigene Sache macht und wollen wir eine Entscheidung treffen später nähern sich. So, ich meine, dass die Mathematik die Theorie gültig macht. Hmmm, ich weiß nicht, ob ich würde, um zu versuchen, diese Annäherung in einem Vorstellungsgespräch oder etwas wie das "zu verkaufen". Hmmm, I don't know if I would to try to "sell" this approach in a job interview or something like that.

Prosit, DJ

P.S. Wenn, in der Softwareentwicklungsliteratur, irgendjemand auf Ideen similiar zu denjenigen gestoßen ist, die oben präsentiert sind, lassen Sie mich bitte eine E-Mail fallen, so kann ich mich dazu verbinden. Es ist ziemlich möglich (vielleicht sogar wahrscheinlich), dass diese "Anarchie Gute" Theorie ist, ist bereits entdeckt worden, und ich bin gerade davon unwissend. 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.

Der Inhalt für diese Website wird durch www.bluebutterfly zur Verfügung gestellt