Linda Northrop

Linda Northrop ist Director des Research, Technology and System Solutions Program am SEI. Sie leitet in dieser Funktion die Arbeit an den Themen Architektur-zentrierte Entwicklung, Software-Produktlinien, Systems-of-Systems und Ultra-Large-Scale Systems. Über letzteren Punkt sprach sie als Keynote Speaker auf der SEPG Europe 2010.

Es gibt einen Trend zu Ultra-Large-Scale Systems, auch wenn ich mir persönlich noch nie Gedanken gemacht habe, dass es solche System überhaupt gibt. Es ist auch nicht entscheidend festzulegen, welche Systeme nun groß und welche riesengroß sind. Aber sie sind bereits überall vertreten.

Das Software Engineering Institute (SEI) führte eine Studie durch im Auftrag der US Army. Dort wurde charakterisiert, was eigentlich Ultra-Large-Scale bedeutet. Nun, im Grunde zeichnet diese System eine bestimmte Undurchsichtigkeit aus. Unüberschaubare Lines of Code, Datenspeicherung oder -verarbeitung, Anzahl Verbindungen, Hardware-Elemente, Prozesse, Interaktionen oder involvierter Benutzer.

Das Resultat der Studie sagte im Grunde, dass herkömmliches Engineering oder auch agile Ansätze nicht funktionieren werden beim Entwickeln von ULS Systems. ULS Systems haben keine zentrale Authorität, niemandem gehört das ganze System. Insofern funktionieren auch zentral gelenkte Prozesse nicht. Gedanklich muss man eher an Ökosysteme denken.

Sehr schön fand ich den folgenden Vergleich: Wir können mit unseren herkömmlichen Methoden Gebäude bauen, auch komplexe Gebäude, aber Ultra-Large-Scale Systems sind in diesem Bild eher zu vergleichen mit einer Stadt. Eine Stadt ist mehr als nur eine Ansammlung von Gebäuden. Da gibt es eine Infrastruktur, Feuerwehr, Polizei und Müllabfuhr, Telekommunikation, ein soziales System.

Paul Nielsen lädt zum Dinner

Mit Porto hatte das Software Engineering Institute (SEI) eine wirklich nette Location gewählt für die diesjährige SEPG Europe, die europäische Konferenz für Prozessverbesserung nach CMMI. Die zweit-größte Stadt Portugals ist Namensgeber ihres Landes und bekannt durch den Portwein. Zahlreiche Weinkellereien reihen sich am Ufer des Flusses Douro.

Als besonderes Highlight wurde für alle Teilnehmer und Gäste (einige flogen Ihre Partner ein) am Mittwoch-Abend ein Bootsausflug auf dem Douro veranstaltet, der schließlich bei der Kellerei Taylor’s endete mit einer kurzen Führung und anschließendem Dinner. Die Terrasse bot einen fantastischen Blick über die Altstadt von Porto an der anderen Uferseite.

Die Konferenz selbst fand in der Universität von Porto statt, genauer an der Engineering-Fakultät. Zahlreiche leerreiche Vorträge, Networking zwischen Prozessexperten aus Europa und den USA und interessante Keynote Speaker machten auch die diesjährige SEPG zu einem Highlight. Nächstes Jahr geht es nach Dublin (Irland) unter dem Thema Power the process.

Auf der Website der SQS-Gruppe heißt es: Trainingsinhalt ist u.a. das SPI Manifesto, der Einsatz von Prozessmodellen (CMMI®, ITIL, Test SPICE etc.), der Einsatz von Lebenszyklusmodellen (V-Modell®, RuP, Agile Vorgehensweisen u.a.), der Einsatz von Beschreibungsmodellen (BPMN, EPK, Swimlane etc.), die Management-Anforderungen an Prozesse, Kultur und Motivation bei der Umsetzung von Veränderungen, Effektiver Rollout von Prozessen, Planung und Umsetzung von Prozessverbesserungsvorhaben.

Das ECQA-Projekt definiert Kriterien und Richtlinien für die Definition von Zertifikaten im europäischen Raum. Insofern ist davon auszugehen, dass das Zertifikat qualitativ einem festgelegten Standard folgt; die Richtlinien stehen auf der ECQA-Website zum Download zur Verfügung.

Ld + V + S1 > K + A

