Heute erschienen in der neuen Ausgabe des Projektmagazins ist Teil 2 meines Artikels über Testmanagement in IT-Projekten. Während es in Teil 1 noch um die Grundlagen ging, beinhaltet Teil 2 vor allem eine Excel-Vorlage. Kommerzielle Test-Suiten sind als Test-Werkzeug häufig überdimensioniert, da ihr Leistungsumfang die Anforderungen vieler IT-Projekte übersteigt und ihre Nutzung meist nur rudimentär erfolgt. Die vorgestellte einfache Excel-Lösung kann der Anwender leicht an seine spezifischen Fragestellungen anpassen und weiterentwickeln.

Eberhard Huber von projekt(B)LOG hat jüngst einige Checklisten für das Projektmanagement zusammengestellt, die er jetzt noch einmal überlicksmäßig zusammenfasst und deren mögliche Verwendung mittels eines Mindmap visualisiert.

Mal wieder ein interessanter PM-Thread auf XING (Abo-Dienst) zum Thema Statusampeln im Projektmanagement. Hier eine Zusammenfassung:

Selbst wenn die Ampelfarben vorweg eindeutig definiert worden sind, haben sie dennoch eine politische Dimension. Farben werden trotz allem unterschiedlich gesehen. Niemand will unangenehm auffallen, es drohen Sanktionen,…

Ehrlichkeit und vernünftige Reporting-Zeiträume wären Voraussetzung für einen sinnvollen Einsatz von Ampeln. Leider ist dies meist nicht so gegeben.

Eindeutige Ampeln sind ein hilfreiches Kommunikationsinstrument, aber inwieweit sie tatsächlich zur Projektsteuerung geeignet sind, ist ein anderes Kapitel.

Im Sinne von KISS (Keep it simple and stupid) sind Ampeln (ähnlich wie Smileys) eine willkommene Vereinfachung. Man spricht hier von Komplexitätsreduktion (das hört sich besser an…). Beides ist ein Reporting mittels Symbolen.

Eine interessante Frage ist auf welcher Ebene Ampeln zum Einsatz kommen:

·         Als Trend für das Gesamtprojekt

·         Auf Meilensteinebene (auch wenn es hier vielleicht bessere Alternativen wie die Meilenstein-Trendanalyse (MTA) gibt.

·         Auf Ebene einzelner Vorgänge

Konkurrierende Ampeln, d.h. den gleichen Sachverhalt  unabhängig voneinander von verschiedenen Beteiligten einschätzen zu lassen, scheint in der Tat niemand einzusetzen.

Eine Kritik an der Ampel ist ihre Beschränkung auf wenige Status (rot/gelb/grün), auch wenn in der Praxis die Kreativität zu Erweiterung unbeschränkt ist (gelbrot/gelbgrün, weiß für noch nicht begonnen, schwarz für abgeschlossen,…).  Alternativ würde sich ein Tacho oder Speedometer anbieten.

Eine berechtigte Kritik geht dahin, was eigentlich festgestellt werden soll: Der Ist-Zustand oder eine Prognose.

Das grundlegende Problem eines Ampelsystems ist aber dass, wir immer nur reagieren anstatt zu agieren, selbst mit einem System welches uns einen Trend aufzeigt.

Ein weiterer Teilnehmer schreibt:

Persönlich glaube ich nicht, dass Ampeln Projekte steuern, aber sie helfen dem Betrachter einfach schneller und rascher die Situation zu erfassen.

Bei kurzen Projektzyklen kann dann auch die Projektretrospektive eine Alternative sein, um den Erkenntniszuwachs sicherzustellen.

Janusz Gorycki setzt sich bei AgileSoftwareDevelopment.com (Englisch) mit den Tücken und Fallstricken des Unit Tests auseinander:

(1)  Unit Test dienen nicht zur Systemdokumentation!
(2) Ein erfolgreicher Unittest sagt nichts darüber, ob das Gesamtsystem auch „gesund“ ist.
(3) Testmodellen zu vertrauen ist falsch.
(4) Zu langsame Unit-Tests sind wertlos.

Das CIO-Magazin berichtet über die überarbeitete DIN-Norm zum Projektmanagement.

Andreas Heilwagen hat dankenswerterweise auf seinem Blog die Inhalte der überarbeiteten Norm zusammengefasst:

Jack Welch relativiert die Bedeutung des Shareholder Value. Die Financial Times Deutschland spricht von einer Kehrtwende bei General Electric, nachdem Jack Welch stets einer der prominentesten Vertreter war. Er selbst würde diese Einschätzung wahrscheinlich nicht teilen, denn er spricht lediglich davon, dass Ursache und Wirkung vertauscht wurden:

„Genau betrachtet ist Shareholder-Value die blödeste Idee der Welt“, sagte Welch. „Shareholder-Value ist ein Ergebnis, keine Strategie, die wichtigsten Interessensgruppen sind die eigenen Mitarbeiter, die eigenen Kunden und die eigenen Produkte.“

Er kritisiert die auf kurzfristige Gewinne ausgerichtete Sharholder Value-Manie. Nachhaltiges Denken und Handeln führt hingegen zu einem Erfolg für alle Beteiligten (auch die Aktionäre).

Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In meinem aktuellen Beitrag für das Projektmagazin habe ich u.a. auf die Rolle des Anforderers bei Test und Abnahme hingewiesen. Hierzu passend eine Meldung des CIO-Magazins: Die Deutsche Bank lagert ihr Software-Testing aus und rechtfertigt das mit Prozessorientierung und Industralisierung der IT.

Ein externes Testing ist legitim, darf aber den Anforderer nicht aus seiner Verantwortung für Qualitätssicherung und Abnahme entlassen. Ein IT-Dienstleister mag durchaus die erforderlichen IT-Prozesse für Software-Entwicklung und Test besser beherrschen, aber kann er auch das erforderliche Business-Know How mitbringen? Weiß er, was Banker wünschen?

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Danny Quick hat einen lesenswerten Beitrag des Linux-Magazins ausgegraben, in dem versucht wird Methoden und Vorgehen agiler Softwareentwicklung auf Betriebsthemen zu übertragen. Wie bei allen „agilen“ Themen braucht es dafür gleich einen neuen Namen: Agile Software Administration.

Für ITIL/Governance geprägte Welten mag sich das Gedankentum zunächst anarchistisch/revolutionär anhören, letztlich setzt es aber, wie alle agilen Ansätze, auf einer gestärkten Kommunikation und Eigenverantwortung auf – zwei Dinge, die noch keiner Betriebsorganisation geschadet haben.