Dieser Ansatz hat den Vorteile, dass der gesamte Entstehungsprozess notiert wird. Dadurch wird es möglich zu erkennen wann und wer zu dieser Entscheidung beigetragen hat. Außerdem ist erkennbar welche Alternativen in Betracht gezogen wurden und entweder aus bestimmten Gründen zurückgewiesen oder einfach nicht ausgewählt wurden. Dies kann vorkommen wenn eine ebenfalls akzeptable Lösung als besser empfunden wurde. Zu einem späteren Zeitpunkt kann so geprüft werden ob diese Entscheidung noch aktuell ist. Bei einer notwendigen Än-derung ist direkt ersichtlich welche weiteren Entscheidungen betroffen sind und eventuell ebenfalls angepasst werden müssen. Die Durchführung dieser Dokumentation kann durch die unterschiedlichen Grafiken schnell aufwendig werden. Es muss ein Prozess etabliert werden der annähernd zeitgleich beim Treffen der Entscheidungen die Informationen sammelt. Eine anschließende Dokumentation wird in der Regel zu ungenau.
Performance des Zugriffes). Diese können auf gleiche Weise, wie Features verwendet und aufgeschrieben werden.
Anschließend werden die Features auf Verbindungen untersucht. Dabei wird hauptsächlich darauf geachtet ob diese Verfeinerungen oder Abhängigkeiten voneinander sind. Die Bezie-hungen können in Form eines Baums dargestellt werden (Feature Baum). Die Wurzel stellt die Anwendung selbst dar. Bei einer Planung mit mehreren Releases werden die Features gruppiert.
Dies geschieht mithilfe desOlympischen Feature Pools. Es werdenSchwimmbahneneingezogen und die Features nach Priorität und Realisierungsreihenfolge einsortiert. Der zuvor erzeugte Baum kann die Gruppierung unterstützen, weil er vorhandene Abhängigkeiten darstellt. Die Abhängigkeiten müssen der Reihe nach Implementiert werden. Die Gruppierung führt eine sichtbare Priorisierung ein.
Durch die unterschiedlichen Darstellungen wurde aufgenommen was entwickelt werden soll (Feature Pool), wann dies entwickelt werden soll (Olympischer Feature Pool) und wie dies entwickelt werden soll (Feature Baum, aufgrund der Abhängigkeiten).
Für die Entwicklung innerhalb des Scrum Zyklus werden die Features anschließend in User Stories oder Epics umgewandelt. Diese befüllen das Product Backlog. Epics müssen vor der Entwicklung in User Stories umgewandelt werden. Die Umwandlung und die Bedingungen für User Stories werden hier nicht beschrieben.
4.8.2 Entwicklung der Softwarearchitektur
Eines der agilen Prinzipien sagt aus, dass zu jeder Zeit Änderungen willkommen sein sollen.
Die gesamte Entwicklung ist darauf ausgerichtet schnell auf Änderungen, z.B. durch neue Anforderungen, reagieren zu können. Dies ist wichtig, weil dadurch das Ziel am Anfang der Entwicklung nicht vollständig verstanden und definiert sein muss. Eine Architektur ist in den meisten Fällen allerdings starr und schwerfällig gegenüber Anpassungen die große Teile der Anwendung betreffen. Trotz der Schwierigkeit ist es wichtig, dass die Architektur bei jeder Iteration an die aktuellen Bedürfnisse angepasst werden kann. Im Folgenden wird erläutert, wie eine Architektur mit Beachtung der agilen Prinzipien entwickelt werden kann.
Plastic Partial Components
DiePlastic Partial Components(PPC, formbare unvollständige Komponenten) bieten die Mög-lichkeit eine flexible Architektur zu entwickeln. Dieses Konzept wurde in unterschiedlichen
Arbeiten eingeführt [45,67,68]. Eine PPC ist eine spezialisierte Komponente, welche alle Eigen-schaften und das Verhalten anderer Komponente erbt. Ausschließlich Basis-Funktionalitäten, welche nicht ererbt werden können, werden innerhalb der PPC realisiert. PPCs können durch Variantsangepasst werden. Variants stellen die Realisierung von Features, die nicht relevant genug sind um eine Hauptkomponente der Anwendung zu sein, dar. Sie fügen der Anwendung eine zusätzliche Funktionalität hinzu. Es ist denkbar, dass diese im Laufe der Zeit entfernt oder an weiteren Stellen benötigt werden. Kenntnisse wie sie gebunden sind besitzen sie nicht.
Dadurch wird es möglich ähnliche Komponenten wiederzuverwenden indem nur einzelne Bestandteile ausgetauscht werden. Die Verbindung von PPCs und Variants geschieht durch Variability Points. Sie beinhalten die Definition der Verbindung und dessen Verwendung.
Abbildung 4.3: Plastic Partial Components [68]
In Abbildung4.3ist ein Ausschnitt eines Diagramms zu sehen, bei dem die zuvor beschriebenen Bestandteile vorhanden sind.DataLoader undDataQuerysind hier PPCs. Beide besitzen den Variability Point fürclustering, welcher durch diehadoopMap/Reduce Variantrealisiert wird.
PPCs sind in erster Linie für die Entwicklung von mehreren nicht identischen aber sehr ähnlichen Systemen gedacht. Bei diesen können einzelne Teile deaktiviert oder ausgetauscht werden. Diese Art der Entwicklung wird auchProduct Line Engineeringgenannt. Eine schnelle Möglichkeit, um auf Änderungswünsche reagieren zu können, ist damit nicht gewährleistet.
Diese Variabilität wird häufig bei Service-basierten Anwendungen eingesetzt. Diese können weitestgehend beliebig zusammengesetzt werden. [45]
Dieser Ansatz erfordert allerdings eine gewisse Vorausplanung, um mögliche Variability Points zu identifizieren. Um diese Up-Front Planung zu umgehen muss diese Lösung mit einem agilen Vorgehen vereint werden. Dies erhöht die Flexibilität der Anwendung. Auf Änderungswünsche kann somit besser reagiert werden.
Aus dem Ansatz der PPCs wurde das Konzept derWorking Architectureentwickelt. Dieses hat das Ziel den Prozess agil zu gestalten. Jede Komponente der Architektur wird als PPC realisiert. Die PPCs werden nach Kundenwunsch iterativ erweitert und verändert. Aufwendige Refaktorisierung sollen durch regelmäßige kleine Anpassungen verhindert werden. Bei der Entwicklung wird initial eine Basisarchitektur entworfen. Die Entwicklung findet anhand der bekannten User Stories statt. Pro Iteration (in Scrum Sprint) werden User Stories ausge-wählt. Nach der Auswahl werden die PPCs, Variants und Variability Points identifiziert und anschließend realisiert. Die variable Architektur wird schrittweise erweitert. [56]
4.8.3 Integration in Scrum
Scrum ist ein Framework und darf nach belieben an die Bedürfnisse angepasst werden. Im Folgenden wird eine Anpassung von Pérez u.a. [68] vorgestellt. Diese integriert die zuvor vorgestellten Themen in das Vorgehen. Das vollständige Vorgehen ist in Abbildung4.4zu sehen. Bei dieser Variante von Scrum wird wie üblich mit dem Product Backlog gearbeitet.
Dieses wird durch die zuvor beschriebene Methode zur Ermittlung der Features gefüllt. Hier kommen der vorgestellte Feature Pool, Feature Tree und Feature Olympic Pool zum Einsatz (siehe Kapitel4.8.1). Die entwickelten Features werden in Stories umgewandelt und in das Product Backlog übertragen. Wie bei Scrum üblich beinhalten diese die Akzeptanzkriterien aber keine technischen Details.
Vor dem Beginn eines Sprint-Zyklus wird das Backlog-Grooming (bzw. Refinement zum Prio-risieren, Teilen, Schätzen u.s.w. der Stories) durchgeführt. Dies ist keine Erneuerung und ist bereits in Scrum vorhanden. Die Stories werden zu diesem Zeitpunkt genauer betrachtet. Da tiefer in das Backlog gesehen wird bewirkt dies, dass mögliche zukünftige technische Heraus-forderungen erkannt werden können. Neu ist der Punkt desSprint Agile Architecting. Dieser
Abbildung 4.4: Integration einer Architekturentwicklung in Scrum [68]
findet im Meeting zum Backlog Grooming statt. Für die ausgewählten Stories werden die PPCs, Variants und Variability Points identifiziert. Hierdurch wird festgestellt ob die Working Architecture aktualisiert werden muss. Beide Teile dieses Meetings finden zeitgleich statt. Eine weitere Aufteilung in Abschnitte ist nicht vorgesehen. Dies ist sinnvoll, da unter anderem für ein zuverlässiges Schätzen der Aufwände erforderlich ist zu wissen, wie diese technisch realisiert werden sollen. Es fällt auf, dass die Personenrolle des Architekten hinzugekommen ist.
Mehrere Architekten können zeitgleich Teil des Teams sein. Die Rollen des Architekten wurde zuvor in4.6vorgestellt. Der anschließende Schritt ist das Sprint Planning Meeting. Dies stammt ebenfalls aus dem originalen Scrum und dient zur Auswahl der Stories für den nächsten Sprint.
Am Ende des Sprints steht dieWorking Architectureund dasWorking Produktzur Auslieferung an den Kunden bereit. Das Daily Meeting, das Sprint-Review und die Retrospektive werden wie zuvor übernommen.