Organisationsmuster

Organisationsmuster dienen der Lösung von Problemstellungen durch das Hinzufügen einer Struktur zu einem System aus Menschen, wie etwa Firmen, politischen Parteien, dem Militär und anderen Organisationen.^[1]

Während Organisationsmuster bereits sehr lange existieren, geht der Begriff des Musters auf den Architekten Christopher Alexander zurück.^[2][3] Die Ideen Alexanders wurden Anfang der 1990er Jahre in der Softwareentwicklung übernommen und später auf Organisationen ausgeweitet.^[1]

Die persönlichen Beziehungen zwischen Mitarbeiten haben einen wesentlichen Einfluss auf die Effektivität eines Teams. Deshalb ist es wichtig eine Gemeinschaft des Vertrauens^[1] (englisch: community of trust) aufzubauen. Ohne Vertrauen zwischen den Mitarbeitern ist die Kommunikation eingeschränkt und Arbeitsabläufe müssen unabhängig bewältigt werden, was zu einem mehrfachen Aufwand führt.

Um die Gemeinschaft zu stärken, ist es wichtig, selbst Vertrauen in die anderen zu zeigen. Zugriffsbeschränkungen auf Informationen oder bürokratische Hürden bei Arbeitsabläufen können das Vertrauen beeinträchtigen, weshalb es wichtig ist Mitarbeitern über ihre eigenen Arbeitsabläufe die Kontrolle zu übergeben. Zudem benötigen die Mitarbeiter das Gefühl bei Entscheidungen einen Einfluss zu haben, da sie dadurch den Entscheidungen eines Entscheidungsträgers eher Vertrauen schenken. Auch fühlen sich die Mitarbeiter dadurch eher dazu verpflichtet Verantwortung für die übertragenen Aufgaben zu übernehmen. Dies ist deshalb wichtig, da einer anderen Person eine Verantwortung nicht gegeben werden kann (sie kann lediglich für ihre Taten Rechenschaftspflichtig sein), sondern die entsprechende Person die Verantwortung selbst übernehmen muss.

Bei der Ermächtigung^[1] (englisch: empowerment) wird bewusst auf die Kontrolle über untergebene Mitarbeiter verzichtet. Im Gegensatz zur Gemeinschaft des Vertrauens die auf einem (impliziten) bilateralen Abkommen beruht, geht die Ermächtigung unidirektional von einer übergeordneten Stelle aus. Das Ziel der Ermächtigung ist einerseits die Gemeinschaft des Vertrauens auszubauen und andererseits die übergeordneten Stellen durch einen Abbau von Bürokratie zu entlasten.

Eine Einschätzung des Zeitplans^[1] (englisch: size the schedule) wird durchgeführt, wenn das zu erstellende Produkt verstanden ist und die Projektgröße abgeschätzt werden kann.

Sowohl zu eng gefasste als auch zu groß angelegte Zeitpläne sind negativ zu bewerten. Zu eng gefasste Zeitpläne führen zu einer Überbeanspruchung der Mitarbeiter und zu einem Nichteinhalten von vereinbarten Terminen oder der Auslieferung eines minderwertigen Produktes. Dadurch werden auch nachfolgende Organisationseinheiten bzw. der Kunde beeinträchtigt. Zu groß angelegte Zeitpläne erhöhen die Kosten für den Kunden durch das Verschwenden von Zeit auf Nebensächlichkeiten. Beides führt zu verpassten Marktchancen.

Einer Beschleunigung von Arbeitsabläufen durch eine Erhöhung der Mitarbeiterzahl steht oft das Brooks’sche Gesetz und das Amdahlsche Gesetz gegenüber.

Die Mitarbeiter, die am Projekt arbeiten, sollten an der Einschätzung der Projektzeit – vor allem für den eigenen Arbeitsaufwand – mitarbeiten. Gute Einschätzungen können hierbei mit finanziellen Anreizen oder zusätzlicher Freizeit belohnt werden. Zudem sollten zwei Zeiteinschätzungen erstellt werden. Ein interner Zeitplan der in Absprache mit den Mitarbeitern erstellt wird, sowie ein externer, welcher mit dem Kunden vereinbart wird. Der externe Zeitplan sollte hierbei für ein mittelgroßes Projekt ein bis zwei Wochen bzw. zwei bis drei Monate über dem internen Zeitplan liegen, um eventuelle Überschreitungen abfangen zu können.

