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

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

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.

Sven Rimbach erzählt frustriert die Anekdote, wie man zu einem „effektivem“ Testmanagement gelangt:

Der einfachste Weg ist es, die Fehlerdatenbank zu löschen…

… fasst Tulca Ertüzün in einem Beitrag für die Computerwoche im Januar zusammen.

Und dahinter verbirgt sich natürlich mal wieder das magische Dreieck.

In den CIO-Nachrichten findet sich ein Beitrag: Schlechtes Anforderungsmanagement. IT versteht das Business nicht. Die Aussage wird belegt mit einer Umfrage des IT-Beraters Arcway.

Diese These deckt sich durchaus mit meiner Erfahrung, aber ich würde darüber hinaus noch viel weiter gehen: Das Unverständnis besteht häufig nicht nur zwischen Auftraggeber und Auftragnehmer, sondern zieht sich durch alle Schichten der Stakeholder eines Projektes. Als Projektmanager finde ich mich regelmäßig in der Rolle des Übersetzers zwischen den verschiedenen Beteiligten. Die Verständigungsschwierigkeiten fangen schon auf Kundenseite über die verschiedenen Hierarchiestufen (vom Top-Management bis zum Enduser) an. Aber selbst auf der reinen IT-Seite besteht dieses Problem, denn ein IT-Architekt ist noch näher am Business und spricht eine andere Sprache als ein  Nerd, der die letzten Bits einer Schnittstelle programmiert. Darüber hinaus gibt es noch so Themen wie IT-Betrieb, etc., die wiederum mit einem anderen Verständnis (und anderen Anforderungen) ausgestattet sind. Da wollen wir noch gar nicht vom Brückenschlag von der Fachabteilung zur IT hin reden…

Die Überwindung solcher Verständnisschwierigkeiten ist nach meiner Überzeugung einer der wichtigsten Erfolgsfaktoren für Projekte.

Computerwoche und CIO-Magazin haben eigentlich eine ganz interesante neue Projekt-Community ins Leben gerufen: 10projects.

Die Idee ist genial: Endlich ein Erfahrungsaustausch unter Projekt-Profis. Konkrete Projekte, konkrete Erfahrungen, echte Expertise.

Natürlich habe ich mich auch angemeldet.

Habe in der Übersicht gleich die ersten fünf Projekte eingesehen, die angeboten wurden, aber was sehe ich da: Eine Sternchenflut. Eitelkeit allenthalben. Projekte laufen scheinbar immer super. Fassungslos und niedergeschlagen verzichte ich erstmal darauf eigene Projekte zu hinterlegen. Zum Einen hindert mich der Kundenschutz, zum Anderen bin scheinbar nur ich ein Versager. Es muss an mir liegen. Wie konnte ich nur an Projekten mitwirken, die gescheitert oder nicht so glücklich verlaufen sind. Oder liegt es gar an mir? (Bitte an dieser Stelle meine Kunden dringend um Feedback!) Zum Glück sind nicht alle meine Projekte gescheitert…

Kevin Rutherford philosophiert in seinem Blog silk and spinach darüber, wie sich Programmierer auf „ihre“ Tester verlassen und ihnen die gesamte Qualitätssicherung überlassen, wenn sie um die Qualität des Testteams wissen. Dies kann dazu führen, dass – überspitzt gesagt – ein gutes Testteam dazu führt, dass die Qualität des Quellcodes nachlässt.

Hört sich zunächst abstrus an, aber kennen wir nicht alle Fälle von Nachlässigkeiten, wenn z.B. die Entwickler vergessen die Berechtigungen mitzutesten, weil sie mit ihren eigenen Berechtigungen eh alles können oder dass sie mal schnell den einen oder anderen Transport übersehen. Je mehr man sich auf andere verlassen kann, umso mehr schleichen sich auch solche Nachlässigkeiten ein. Liegt wohl in der menschlichen Natur. Ein schlechtes Testteam oder gar der Verzicht auf Tests stellen keine wirkliche Alternative dar.