Serie: Wie tötet man die Architekturabteilung? Teil 1

Teil 1: Der Mitarbeiter, der früher als Architekt bekannt war

Jedes System hat eine Architektur, aber sie wird nicht unbedingt von einem Architekten entworfen. Dieser Beitrag skizziert ein Referenzmodell für agile Organisationen ohne die Rolle des Architekten. In den nächsten Beiträgen dieser Serie werden wir Ihnen Best Practices vorstellen, wie Sie die Architektur in diesem agilen Referenzmodell ohne Architekten verbessern können.

Klassische IT-Architekten passen nicht in agile Organisationen

Agile Organisationen scheinen für klassische Architekten eine feindliche Umgebung zu sein. Die DONE-Teams werden ermutigt, das Einfachste zu tun, was möglicherweise funktionieren könnte(DTSTTCPW) und Big Design Up Front(BDUF) zu vermeiden. Außerdem werden die Teams dazu ermutigt, sich selbst zu organisieren und ihre eigenen Entscheidungen zu treffen. Mit einer klassischen architektonischen Denkweise kann man sich in einer agilen Organisation leicht übergangen fühlen. Wenn Sie ständig Projektstart-Architekturdokumente schreiben, scheint es, als würden diese Dokumente nie gelesen werden. Oder noch schlimmer: Sie bekommen nie die Gelegenheit, das Dokument richtig zu schreiben, weil das DONE-Team bereits mit der Entwicklung begonnen hat.

Architektur bleibt wichtig

Dieser Blogbeitrag ist der Beginn einer Reihe von Best Practices für die Architektur in einer agilen Organisation. In dieser neuen Organisation ist es gut möglich, dass niemand mehr den Titel Architekt trägt. Dennoch bleibt die Architektur des Systems von entscheidender Bedeutung für Ihren langfristigen Erfolg. Der Prozess zur Erstellung und Pflege der Architektur in einer agilen Organisation ist anders! Die Architektur wird zu einer Teamaufgabe. Wie können Sie also sicherstellen, dass die Teams die richtigen Entscheidungen treffen?

Einführung eines agilen Organisationsmodells

In diesem ersten Beitrag wird ein Referenzmodell für eine typische agile Organisation vorgestellt. Die folgenden Teile dieser Serie werden auf diesem Referenzmodell aufbauen und die technischen Rollen in allen Phasen des Software-Lebenszyklus vorstellen.

Es FERTIG machen

Agile ist ein Sammelbegriff für eine Reihe von Prozessen: SCRUM, eXtreme Programming, RUP, DSDM und möglicherweise andere. Der bekannteste agile Prozess ist SCRUM. Diese Serie geht von einem SCRUM-Prozess aus, der um Prinzipien und Praktiken aus der eXtreme Programming-Gemeinschaft erweitert wurde. Abbildung 1 gibt einen Überblick über den SCRUM-Prozess. In der To Do-Spalte befindet sich ein Backlog mit User Stories, die in Sprints von 2-3 Wochen iterativ in Potentially Shippable Software (DONE) umgesetzt werden. Während der Sprints gibt es tägliche Standup-Meetings, die die Kommunikation im Team über Fortschritte und Hindernisse erleichtern.

SCRUM ist ein leichtgewichtiger Prozess. Er bietet eine hilfreiche Struktur, Denkweise und bewährte Verfahren für ein einzelnes Entwicklungsteam. Es hilft Ihnen jedoch nicht bei der Erstellung von User Stories, der Verwaltung der Architektur und der Skalierung über mehrere Teams hinweg. Es sagt Ihnen übrigens auch nicht, wie man ein Käseomelett backt. In einem größeren Unternehmen benötigen Sie wahrscheinlich User Stories, eine Architektur und mehrere Teams. Und wahrscheinlich brauchen Sie irgendwann auch Käse-Omeletts. Anstatt also zu einem schwergewichtigen Prozess zu wechseln, der all dies abdeckt, sollten Sie SCRUM um zusätzliche Prozesse und Best Practices für die anstehenden Herausforderungen erweitern. Sie können die Ergänzungen auswählen, die zu Ihrer Organisation passen.

BEREITSCHAFTEN

Um User Stories zu schreiben, bevor ein Sprint beginnt, können Sie Iterationen einführen , die den SCRUM-Sprints vorausgehen, um Stories READY zu machen. Abbildung 2 veranschaulicht das Modell einer agilen Organisation und die Beziehung zwischen dem READY-Team und dem DONE-Team.

