Ein agiles Projekt mit dem RedSpark Framework von A bis Z

Agil mit Stil
Kommentare

Konzeption
Das Konzept besteht für einfache CMS-Seiten häufig aus einem Navigationskonzept sowie einer Sitemap. Speziell für individuelle Entwicklungen ist aber sehr viel mehr nötig. Unserer Erfahrung

Konzeption

Das Konzept besteht für einfache CMS-Seiten häufig aus einem Navigationskonzept sowie einer Sitemap. Speziell für individuelle Entwicklungen ist aber sehr viel mehr nötig. Unserer Erfahrung nach ist eine ausführliche Konzeptphase daher für die spätere Umsetzung unerlässlich, da hier – genau wie später noch einmal bei Abstimmung der Unit- und Akzeptanztests – viele Fragen aufgeworfen und entschieden werden müssen. Auch für die Konzeptionsphase kann im Übrigen die Aufteilung der Anwendung in Apps von Vorteil sein. Bei häufiger Verwendung von Apps lassen sich so gegebenenfalls konzeptionelle Gedanken und Formulierungen wiederverwenden und um gemachte Erfahrungen aus vorherigen Projekten ergänzen. Zudem lassen sich die Konzeptabschnitte häufig nach Apps aufgeteilt gesondert behandeln. So kann der Kunde schon einmal das CMS-Konzept freigeben, während der Blog noch weiter konzipiert wird.

Design

Beim Thema Design ist zunächst zu sagen, dass das RedSpark-System diesbezüglich keinerlei Vorgaben oder Einschränkungen unterliegt. Bislang war jedes Layout umsetzbar. Zur Not kann für sehr aufwändige Animationen auf ein Flash Frontend mit RedSpark als Backend zurückgegriffen werden. Im Bereich Design ist es aber dennoch so, dass sich natürlich Prozesse von Projekt zu Projekt wiederholen. Neben den bereits im RedSparkCore oder über den RedSpark Store verfügbaren Layouts verfahren wir im Hause Kuborgh häufig nach unserem so genannten Style-Guide-Prozess, bei dem es kurz gesagt um den Versuch einer Annährung von Design und Technik geht. Im Rahmen des Style-Guide-Prozesses werden dabei circa zehn Standardansichten (z. B. Listen, Boxen, Buttons) definiert, die jeweils komplett gestaltet und vermessen werden. Alle später nicht mit Elementen der Standardansichten abbildbaren Seitenbereiche werden zusätzlich als „Specials“ behandelt und einzeln kalkuliert und umgesetzt.

Diese Form der Abstraktion der Layouterstellung bietet gleich mehrere Vorteile. Die Designerstellung und -umsetzung wird viel besser kalkulierbar. Für jede Standardansicht lassen sich die zu erwartenden Fragen und Probleme bereits im Vorwege klären. Zum Beispiel gibt es hinsichtlich Schriften und Buttons nur eine begrenzte Anzahl technischer Möglichkeiten. Bei einer Diskussion von Für und Wider bereits im Vorfeld lassen sich Missverständnisse (z. B. hinsichtlich der Nutzung von Nichtstandardschriften) häufig vermeiden und der Kunde kann in die Entscheidung mit einbezogen werden.

Die Layouterstellung kann dabei zudem durch das System unterstützt werden. In der App RedSparkDevelop befindet sich das Modul Dev [5]. Dieses bietet eine Umsetzung der angesprochenen Standardansichten. Durch die Möglichkeit, in RedSpark in jeder individuellen Kunden-App beliebige Bestandteile verlinkter Apps durch Objektorientierung zu überschreiben [6], kann die Auswahl der Standardsichten sowie die eventuell nötigen Specials genau festgelegt werden. Für Designer, Entwickler und nicht zuletzt Kunden steht so binnen kürzester Zeit ein System zur Verfügung, in dem nach und nach alle Elemente des Layouts entstehen. Ein besonderer Vorteil ist zudem, dass die Standardformulare, -listen etc. bereits im Browser funktionsfähig sind. Fehlermeldungen erscheinen so beispielsweise erst nach dem Absenden des Formulars. Außerdem können die Längen der „Lorem-Ipsum“-Textblöcke variiert werden, was das Verhalten des Layouts bei unerwartet kurzen und lagen Texten simuliert – ein Vorgang, der leider sonst häufig erst bei Pflege der Textdokumente zur Sprache kommt, da ist es aber meist schon fast zu spät. Während der Umsetzung dient ein komplett umgesetztes Layout im Dev-Modul unserer Erfahrung nach immer wieder als zentraler Ausgangspunkt für HTML Snippets, an dem sich alle Entwickler das entsprechende Markup für Buttons oder ähnliches herauskopieren können.