Comparable Work^[1] ist ein Muster, welches von Ward Cunningham wie folgt definiert wurde:

Siehe auch: Scrum.

Bei get on with it^[1] oder auch partial evaluation wird das Projekt bereits gestartet, obwohl noch nicht alle Anforderungen klar sind. Auch sind Abhängigkeiten im Detail oft nicht vorhersehbar und ergeben sich oft erst gegen Ende eines Projektverlaufs. Sobald die Richtung der Projektentwicklung abschätzbar ist, sollte daher mit den Dingen begonnen werden, für die eine hohe Zuversicht besteht. In dieser Phase kann bereits nach einem informellen Arbeitsplan gearbeitet werden und Prototypen können ausgearbeitet werden. Die Prototypen geben zugleich eine Einsicht wie die Struktur des fertigen Produkts aussehen kann und ermöglicht das Benennen von stable bases. Oft werden früh gestartete Projekte in Form von Skunk works ausgeführt. Diese werden am besten parallel zu anderen Geschäftsprozessen ausgeführt und nutzen dabei nicht ausgelastete Ressourcen.

Dieses Muster führt zu einer Beschleunigung der Fertigstellung des Produktes. Da jedoch Arbeit aufgrund von sich ändernden Anforderungen teilweise verworfen werden muss, sollte dieses Muster nicht eingesetzt werden, wenn es sich bei der für die Aufgabe benötigten Ressourcen um einen Engpass handelt, von dem auch andere Prozesse abhängig sind. Auch bedarf es einer guten Kommunikation mit nachfolgenden Einheiten mittels responsibilities engage und hallway chatter.

Siehe auch: Build prototypes.

Named stable bases^[1] sind definierte Schnittstellen zwischen Projektteilen. Diese werden benannt, wenn der Projektplan erstellt wurde und die Entwicklung des Produktes gestartet ist. Durch die definierten Schnittstellen erlangen die einzelnen Teams ein gemeinsames Verständnis für das zu entwickelnde Produkt und können auf ein definiertes Grundverhalten aufbauen. Die Menge der festgelegten und benannten Schnittstellen sollte dabei regelmäßig (z. B. wöchentlich) erweitert werden.

Die Entwicklung von Prototypen stellt einen Weg dar, eine Grundmenge an Schnittstellen zu definieren.

Siehe auch: Build prototypes, Programming Episodes.

Bei der inkrementellen Integration^[1][5] (englisch: incremental integration) werden die Teile eines zu entwickelnden Produktes regelmäßig zusammengefügt. Hierdurch werden größere Integrationsprobleme im späten Entwicklungsstadium des Produktes vermieden. Der Entwicklungsstand wird aufgezeichnet und zu einer neuen stable base, auf der die weitere Entwicklung des Produktes aufgebaut wird.

Als private world^[1][5] (private Welt) wird eine Arbeitsumgebung bezeichnet, über die ein einzelner Mitarbeiter alleine verfügt und alle nötigen Werkzeuge bereitstellt, die für die Tätigkeiten des entsprechenden Mitarbeiters nötig sind.

Private worlds sind häufig in der Softwareentwicklung anzutreffen, bei dem ein Programmierer neben der Integrierte Entwicklungsumgebung und dem Compiler auch über einen lokalen Snapshot der zu entwickelnden Software (d. h. einer named stable base) und den benötigten Programmbibliotheken verfügt, um die Software jederzeit erstellen und testen zu können.

Build Prototypes^[1][6] (baue Prototypen) ist ein Grundsatz, der den Bau eines Prototyps des zu erstellenden Produkts empfiehlt. Am Prototyp wird das Konzept des Produktes ersichtlich und es können mögliche Probleme des Produktes bereits frühzeitig erkannt und in der weiteren Produktentwicklung in Form von zu testenden Anforderungen berücksichtigt werden.

Durch den Prototyp kommen Änderungsanforderungen an das Produkt bereits frühzeitig, wodurch teure Fehlentwicklungen vermieden werden. Es ist hierbei ratsam den Kunden in die Entwicklung mit einzubeziehen und Feedback zum Prototyp einzuholen.

