Grundregeln des IT ProjektManagements

Ein paar grundlegende Leitsätze. Ich weis schon, wenn man das liest, denkt man sich: Hey das ist doch selbstverständlich. Aber im tatsächlichen Tagesgeschäft wird erstaunlich wenig davon eingehalten.

Stand Up Meeting

Zu beginn eines Tages sollte es it dem Team ein kurzes Stand Up Meeting geben. Das bedeutet, das Team steht im Kreis. Stehen, damit das Meeting nicht zu lange dauert. Jeder beantwortet reihum folgende drei Fragen.

1. Was hast du gestern getan?
2. Was planst du heute zu tun
3. Was behindert dich momentan gerade in deiner Arbeit

Projekt Definiton

Projekte werden durch einen Business Plan definiert (eine DIN A4 Seite reicht)

Anforderungsmanagement

Das Projekt wird dann durch Anforderungen detailliert definiert. Diese Anforderungen werden in User Stories formuliert: "User soll ... können ..." Aus diesen User Stories werden später automatisierte Test Cases. Anforderungen werden im Planning Poker geschätzt. Anforderungen werden auf Tasks heruntergebrochen und in einem Tool getrackt. Bei einem Software Implementierungs Projekt werden Tasks direkt mit code changes/commits verknüpft

Projektplan erstellen

Die Intelligenz in der Erstellung eines Projektplans liegt nicht darin, vage Fertigstellungstermin zu erfinden. Termin sind keine Eingabe eines Projektplans, sondern dessen Ergebnis. Anstatt dessen sollte man sich Mühe geben, das große Projektziel sinnvoll in kleinere, soweit möglich voneinander unabhängige, parallelisierbare Tasks zu gliedern. Jeder dieser Tasks wird dann geschätzt. Wenn jetzt noch Abhängigkeiten zwischen den Tasks definiert sind, dann lassen sich Fertigstellungstermine entlang des Critical Pathes automatisiert berechnen.

Schätzen: Planning Poker

Tasks werden vom Team im Planning Poker Meeting geschätzt. Jede Anforderung wird auf eine Karte geschrieben und vom Moderator erklärt. Jeder Entwickler erhält Karten mit Personen/Bearbeiter Tagen: 0.2, 0.5, 1, 2, 3, 5, 7, 10, "unendlich". Nachdem die Karte vorgestellt wurde legt jeder Entwickler eine dieser Karten verdeckt auf den Tisch. Ist eine "unendlich" Karten dabei, so gilt das als Veto und die Anforderung muss noch genauer erklärt werden. Ansonsten werden die beiden Extremas gestrichen und der Durchschnitt der restlichen Karten gilt als die Schätzung.

Liegen die Schätzungen immer noch weit verstreut, sollte man noch einmal die Anforderung genauer Analysieren.

Testen

Es muss nicht unbedingt test-driven-development in Reinstform sein: Erst den Test schreiben und dann die Implementierung. Sondern es gilt ein gesundes Verhältnis zu finden zwischen:

• Aufwand um die Tests zu schreiben
• Aufwand um die Tests am laufen zu halten: Testdaten bereitstellen oder Mock Objekte pflegen
• Code Abdeckung: Für die "zentralen Stellen im Code" (=die häufig durchlaufen werden) sollte es automatisierte Unit-Tests geben.
• Unit-Tests schenken einem Regressionstests

Task Management und Issue-Tracking

Das Toole spielt keine Rolle. Wichtig ist nur, dass mindestens folgende Attribute getrackt werden können.

• Wer hat den Hut auf? Wer ist für den Taks verantwortlich?
• Wer muss den nächsten Schritt für diesen Task erledigen?
• Ursprüngliche Schätzung (aus dem Planning Poker)
  
• Restlicher Aufwand (Bereits verbrauchte Zeit + Restaufwand kann größer werden als die ursprüngliche Schätzung. Natürlich ist das nicht gut, aber es kommt vor und sollte ehrlich getrackt werden.)

Statuus eines Tasks

• Neu (nachdem ein Task eröffnet wurde)
• Zugewiesen (Wenn ein Verantwortlicher definiert ist)
• In Arbeit (Wenn mit der Umsetzung begonnen wurde)
• warten auf ... (warten auf Input von ...)
• umgesetzt (Entwickler sagt er sei fertig. Dies heist noch nicht, dass die Lösung von demjenigen akzeptiert wurde, der den Task ursprünglich erstellt hat!)
• Lösung abgenommen (Kann nur vom ursprünglichen Ersteller gesetzt werden.
• Duplikat von ... (Wenn Problem bereits bekannt und in Arbeit)
• Won't fix (es kann Gründe geben einen Bug nicht zu beheben.)
• Nur wer einen Bug eröffnet hat, darf ihn auch wieder schließen!
  

Nicht viele Issuetracking System bieten das Feature: Task A hängt ab von Task B. A kann also erst begonnen werden, wenn B gelöst ist. Hierüber kann der Critical Path berechnet werden

Es gibt keine Diskussion, was ein Bug und was ein Feature Request ist! Alles wofür es ein Anforderungskärtchen gab ist ein Bug. In allen anderen Fällen ist es ein Feature Request.

Controlling

Ein Projekt zu kontrollieren bedeutet mindestens: Nach der Hälfte der Zeit prüfen, ob man halb fertig ist.

Übergabe in den Betrieb

Nachdem ein neues Feature entwickelt und getestet wurde, muss es in den Betrieb übergeben und durch das Operationg Abgenommen werden. Dazu zählen u.a.

• Übergabe der Dokumentation
• Schulung des Supports
• Evtl. Erhöhung der Kosten eines bestehenden Wartungsvertrages
• Evtl. Anpassung der Hardware