Agile Prinzipien

Vor der Beschreibung des Umsetzungsprozesses sollen einige Stichworte aus dem Umfeld der agilen Prinzipien und Prozesse angerissen werden, die unserer Erfahrung nach durch das RedSpark Framework in besonderem Maße unterstützt werden:

  • Rapid Prototyping: Unterstützt durch schnelle Einrichtung der App und Parallelisierung der Arbeitsprozesse.
  • Product Backlog, Feature-driven Development: Unterstützt durch Einsatz der Featureliste.
  • Unit Tests/Acceptance Tests: Unterstützt durch einfach zu erstellende Unit Tests im RedSpark Framework.
  • Sprints und Refaktorierung: Unterstützt durch Snapshots, Versionierung und Subversion Branches.
  • Sprint-Review: Effektiv durch einfache Verallgemeinerung gefundener Lösungen.
  • Wiederverwendung vorhandener Ressourcen: Unterstützt durch Verwendung von Apps.
  • Flexibilität, Zweckmäßigkeit und Kundennähe: Durch individuelle Projekt-Apps und die Möglichkeit, alles pro Kunde erweitern und verfeinern zu können.

All diese Prinzipien unterstützt das RedSpark Framework in besonderem Maße und ist damit sehr gut für den Einsatz in Teams geeignet, die z. B. Scrum, Feature-driven Development oder eXtreme Programming als agilen Prozess gewählt haben. Nun aber hinein in die Betrachtung der Vorgehensweise der eigentlichen Projektumsetzung des Projekts.

Umsetzung – Vorbereitungsphase

Im Sinne des Rapid-Prototyping-Ansatzes gilt es, so schnell wie möglich Projektbeteiligte in die Lage zu versetzen, mit der produktiven Arbeit zu beginnen und zugleich dem Auftraggeber ein Gefühl zu vermitteln, was ihn erwartet. Das RedSpark Framework unterstützt diesen Prozess in erster Linie durch Skripte, die einem Entwickler nach Angabe weniger Parameter nicht nur die App selbst, sondern auch neue Module, neue Models und nicht zuletzt die Actions nach bekanntem CRUD-Ansatz (Create-Read-Update-Delete, erweiterbar durch Listen und Feeds) inklusive komplett vorbereiteter Unit Tests generieren. Eine genaue Beschreibung der Nutzung dieser Skripte sind sowohl im RedSpark-Artikel im PHP Magazin 6.10 [6] als auch auf der Webseite unter [7] zu finden. Nach Erzeugung der Dateien für eine erste Rumpf-App sollten diese direkt in den Trunk eines entsprechenden Subversion Repositories geladen, also „committed“ werden, um eine Zusammenarbeit der verschiedenen Projektbeteiligten zu ermöglichen. Alle können die App aus dem Subversion Repository in eine lokale Entwicklungsumgebung „auschecken“, die Datenbank wird beim ersten Booten der App automatisch initialisiert und jeder kann weitestgehend unabhängig mit der Arbeit beginnen. Folgende Aufgaben können direkt begonnen werden:

  • Grafik: Slicen der Dateien für die HTML-Umsetzung
  • HTML: Umsetzung der Layouts direkt als RedSpark Template
  • Projektmanager: Abstimmung mit dem Kunden sowie Einrichtung von CMS-Vorlagen
  • Entwickler: Umsetzung der Individualentwicklungen sowie Erstellung erster Tests

Das RedSpark Framework bietet durch den konsequenten Einsatz des Subversion Repositories Grafikern und HTMLern die Möglichkeit, das Template zunächst komplett unabhängig von der Entwicklung und zugleich die Entwicklung ihrer Aufgaben unabhängig von der CMS-Einrichtung durchführen zu können, obwohl alles an einer zentralen Stelle abgelegt und für alle zugreifbar ist (Kasten: „Versionierung“).