Take no small slips^[1] (etwa: mache keine kleinen Ausrutscher) ist anzuwenden, wenn ein Projekt hinter dem Zeitplan liegt. Wenn der geplante Fertigstellungstermin immer wieder um einige wenige Tage verschoben wird, sinkt das Vertrauen in den Projektplan. Daher sollte der Fertigstellungstermin gleich um einen größeren Bereich, ggf. mit eingeplanter Sicherheit, verschoben werden.^[7]

Der Projektstatus sollte etwa einmal wöchentlich überprüft und dabei der voraussichtliche Fertigstellungstermin aufgrund statistischer Daten erneut eingeschätzt werden.

Arbeitsteilung^[1][8] (englisch: work split) ist eine Methode um sich auf die wichtigen Tätigkeiten zu konzentrieren, indem das Team aufgeteilt wird und weniger wichtige Tätigkeiten in Untergruppen verlagert wird. Die wichtigen Tätigkeiten sollten hierbei nicht mehr als die Hälfte des Teams beschäftigen, während unwichtige Tätigkeiten entfallen können.

Eine Arbeitsteilung sollte angewandt werden, wenn wichtige Ziele hinter dem Zeitplan liegen, weil das Team mit der Erreichung weniger wichtiger Ziele beschäftigt ist.

Wenn für jede Arbeitsgruppe in einem Projekt der voraussichtliche Fertigstellungstermin berechnet wird, so wird die Differenz zwischen dem voraussichtlichen Fertigstellungstermin und dem geplanten Fertigstellungstermin als completion headroom^[1][8] (wörtlich: Fertigstellungs-Kopffreiheit) bezeichnet.

Diese Differenz sollte mindestens einmal pro Woche neu berechnet werden, um mit geeigneten Maßnahmen durch das Management gegensteuern zu können, falls die Differenz zu stark ansteigen sollte. Hierbei eignet sich unter anderem eine Neupriorisierung und anschließende Aufteilung der Tätigkeiten sowie ggf. das Verschieben des geplanten Fertigstellungstermins.

Implizite Anforderungen^[1] (implied requirements) sind Anforderungen, die der Kunde hat, ohne dass diese explizit aufgelistet werden. Implizite Anforderungen entstehen, indem die einzelnen Funktionen des zu entwickelnden Produktes aufgeteilt und benannt werden.

Speziell in der Softwareentwicklung können implizite Anforderungen Sicherheit, Performance, Logging, Backup-Strategien, Fehlerbehandlungen, Wartbarkeit, Anpassbarkeit an veränderte Geschäftsprozesse usw. beinhalten.

Eine Warteschlange^[1] (englisch: work queue) ist eine priorisierte Liste implizierter Anforderungen, also noch zu tätigenden Arbeiten. Die Reihenfolge der Tätigkeiten ändert sich, wenn sich die Anforderungen ändern.

Eine Warteschlange entspricht dem Backlog in Scrum.^[8][9][10]

Eine Warteschlange ist deutlich einfacher zu handhaben und übersichtlicher als ein traditioneller Netzplan aus Gantt-Diagrammen, der schwerer zu erstellen ist, die beteiligten Personen mit Details überfordert und zudem großteils verworfen werden muss, falls sich die Anforderungen ändern.

Ein Recommitment Meeting^[1][8] ist ein Treffen des Projektmanagements und führender Entwickler eines Projekts, wenn implizite Anforderungen nicht innerhalb des vorgesehenen Zeitplans eingehalten werden können. Hierbei gilt es zu klären, wie eine benötigte Funktionalität mit dem kleinstmöglichen Aufwand zu realisieren ist. Anschließend wird der Zeitplan mit Hilfe eines Work-Queue-Berichts aktualisiert.

Ein Informal Labor Plan^[1] ist ein öffentlicher Richtzeitplan. Individuen oder Kleingruppen erstellen eigene kurzzeitige Zeitpläne, um die Arbeit so einzuteilen, dass der vom Management aufgestellte Zeitplan bestmöglich eingehalten werden kann. Der Projektmanager überwacht den Zeitplan lediglich mit einer groben Auflösung, während sich die Mitarbeiter selbstständig um die Details kümmern und sich untereinander zur Einhaltung ihres Zeitplans verpflichten.