Diese Formel beantwortet die Frage, wann denn eine Veränderung durchgeführt werden sollte oder durchgeführt wird. Dabei steht Ld für den Leidensdruck, dem man ausgesetzt ist in der derzeitigen Situation. V steht für die Vision, die man entwickelt als als Zielszenario für die Veränderung und S1 bezeichnet den ersten Schritt, der zu gehen ist, um die Vision zu erreichen. Den sollte man mindestens kennen und einschätzen können.

Die Summe aus diesen Werten muss größer sein, als die beiden Einflussfaktoren auf der rechten Seite der Ungleichung. Dabei steht K für die Kosten, die die Veränderung mit sich bringt. Dabei sind nicht nur Geldmittel und Ressourcen gemeint, die man aufbringen muss, sondern auch physische und psychische Anstrengungen, die Veränderung herbeizuführen.

Der zweite Summand A steht für “Angst”. Eine Veränderung bringt immer eine gewisse Form von Angst bei den betroffenen Menschen mit sich. Diese entsteht bspw. durch Stress, Unsicherheit oder Entzug von Verantwortung. Interessant ist es dann, wenn man sich überlegt, wie man auf Angst reagieren kann. Es gibt eigentlich nur drei Reaktionen: tot stellen, Flucht oder Angriff. Und diese drei Reaktionen sind genau die, die wir bei Mitarbeitern beobachten, die Änderungen unterworfen sind.

Nun ist die Ungleichung mathematisch etwas schwer aufzulösen, lassen sich die Summanden doch kaum vergleichbar quantifizieren. Aber sie führt pragmatisch vor Augen, worauf wir achten müssen, wenn wir Veränderungen durchführen wollen.

Buch-Tipp

Watts Humphrey hat gerade ein neues Buch veröffentlicht mit dem Titel Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself.

Der Titel ist nicht verwunderlich, hat sich Watts doch in den letzten Jahren viel mit seinem Team Software Process beschäftigt. Die Menschen stehen im Vordergrund. Und so sagt er auch selbst über sein Buch, dass es keine Software Principles beschreibt, sondern People Principles.

Watts hat über die Jahre erkannt, dass die Grundsätze, die bei Hardware-Entwicklung gelten, sich nicht einfach auf Software übertragen lassen. Management von Software-Projekten hat mit Wissen zu tun. Es ist schwer, die Leute zu managen, wenn man nicht versteht, was sie tun.

Als Watts 1986 beim Software Engineering Institute (SEI) anfing, entwarf er den Personal Software Process (PSP), um Software-Entwicklern zu helfen, durch einen Daten-getriebenen Prozess ihre eigene Arbeit zu optimieren. Watts wurde dafür die National Medal of Technology verliehen, die höchste Auszeichnung, die in den USA im Bereich Technologie vergeben wird.

Und obwohl das Wort Software im Titel steht bemerkt schon ein Reviewer, dass das Buch wohl eine sehr interessante Lektüre zum Thema Management allgemein ist.

Buch-Empfehlung

Jeder schimpft drüber, aber doch haben es die meisten im Einsatz: Microsoft Project. Dieses Jahr soll nun die Version 2010 kommen; bei Microsoft kann man schon die Beta-Version herunterladen. Das habe ich mal getan.

Als erstes wird wohl das Menüband auffallen, die schon aus Office 2007 bekannt ist. Die große Menüzeile am oberen Bildrand soll für kontextsensitive Bedienung sorgen. Ich muss gestehen, ich suche immer noch verschiedene Funktionen in Word und Excel, aber mein Umstieg auf 2007 ist auch noch nicht so lange her. Wir werden sehen, wie sich das in Project verhalten wird. Eine ähnliche Menüführung soll nun aber auch beim MS Project Server 2010 zum Einsatz kommen, um Einheitlichkeit zu und Einarbeitungszeit zu verbessern.

Klickt man in diesem Menü auf die Registerkarte Datei, befindet man sich (Vorsicht Begriff!) im Backstage, der zentralen grafischen Oberfläche zur Verwaltung der Projektdateien. Im Grunde nur ein toller Begriff für eigentlich nichts Neues – das Datei-Menü halt.

Die rechte Maustaste ist etwas intelligenter geworden und bietet nun die Befehle, die man angeblich am häufigsten braucht.

