Sebastian Preuss/ Seibert Media weist in einem lesenswerten Beitrag auf die Bedeutung des Debriefings im Testmanagement hin. Die Tester im User-Test sichern nicht nur die Qualität, wir sollten ihren Einfluss auf das Changemanagement auch nicht vergessen! Ihre Eindrücke und ihr Feedback landen früher oder später bei den Anwendern. Selbst wenn der Test schief lief, können sie bei den Anwendern für Verständnsi und Akzeptanz beitragen.

Mit dem Thema Testmanagement haben wir uns hier auch schon wiederholt auseinander gesetzt:

#195 Testmanagement in IT-Projekten
#187 Umgang mit Testfehlern
#156 Excel Toolset
#153 Your Unit Tests lies to you
#148 Testmanagement in IT-Projekten: Organisation und Ablauf
#145 “Effektives” Testmanagement
#86 Gute Tester, schlechte Tester

Neuerdings häufen sich untern den Anhängern von agilen Methoden Posts über Kanban. So widmen sich z.B. Pawel Brodzinski und Henrik Kniberg dem Thema.

Kanban kommt eigentlich aus der Produktionssteuerung und beruht im Wesentlichen auf dem Pull-Prinzip. Statt einer zentralen Steuerung (also übertragen einer zentralen Planvorgabe), wird dezentral ja nach aktuellem Bedarf (also situationspezifisch je Sprint) Material (also Input/Requirements/Zulieferungen) abgerufen.

Auch über Lean Management findet man gelegentlich ähnliche Übertragungen auf das Projektmanagement.

Die guten alten Management-Methoden finden also im Projektmanagement und der Softwareentwicklung ein erfolgreiches Recycling.

Craig Brown von Better Projects hat eine Taxonomie für Requirements von Don Firesmith ausgegraben. Zugegeben, solche Übersichten sind immer etwas abstrakt und theoretisch, haben aber durchaus ihre Berechtigung, z.B. um einen Anforderungskatalog auf Vollständigkeit und Qualität hin zu überprüfen.

Je besser der Anforderungskatalog, umso überschaubarer werden die erforderlichen Änderungen (jedenfalls im Normalfall).

Natürlich wird es immer Änderungen geben, denn die Welt dreht sich immer weiter und wir wissen heute (hoffentlich) auch mehr als gestern. Paul Ritchie von Crossderry Blog weist darauf hin, dass bei Change Requests häufig eine der wichtigsten Fragen nicht gestellt wird, nämlich welche anderen Anforderungen/Changes möglicherweise auf der Strecke bleiben wenn ein bestimmter Change Request verabschiedet und realisiert wird. Sozusagen die Opportunitätskosten eines CRs.

Craig Brown schlägt Storyboards als “requirement tool” vor. Leider beschränken sich seine Ausführungen auf die Überschrift und ein Youtube-Video über Storyboards im Film. Storyboards sind natürlich auch wieder eine Visualisierungstechnik, insofern ist der Ansatz interessant. Die Frage liegt darin, wie Storyboards auch auf abstraktere, weniger visuelle Themen als Film oder beispielsweise die Präsentationserstellung angewendet werden können.

Über SCRUM war hier schon öfters die Rede. Bei Henrik Kniberg finden sich aktuell zwei interessante Beiträge zu SCRUM (alle in Englisch). Zum Einen die Präsentation zu seiner SCRUM-Einführung auf der Agile 2009 in Chicago, zum Anderen seine SCRUM Checklist 2.0, “a simple tool to help you get started with Scrum, or assess your current implementation of Scrum”.

Seit Ur-Zeiten der IT gilt das alte Grundprinzip: Garbage in – garbage out.

Was nützen die besten Auswertungen und Bericht, wenn die Datengrundlage nichts wert ist. Und manches ERP-System oder andere Applikation strotzt nur vor Datenleichen. In fast allen Migrationsprojekten sind deshalb vor der eigentlichen Migration aufwändige Bereinigungen und Analysen erforderlich. In den Auswertungen hat bis dahin die schlechte Qualität offenbar nicht gestört…

Datenqualität ist eine Facette, die nächste Frage ist, ob nicht Äpfel mit Birnen verglichen werden. Gerade wenn unterschiedliche Vorsysteme einbezogen werden, ist beim besten Willen nicht selbstverständlich, dass alle Vorsysteme unter einer Größe  X auch das Gleiche verstehen, das sie gleiche Berichtszyklen haben, etc.  Die Tücke liegt im Detail. Schnell läuft man Gefahr sich in einer Scheingenauigkeit zu verlieren, die nichts anderes wiedergibt als die mittlere Krankenhaustemperatur. (Das Messen der Körpertemperatur eines Patienten mag für den Arzt ja aufschlussreich sein, aber der Durchschnittswert aller Patienten in einer Klinik ist nur mehr eine äußerst fragwürdige Größe.)

BI-Projekte stecken häufig in einem Anforderungsdilemma.

Denn sie wissen nicht, was sie wollen…

