Programmieren? Wie geht das noch?

Sigmar Gabriel will Programmieren als Schulfach etablieren. Aber mal ehrlich, wer weiß denn heute noch, wie Programmieren geht?

Ich war im Heinz Nixdorf MuseumsForum eher enttäuscht, für Nicht-Techniker hatten sie keine schöne, einfache Erklärung, was denn Programmieren überhaupt ausmacht.

Wie sag' ich es also dem Kind oder anderen interessierten?

Tipp: Open Roberta - aus dem Roboter-Bereich zwar, aber sehr anschaulich, direkt im Browser nutzbar.

Ich finde, jeder sollte wissen, was eine Schleife und eine Fallunterscheidung tun - das könnte schon viele Missverständnisse vermeiden.

Literatur-Tipp: Die Kunst des klaren Denkens

Der Titel hört sich erstmal sperrig und verschnarcht an - der Inhalt ist pure Erkenntnis: unsere Psychologie kommt unserer Rationalität ganz gerne in die Quere. 

Rolf Dobelli hat typische, psychologisch untersuchte Denkfallen zusammengestellt und mit alltäglichen Beispielen illustriert: ein Must-Read: immer und immer wieder! 

Z.B.: Lassen Sie sich nie einen Drink spendieren - der Spender erwartet immer eine Gegenleistung!

Schätzen in der Software-Entwicklung

„Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.“ 

Dieses Zitat wird laut Wikipedia unter anderem Nils Bohr zugeschrieben.

Diese Weisheit kannte ich nicht als junger Entwickler, der gerade – frisch von der Uni – in ein sehr langlaufendes Projekt einstieg. Gut, ich konnte mit Forms und PL/SQL Masken und Prozeduren schreiben, das ging flott, wenn man vor allem Datenverarbeitungsmasken (CRUD – Create, Read, Update, Delete) erstellte.

Das Projekt war wohl eigentlich für ein Jahr geplant, nahm aber Züge eines bekannten Flughafen-Neubaus an. Also ließ der neue Projektleiter die Reste schätzen, um herauszuarbeiten, wie lange man denn noch brauchen würde. Schnell gemacht, abgegeben und weiterentwickeln, es herrschte ja Zeitnot.

Kurze Zeit später wurde ich von ebenjenem Projektleiter angepflaumt, warum denn meine Schätzungen völlig von den sich abzeichnenden realen Aufwänden abweichen würden. Und das taten sie! Das war mir natürlich peinlich und ich kloppte Überstunden um Überstunden.

Was war geschehen? Wieso konnte ich trotz einigermaßen profunder Kenntnisse des (längst versunkenen) Frameworks keine realen Aufwände schätzen? Was macht Schätzen so schwierig?

Wir treffen Annahmen!

Wir müssen sie treffen, weil selbst die beste schriftliche Spezifikation nicht alle Fragen beantworten kann! Häufig trifft man dabei Annahmen, wenn man auf eine Lücke gestoßen ist: 

„Wenn der Satz für eine Person gelöscht wird, dann sollen bestimmt die abhängigen Sätze in der Adress-Tabelle auch gelöscht werden.“

Über explizite Annahmen kann man mit dem Kunden, dem Projektleiter oder anderen Schätzern leicht sprechen, gefährlicher sind implizite Annahmen, die uns gar nicht bewusst werden:

• „Datenbank-Indizes legt das System selbständig für die Foreign Keys an.“
• „Die zulässigen Werte für ein Feld werden vom aufgerufenen Service überprüft.“
• „Die Web-Schicht filtert SQL-Injection-Versuche aus den Eingabefeldern heraus.“

Sie können sich leicht vorstellen, was passiert, wenn solche Annahmen nicht zutreffen: Probleme und Fehler im Test oder sogar in der Produktion, Mehraufwand, Terminverschiebungen, ...

Welche Annahmen haben Sie bei Ihrem letzten Projekt implizit getroffen, die Ihnen dann bewusst wurden? Und wann wurden sie Ihnen bewusst – in der Planung oder erst in der Umsetzung?

Leider neigen wir meist auch noch dazu, dabei den besten Fall anzunehmen, vor allem, wenn man sowieso in einem Kontext voller Erwartungen und bereits geäußerter Wünsche unterwegs ist! 

„Das wird doch wohl nicht mehr als eine Woche dauern, oder?“ - Und schon hat Ihr Chef einen Anker gesetzt, der Ihre Schätzung beeinflussen wird! 

Welche Fehler habe ich damals gemacht?

Ich habe in Stunden geschätzt. 

Meiner Beobachtung nach neigen wir meist zu kleinen Zahlen – in jeder Lebenslage, außer beim Gehalt. In einem erwartungsgeladenen Kontext noch viel mehr. „Zehn Stunden? Sooo viel?“

Tipp: Schätzen Sie in Projekttagen (oder Personentagen)!

Ich habe alleine geschätzt. 

Damals, in den 90ern, konnten richtige Männer das noch! OK, eine zweite, unabhängige Schätzung hätte vielleicht implizite Annahmen aufgedeckt und explizite Annahmen hinterfragt.

Tipp: Führen Sie Doppel-Blind-Schätzungen als Schätzklausuren durch: beide schätzen unabhängig voneinander und werden dabei nicht gestört. Im besten Fall bauen sich beide unabhängig voneinander auch noch die Schätztabelle auf...

Ich habe meine Schätzung nicht validiert. 

Man hat nicht immer einen zweiten Schätzer zur Verfügung – was tun? Ich versuche, über irgendeine Form von Komplexitätsfaktoren die Schätzung der Personentage von der Komplexität zu trennen, z.B. durch