Ein nettes neues Feature ist die Zeitachsenansicht, mit der sich Vorgänge und Meilensteine auf einem Zeitstrahl abbilden lassen. Somit kann ich mal eben schnell eine nette Projektübersicht basteln und muss dafür nicht Powerpoint oder Visio bemühen.

Die Terminplanung soll Excel-mäßiger gestaltet sein und ich kann auf Manuelle Planung umschalten, so dass die Berechnungsfunktionen ausgeschaltet werden. Was für ein Feature! Unsere Projektleiter werden es lieben. Denn “Project zerschießt doch immer den Projektplan” ;-)

Die Ansicht Teamplanung bietet eine Übersicht über die geplanten Mitarbeiter (Ressourcen). Ich kann sehen, an welchen Vorgängen Mitarbeiter arbeiten, welchen Vorgängen noch keine Ressourcen zugeordnet sind oder wo Mitarbeiter überlastet sind. In letzterem Fall kann ich den Vorgang einfach von einer Ressource auf eine andere ziehen, schon habe ich die Überlastung beseitigt.

Vorgänge lassen sich nun inaktiv schalten, um bspw. wichtige Informationen im Projektplan zu lassen, die aber für die Planung irrelevant sind.

Weiterhin gibt es nun Top-Down-Sammelvorgänge. Während sich bisher ein Sammelvorgang immer aus seinen zugeordneten Teilvorgängen definierte, lassen sich nun Sammelvorgänge mit Datumsangaben versehen, die von den Teilvorgängen nicht überschrieben werden. Dadurch lassen sich bspw. die Projektphasen zeitlich terminieren, obwohl die inhaltliche Planung einer Phase noch nicht klar ist (Grobplanung).

Die Zusammenarbeit mit Sharepoint wird intensiviert und der Project Portfolio Server (wer auch immer ihn genutzt hat) wandert nun mit in den Project Server 2010.

Das schönste aber: Project 2010 ist mit früheren Versionen abwärtskompatibel. Also, Mut zum Umstieg!

Seite 620ff.

Nachdem Code Junkie Basti, unser Projektleiter Andreas und Q-Mann Wolfgang nun ihre kleinen Meinungsdifferenzen über das richtige Maß an Formalität von Peer Reviews beseite legen konnten (siehe Artikel Wieviel Review hätten’s denn gern?), fragen sich die drei aber heute, was denn eigentlich CMMI zu den Peer Reviews sagt.

“Pah, nichts wird drin stehen”, meckert Wolfgang; er ist noch nicht wirklich überzeugt, dass dieses neumodische Modell wirklich mehr bringen soll als sein verehrter ISO-Standard. Währenddessen blättert Andreas in der deutschsprachigen Ausgabe des Buches: “Doch, hier hinten im Glossar ist es schon mal erwähnt. Peer-Review: Prüfung von Arbeitsergebnissen durch Gleichrangige während der Entwicklung der Arbeitsergebnisse, um zu beseitigende Mängel zu entdecken.“, zitiert er. Basti guckt grinsend hinter seinem Laptop hoch. Er hat sich inzwischen das PDF gezogen und nach dem Begriff durchsucht. “Mehr zur Durchführung von Peer-Reviews steht im Prozessgebiet Verifizierung“, findet er heraus.

Und tatsächlich! Auch wenn CMMI kein eigenes Prozessgebiet für Peer Reviews vorsieht, widmet es den Prüfungen durch Gleichgestellte doch ein eigenes Spezifisches Ziel, nämlich Specific Goal (SG) 2 im Prozessgebiet Verifizierung: “Peer-Reviews werden für ausgewählte Arbeitsergebnisse durchgeführt”. Als Ziel ist es ein erforderliches Element in einem Appraisal – an Peer Reviews kommt also keiner herum, sollte auch keiner, wie wir schon gelernt haben (siehe Artikel Was bringen Peer Reviews?).

Die drei Practices, die das Ziel dann aufweist, sind recht simpel zu verstehen, nämlich

1. Peer-Reviews vorbereiten
2. Peer-Reviews durchführen
3. Daten aus Peer-Reviews analysieren

VER SP 2.1 Peer-Reviews durchführen

Die genannten Schritte zur Vorbereitung könnten sich auch in der Beschreibung einer Peer Review Methode wiederfinden. Hier geht es darum, für jedes einzelne Peer Review zu entscheiden, wie formal es durchgeführt werden soll, wer die Prüfer sind, welche Metriken erfasst werden sollen und wie die Ein- und Ausgangskriterien lauten. Hier geht es um Review-Checklisten zu bestimmten Arbeitsergebnistypen, um die Festlegung der Zeitpunkte von Peer Reviews (Peer-Review-Zeitplan) und darum, dass der Autor oder Reviewleiter das Reviewobjekt rechtzeitig verteilt.

Die meisten dieser Punkte sollten grundsätzlich festgeschrieben sein, bspw. in der Peer Review Guideline und einer entsprechenden Vorlage für das Reviewprotokoll.

VER SP 2.2 Peer-Reviews durchführen

Hier geht es nun um das Auffinden von Fehlern und Unzulänglichkeiten im untersuchten Arbeitsergebnis. Fehler und offene Punkte werden dokumentiert, damit der Autor sie lösen kann. Ein weiteres Peer Review des selben Arbeitsergebnisses kann erforderlich sein.

VER SP 2.3 Daten aus Peer-Reviews analysieren

Measurement and Analysis lässt grüßen in dieser Practice. Definierte Metriken werden erhoben und für künftige Analysen gespeichert. Dabei ist insb. in Deutschland auf datenschutzrechtliche Sicherung zu achten. Die erhobenen Daten sollten nicht zur Leistungsbewertung von Mitarbeitern verwendet werden können.

Sinnvolle Daten könnten die folgenden sein:

• Produktname und Produktgröße zur Klassifizierung der Daten
• Zusammensetzung des Review-Teams (Rollen)
• Art (Formalität) des Peer Reviews
• Vorbereitungszeit aller Prüfer und Dauer der Review-Besprechung
• Größe des Arbeitsergebnisses bspw. in Anzahl Zeilen
• Anzahl, Schwere, Typ, Ursprung der Fehler
• Phase, in der die Fehler gemacht wurden

Es ließen sich daraus gewisse Metriken errechnen, die man im Laufe der Zeit optimieren könnte:

• Erkennungsrate: Anzahl Fehler / Anzahl Zeilen
• Erkennungseffizienz: Anzahl Fehler / Benötigte Zeit

Sie sehen, CMMI verlängt Peer Reviews und zwar nicht nur die Durchführung, sondern auch die Analyse und damit die ständige Verbesserung des Prozesses. Die Process Area Verification ist auf Maturity Level 3.

Ich denke, es macht gerade in solchen Zeit Sinn, Verbesserungs-Initiativen zu starten. Dafür gibt es mehrere Gründe:

• Wie eingangs erwähnt, sind Mitarbeiter evtl. eher verfügbar, wenn die Auftragslage schlecht ist. Jetzt hat kann man den einen oder anderen fähigen Mitarbeiter dazu bewegen, an Prozessverbesserung mitzuarbeiten, den man sonst nie bekommen hätte, da er sowieso schon total überlastet war.
• Die Motivation der Mitarbeiter kann man dahin lenken, dass sie nun am ehesten einsehen, dass sich etwas ändern muss, um aus der Krise heraus zu kommen. Sie einzubeziehen zeigt ihnen, dass sie wichtig sind und man sie halten will. Gemeinsam gestärkt aus der Krise könnte das Motto lauten, dem alle folgen.
• Auch das obere Management weiß, dass es etwas tun muss, und Prozessverbesserung könnte da einen wichtigen Teil der Strategie ausmachen. Überzeugungsarbeit leistet man hier am besten mit Zahlen.

Natürlich gilt auch in Krisenzeiten alles, was sonst gilt, um Veränderung herbeizuführen, etwa: Probleme von den Akteuren selbst identifizieren lassen, alles in kleinen Schritten umsetzen, aber den Blick auf das große Ganze lenken und jede Änderung pilotieren, schulen und strukturiert ausrollen.

Wie läuft’s bei Ihnen? Werden die Prozessverbesserungs-Aktivitäten in schlechten Zeiten eher hoch- oder runtergefahren?

Wer hat denn nun Recht? Wie läuft ein “richtiges” Peer Review ab? Wieviel Aufwand muss man treiben? Die Standardantwort (“It depends.”) passt natürlich auch hier: Es kommt drauf an. Es kommt drauf an, wie wichtig mein Arbeitsergebnis ist. So würde ich mich einer Anforderungsspezifikation bestimmt intensiver widmen als der Überarbeitung der Testspezifikation einer Komponente, die schon seit Jahren in Betrieb ist. Vielleicht aber auch nicht, denn die Testfälle, die hinzugefügt wurden, sollen nun endlich die immer wieder auftauchenden Probleme der Komponente lösen.

Es kommt auch drauf an, in welchem Zustand sich ein Arbeitsergebnis befindet. Bei den Artikeln zu den (informaleren) Walkthroughs haben wir schon festgestellt, dass diese eher angewendet werden, wenn das Arbeitsergebnis vielleicht ein Drittel fertig ist, um sich die Richtung bestätigen zu lassen. Vor der endgültigen Freigabe eines Projekthandbuches müsste ich aber doch sehr wohl etwas mehr Formalität an den Tag legen, bestimmt doch dieses Wesentliches im weiteren Projektverlauf.

Was aber unterscheidet nun die unterschiedlichen Peer Review Methoden? Basti, Andreas und Wolfgang haben schon einige afugedeckt.

• Der Einsatz eines Reviewleiters kann sinnvoll sein, da er den Peer Review Prozess kennt und als geschulter Moderator im Führen von Meetings erfahren ist.
• Ein gewisses Maß an Konfigurationsmanagement erleichtert das Peer Review. Dazu zählt zum einen, das Dokument “aufzuräumen”, mit Zeilennummern zu versehen, auf Rechtschreibfehler zu prüfen und Kommenatre zu entfernen. Zum anderen sollte für das Review die Unveränderbarkeit des Reviewobjekts sichergestellt werden, damit alle Reviewer die selbe Version des Arbeitsergebnisses prüfen.
• Für größere Peer Reviews macht es oft Sinn, ein Review Kickoff durchzuführen, in dem der Reviewleiter oder der Autor kurz das Vorgehen erläutert, einen Überblick über das zu prüfende Arbeitsergebnis liefert und evtl. verschiedene Schwerpunkt-Sichten an die Reviewer verteilt.
• Entscheindend ist dann bei allen Peer Reviews aus meiner Sicht, dass sich die Reviewer das Arbeitsergebnis “offline” ansehen und ihre Anmerkungen notieren. Diese Vorbereitung ist wichtiger als ein anschließendes Reviewmeeting. In diesem sollten die gefundenen Findings nur noch besprochen werden, so dass der Autor weiß, was gemeint war.
• In einem sehr reifen Reviewprozess kann man nach einem Peer Review die gefundenen Unzulänglichkeiten analysieren, um Kernursachen für Fehler zu identifizieren. Diese können dann in Checklisten eingearbeitet werden, um die selben Fehler zukünftig zu vermeiden.

Grundsätzlich macht es also Sinn, sich mehrere Peer Review Methoden zu definieren, die dann jeweils die oben genannten Elemente einbinden oder eben nicht. Neben dem Walkthrough schlage ich den informalen Buddy Check (“Schau mal rüber”) vor, darüber hinaus aber auch ein formaleres Technisches Review mit Offline Review und Reviewprotokoll, sowie die sehr formale Inspektion, die nicht vom Autor selbst, sondern von einem Reviewleiter geführt wird.

Also, Basti, Andreas und Wolfgang, ich denke, Ihr alle hattet irgendwie Recht.

Um eine Vorstellung zu bekommen, hier ein paar der Themenbereiche, denen die Präsentation typischerweise zuzuordnen sind:

• Arbeiten als Team
• Änderungsmanagement
• CMMI for Service
• Risikomanagement
• CMMI und Agile
• High Maturity
• Kombinieren von Referenzmodellen
• CMMI für kleinere Unternehmen
• Measurement

Watts Humphrey, quasi der Vater des CMMI, war Keynote Speaker am Mittwoch. Ein beeindruckender Mann; ich konnte ihn letztes Jahr auf der europäischen SEPG in Prag erleben.

An deutschen Referenten fiel mir bisher nur der Vortrag von Winfried Russwurm (und Kollegen) von Siemens auf. Wir werden bestimmt mehr treffen, wenn es Ende Juni für Europa soweit ist.

Die diesjährige SEPG Europe wird vom 28. Juni bis 1. Juli in Portugal stattfinden.
Weitere Details finden Sie auf der Website des SEI.