Wie bereits oben angedeutet, lässt sich die anfangs erzeugte Featureliste im Sinne der agilen Entwicklung z. B. für Scrum als Product Backlog oder für den Feature-driven-Development-Prozess direkt als Featureliste wiederverwenden. Durch die leichte Integrierbarkeit in Front- und Backend ist der Fortschritt an der Liste stets leicht nachvollziehbar und natürlich durch die Pflege und Speicherung im Subversion immer genau für den aktuelle sichtbaren Stand zutreffend.

Umsetzung – Sprint-Phase

Die Entwicklung innerhalb eines Branches ist natürlich von Team zu Team unterschiedlich. Ein vorstellbares Vorgehen könnte aber wie folgt aussehen: Nach Abstimmung des Sprint-Backlog bilden die Entwickler einen Branch für den aktuellen Sprint, auf dem alle Teammitglieder arbeiten. Die anderen Teams können zeitgleich auf dem letzten stabilen Stand mit der Einrichtung der CMS-Vorlagen und in späteren Sprints mit der Content-Pflege fortfahren.

Während der eigentlichen Entwicklung bietet das Framework das volle Spektrum zwischen vorgefertigten Apps wie RedSparkBlog sowie Scaffolding-Skripten auf der einen und der vollen Individualität des Zend Framework auf der anderen Seite. Zusätzlich bietet das RedSpark Framework eine Infrastruktur, um schnell und einfach möglichst große Teile des Codes der eigenen App mit Unit oder Akzeptanztests zu prüfen. Das Scaffolding für die CRUD Actions beispielsweise generiert gleichzeitig die entsprechenden Tests, das Scaffolding zur Erzeugung des Moduls die entsprechende Test Suite. Zusätzlich sind weitere Tests bereits abstrakt vorbereitet, um z. B. schnell und einfach Feeds und Schnittstellen zu testen. Zu guter Letzt bietet das System für eigene, individuelle Tests die Möglichkeit, speziell vorbereitete RedSpark Asserts zu nutzen, um zum Beispiel zuzusichern, dass der systemeigene Error Stack keine Fehler enthält, ein Formular ausgegeben wurde oder ähnliches. Alle weiteren Aspekte in Sachen Entwicklung und Unit Testing im RedSpark Framework, z. B. auch die Nutzung von Selenium-Tests, befindet sich in Form von Dokumentation oder Tutorials unter [8].

Am Ende eines Sprints wird die Featureliste entsprechend aktualisiert, der Branch von einem der Entwickler zurück in den Trunk gemerged und anschließend ein Subversion Tag erstellt. Parallel dazu erstellt der Projektleiter über das Backend einen Snapshot der inzwischen gepflegten Inhalte und spielt auch diesen ins Repository. Die so fixierte Version kann dann für den Kunden sichtbar auf die Onlineplattform gespielt und vom Kunden freigegeben werden. Zudem hat jeder Projektmitarbeiter die Möglichkeit, leicht auf diesem fixierten Entwicklungsstand weiter zu arbeiten, selbst die inzwischen weiter gepflegte Datenbank würde durch Löschen der lokalen Entwicklungsversion aus dem erzeugten Snapshot neu erzeugt.

Umsetzung – Review-Phase

Die Review-Phase wird häufig unterschätzt, weil sie in den Augen der Entwickler, bis auf die Präsentation des Zwischenstandes, häufig keine wirklichen „Ergebnisse“ bringt. Mit dem RedSpark Framework ist dies anders. Am Ende jedes Sprints kann jeder Entwickler gefundene Lösungsansätze im Team vorstellen, die gegebenenfalls verallgemeinert und in Folgeprojekten wiederverwendet werden können. Diese Funktionen können dann „eine Ebene höher“ abstrakt implementiert werden. Konkret werden sie in eine andere App (etwa RedSparkCore für alle Projekte oder eine spezielle App für alle dauerhaft wiederverwendbaren Entwicklungen für den aktuellen Kunden) oder sogar die RedSpark Library verschoben. Der Aufwand für die Abstrahierung der Lösungen wird nicht auf das Projektkonto gebucht, die Zusatzarbeiten lohnen sich aber über die Zeit, da so eine immer bessere Basis im RedSpark Framework entsteht. Dadurch angeregt macht die Review-Phase allen Beteiligten mehr Spaß und ist auch für Feedback und Erkenntnisse, die nicht die Programmierung betreffen und im nächsten Sprint besser laufen sollen, viel effektiver.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -