DASHBOARDS, COCKPITS UND PROJEKTLEITSTÄNDE: HERAUSFORDERUNG MESSSYSTEME FÜR DIE SOFTWAREENTWICKLUNG

Transkript

1 mehr zum thema: die autoren DASHBOARDS, COCKPITS UND PROJEKTLEITSTÄNDE: HERAUSFORDERUNG MESSSYSTEME FÜR DIE SOFTWAREENTWICKLUNG Messsysteme für die Softwareentwicklung stehen bei Projektleitern und IT- Managern hoch im Kurs. Das ist verständlich, denn erfolgreich eingeführte Software-Projektleitstände vermitteln Überblick und Transparenz und helfen somit, Kosten, Qualität und Termindruck in der Softwareentwicklung besser in den Griff zu bekommen. Das Angebot am Werkzeugmarkt ist groß und reicht von Werkzeugen für Business-Intelligence in der Softwareentwicklung bis hin zu vollständig integrierten Dashboard-Lösungen. Die erfolgreiche Einführung von Messsystemen hängt jedoch vor allem von konzeptionellen und organisatorischen Faktoren ab und stellt sich in der industriellen Praxis als herausforderndes Unterfangen dar. Anhand der Einführung eines Cockpits bei einem mittelgroßen Softwarehersteller für Business-Software zeigt dieser Artikel ein mögliches Konzept, beschreibt die Herausforderungen und geht auf die für dieses Projekt maßgeblichen Erfolgsfaktoren ein. Werden Softwareentwicklungsprojekte größer, entsteht beim Management und der Projektleitung zunehmend der Bedarf, Softwareprozesse transparent darzustellen und zusätzliche Unterstützung bei der Analyse und Kontrolle der anfallenden Daten im Softwareentwicklungszyklus zu erhalten. Besonders hilfreich ist diese Unterstützung, wenn in einem Unternehmen mehrere Entwicklergruppen an verschiedenen Produktteilen arbeiten. So stellen sich Fragen wie z. B.: Welchen Fertigstellungsgrad hat die derzeit in Entwicklung befindliche Softwareversion über alle Entwicklergruppen hinweg? Welche Features wurden bei der Umsetzung der letzten Version deutlich unterschätzt und haben dazu beigetragen, dass sich die Auslieferung verzögerte? Bei kleinen Projekten sind diese Fragen meist noch gut aus dem Bauch heraus zu beantworten, bei größeren Produktentwicklungen mit mehreren Entwicklungsgruppen ist jedoch eine zusätzliche objektive Untermauerung des reinen Bauchgefühls anhand aussagekräftigen Zahlenmaterials unerlässlich (vgl. [Boe04]). Aufgabe eines Cockpits ist es, die relevanten Informationen in kompakter Form zur Verfügung zu stellen, um so jederzeit einen aktuellen Überblick über die gesamte Softwareentwicklung zu haben und Fragen rasch beantworten zu können. Auch die Entwickler können von Informationen über den Softwareentwicklungsprozess profitieren: Eine ehrliche Konfrontation mit den eigenen Entwicklungsdaten ist hilfreich, um die bisher geleistete Arbeit zu reflektieren und das Potenzial für Prozessverbesserungen aufzuspüren. Eine transparente Anzeige des Fortschritts der eigenen Arbeitspakete liefert den Entwicklern frühzeitig Rückmeldung, nützt bei der Planung des nächsten Iterationsschrittes und dient als Kommunikationsplattform. So sollen aktuelle Werkzeuge, wie z. B. JIRA (Atlassian) oder Rational Team Concert (IBM) die Softwareentwicklung anhand von integrierten Dashboards für Entwickler und Teams besser nachvollziehbar und planbar machen. Das Projektumfeld Bei einem mittelgroßen Softwarehaus für Business-Software in Österreich ist das Issue-Management zentraler Bestandteil des Softwareentwicklungsprozesses und wird intensiv von über 200 Personen aus verschiedenen Unternehmensbereichen genutzt: Die Support-Mitarbeiter erfassen die Wünsche und Fehlermeldungen von Stefan Larndorfer ( ist wissenschaftlicher Mitarbeiter am Software Competence Center Hagenberg und beschäftigt sich dort seit mehreren Jahren mit der Konzeptionierung, Implementierung und Einführung von Software-Cockpits. Rudolf Ramler ( ist Projektleiter und wissenschaftlicher Mitarbeiter am Software Competence Center Hagenberg. Seine Forschungsschwerpunkte sind Qualitätsmanagement, Requirements-Engineering und Testen von Softwaresystemen. Clemens Buchwiser ( ist bei der Firma BMD Systemhaus GmbH im Bereich Qualitätssicherung und Testkoordination tätig. Kunden. Durch den engen Kontakt zum Kunden verfügen die Support- Mitarbeiter über ein sehr gutes Verständnis der Kundenanforderungen. Die Entwickler erfassen umzusetzende Aufgaben vorab im Issue-Management- System und verteilen diese im Zuge der eigenen Planung auf die kommenden Iterationen. Die Leiter der verschiedenen Entwicklergruppen planen kommende Iterationen anhand der vorliegenden (vorgeplanten) Entwickleraufgaben und der 72 73

2 fachartikel Beispiele für Software-Cockpits Abb: 1: Das Management-Cockpit mit der Möglichkeit der OLAP-Analyse. Anforderungen des Supports (Kundenwünsche, Ideen). Im Zuge der Planung wird entschieden, welche Ideen vom Support in Entwickleraufgaben umgewandelt werden und wie diese am besten umgesetzt werden. Ein Experten-Gremium (Gruppenleiter, Produktmanager und Verkaufsverantwortliche) bewertet die erfassten Aufgaben und Anforderungen mittels einer Business-Value-Analyse. Gemeinsam werden Arbeitspakete für die nächsten Iterationen geschnürt, die bestmöglich auf die Business-Strategie des Produkts abgestimmt sind. Die Produktentwicklung erfolgt anhand eines iterativen Entwicklungsprozesses mit monatlichen Releases. Der umfangreiche SupportBereich stellt sicher, dass neue Kundenanforderungen rasch analysiert und im Issue-Management-System in der richtigen Kategorie (Produktidee/spezielle Kundenanforderung/Fehler) dokumentiert werden. Abb. 2: Das Cockpit für Entwickler und Support visualisiert einfache integrierte Metriken aus dem Issue-Tracking und der Arbeitszeitaufzeichnung. 4/2009 Die Qualität eines Cockpits und dessen konkreter Inhalt werden in erster Linie vom Informationsbedarf, der Qualität der dargebotenen Informationen und deren Interpretation bestimmt. Trotzdem sollte man sich bewusst sein, dass die Art der Darstellung der Informationen, Benutzerfreundlichkeit und das Design des Cockpits eine wichtige Rolle spielen. Ein gelungenes Dashboard-Design ist nicht das Produkt einer Ansammlung von gestylten Tachometern, Thermometern und Ampeln, sondern hat mit Information-Design, Einfachheit und Kommunikation zu tun (vgl. [Few06]). Möglichst gut aufbereitete Informationen helfen, die komplexen Zusammenhänge benutzerfreundlich zu präsentieren, und senken die Hemmschwelle, sich mit den Daten auseinanderzusetzen. Die Screenshots in den Abbildungen 1 bis 4 zeigen exemplarisch, wie die Cockpit-Lösung im konkreten Fall aussieht, und geben einen groben Überblick über die zur Verfügung gestellten Metriken: Das Management Cockpit in Abbildung 1 erlaubt eine Analyse der Daten mittels OLAP und stellt dem Qualitätsmanagement somit umfangreiche Möglichkeiten der Datenauswertung zur Verfügung. Die Metriken gehen insbesondere auf geschätzte und gebuchte Stunden von einzelnen Softwarepaketen ein und erlauben eine separate Betrachtung der Erstellungskosten gegenüber anfallenden Wartungskosten. Weitere Metriken geben Auskunft über die Prozessqualität, wie z. B. der Granularität der erfassten Entwickleraufgaben, der Einhaltung von Qualitätssstandards und Prozessen, Zahlen zur Planungsqualität und der Schätzqualität der Entwicklung. Das Cockpit für Entwickler und Support in Abbildung 2 visualisiert fundamentale einfache Metriken, die aus jedem Issue-Tracking-Datenbestand extrahiert werden können: Auswertungen zu neu erfassten und erledigten Entwickleraufgaben (Issues) werden neben einem Burndown-Chart und dem Fertigstellungsgrad der aktuellen Version dargestellt. Eine Integration mit dem Arbeitszeiterfassungssystem ermöglicht es, die Kosten für umgesetzte Entwickleraufgaben zu ermitteln.

3 Abb. 3: Die Visualisierung einer Iterationskurve im Cockpit: Die Darstellung an der X-Achse mit Wochen hat sich als optimale Granularität herausgestellt. Vorgehensweise bei der Einführung Der Prozess der Einführung des Cockpits gliederte sich in mehrere Phasen (siehe Abb. 5), wobei der Analyse der bestehenden Arbeitsweise und der Prozessoptimierung besonderes Augenmerk geschenkt wurde. Die wichtigste Frage des Projekts war nicht, wie die vorhandenen Daten sinnvoll als Metriken dargestellt werden können, sondern wie ein Messsystem den Entwicklern, Gruppenleitern und dem Management im täglichen Leben einen realen Nutzen bringen kann. Die gemeinsame Erarbeitung dieser Frage hat zur Folge, dass man Prozesse neu überdenkt, den Nutzen von bisherigen Werkzeugen hinterfragt und dazu bereit ist, festgefahrene Ansichten und Meinungen im Unternehmen durch neue Argumente und Sichtweisen zu verändern. Über verschiedene Stapel-Optionen im Balkendiagram (siehe Abbildung 3) ist es möglich, die Zusammensetzung der Daten interaktiv anhand verschiedener Kriterien zu betrachten. Ein Vergleich von Daten einer Iteration mit Daten anderer Iterationszeiträume erleichtert das Bewerten der aktuellen Projektsituation (vgl. [Kan01]). Für den Gruppenleiter, der die Kosten einer Iteration kalkulieren muss, ist die Gegenüberstellung der geplanten Schätzwerte der gesamten Entwicklergruppe mit den tatsächlichen Kosten besonders interessant (siehe Abbildung 4). So bekommt er nach einiger Zeit ein besseres Gespür dafür, wie gut seine Entwicklergruppe im Schätzen von neuen Aufgaben ist, und kann damit besser die Kosten von zukünftigen Softwareversionen abschätzen. Darüber hinaus gibt es für einzelne Entwickler die Möglichkeit, sich mit den eigenen Schätzwerten und gebuchten Zeitwerten pro Aufgabe auseinanderzusetzen. Die Balkendiagramme unterhalb der Prozentangaben zeigen eine detaillierte Gegenüberstellung für jede Entwickleraufgabe. So wird ersichtlich, wie gut der einzelne Entwickler seine Aufgaben schätzt. Der Entwickler kann diese Informationen nutzen, um seine Fähigkeit, Aufgaben zu schätzen, zu verbessern. Abb. 4: Der Fortschritt einer Iteration: Geschätzte und gebuchte Werte werden einander gegenüber gestellt

4 Ziele, Fragen und Metriken Beim GQM-Ansatz (Goal-Question- Metric, vgl. [Bas04]) werden von definierten Zielen strukturiert Fragen und Metriken abgeleitet. Zusammen mit dem Management und den Gruppenleitern erarbeiteten wir in dieser Phase einen Katalog von Zielen, Fragen und Metriken, der die Basis des neuen Prozesses wurde. In diesem Katalog durften durchaus auch Fragen formuliert werden, die im bestehenden Prozess nicht ohne Weiteres zu beantworten waren, da die erforderlichen Daten dafür fehlten. Merkmale des Soll-Prozesses Unabhängig von konkreten Werkzeugen und bestehenden Prozessen wurden in dieser Phase Merkmale des Soll-Prozesses erarbeitet. Die Merkmale beschreiben vor allem Anforderungen an den neuen Soll- Prozess, die sich bei einer konsequenten Umsetzung des GQM-Kataloges ergeben. Das Ergebnis war ein Dokument mit 17 Punkten, das die Merkmale des Soll- Prozesses und die daraus resultierenden Auswirkungen eines gelebten Soll-Prozesses auf die Datenerfassung beschreibt. Die 17 Merkmale konnten sehr gut als Kommunikationstext verwendet werden, um allen Beteiligten die Konsequenzen und Veränderungen klar zu machen, die auf sie zukommen würden. Ausführliche Diskussionen über jeden dieser Punkte schufen bereits in dieser frühen Projektphase ein neues Bewusstsein für die Abläufe in der Entwicklung, das die Aufmerksamkeit und Fähigkeit zur Selbstkritik erhöhte. Soll-Prozess-Definition Die eigentliche Prozessdokumentation eignete sich aufgrund der Länge und der Form einer erweiterten ereignisgesteuerten Prozesskette (eepk) nicht für die allgemeine Diskussion. Ergebnis dieser Phase war eine 20-seitige Dokumentation des Soll-Prozesses, aufbauend auf dem GQM-Katalog und den Merkmalen des Soll-Prozesses. Die bisherige ISO9001-Prozessdokumentation verwendeten wir bei der Modellierung als Dokumentenvorlage. Die vollständige Modellierung des neuen Prozesses diente hauptsächlich als Referenz- und Nachschlagewerk. Abb. 5: Ein Modell der Vorgehensweise zur Cockpit-Einführung. Abbildung 5 lässt die Vermutung zu, dass die Projektabwicklung wasserfallartig vorangetrieben wurde. Tatsächlich überschnitten sich die einzelnen Phasen aber erheblich und ein regelmäßiges Vorfühlen in zukünftige Phasen erwies sich als nützlich, um den Weg für gute Ideen möglichst frühzeitig vorzubereiten. Erhebung des Ist-Zustands In diesem Schritt wird erhoben, wie derzeit im Unternehmen gearbeitet wird. Da mehrere Produktgruppen existieren, die zum Teil unterschiedliche Prozesse und Werkzeuge für ähnliche Aufgaben verwenden, musste die Analyse des Ist-Prozesses in jeder Produktgruppe separat durchgeführt werden, um ein produktgruppenübergreifendes optimales Konzept erarbeiten zu können. Im vorliegenden Fall wurde beschlossen, die neuen Prozesse und Werkzeuge anhand von zwei repräsentativen Pilotgruppen zu erproben. Diese zwei Pilotgruppen standen bereits während der Konzeptionierung für Interviews und kleine Versuche zur Verfügung. Die intensive Zusammenarbeit mit den Pilotgruppen in dieser frühen Phase ergab viele wertvolle Einblicke in das Tagesgeschäft der Entwickler und half, das neue Konzept optimal auf deren Bedürfnisse abzustimmen. Werkzeugunterstützung In diesem Schritt wurde sichergestellt, dass der neue Soll-Prozess optimal von den bestehenden und neuen Werkzeugen unterstützt wird. Für die Entwickler lässt sich eine Prozessveränderung sehr anschaulich darstellen, indem die verschiedenen Prozessschritte mit den dafür benötigten Werkzeugen bzw. Bildschirm-Schnappschüssen verbunden werden. Eine gute Werkzeugunterstützung, die geringen Overhead bei den Entwicklern verursacht, trägt maßgeblich zur Akzeptanz des neuen Prozesses bei. In dieser Phase wurde ein erster Prototyp eines Cockpits für das Management und die Entwickler implementiert. Die Auswahl geeigneter Werkzeuge für das Prototyping ermöglichte eine iterative, partizipative Entwicklung mit den Gruppenleitern und Entwicklern. Einführung bei den Pilotgruppen In dieser Phase wurden mehrere Workshops mit den Pilotgruppen durchgeführt, um zu den erarbeiteten Konzepten und Werkzeugen Feedback aus dem Tagesgeschäft einzuholen. Ziel dieser Phase waren die schrittweise Einführung des neuen Prozesses sowie die Etablierung einheitlicher Begriffe und einer gemeinsamen Vision zur besseren Verständigung. Begleitung von zwei Iterationen Durch persönliche Interviews mit Key- Usern wurde in der Phase Begleitung von zwei Iterationen evaluiert, wie sich die neuen Konzepte im Entwickleralltag 4/2009

5 bewähren. Zusätzlich wurden die gesammelten Daten überprüft, um auf Fehler in der Werkzeugverwendung aufmerksam zu werden. Diese beruhten vor allem auf Missverständnissen oder Unklarheiten im Zusammenhang mit dem neuen Prozess. Evaluierung des neuen Prozesses Inwieweit sind neue Werkzeuge, Prozesse und vor allem die bessere Übersicht der Metriken für Entwickler, Gruppenleiter und das Management von Vorteil? Welchen Nutzen ziehen die Beteiligten aus dem Cockpit? Ziel dieser Phase ist die Aufarbeitung dieser Fragen. Das Rollout des Cockpits auf das restliche Unternehmen wurde an das Ergebnis dieser Phase geknüpft. Herausforderungen bei der Cockpit-Einführung Die erfolgreiche Einführung eines Cockpits in einen vorhandenen Entwicklungsprozess mit etablierten Werkzeugen und bestehenden Daten stellt in der Praxis eine große Herausforderung dar. Nur allein die Einführung neuer Tools zur Darstellung von Metriken führt sicherlich nicht zum gewünschten Erfolg. Eine Reihe von Herausforderungen ergibt sich durch Wechselwirkungen, die vor allem die Organisation und den Umgang mit Daten und Metriken in der Organisation betreffen. Messen: emotional stark behaftet Messen ist vor allem dann stark emotional behaftet, wenn der Eindruck entsteht, dass persönliche Daten, wie z. B. die Aufgabenlisten der Entwickler, für eine Messung, Überwachung oder Beurteilung verwendet werden. Es bauen sich Ängste auf, das Management könnte die Daten missbrauchen und verfolge das Ziel, den gläsernen Mitarbeiter zu schaffen. Diese Ängste entstehen, wenn die Betroffenen vermuten, dass das Management kein Vertrauen in die zu Messenden hat. Folglich verlieren auch die Betroffenen das Vertrauen in das Management und sind nicht daran interessiert, an einem Projekt mitzuarbeiten, das die Messung der Softwareentwicklung zum Ziel hat. Diese Mitarbeit ist aber gerade in einem Projekt wichtig, das fundamentale Prozesse eines Softwareentwicklungsunternehmens analysieren, verbessern und transparenter machen will. Ein Weg aus dieser Misere kann im Prinzip der sinnvollen Transparenz, wo nötig liegen. Nur dort, wo wesentliche und überprüfbare Punkte zu verfolgen sind, müssen diese auch messbar gemacht werden. Dadurch ergeben sich eher banale Metriken, wie z. B.: Welche Aufgaben sind pro Entwickler für die nächste Version geplant? Wie viele Aufgaben sind noch aus der letzten Version offen? Wie viele Stunden waren für die letzte Version erforderlich? Diese Fragen werden von allen Entwicklern und Gruppenleitern als sinnvoll erachtet. Eine Beschäftigung mit diesen zentralen Fragen und die kontinuierliche Darstellung und Konfrontation mit den Antworten (siehe Entwickler-Dashboard in Abb. 2) wird nicht im negativen Sinne der Kontrolle zur Überwachung, sondern im positiven Sinne der Kontrolle zur Steuerung basierend auf Fakten wahrgenommen. Dieser Ansatz trägt maßgeblich dazu bei, die Leistung der Softwareentwicklung transparenter zu machen, und stellt deshalb für alle Beteiligten eine Win-Win-Situation dar. Dysfunktionale Effekte von Metriken Dysfunktionale Effekte von Metriken entstehen dann, wenn der Prozess der Messung die Organisation in einer kontraproduktiven Art und Weise beeinflusst und das zu Ergebnissen führt, die im Gegensatz zur beabsichtigten Wirkung der Einführung des Messsystems in der Organisation stehen (vgl. [Jon99]). Im Kasten 1 wird dieses Phänomen anhand eines fiktiven Beispiels erklärt. Der Grund für dysfunktionale Effekte liegt darin, dass Menschen Messungen, die einem bestimmten Zweck unterliegen, durchschauen und sie für ihre Zwecke manipulieren können. Dafür gibt es unzählige Beispiele, sei es nun im Zusammenhang mit der aktuellen Finanzkrise (Stichwort: Quartalszahlen optimieren ) oder mit der Lebensmittelindustrie (Stichwort: Bestimmung des Reifegrads von Tomaten anhand von Farbtabellen ). Allen Beispielen ist gemeinsam, dass die Auswahl der Metriken nicht perfekt mit dem eigentlich zu erreichenden Ziel übereinstimmt (vgl. [Bla63]). Das wäre nicht weiter schlimm, wenn die von den Messungen betroffenen Menschen nicht beginnen würden, die Metriken anstatt der eigentlichen Ziele zu optimieren. Ironischerweise steht die Optimierung der Metriken meist im Widerspruch zur Erreichung des eigentlichen Ziels (vgl. [Aus96]). Ziel bei der Einführung des Cockpits zur Planung des Issue-Managements war es in erster Linie, die während einer Iteration entstehenden Daten zu visualisieren, den aktuellen Status wahrheitsgetreu darzustellen und bestehende Zusammenhänge transparent zu machen. Nach dem Ansatz des Pure Informational Measurement (vgl. [Aus96]) werden keine Bewertungen an die Messungen geknüpft; es werden keine Aussagen wie gut oder schlecht getätigt und folglich auch keine Ampeldarstellungen oder Tachometer mit grüner und roter Zone eingesetzt. Dieser Ansatz verhalf dem Projekt zu einer positiven und angstfreien Akzeptanz des Cockpits durch die Gruppenleiter und Entwickler. Gruppenübergreifende Dateninterpretion Aufgrund unterschiedlicher Entwicklungsprozesse und Werkzeuge in verschiedenen Entwicklergruppen ergibt sich im Laufe der Zeit eine Datenbasis, die zwar auf den gleichen Datenstrukturen basiert, deren Semantik jedoch von Gruppe zu Gruppe eine andere ist. Das ist oft darauf zurückzuführen, dass unterschiedliche Gruppen unterschiedliche Projektkulturen entwickeln und ohne Vorgaben von Prozessstandards im Laufe der Zeit so auch eine unterschiedliche Verwendung von Werkzeugen und Interpretationen von Projektdaten entsteht. Dieses Problem wird nochmals verschärft, wenn zu verschiedenen Prozessen und Projektkulturen noch unterschiedliche Werkzeuge hinzukommen, die eigentlich ähnliche Aufgaben übernehmen. Bevor eine gruppenübergreifende Datenauswertung erfolgen kann, ist genau zu prüfen, ob eine Konsolidierung auf eine homogene Werkzeuglandschaft nicht sinnvoller ist als eine Zusammenführung von verschiedenen Datenbeständen. Erfassen von Daten des Softwareentwicklungsprozesses Wichtige Aspekte der Softwareentwicklung lassen sich leider nicht automatisch messen. Messbar werden diese Aspekte erst, wenn die Softwareentwicklung so organisiert ist, dass als Ergebnis sinnvoll messbare Artefakte entstehen. Diese Artefakte können dann automatisch ausgewertet werden. Die Erstellung dieser Artefakte ist jedoch ein manueller Prozess. Issues, also Ent

6 Projekt A läuft gut, doch der Projektleiter möchte die Entwickler zusätzlich motivieren. Nachdem ein neu eingeführtes Dashboard es ihm bequem erlaubt, die Umsetzung der Issues der einzelnen Entwickler zu vergleichen, kommt er auf folgende Idee: Je mehr Issues ein Entwickler pro Iteration umsetzt, desto produktiver und wertvoller ist dieser Entwickler. Also soll derjenige Entwickler, der die meisten Issues pro Iteration umsetzt, einen Bonus bekommen. Nachdem der Projektleiter seine Idee den Mitarbeitern mitgeteilt hatte, war er gespannt, wie sich die zusätzliche Motivation auf die Produktivität auswirken wird. Tatsächlich konnte der Projektleiter eine gesteigerte Motivation und eine höhere Produktivität bei den Entwicklern erkennen. Das Ergebnis nach der ersten Softwareiteration war sehr zufriedenstellend für ihn. Am Beginn der zweiten Iteration beschlossen einige Entwickler, etwas größere Aufgaben in kleinere überschaubarere Aufgaben zu unterteilen. Der Projektleiter war einverstanden. Diese Entwickler konnten nun nicht, wie bisher, durchschnittlich 40 Issues pro Iteration erledigen, sondern 80. Als andere Entwickler bemerkten, dass sie in den Produktivitätsauswertungen um mehr als die Hälfte zurücklagen, beschlossen diese, ebenfalls größere Issues in mehrere kleine Issues zu unterteilen. Nach einigen weiteren Wochen erledigte ein Entwickler durchschnittlich 400 Issues pro Iteration, indem er für jede Änderung im Code ein separates Issue erstellte. Die Produktivitätsauswertungen waren diesmal so gut wie noch nie. Dennoch war der Projektleiter diesmal überhaupt nicht zufrieden mit dem Ergebnis. Die tatsächliche Produktivität war massiv gesunken, da sich alles nur noch um Issues drehte und durch das ständige Erstellen von neuen Issues kaum Zeit für sinnvolle Tätigkeiten blieb. Auch Versuche, statt einer einzigen Metrik mehrere Produktivitätsmetriken zu kombinieren, endeten damit, dass die Entwickler nach einiger Zeit einen raffinierteren Weg fanden, um die scheinbare Produktivität nach oben zu schrauben (siehe Abb. 6). Kasten 1: Dysfunktionale Effekte: ein Beispiel aus der Praxis. wickleraufgaben, die im Zuge des Softwareentwicklungsprozesses entstehen, gehören ebenfalls zu diesen manuell erstellten Artefakten. Aufgrund der manuellen Tätigkeiten, die mit der Schaffung der Issue-Datenbasis verbunden sind, ergeben sich folgende Konsequenzen: Es ist unrealistisch, dass ein Projektmanager alleine die Issue-Datenbasis pflegt und den kontinuierlichen Projektfortschritt durch die Führung von Interviews mit allen Beteiligten objektiv bestimmt. Dies würde einen unzumutbar hohen Overhead für den Projektmanager bei gleichzeitig relativ ungenauen Informationen in der Datenbasis ergeben. Folglich müssen die Softwareentwickler die Issue- Datenbasis pflegen und so zur Visualisierung des Arbeitsfortschritts beitragen. Daher ist es sinnvoll, das Ergebnis der Datenpflege jedes einzelnen Entwicklers vor allem auch diesen selbst in Form eines Entwickler-Dashboards zugänglich zu machen. Das motiviert die Entwickler, den kleinen Overhead im Zusammenhang mit der Datenpflege in Kauf zu nehmen, und macht ihnen klar, wozu sie das eine oder andere Eingabefeld eigentlich mit Daten füttern. Informationen in hoher Qualität bereitstellen Um das Ziel, Daten in hoher Qualität bereitzustellen, zu erreichen, müssen bereits bestehende Datentöpfe analysiert und zukünftige Datenquellen (d. h. die Dateneingaben) angepasst werden. Der Grund für inkonsistente Datensätze Abb. 6: Die Wirkung dysfunktionaler Metriken (aus [Aus96]). oder fehlende Daten ist häufig, dass es kaum Feedback-Mechanismen für fehlerhafte Dateneingaben gibt. Ein weiterer Grund kann darin bestehen, dass die vorgeschriebene Art und Weise, wie Daten zu erfassen sind, zu komplex und umfangreich geworden ist, sodass sich kein Mehrwert mehr aus der Datenerfassung ziehen lässt. Das führt wiederum dazu, dass Daten nur um des Prozesses Willens eingegeben und gewartet werden. Die eigentlich nutzbringenden Datenaufzeichnungen führen die einzelnen Entwickler auf Papier oder in ihren eigenen Excel-Tabellen. Um Datenqualität zu erreichen, sollte man sich immer vergegenwärtigen, dass die gewonnen Daten gerade im Issue-Tracking manuell von Menschen eingegeben werden müssen und deshalb der damit verbundene Overhead so gering wie möglich gehalten werden muss. Übereifer beim Messen Nach ersten Erfolgen bei der Erhöhung der Transparenz im Entwicklungsprozess besteht die Gefahr, dass immer ausgefeiltere Metriken vom Management gewünscht werden. Hier sollte man sich immer wieder vergegenwärtigen, dass die Sammlung, Auswertung und Interpretation der Daten Zeit und Geld kostet. Außerdem müssen die Entwickler für die Sammlung der Daten motiviert werden können und dazu bereit sein, sich ehrlich einzubringen. Auch die Analyse der Daten mit Methoden des Data Mining sind kostspielig und erbringen gegenüber konventionellen Datenanalyse-Methoden, wie z. B. OLAP, in der Regel nur einen geringen Mehrwert. Um neue Zusammenhänge in den Daten zu finden, sind eine Analyse mittels Datenvisualisierung und der direkte Kontakt mit den Entwicklern aussichtsreicher, als statistische Methoden auf oftmals vagen Entwicklerdaten anzuwenden. Erfolgsfaktoren Das in diesem Artikel beschriebene Beispielprojekt dauerte ungefähr eineinhalb Jahre und wurde am Ende der Projektlaufzeit von den Entwicklern und dem Management evaluiert. Dazu wurde ein strukturiertes Interview mit Schlüsselpersonen aus der Entwicklung und dem Management durchgeführt. Die Befragung ergab, dass die Benutzer sowohl in der Entwicklung als auch im Support von den positiven, kurz- und mittelfristigen Auswirkungen des Projekts überzeugt sind. 4/2009

7 Folgende Erfolgsfaktoren stellten sich als wichtige Eckpfeiler im Projekt heraus: Vertrauensbildung durch Beteiligung der Entwickler: Die organisatorische Einbettung der Entwickler in Form von Pilotgruppen in das Projekt hilft, Vertrauen aufzubauen. Leitsatz muss dabei sein, mit den Entwicklern gemeinsam zu verbesserten Prozessen und zu einem sinnvollen Messinstrument zu kommen. Einbeziehung des Managements: Zusammen mit dem Management sind wichtige Rahmenbedingungen, wie etwa Qualitätsstandards oder die Einbeziehung des Betriebsrates, zu klären. Prozessveränderungen und Messstrategien müssen mit dem Rückhalt des Managements im Unternehmen gelebt werden. GQM als Basis für Messungen: Messungen für die Softwareentwicklung sind wertvoll, wenn sie an deren Zielen ausgerichtet sind. Die strukturierte Erarbeitung dieser Ziele und die darauf folgende Ableitung von Fragen und Metriken hilft, sich auf die wertvollen Metriken zu konzentrieren. Vermeidung von dysfunktionalen Effekten: Stehen Transparenz und Nachvollziehbarkeit und nicht die Bewertung im Vordergrund der Messung, wird die Gefahr von dysfunktionalen Effekten gemildert. Die Schaffung eines Bewusstseins für dysfunktionale Effekte von Metriken bei Entwicklern und dem Management soll verdeutlichen, dass ein ehrliches Engagement bei beiden die Basis für hochwertige Metriken ist. Jegliche Formen der Verwendung der Cockpit-Daten für eine Bewertung gefährdet zwangsläufig den Zweck des Cockpits. Aussagekräftige Cockpits durch hohe Datenqualität: Gut verstandene Prozesse, die konsistente, aussagekräftige und automatisch messbare Artefakte liefern, sind die Basis für überzeugende Informationen in Cockpits. Gut benutzbare Werkzeuge für die Eingabe und Pflege von Entwicklerdaten sind dazu ebenfalls wichtig. Entwicklung von Metriken, die im Entwickleralltag nutzbringend sind: Man unterscheide zwischen Metriken, die laufend informieren können (vgl. [Kan01] und [For07]), und Metriken die statistische Funktion haben. Prozessänderungen, nur um statistische Kenngrößen zu erhalten, sind teuer und bergen ein hohes Risiko, sich langfristig nicht erfolgreich durchzusetzen. Verwendung von klaren, positiven Begriffen: Klare und positiv formulierte Sprachelemente tragen dazu bei, dass Prozesse eindeutig kommuniziert werden können und die Interpretation der Daten einfach ist. Die Namen von Werkzeugen, Eingabefeldern und Prozessen sind wichtig. Die Sprache ist die Mutter der Gedanken! Einfache Prozesse und elementare Daten für verständliche Metriken: Im Zuge einer möglichen Prozessverbesserung sollte versucht werden, die Komplexität von Prozessen und elementare Daten möglichst zu vereinfachen (z. B.: Das Datenobjekt Issue ist so einfach wie möglich, so komplex wie nötig). Weniger ist mehr: Die Entwicklung von einigen wenigen, qualitativ hochwertigen Metriken, die oft im Entwickleralltag eingesetzt werden, bringt mehr als die Entwicklung vieler komplexer Metriken, die kaum jemand verstehen und überblicken möchte. Benutzer von Cockpits wollen nur mit relevanten Metriken, kompakt und auf einer Bildschirmseite dargestellt informiert werden. Fazit Richtig eingeführte und genutzte Software- Cockpits leisten einen wichtigen Beitrag zur zielorientierten, kontinuierliche Konfrontation mit transparenten Software- Projektdaten im Team. Die Herausforderungen bei der Einführung und Entwicklung eines Software-Cockpits liegen dabei hauptsächlich auf organisatorischer und sozialer Ebene. Ein Vorgehen entlang der Kette klare Ziele zielgerichtet verbesserte Prozesse Visualisierung der relevanten Daten schafft dabei gute Voraussetzungen für die nachhaltige Einführung eines Software-Cockpits in die Softwareentwicklung. Literatur & Links [Aus96] R. D. Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996 [Bas04] V. R. Basili, G. Caldiera, H. D. Rombach, The Goal Question Metric Approach, 1994 [Bla63] P. M. Blau, The Dynamics of Bureaucracy: A Study of Interpersonal Relations in Two Government Agencies, The University of Chicago Press, 1963 [Boe04] B. Boehm, R. Turner, Balancing Agility and Discipline, Addison-Wesley, 2004 [Few06] S. Few, Information Dashboard Design, O Reilly, 2006 [For07] Forrester Consulting, Changing The Cost/Benefit Equation For Application Development Metrics, 2007, siehe: resources/en/pdf/white_papers/alm-forrester-appdev- metrics-wp.pdf [Jon99] P. M. Johnson, Leap: A Personal Information Environment for Software Engineers, University of Hawaii, 1999 [Kan01] S. H. Kan, J. Parish, D. Manlove, Inprocess metrics for software testing, IBM Systems Journal, Vol. 40, No 1, 2001, siehe: [Soft] Deutsches Forschungsinstitut für ganzheitliche Software Cockpits, siehe: