Zunächst etwas zu unserer kleinsten aber wichtigsten Instanz, auf der unsere gesamte Webseite aufbaut: die Prozessbausteine.

Prozessbausteine sind Best-Practices oder auch einfach Praktiken aus der Software-Entwicklung, sei aus der agilen oder der traditionellen. Sie sind Teil des Software-Entwicklungsprozesses und stellen eine erprobte Aktivität dar. Ein Prozessbaustein ist prozess-, vorhabens- und toolunabhängig, sodass sein Einsatz durch diese drei Eigenschaften nicht eingeschränkt ist. So kann z.B. ein Stand-Up Meeting in einem agilen oder auch traditionellen Entwicklungsprozess angewandt werden, ohne dass bei seiner Durchführung auf ein Tool zurückgegriffen werden muss.

Wir haben alle Prozessbausteine einer einheitlichen Beschreibung unterzogen, um so einer Konsistenz innerhalb der Detaillierung zu erreichen und die Bausteine besser miteinander zu vergleichen. Sie werden mit Hilfe folgender Attribute beschrieben: Name, Synonyme, Beschreibung / Funktionsweise, Referenz, Vorbedingung, Nachbedingung, Vorteile, Nachteile, Fallstricke, Variationsparameter, „Undo“-Schritte, Risikofaktoren, Aufwände (z.B. Einführungsaufwand), Fallbeispiele / Evaluation.

  

Reine Prozessbausteine ohne jeglichen Bezug zur praxisrelevanten Nutzung und ihren Mehrwert für diese bringen in der Regel jedoch reichlich wenig. Also stellen wir jetzt ihre Relation zu Zielen und dem Kontext her.

Ziele sind Verbesserungsziele, die von Unternehmen angestrebt werden und von Unternehmen zu Unternehmen unterschiedlich sind, wie z.B. Kundenmitsprache steigern, technische Qualität erhöhen, Kompetenzfokussierung verbessern. Die Verbesserungsziele werden mit dem Einsatz von Prozessbausteinen erreicht, stellen also eine angestrebte, positive Auswirkung eines Prozessbausteins dar. Hierbei sind mit jedem Ziel genau die Prozessbausteine verknüpft, die dieses positiv beeinflussen. Auf prokob.info finden Sie vier Ziel-Hauptgruppen mit jeweils konkreten Unterzielen.

Der Kontext beschreibt die Rahmenbedingungen, in denen ein Prozessbaustein zum Einsatz kommen kann oder auch nicht. Auch er ist direkt mit Prozessbausteinen verknüpft und dient als Vorbedingung für deren Nutzung. So ist z.B. bei nur einer Person im Projektteam der Prozessbaustein „Pair Programming“ nicht anwendbar, da mindestens zwei Personen benötigt werden. Der Kontext kann anhand von fünf Eigenschaften mit jeweils vier Abstufungen festgelegt werden:

 

  • Endnutzerverfügbarkeit: Beschreibt, wie oft die Nutzer erreichbar sind bzw. vor Ort sein können, z.B. für Nutzer-Tests. Abstufungen: keine, monatliche, wöchentliche, tägliche Verfügbarkeit
  • Kundenverfügbarkeit: Beschreibt, wie oft die Kunden erreichbar sind bzw. vor Ort sein können, z.B. für Rückfragen zu Anforderungen oder für Produktpräsentationen. Abstufungen: keine, monatliche, wöchentliche oder tägliche Verfügbarkeit
  • Projektdauer: Beschreibt die konkrete zeitliche Dauer eines Projektes. Abstufungen: 0-4 Wochen, 1-3 Monate, 3-6 Monate, > 6 Monate
  • Teamgröße im Projekt: Wird zwar auf ein einzelnes Team bezogen, es können aber dennoch mehrere Teams in einem Projekt arbeiten. Die Teamgröße ist daher nicht mit der Gesamtzahl aller am Projekt beteiligten Personen zu verwechseln. Abstufungen: 1, 2-5, 5-10, > 10 Personen
  • Verteilung: Beschreibt die örtliche Verteilung des Projektteams, z.B. städte- oder länderübergreifend. Abstufungen: Onsite, Onshore, Nearshore, Offshore

 

Bis hierhin haben wir unsere Begrifflichkeiten Prozessbaustein, Ziele und Kontext erklärt und wie diese drei Bezeichnungen miteinander verknüpft sind. Mit dem Entwicklungsprozess an sich wurden die Prozessbausteine direkt jedoch noch nicht in Verbindung gebracht. Hierzu dient die Prozessmatrix.

Die Prozessmatrix verdeutlicht, wann, d.h. in welcher Phase im Entwicklungsprozess der Prozessbaustein eingesetzt werden kann. Die Matrix setzt sich aus den fünf PMI-Prozessgruppen (horizontal) und den fünf Artefaktgruppen der ISO12207 (vertikal) zusammen. Für jede Zelle kann nun ein passender Prozessbaustein in den Entwicklungsprozess eingeführt werden. Hierbei beschränkt sich der Nutzen eines Bausteins keinesfalls auf eine bestimmte Zelle, sondern kann sich auch über mehrere Zellen erstrecken. So ist z.B. der Prozessbaustein „StandUp Meeting“ in der Prozessgruppe „Planung“ zu verorten, deckt dort aber alle Artefaktgruppen ab.

  • Artefaktgruppen: Sind das geplante (Zwischen-)Ergebnis, z.B. Pflichtenheft oder Codes, das einen direkten oder indirekten Beitrag zum Prozessendergebnis liefert: Anforderung, Entwurf, Implementierung, Test, Deployment
  • Prozessgruppen: Sind für das Projektmanagement logische Kategorisierungen von Prozessbausteinen: Initiierung, Planung, Umsetzung, Controlling, Abschluss

 

Bisher wurden die Prozessbausteine nur als Individuen im Entwicklungsprozess betrachtet ohne jegliche Relation zueinander. Sie besitzen jedoch Abhängigkeiten zueinander, sodass es von Vorteil ist, bestimmte Prozessbausteine in Kombination anzuwenden. Mögliche Kombinationen werden durch Ensembles, Orchester und durch ein Abhängigkeitsnetzwerk gegeben.

Ensembles sind eine sinnvoll zusammengesetzte Menge an Prozessbausteinen. Sie werden hauptsächlich über ein Matching von „Nachbedingung eines Prozessbausteins“ zu „Vorbedingungen eines Prozessbausteins“, über die Prozessmatrix und über die Verbesserungsziele gebildet. Sie sind vor allem dann hilfreich, wenn nur ein bestimmter Teil des Entwicklungsprozesses neu aufgestellt werden soll.

Ein Orchester entsteht, sobald ein Ensemble sowohl alle Prozessartefakte als auch alle Prozessgruppen abdeckt – am besten möglichst effektiv. Jede der 25 Zelle der Matrix ist somit mit mindestens einem Prozessbaustein belegt, d.h. die Matrix ist vollständig. Dies bedeutet noch nicht zwingend, dass dieses Orchester schon ausreicht, da es ggf. sinnvoll sein kann eine Zelle mehrfach zu belegen. Zum Beispiel wird im Beispiel zur Umsetzung der Implementierung noch nichts über die Codierung gesagt.

Das Abhängigkeitsnetzwerk visualisiert die in direkter Relation zueinanderstehenden Prozessbausteinen. Hierbei spielen sowohl die Verknüpfung von Vor- und Nachbedingungen wie auch die Einordnung in die Matrix eine wichtige Rolle. Denn aus diesen Verbindungen entsteht unser Abhängigkeitsnetzwerk. Darüber hinaus bestehen aber auch Abhängigkeiten, die den Einsatz eines Prozessbausteines bestimmen, z.B. Kontexteigenschaften. Das Netzwerk dient dazu, die für den eigenen spezifischen Entwicklungsprozess geeigneten Prozessbausteine, Ensembles oder Orchester zu bestimmen.

 

Nun haben wir alle Begriffe, die unsere Idee von prokob.info umschreiben, definiert. Dennoch fehlt der bisher abschließende Effekt, den wir mit all dem erreichen wollen – die praktische Umsetzung. Diese gestaltet sich zum einen durch die Lösung und zum anderen durch die Transition.

Die Lösung ist das Endergebnis der Suche nach geeigneten Prozessbausteinen, Ensembles oder Orchestern. Dabei ist das Endergebnis nicht eine wahllose Aneinanderreihung der einzuführenden Praktiken, sondern eine Ziel- und Kontextspezifisches Ausgabe.

Die Transition stellt schließlich den praktischen Teil unserer Idee dar. Mit ihr wird die vorab ausgearbeitete Lösung nach und nach in den bestehenden Entwicklungsprozess in einer aufeinander aufbauenden Reihenfolge implementiert. Vorteil unserer Transition ist es, dass zu jederzeit die Einführung der in der Lösung enthaltenen Prozessbausteine abgebrochen werden kann, ohne negative Auswirkungen auf den Entwicklungsprozess zu erzeugen. Denn bereits nach der Implementierung eines Bausteins, findet eine Prozessverbesserung mit einer eventuell angestrebten Zielerreichung statt.