In einem READY-Team arbeiten Product Owner mit Stakeholdern, Analysten und Beratern zusammen, um spezifische User Stories für den nächsten Sprint zu schreiben. Ein Product Owner kann mehrere DONE-Teams bedienen. In einer größeren Organisation kann es jedoch auch mehrere READY-Teams geben. Für eine gute Kommunikation ist es wichtig, teamübergreifend zu kommunizieren. Ein Scrum of Scrums ist eine der Lösungen, um diese Art der Kommunikation zu erleichtern.

Sie bekommen es PRIORITÄT

Es braucht Zeit, um gute User Stories zu schreiben. Wenn das READY-Team nicht in der Lage ist, Stories vor dem nächsten Sprint zu liefern, kann ein DONE-Team nicht rechtzeitig mit der Entwicklung beginnen. Woher wissen Sie, welche Stories Sie zuerst schreiben müssen? Dazu brauchen Sie ein gutes Verständnis der Prioritäten. Die Prioritäten hängen von den Zielen Ihres Unternehmens ab. In den meisten Unternehmen ist die Nachfrage nach neuen Softwarefunktionen größer als die Kapazität der Mitarbeiter zur Realisierung der Software. Es müssen also Entscheidungen getroffen werden.Das agile Referenz-Organisationsmodell kennt einen Chief Product Owner, der über die Prioritäten neuer Initiativen entscheidet, bevor die User Stories geschrieben werden.Um über Prioritäten zu entscheiden, noch bevor die endgültigen User Stories geschrieben werden, brauchen Sie eine Analyse und Kommunikation auf hohem Niveau. Zu diesem Zweck gibt es die Phase Getting it PRIORITIZED.

Es in die PRODUKTION bringen

Die einzige wertvolle Software ist Software in Produktion. Traditionell zielt SCRUM darauf ab, potenziell auslieferungsfähige Software zu liefern. Im Idealfall geht das DONE-Team noch einen Schritt weiter. Die Definition von DONE sollte lauten: DONE = LIVE.Irgendwann gibt es einen Übergang der Software von der Entwicklung in die Produktion. Und in der Produktion muss die Software gewartet werden. In einer agilen Organisation muss der Übergang so reibungslos wie möglich erfolgen. Und die Übergänge müssen so oft wie möglich erfolgen, denn je öfter Sie das tun, desto einfacher wird es. Bewährte Vorgehensweisen zur Unterstützung dieses Prozesses werden in der Phase Einführung in die PRODUKTION beschrieben.

Also, wo ist der Architekt?

In den vier Phasen haben Sie Product Owner, Chief Product Owner, Entwickler und Operatoren getroffen. Aber in keiner der Phasen wurde ein Architekt erwähnt. Wo ist also der Architekt? Erinnern Sie sich an die Einleitung zu diesem Blogbeitrag? Dort hieß es: "In dieser neuen Organisation gibt es eine gute Chance, dass niemand mehr den Titel Architekt trägt." Die gute Nachricht ist, dass in der Einleitung auch gesagt wurde: "Jedes System hat eine Architektur, aber es wird nicht unbedingt von einem Architekten entworfen."

Bleiben Sie dran für die nächste Folge von How to Kill the Architecture Department

In den nächsten Beiträgen werden die neuen Rollen für The Employee Formerly Known As Architect in der agilen Organisation erläutert. Jede Phase hat ihre eigene Architektenrolle. Unten sehen Sie einen kleinen Vorgeschmack auf eine der neuen Rollen. Lesen Sie die folgenden Teile dieser Serie weiter und erfahren Sie, was die anderen Rollen sind.

Was sind die Aufgaben eines Technical Product Owner? Und wie lassen sich diese mit den Aufgaben eines Architekten in einem klassischen Unternehmen vergleichen? Bitte teilen Sie uns Ihre Meinung mit, indem Sie unten kommentieren! Fortsetzung folgt in zwei Wochen!

Mehr aus dieser Serie

• Wie man die Architekturabteilung tötet - Teil 1
• Wie man die Architekturabteilung tötet - Teil 2
• Wie man die Architekturabteilung tötet - Teil 3
• Wie man die Architekturabteilung tötet - Teil 4
• Wie man die Architekturabteilung tötet - Teil 5
• Wie man die Architekturabteilung tötet - Teil 6
• Wie man die Architekturabteilung tötet - Teil 7