Bei einer Development-Episode^[1] kümmern sich alle Mitarbeiter eines Teams um dasselbe Problem. Hierdurch werden die unterschiedlichen Stärken der einzelnen Personen kombiniert, um eine bestmögliche Lösung zu erzielen. Als Nebeneffekt wird Wissen von Spezialisten auf die anderen Mitarbeiter übertragen, wobei auch das Ansehen der Spezialisten innerhalb der Gruppe steigt.

Developer Controls Process^[1] ist eine Informationsstruktur innerhalb eines Unternehmens, bei dem die Entwickler eines Produkts bidirektional mit allen beteiligten Stakeholdern kommunizieren können. Der Informationsfluss umfasst hierbei etwa Ideen, Anforderungserhebung, Testen, Auslieferung und Vermarktung der jeweiligen Produkte.

Hierbei gilt es jedoch darauf zu achten, Entwickler nicht mit Aufgaben zu überlasten. Dies kann durch Filterung des Informationsflusses, Aufgabenverteilung innerhalb des Entwickler-Teams, sowie Delegierung erfolgen.

Work flows inward^[1] ist eine Informationsstruktur, bei der Arbeit von außerhalb des Unternehmens direkt zur passenden Rolle fließt. Um dies zu ermöglichen, bedarf es klar definierter Rollen und gefestigter Prozessabläufe.

Kennzeichnend ist hierbei, dass das Management nur gering am Informationsfluss beteiligt ist und keine zusätzliche Arbeit generiert. Zudem ist darauf zu achten, dass der Informationsfluss von einem Kunden zum jeweiligen Mitarbeiter einen informellen und keinen weisenden Character besitzt.

Eine programming episode^[1] ist es, wenn von einer Software jene Programmabschnitte in Code festgeschrieben werden, zu denen es eine klare Entscheidung zum gewünschten Verhalten gibt. Programmabschnitte zu denen keine klare Entscheidung möglich ist, werden nach einem Review der existierenden Codebasis zu einem späteren Zeitpunkt getroffen und in einer nachgelagerten programming episode implementiert.

Someone always makes progress^[1] ist ein Managementprinzip, bei dem sich ein Teil des Teams um die Kernaufgabe der Erreichung eines bestimmten Ziels kümmert, während sich ein anderer Teil des Teams um Aufgaben kümmert, welche von der Kernaufgabe ablenken.

Weitere Projektmanagementmuster sind team per task, sacrifice one person, mercenary analyst, interrupts unjam blocking, don’t interrupt an interrupt, day care und surrogate customer.^[1]

Bei size the organisation^[1] geht es darum, die benötigte Größe eines Teams für ein Projekt, bzw. die benötigte Größe des Unternehmens als Summe aller Teams, einschätzen zu können. Bei großen Projekten (bei Software > 25 kSLOC) ist es selten, dass das Projekt innerhalb der geplanten Zeit und Kosten fertiggestellt wird. Die Gründe hierbei sind vielfältig:

Wenn das Projektteam zu groß ist, werden meist die Kosten so hoch, dass sich das Investment nicht lohnt. Bei einem zu großen Projektteam geht der gemeinsame Überblick über das Produkt verloren. Zu große Teams sind bei kleinen Änderungen weniger anpassungsfähig und brachen länger um zu reagieren. Bei einem zu kleinen Team kann die Zeit nicht eingehalten werden. Ist das Projektteam zu klein, fehlt die kritische Masse und damit das Moment um das Projekt zu verwirklichen. Wird das Projektteam während des späten Projektverlaufs vergrößert, tritt das Brookssche Gesetz ein.

Bei Softwareprojekten mit einem gut ausgewählten und unterstütztem Projektteam von 10 Personen lassen sich Projekte der folgenden Größenordnung bewältigen:^[1] 60 kSLOC in 8 Monaten, 200 kSLOC in 15 Monaten und 1500 kSLOC in 31 Monaten. Hierbei kann jede Rolle im Team mit 3 bis 7 anderen Rollen kommunizieren, wodurch auch eine Kommunikation innerhalb verschiedener Abteilungen in großen Unternehmen gewährleistet ist.

Die beste Teamgröße variiert mit dem Projekt, sollte jedoch nicht weniger als 3 Personen und nicht mehr als 12 Personen ausmachen. Größere Teams sollten aufgeteilt werden, wobei aber auch die Aufteilung durch eine Veränderung der Arbeitsabläufe zu einer Verringerung der Produktivität führen kann.

Ein surrogate customer^[1] (Ersatzkunde) wird eingesetzt, wenn der Kunde für Feedback zum Produkt benötigt wird, der Kunde jedoch nicht zur Verfügung steht.

Die Problematik, dass der Kunde nicht zur Verfügung steht, kann aus verschiedenen Gründen entstehen. Etwa wenn das Produkt die Kunden erst erzeugen soll, der Kunde zu beschäftigt ist, der Kontakt mit dem Kunden zu einem gegebenen Zeitpunkt unangebracht ist oder eine fehlerhafte Unternehmenspolitik die Entwickler des Produktes vom Kunden trennt. Um den Kunden zu ersetzen, sollte eine Person gewählt werden, die nicht an der Entwicklung des Produktes beteiligt (d. h. nicht voreingenommen) ist. Jedoch gilt zu beachten, dass ein Ersatzkunde den eigentlichen Kunden nicht völlig ersetzen kann und nur eine zeitlich begrenzte Lösung darstellt.

• BS 15000
• ITIL
• ISO/IEC 20000
• Microsoft Operations Framework (MOF)
• COBIT
• eTOM

• Alistair Cockburn

• James O. Coplien, Heil B. Harrison: Organizational Patterns of Agile Software Development. Pearson, Prentice Hall, Upper Saddle River 2004, ISBN 978-0-13-146740-8, S. 432. 
• Linda Rising: The Patterns Almanac 2000. Addison-Wesley, Amsterdam 2000, ISBN 978-0-201-61567-8, S. 448. 
• Steve Berczuk, Brad Appleton: Software Configuration Management Patterns: Effective Teamwork and Practical Integration. Addison-Wesley, 2002, ISBN 978-0-201-74117-9, S. 208. 

• Ward Cunningham: Portland Pattern Repository’s Wiki. Cunningham & Cunningham, Inc., abgerufen am 10. März 2013 (englisch). 
• Brian Foote: Pattern Labyrinth. Abgerufen am 10. März 2013 (englisch). 

1. ↑ ^{a b c d e f g h i j k l m n o p q r s t u v w x y z aa} James O. Coplien, Heil B. Harrison: Organizational Patterns of Agile Software Development. Pearson, Prentice Hall, Upper Saddle River 2004, ISBN 978-0-13-146740-8, S. 432. 
2. ↑ Christopher Alexander: A Pattern Language: Towns, Buildings, Construction. Oxford University Press, New York 1977, ISBN 978-0-19-501919-3, S. 1171. 
3. ↑ Christopher Alexander: The Timeless Way of Building. Oxford University Press, 1979, ISBN 978-0-19-502402-9, S. 568. 
4. ↑ John Vlissides, Norman Kerth, James Coplien: Pattern Languages of Program Design (= Pattern Languages of Program Design. Band 2). 1. Auflage. Addison-Wesley, 1996, ISBN 978-0-201-89527-8, Demo Prep: A Pattern Language for the Preparation of Software Demonstrations, S. 624 (englisch, c2.com [abgerufen am 7. März 2013]). 
5. ↑ ^{a b} Stephen Berczuk, Brad Appleton: Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley, Amsterdam 2002, ISBN 978-0-201-74117-9. 
6. ↑ Ian Graham: Specification in Expert Systems and Conventional IT Projects. In: Computing and Control Engineering Journal 2. Band 2, 1991, S. 82–89. 
7. ↑ Frederick Brooks: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995, ISBN 978-0-201-83595-3, S. 272. 
8. ↑ ^{a b c d} Ward Cunningham, John Vlissides, Norman Kerth, James Coplien: Pattern Languages of Program Design (= Pattern Languages of Program Design. Band 2). Addison-Wesley, Amsterdam 1996, ISBN 978-0-201-89527-8, Episodes: A Pattern Language of Competive Development. 
9. ↑ Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherlan: Scrum: A Pattern Language for Hyperproductive Software Development. (PDF; 118 kB) Abgerufen am 28. März 2013 (englisch). 
10. ↑ Linda Rising: The Patterns Almanac 2000. Addison-Wesley, Amsterdam 2000, ISBN 978-0-201-61567-8, S. 448.