• T-Shirt-Sizes: S, M, L, XL
• Story Points (a la Scrum): 0, 1, 2, 3, 5, 8, ... (Fibonacci-Reihe)
• Function Points: Wie viele Aktionen / Schritte sind in dem Use Case enthalten, wie viele Masken, usw. 

Im zweiten Schritt ordne ich Aufwände den Faktoren zu. Anmerkung: Story Points stellen eigentlich noch einen anderen Ansatz dar.

Tipp: Schätzen sie auf mehrere Arten und Nutzen Sie irgendeine Form von Komplexitätsfaktoren.

Noch ein Tipp: Meist schätze ich Use Cases zuerst und bilde mir eine Menge von Komponenten, mit denen die Use Cases umgesetzt werden. Diese Komponenten schätze ich dann, aus der Matrix Use Cases zu Komponenten sehe ich, wo Schwerpunkte und Inseln sind.

Ich habe nur einen Fall geschätzt – noch dazu den „best case“.

Tipp: Erstellen Sie Drei-Punkt-Schätzungen nach PERT (Programme Evaluation and Review Technique). 

  

Ihr wirksamstes Werkzeug ist in der Regel die Drei-Punkt-Schätzung 

Die Grundidee: Sie schätzen drei Varianten:

• Optimistisch: alles gut, keine Hindernisse (O)
• Normalfall: es ruckelt hier und da, niemand hat das Datenbank-Schema aufgesetzt usw. (N)
• Pessimistisch: Denken Sie an Murphy’s Gesetz: was schief gehen kann, wird schief gehen! Also: Es ist noch nicht mal eine Datenbank installiert.  (P)

Für jede dieser Varianten schätzen Sie Ihre Use Cases in Personentagen. Nach PERT berechnen Sie dann stark vereinfacht (für Projektleiter halt) den Mittelwert: 

PERTWERT = (O + 4 * N + P) /6 

und die Varianz: 

V = (P – O)/6

Eigentlich steckt keine Simpel-Mathematik dahinter, sondern die Beta-Verteilung. Keine Normalverteilung, weil es unwahrscheinlicher ist, dass Sie weniger Aufwand brauchen werden: Mehr Aufwand kommt in der Software-Entwicklung häufiger vor...

Haben Sie alle Use Cases geschätzt? Wie berechnen Sie nach PERT die Gesamtsumme und die zu erwartende Abweichung?

Bilden Sie die Summe über die PERT-Werte: 

SP = Summe (PERTWERT(i))

Dummerweise ist die Standardabweichung Sigma (was ich oben Varianz nannte) nicht so einfach: 

Sigma = Wurzel (Quadratsumme(V(i)))

Geht in Excel aber auch sehr einfach.

Der Trick ist: Sie erhalten nicht einen Wert, sondern eine statistische Aussage: Mit einer Wahrscheinlichkeit von x Prozent benötigen Sie maximal n Tage:

• 50%: PERTWERT
• 68,2%: PERTWERT + 1 * Sigma
• 95,5%: PERTWERT + 2 * Sigma
• 99,7%: PERTWERT + 3 * Sigma

Bei PERTWERT=50 PT und Sigma = 5 PT werden Sie also 65 PT benötigen und das mit 99,7% Wahrscheinlichkeit.

Toll, oder? Das ist doch mal eine andere Aussage als „50 PT, vielleicht auch 60 PT“! Schauen Sie sich mal das einfache Beispiel in Excel an. 

Kleiner Hinweis

Die Wahrscheinlichkeit bezieht sich nur auf Ihre Schätzung – ohne Gewähr und Garantie für die Risiken außerhalb der Schätzung! Aber immer noch besser als früher...

Wie erstellt man eine Drei-Punkt-Schätzung praktisch? 

Hat man nicht auch da schon Anker im Kopf?

• Ich schätze pro Spalte und nicht pro Zeile, also: blenden Sie andere Spalten aus und konzentrieren sie sich auf den optimistischen Fall für alle Use Cases, dann den Normalfall usw. Zwischen den Schätzdurchgängen für O, P und N mal eine Pause machen!
• Danach suche ich erst mal die offensichtlichen Fehler: wo ist O größer als P oder N? Wo ist P niedriger als N?
• Dann suche ich mir die Zeilen mit der höchsten Varianz und analysiere: Warum ist die Varianz so hoch? Wie kann ich die Unsicherheiten klären oder abgrenzen?

Wie sieht das in voller Schönheit aus?

Hier ein Beispiel mit Phasen, Gruppen und anderen Strukturen und der Auswertung am Ende der Seite in Excel. Es kann hilfreich sein, sofort die Annahmen für jede Schätzung zu dokumentieren. Größere Excel-Künstler als ich können das sicher hübscher formatieren. 

Und, welche Zeilen würden Sie sich zur weiteren Prüfung vornehmen? 

Eine Anmerkung noch zum Sinn der Drei-Punkt-Schätzung

Bei Wikipedia und in einigen Blogs wie z.B. bei Michael Jendryschik findet man die Bezeichnungen „min“ und „max“ anstelle von „optimistisch“ und „pessimistisch“. 

Min und Max halte ich für irreführend. 

Warum? Mein Ziel bei den Schätzungen ist vor allem, möglichst viele Annahmen und Lücken herauszuarbeiten – alles, was ich wirklich gut verstanden habe, bereitet mir kaum Magenschmerzen. Daher kann ich nur empfehlen, dem Schätzer „optimistisch“ und „pessimistisch“ nahezubringen! 

Jede implizite Annahme sollten Sie als verborgenen Schatz betrachten – oder als Tretmine... Eine perfekte Schätzung ist nur NACH der Umsetzung möglich – versuchen Sie lieber, Ihre Sicht auf das Problem zu vervollständigen!

Literatur-Tipp: Steve McConnell: Software Estimation: Demystifying the Black Art (2006)