WIESBADEN (CW) - Microsoft weiss also doch - zumindest theoretisch - wie man grossartige Software programmiert und rechtzeitig ausliefert. Das werden so einige gedacht haben, die dem Vortrag "21 Rules for Shipping great Software on Time" von Jim McCarthy, Microsofts Director der C++-Unit, auf der diesjaehrigen Entwickler- Konferenz "Devcon" lauschten*. Im folgenden drukken wir einige der Ratschlaege, die im uebrigen einen interessanten Einblick in die Entwicklungspolitik von Microsoft geben.
1. Gestehen Sie ein, dass Sie nicht alles wissen. Eine wichtige Aufgabe besteht darin, das Unsichere als Fakt zu akzeptieren, so dass die Projektorganisation Unsicherheiten einplant. Eine Pseudo- Ordnung ist kein geeignetes Mittel gegen Unsicherheiten.
Zudem muss jeder Projektbeteiligte die Freiheit haben, zugeben zu koennen, dass er etwas nicht verstanden hat. Da bleibt keine Zeit fuer Nettigkeiten. Definitiv ziehen die Leute den Erfolg vor.
2. Verschaffen Sie sich eine gesicherte Erkenntnis ueber den Projektstatus. Zu erreichen ist das nur durch eine gut funktionierende Qualitaetssicherung. Dabei sollte sowohl die Arbeit eines Tages als auch das gesamte Projekt woechentlich oder hoechstens im Abstand von zwei Wochen geprueft werden.
Qualitaetssicherung bedeutet, genauestens ueber den Stand eines Projekts zu einem definierten Zeitpunkt informiert zu sein. Ohne ein spezielles Testteam bleiben die Informationen unvollstaendig und relativ.
Deshalb ist Qualitaetssicherung unabdingbare Voraussetzung fuer den Erfolg eines Projekts. Firmen, die dieses Instrument nur rudimentaer oder ueberhaupt nicht einsetzen, ist nicht zu helfen.
3. Machen Sie sich das magische Dreieck bewusst. Nur drei Komponenten bestimmen die Arbeit des Entwicklers: die Ressourcen (Mitarbeiter und Geld), die Software-Features und der Zeitplan. Wird das Dreieck an einer Seite veraendert, hat dies Auswirkungen auf die anderen.
4. Behalten Sie das Ziel im Auge. Nicht jedes Feature kann sofort realisiert werden. Manchmal nimmt die Umsetzung Monate oder Jahre in Anspruch. Wird versucht, den Fortschritt taeglich zu messen, bewegt sich anscheinend nur wenig. Es ist daher schwer, den Ueberblick zu behalten und gegen Frustrationen anzukaempfen. Deshalb muss jeder Projektbeteiligte staendig das uebergeordnete Ziel im Auge haben: Die Software rechtzeitig fertigzustellen.
5. Setzen Sie Null-Fehler-Marken. "Null Fehler" heisst nicht, dass das Produkt keine Bugs mehr aufweist oder Funktionen fehlen. Es heisst, dass der Qualitaetslevel erreicht wurde, der fuer diesen Meilenstein definiert war. (Die Freigabe der Software ist einer dieser Null-Fehler-Meilensteine.)
Der Vorteil von solchen Marken ist, dass jeder im Projektteam sie akzeptieren und erreichen muss. Auf diese Weise lassen sich bisher unbekannte Faktoren aufdecken und zugleich feststellen, an welchen Stellen es in der Entwicklung noch hakt. Die Chance zu einer Revision ist gegeben.
6. Hueten Sie sich vor Einzelkaempfern. Entwickler neigen dazu, eigenbroetlerisch vor sich hin zu entwickeln. Das aber ist ein Fluch fuer jedes Projekt. Deshalb sollte den Entwicklern unabhaengig von individuellem Temperament und Brillanz klar sein, dass sie in einem Team arbeiten. Jeder muss verstanden haben, welche Aufgabe er darin zu erfuellen hat. Dazu sollte jeder der Mitarbeiter stets in der Lage sein, seine Arbeit den anderen Teammitgliedern transparent zu machen.
Einige der Entwickler finden dieses Vorgehen nicht tolerabel. Mag sein, dass es fuer diese Leute eine Position in unserer Softwarewelt gibt, doch garantiert nicht in einem Team, das sich zur Aufgabe gesetzt hat, grossartige Software rechtzeitig zu liefern.
7. Machen Sie sinnvolle Zeitplaene. Im allgemeinen weiss jeder schon, bevor es ueberhaupt ein Enddatum gibt, dass dieses nicht eingehalten werden kann. Das ist jedoch kein Grund, sich gegenueber einem zeitlichen Rahmen gleichgueltig zu verhalten. Bei jedem Meilenstein, der nicht rechtzeitig erreicht wird, geht dem Projektteam ein Stueckchen Glaubwuerdigkeit verloren. Deshalb muss versucht werden, den naechsten Meilenstein in der Zeit zu erreichen.
Nur wenn alle Komponenten eines Softwareprojekts ins Schleudern geraten, die Gruende dafuer sowie die Gegenmassnahmen bekannt sind, sollte ein vorlaeufiges Scheitern eingestanden werden. Wenn dann neue Meilensteine festgelegt werden, sollten sie so nah wie moeglich an dem tatsaechlich Machbaren liegen.
8. Keine Panik. Ins Schleudern geraet ein Projekt dann, wenn Dinge, die bisher unbekannt waren, noch unsicherer werden. In aller Regel sollten die Gruende dafuer bekannt sein. Ist das nicht der Fall, muessen sie aufgedeckt und allen zugaenglich gemacht werden, damit alle davon profitieren koennen.
Sorgt der Schleuderkurs jedoch fuer Ueberraschung, ist das ein Indiz dafuer, dass die Kommunikation innerhalb des Teams nicht funktioniert. Das muss auf jeden Fall bis ins Detail aufgeklaert werden.
9. "Tiefstapeln" ist nicht nur erlaubt, sondern ratsam. Eine gute Loesung wiegt mehr als alle Versprechungen.
12. Portabilitaet ist etwas fuer Paddelboote - die muss man hin- und hertragen koennen. Der Aufwand fuer die Software-Erstellung potenziert sich mit jeder neuen Plattform. Deshalb: Fordern Sie Multiplattform-Unterstuetzung bei der Systemsoftware und investieren Sie in Ihr Produkt nur das Noetigste.
21. Verfuegen Sie einen Auslieferungsmodus. Dafuer muessen unter anderem folgende Bedingungen erfuellt sein:
- Der naechste Meilenstein ist die Softwarefreigabe.
- (Nahezu) jeder muss glauben, dass der Auslieferungstermin eingehalten werden kann.
Letztlich steckt jeder in einem Zustand freudiger Erwartung und sehnt die Auslieferung herbei.
Die Endphase wird durch den Einsatz einer Aktivitaetenliste gesteuert. Ist diese abgehakt, kann die Software freigegeben werden.
Zur Ueberpruefung sollte es taegliche Meetings der Projektverantwortlichen geben, die nach einer Ad-hoc-Agenda konferieren. Dabei geht es darum, einen akzeptablen Qualitaetsstandard fuer die Fertigstellung zu erreichen.
Kosmetische Aenderungen, Leistungs-Features und Zusatzfunktionen zaehlen nicht. Nur sogenannte "Showstoppers", Bugs, die mehr als eine Handvoll Benutzer betreffen oder zu ernsthaften Fehlreaktionen der Software fuehren, duerfen in der Schlussphase noch beruecksichtigt werden.