Statt klar auf die Ziele und Vorgaben zu fokussieren verlieren sich viele Anforderer in der Fragestellung, welche Informationen könnten vielleicht noch nützlich sein und welche Berichte gab es in der Vergangenheit. In einem großen Datawarehouse-Projekt, dass das Reporting über verschiedene ERP-Systeme und Unternehmensbereiche zusammenführen sollte, führte dies dazu, dass die Spezifikation des neuen Reportings quasi aus den Spezifikationen aller Altsysteme plus zusätzlicher, neuer Anforderungen bestand. Ein Monster war geboren, aber der eigentliche Projektauftrag und die Vorgabe Cross-Selling-Potentiale zu schöpfen wurden schier erdrückt.

… aber jeder kann mitreden…

Das Fatale an Reporting-Themen ist, das fast jeder meint mitreden zu können bzw. zu müssen. Und dies gilt leider nicht nur für die Inhalte, sondern auch für das Layout. Welche Hintergrundfarbe und wohin mit dem Button… Die Diskussionspunkte sind unzählig und wer die Evolutionsstufen eines einzelnen Berichts verfolgt, wird mit Entsetzen feststellen, welche teilweise auch unsinnigen Anforderungen eingebaut, umgebaut und manchmal auch wieder ausgebaut werden.

… und sie sind unersättlich.

Die letzte wesentliche Erkenntnis für die Anforderungen an BI-Systeme (oder Reporting-Systeme im allgemeinen) ist, dass diese nie abgeschlossen sind. Informationen erwecken neue Informationsbedürfnisse. Ganz gleich, ob diese sinnvoll sind oder nicht. Change Requests sind vorprogrammiert. Eine sinnvolle Vorgehensweise ist daher, den eigentlichen Projektscope zunächst relativ eng und eindeutig zu gestalten und möglichst schnell auf ein CR-Verfahren in dem den einzelnen Anforderungen Preisschilder umgehängt werden  umzusteigen. Es ist immer wieder erstaunlich wie sehr so ein Preisetikett Dringlichkeit und Wichtigkeit von Anforderungen relativiert.

In fünf Beiträgen wird hier das Thema Business Intelligence (kurz: BI) aufgegriffen. Unter diesem Modebegriff versammeln sich…

…Verfahren und Prozesse zur systematischen Analyse (Sammlung, Auswertung und Darstellung) von Daten in elektronischer Form. Ziel ist die Gewinnung von Erkenntnissen, die in Hinsicht auf die Unternehmensziele bessere operative oder strategische Entscheidungen ermöglichen. Dies geschieht mit Hilfe analytischer Konzepte und IT-Systeme…

Also salopp zusammengefasst: Hinter BI verbergen sich Kennzahlensysteme und Reporting.

Hans-Ulrich Küpper beschreibt welchen Anforderungen Kennzahlensysteme grundsätzlich genügen sollten:

(1) Kennzahlen sollten einfach und klar sein.
(2) Kennzahlensysteme sollten nicht zu komplex sein (Küpper empfiehlt daher eine hierarische Struktur).
(3) Kennzahlen haben eine Indikatorfunktion.
(4) Kennzahlen und Kennzahlensysteme sollten partizipativ hergeleitet werden.

ad 1: Mit der Einfacheit und Klarheit ist es in der Praxis häufig schnell vorbei. Wer einmal zwei Vertriebskaufleute im Anlagenbau über die vermeintlich eindeutige Größe Umsatz hat streiten hören, der weiß was ich meine… Wann wird denn ein Auftragseingang zum Umsatz? Wie wird mit Skonti, Rabatten und Gutschriften umgegangen? Der Phantasie in solchen Diskussionen sind leider keine Grenzen gesetzt.

ad 2: Warum sollten die Systeme nicht zu komplex sein? Nun, weil Personen sich nur über eine begrenzte Zahl von Zielen steuern lassen. Mit zunehmender Komplexität weicht die Klarheit dem Information Overkill.

ad 3: Klar – Kennzahlen sollen etwas Aussagen, sonst könnten wie sie uns sparen…

ad 4: Die partizipative Herleitung hat vor allem mit den Themen Akzeptanz und Verständnis zu tun. Das System ist nicht aufoktruiert und entspricht den eigenen fachlichen Anforderungen. Die Mitarbeiter, die mit dem Reporting arbeiten, wissen darüber hinaus, was sich dahinter verbirgt, was gemessen oder hochgerechnet wird, und sind daher auch in der Lage die Ergebnisse zu interpretieren.

Agile Softwareentwicklung hat auch bei Microsoft Einzug erhalten. Ein Bericht in Spiegel online hat zahlreiche Reaktionen in den einschlägigen PM- und Sofftwareentwicklungs-Blogs gefunden, z.B. bei Jens Coldewey, Danny Quick und last but not least Andreas Heilwagen.

Die Zusammenfassung meiner beiden Beiträge für das Projektmagazin von Anfang des Jahres gibt es jetzt als Präsentation:

Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset