Beiträge getagged mit softwareengineering
Die Vasa und Software Engineering
Vielleicht ist dem einen oder anderen die Geschichte von der Vasa bekannt, ein Schiff, das im 17Jhd in Schweden (Stockholm) gebaut worden ist. Ich selbst habe das Schiff und seine Geschichte auf der ECSCW-Konferenz in Stockholm 1995 kennen gelernt.
In der neuesten Ausgabe der Communications of the ACM (Vol 51, No 9, S 25ff) berichtet George Neville-Neil die Geschichte der Vasa im Kontext der Lehren, die daraus für Software Engineering gezogen werden können. Und diesen Bericht möchte ich hier wiedergeben:
The Vasa was built between 1626 and 1628 for King Gustavus Adolphus of Sweden, who was, at that time, attempting to rule the Baltic Sea. In the 17th century, rulers were expected to be capable of more than just giving orders, so Adolphus not only organized wars, he also helped design the ships of his naval fleet. At the time Swedish warships had one deck of cannons on each side from which they fired fusillades at enemy ships, sometimes even hitting the other ships and damaging them. When the Vasa was commissioned, this single row of cannons was considered state of the art.
Some time during the construction of the ship Adolphus found out that the Poles had ships with two decks of guns, so he modified the design of the Vasa to have a second gun deck. This would have made it the most powerful naval vessel of the time, capable of delivering a broadside of devasting proportions. The men he had contracted to build his ships attempted to explain that the ship had too little ballast to support two gun decks, and that the resulting ship likely would be unsafe to sail. The King insisted – just like, say, many project managers – that his orders should be followed. On a software project you can quit, but if the King is your boss you might lose more than your job – you might, say, lose your head – so the project went forward.
In 1628 the ship was finally ready for quality assurance (QA) testing. Seventeenth-century QA of ships was a bit different from what might happen today. Thirty sailors were picked and asked to run back and forth, port to starboard, across the deck of the ship. If the ship didn’t tip over and sink, then the ship passed the test. (…) After only three runs across the deck the Vasa began to tilt wildly and the test was canceled. The test may have been canceled, but not the project. This was the King’s ship, after all, and she would sail. And sail she did.
On August 10, 1628, in a light breeze, the Vasa set sail. She was less then a mile from dock when a stiff breeze knocked her sideways. She took on water, and sank in full view of a crowd of thousands od onlookers. (…)
Es hat sich wirklich nicht viel geändert im Projektmanagement …
Buchkommentar – Adrenalin Junkies & Formular Zombies
Bei einem meiner Spaziergänge durch einen unserer Buchläden ist mir vor einiger Zeit das Buch “Adrenalin Junkies & Formular Zombies – Typisches Verhalten in Projekten” von Tom DeMarco und anderen (konkret: die “Atlantic Systems Guild”) aufgefallen. Nachdem ich die anderen Bücher von Tom DeMarco zu Softwareengineering und Projektarbeit (konkret: The Deadline/Der Termin, Peopleware oder Slack/Spielräume) mit großen Vergnügen verschlungen habe, landete auch die Neuentdeckung auf meinem Still-to-Read-Stapel …
Mein erster Eindruck nach dem Lesen: zuerst einmal etwas enttäuscht … Das Buch liefert zwar viele interessante Einblicke in (Software-)Projektarbeit und damit auch gute Anregungen, wo man hinschauen oder eingreifen sollte/könnte – aber es fehlt die zusammenhängende, geschichtenartige “Schreibe”, die ich bisher bei Tom DeMarco gewohnt war – und geliebt habe.
Denn das Buch ist kein zusammenhängender Text, sondern eine Sammlung von 86 Mustern, die bei (Software-)Projektarbeit beobachtet werden können. Jedes Muster ist auf einer bis vier Seiten kurz beschrieben. Dabei ist die Qualität (und Lesbarkeit) der Beschreibungen stark unterschiedlich. Weiterhin sind positive, negative und neutrale Muster wild gemischt.
Hier noch die “Muster”, die mir beim Lesen des Buches als besonders lesenswert bzw. erwähnenswert aufgefallen sind – mit ein paar Kommentaren von mir dazu.
7) Manana: “Wir alle verfügen über Zeitfenster, innerhalb derer wir erkennen, dass wir in Gang kommen und dranbleiben müssen, um eine Tätigkeit abzuschließen. Stichtage jenseits dieser Zeitfenster erzeugen kein Gefühl von Dringlichkeit und folglich auch nur eine geringe Motivation, sofort zu handeln.” (S. 19) – “Ausserhalb dieses Wahrnehmungsfensters befindet sich Manana. Manana bedeutet, dass wir zwar grundsätzlich einsehen, dass wir diese Arbeit erledigen müssen, aber nicht begreifen, dass wir umgehend damit beginnen müssen, um rechtzeitig fertig zu sein.” (S. 20).
Die Lösung ist (wie bei vielen der Muster/Probleme) einfach: Zwischenziele definieren, die innerhalb des Zeitfensters liegen. Trotz dieser einfachen Lösungsmöglichkeit wird aber nicht immer (rechtzeitig) erkannt, dass überhaupt ein Problem existiert.
26) Der Versuchsballon: “Bei einem Versuchsballon handelt es sich (…) um einen Lösungsvorschlag, von dem Sie allerdings wissen, dass er unvollkommen und/oder fehlerhaft ist, und den Sie bewusst einsetzen, um von Kollegen oder Kunden Kritik zu bekommen.” (S. 68).
Schöner habe ich die Idee der iterativen Entwicklung, des häufigen Generierens und Diskutierens von Prototypen noch nicht dargestellt gesehen. Dazu passt auch das auf S. 69 abgedruckte Zitat von Albert Schweitzer sehr gut: “Beispiele sind nicht das Hauptmittel um andere zu überzeugen. Sie sind das einzig mögliche Mittel.”.
75) Die Kühlschranktür: “Teammitglieder hängen ihre Arbeitsergebnisse routinemäßig für alle sichtbar aus.” (S. 185).
Hier wird besprochen, was mit Awareness / einem Gewahrsein über die Arbeit der anderen / den Stand der Arbeiten bzw. des Projektes erreicht werden kann. Das passt auch sehr gut zu den in vielen anderen Mustern angesprochenen Problem mit der zu starken (blinden) Konzentration auf in Vorgehensmodellen vorgeschriebenen Dokumenten zur Fortschrittsdokumentation (z.B. Muster 79 Papierfabrik).
Anstelle einer “Kühlschranktür” kann man natürlich auch Medien wie Blogs benutzen – sollte sich aber immer der Vorteile der Kühlschranktür bewusst sein bzw. versuchen sie nachzubilden!
Gut hierzu passt auch das Muster 81 Lagezentrum. Hier wird ein Projektraum empfohlen, der erstens Informationsaustausch und Informationsbewahrung sicherstellt – und dem Projekt einen sichtbaren Wert gibt.
76) Morgen scheint die Sonne wieder …: “Der Projektmanager ist davon überzeugt, dass der durchschnittliche künftige Fortschritt den durchschnittlichen zurückliegenden Fortschritt übertrifft.” (S. 187).
77) Einer geht noch: “Die Beteiligten sichern Unterstützung für ein Projekt zu, blähen es dann aber immer weiter auf, bis das Projekt unter der Eigenlast zusammenbricht.” (S. 190).
83) Aus gehabtem Schaden nichts gelernt …: “Ein Team erkennt seine Fehler, aber wiederholt sie trotzdem.” (S. 203).
In diesem Muster wird ausführlich auf den Aspekt der Lessons-learned eingegangen und auch einige konkrete Tipps zu deren erfolgreichen Durchführung/Implementierung gegeben (S. 205). Erstmal sollten Nachbesprechungen überhaupt abgehalten werden. Dann sollte vermieden werden, dass die Besprechungen nur zum “Dampfablassen” genutzt werden – z.B. nur Beschreibungen von Problemen gesammelt werden, aber keine Handlungsanweisungen zur zukünftigen Begebung.