Mitgliedernews: Das Ticket zum Erfolg? – Chancen einer Feature getriebenen Entwicklung

Beinahe jedes IT-Projekt setzt auf die ein oder andere Art und Weise Features um. Jedes Software Produkt brüstet sich mit einer umfangreichen Feature Liste und Feature getriebene Entwicklung scheint, auf den ersten Blick, das Normalste der Welt zu sein. Der Teufel steckt jedoch, wie so oft, im Detail: in der Ausgestaltung der einzelnen Features.

Was ist ein Feature?

Ein Feature ergibt sich in einem klassischen Digital-Projekt aus einer Kombination aus verschiedenen Anforderungen – sowohl fachlich als auch technischer Natur. Es beschreibt primär eine Eigenschaft oder Funktion, die das Produkt erhalten soll. Dies ist natürlich sehr unspezifisch. Die Frage muss daher wesentlich konkreter gefasst werden: Was ist ein geeignetes Feature, um das Projekt voranzutreiben und dem Entwicklungsteam sinnvolles Arbeiten zu ermöglichen?

Feature versus Story

In heutigen Softwareentwicklungstools wie JIRA und anderen Ticketsystemen entspricht ein Feature oft einer sogenannten User Story. Kommt die Feature getriebene Entwicklung also aus dem agilen Umfeld? Und kann sie nur dort angewendet werden? Definitiv nein.

Vielmehr hat die agile Entwicklung das Feature erneut wieder in den Fokus der Entwicklung gerückt. Auch die klassischen Konzeptpapiere sind Sammlungen von Features und deren Beschreibung. Nur sind in Vorgehensweisen wie Wasserfall oder V-Modell die Definition eines Features und dessen Umsetzung zeitlich voneinander getrennt. Teilweise ist fachliche und technische Konzeption auch aufgeteilt in Pflichten- und Lastenheft.

Im agilen Umfeld – sei es nun Scrum oder Kanban oder eine Mischform – sind Definition und Umsetzung wesentlich näher beieinander.

Die Feature getriebene Entwicklung stellt nun das Feature ganz klar in den Mittelpunkt des Projekts. Während der Umsetzung gilt das Ticket als zentrales Dokument bzw. Artefakt, um alle Informationen zu einem Feature zusammenzustellen.

Warum Features?

Durch die Aufteilung der Konzeption in Pflichtenheft und Lastenheft und einem sehr späten Beginn der eigentlichen Umsetzung entstehen lange, parallele und damit getrennte Handlungsstränge.

Hinzu kommt, dass umfangreiche Konzeptpapiere oftmals nicht gelesen werden. Viele Kunden stehen kurz vor dem Start der Umsetzung schon so in den Startlöchern, dass für das Studium des Feinkonzepts oftmals nicht die nötige Muße vorhanden ist und teilweise auch die Zeit fehlt, es in der Tiefe durchzugehen. Und wer kann die Komplexität eines so umfangreichen Projekts anhand eines 350 Seiten Konzeptes noch erfassen? Es bleibt trotz einer Unmenge an produziertem Papier viel Raum zu Interpretation und Missverständnissen.

Dadurch kommt im Projektverlauf trotzdem zu Auseinandersetzungen, weil die Erwartungen nicht getroffen wurden. Und als Dienstleister zieht man langfristig meist “den Kürzeren”. Die Beziehung zwischen Kunde und Dienstleister leidet und wirklich Spaß macht das Projekt so auf jeden Fall nicht mehr.

Zudem können die althergebrachten Argumente der agilen Vorgehensweise hier ebenfalls ins Feld geführt werden: Anforderungen ändern sich über die Zeit, daher sollten sie erst kurz vor der tatsächlichen Umsetzung konkret formuliert werden. Aber dies ist kein Artikel über Scrum versus Wasserfall, sondern er zeigt, wie man gute Features definiert und welche Erfolgsfaktoren hierbei eine Rolle spielen.

Gemeinsame Verantwortung

Wichtig für eine erfolgreiche Umsetzung ist besonders die gemeinsame Verantwortung von Fachbereich und Entwicklung. Nur gemeinsam kann ein Feature konkret genug beschrieben werden, um ein gemeinsames Verständnis der Aufgabe herzustellen. Eine gleichartige Erwartungshaltung ist extrem wichtig, um ein Projekt erfolgreich abzuschließen.

Daher sollte auch das jeweilige Ticket, in dem das Feature beschrieben ist, allen Projektteilnehmern gemeinsam gehören. Im Ticket werden u.a. die folgenden Details beschrieben:

Fachliche Anforderungen: Was ist das zentrale Ziel, das die Fachabteilung erreichen möchte?

• Kurze Beschreibung des Features, worum geht es?
• Was sind die Key Points, die der Fachabteilung besonders wichtig sind?
• Wie soll ein Feature funktionieren, welche Abläufe sind essentiell?
• Was sind Akzeptanzkriterien, wie weiß das Entwicklungsteam, dass das Feature fertig ist?

Rückfragen: Ein temporärer Bereich, in dem das Entwicklungsteam Rückfragen für ein Meeting mit der Fachabteilung oder dem Product Owner sammeln kann.

• Dies könnte auch in einem verknüpften Ticket gesammelt werden. Es kann aber sinnvoll sein, dies zu Dokumentationszwecken direkt im eigentlichen Feature Ticket zu verorten

Technische Umsetzungsplanung: Welche Ideen hat das Entwicklungsteam bereits gesammelt?

• Welche Technologie wird eingesetzt?
• Welche Annahmen über die Ausgangslage werden getroffen? Welche Abhängigkeiten gibt es?
• Welche Entwurfsmuster oder Ansätze werden verfolgt?
• Wie sind die Zuständigkeiten zwischen Frontend und Backend aufgeteilt?
• Wie können aus den Akzeptanzkriterien bereits Testszenarien abgeleitet werden?
• Wieviel Aufwand sieht das Entwicklungsteam für die Umsetzung des Features

Ein Wort zur Aufwandsschätzung

Viele Entwicklungsteams, die “Scrum nach Lehrbuch” praktizieren wollen, tun sich schwer damit, in Stunden oder Personentagen zu schätzen. Es wirkt “zu konkret”. Es scheint keine Schätzung mehr zu sein, sondern ein Ergebnis.

Letztendlich ist die Schätzung in Stunden aber auch eine Komplexitätsbewertung. Und um die geht es beim klassischen Planning Poker hauptsächlich. Letztendlich rechnen viele Entwickler die Punkte des Planning Pokers ohnehin wieder in Stunden um, damit sie die korrekte Bewertung für sich im Kopf machen können. Und beim Planning selber ist es in einem Kunde-Dienstleister Verhältnis ebenfalls wichtig, die Aufwände für das Projekt konkret genug zu kennen, damit ein Sprint oder eine Umsetzungsplanung halbwegs treffsichere Erkenntnisse liefert.

Bisher war es nach einer kurzen Umgewöhnung noch nie ein Problem für Entwickler, Features in Stunden und Tagen statt in Punkten zu schätzen. Die Diskussionen, warum ein Entwickler 2 Stunden und einer 6 Stunden schätzt, sind genauso hilfreich und decken die gleichen Dinge auf, wie ein Unterschied in Punkten.
Tipps für die Praxis

Was sollte man bei der Definition von Features beachten?

• Immer eine feste Struktur: Legen Sie alle Feature Tickets nach dem gleichen Schema an. So ist sichergestellt, dass kein Aspekt vergessen wird und alle Projektmitarbeiter sich jederzeit zurechtfinden.
• Lieber eine Frage zu viel stellen, als eine Frage zu wenig: Bei der Beschreibung eines Features gilt das Motto: Viel hilft viel. Jede Frage, die bereits bei der Definition gestellt wird, sorgt für weniger Abstimmungsaufwand im Laufe der Umsetzung.
• Auch offensichtliche Annahmen konkret hinterfragen: Manches erscheint auf den ersten Blick “normal” und “selbstverständlich”. Doch viele Projekte zeigen deutlich, dass gerade hier die Erfahrungswelten der Beteiligten voneinander abweichen können. Das macht Missverständnisse in diesem Bereich besonders ärgerlich, weil damit keiner gerechnet hat.
• Ein Bild sagt mehr als tausend Worte: Viele Themen lassen sich entweder mit viel Prosa beschreiben oder mit einem Diagramm schnell auf den Punkt bringen. Auch Scribbles oder Ergebnisse des Paper Prototyping können wertvolle Informationen für die Umsetzung enthalten.
• Mehrdeutigkeit vermeiden: Machen Sie vor dem Finalisieren der Definition auf jeden Fall noch einen Plausibilitäts-Check. Oft kommt es vor, dass im Rahmen von Diskussionen plötzlich widersprüchliche Informationen im Ticket angekommen sind. Hier fällt es nachher schwer, die gültige Definition zu ermitteln. Gehen Sie also auf Nummer sicher und prüfen Sie die fertiggestellte Definition. So können Sie unangenehme Überraschungen vermeiden.
• Überschaubare Größe eines Features: Der Aufwand pro Gewerk sollte nicht mehr als einen Personentag betragen. Beteiligt sein können beispielsweise Frontend, Backend, Administration, Design, etc. Hierdurch wird das Risiko für das einzelne Feature auf genau diesen Aufwand minimiert.
• Abhängigkeiten reduzieren: Features sollten möglichst so gekapselt werden, dass keine konkreten Abhängigkeiten bestehen. Je isolierter ein Feature umgesetzt werden kann, umso besser kann es auch getestet und abgenommen werden.
• Akzeptanzkriterien und Testkriterien gehören zusammen: Das zentrale Element für die Abnahme eines Features durch den Fachbereich sind die Akzeptanzkriterien. Sie ermöglichen es, die Erwartungshaltung genau zu definieren. Im Optimalfall können an die Akzeptanzkriterien der Fachabteilung direkt Testszenarien der Entwicklung geknüpft werden. So wissen beide Seiten, wann das Feature als abgeschlossen gilt.

Kunst oder Wissenschaft?

Die Tipps zeigen, dass es an der ein oder anderen Stelle durchaus knifflig werden kann. Welches Feature hat schon keinerlei Abhängigkeiten? Kann man immer so genau zwischen acht und zehn Stunden Aufwand differenzieren? Hier verschwimmt die Grenze zwischen Kunst und Wissenschaft. Das optimale Beschreiben eines Features basiert in den meisten Fällen auf Erfahrung und einer Intuition, wie ein Feature am besten “geschnitten” wird, damit man möglichst alle Tipps beachtet. Sie sollten jedoch nicht als Dogma betrachtet werden.

Gibt es beispielsweise Features, die länger als acht Stunden im Backend bedeuten, so kann es durchaus sinnvoll sein, dies trotzdem so beizubehalten. Wenn beispielsweise die Umsetzung mehrerer Webservices gebündelt Sinn macht und die Vorgehensweise klar ist, so ist auch das Risiko für dieses Feature nicht besonders hoch. Es handelt sich um “Fleißarbeit”, die gut abzuschätzen und planbar ist.

Chancen und Herausforderungen beim Dienstleister

Wie man sieht, maximiert die gemeinsame Verantwortung bei den Tickets (und damit den Features) die Transparenz im Entwicklungsprozess. Die Fachabteilung darf und muss sich aktiv einbringen. Sie bekommt mit, welche technischen Hürden bestehen und welche Anforderungen eventuell trivial sind. Das Entwicklungsteam bekommt mit, warum welche Funktionen benötigt werden und erkennt, dass die Wirklichkeit wesentlich “dreckiger” ist als in der schönen Welt von 0 und 1. Schließlich sind Digital-Projekte meistens komplexe Abläufe in komplexen Umfeldern, die nicht am Fließband abgearbeitet werden können.

In der Theorie wird somit das gemeinsame Verständnis füreinander gestärkt. Soweit so gut. Was sind nun die Risiken der Feature getriebene Entwicklung für Dienstleister? Findet die Entwicklung komplett In-House und ohne externen Dienstleister statt, sind die Fronten geklärt und die Kosten liegen komplett intern. Hier kann es natürlich auch zu Unstimmigkeiten kommen, aber dies kann innerhalb der bestehenden Organisation gelöst werden.

In der Beziehung zwischen Dienstleister und Kunden gibt es eine andere Dynamik. Man muss sich daher im Klarem sein, dass Transparenz ein großes Maß an Vertrauen und Goodwill erfordert. Nicht jede Beziehung hält dies aus. Wenn eine Atmosphäre des Misstrauens besteht, dann kann das Entwicklungsteam nicht offen über technische Hürden sprechen. Bereits getroffene Entscheidungen können nur sehr schwer für eine noch bessere Lösung in Frage gestellt werden. Und fehlende Kompetenz in einem Bereich kann nicht offen zugegeben werden, weil man sich sonst in ein schlechtes Licht rückt. Die Aufwände können beim Kunden für Unverständnis sorgen und es kann zu handfestem Streit bei den gemeinsamen Meetings kommen.

Spielen beide Seiten mit offenen Karten, so zeigt die Erfahrung aber: Es lohnt sich! Die Transparenz stärkt das Vertrauen in die Kompetenz und die Arbeitsweisen. Die Vorgehensweisen des Dienstleisters werden nachvollziehbar. Das Anliegen des Kunden wird deutlich. Die Ergebnisse der Umsetzung sind besser und passen genau zu den Erwartungen des Kunden. Beide Seiten können ein erfolgreiches Digital-Projekt feiern.

Typische Herausforderungen und mögliche Lösungsansätze

Auch, wenn man sich gemeinsam und mit jeder Menge Vertrauen in das Abenteuer eines Relaunchs oder einer Produktentwicklung stürzt, zeigt die Projekterfahrung, dass es doch einige Herausforderungen zu meistern gilt:
Stakeholder können Anforderungen schlecht formulieren

Viele Mitarbeiter von Fachabteilungen sind es nicht gewohnt, Anforderungen so zu formulieren, dass sie jemand anderes, geschweige denn ein Entwickler mit einem ganz anderen Erfahrungshintergrund, genauso versteht, wie es gemeint ist. Ein Entwicklungsteam mit einer großen Domain Knowledge, also Vorerfahrung in dem Fachbereich um den es geht, kann hier helfen. Es kann hilfreich sein, die Untiefen des Leasingerlasses zu kennen, um die größten Klippen zu umschiffen. Wie damit aber von Kunde zu Kunde intern umgegangen wird, kann nur die Fachabteilung definieren.

Die Erfahrung zeigt, dass zwei Aspekte sehr hilfreich sind: On-Boarding und Coaching-on-the-Job. On-Boarding kann durch einen vorgelagerten Workshop geschehen. Hier werden alle Beteiligten anhand von Beispiel Features durch den Prozess geleitet. Es wird klargemacht, welche Rolle im Projekt für welche Themen verantwortlich ist. Idealerweise wird gegen Mitte des Workshops bereits das ein oder andere Feature aus dem Projekt heraus als Übungsgegenstand verwendet.

Das Coaching sollte im Rahmen der Umsetzungsphase in regelmäßigen Intervallen geschehen. Hier bietet es sich an, anhand von anstehenden Features das Refinement mit einem Scrum Master oder Projektleiter gemeinsam vorzunehmen. Zu Beginn des Projekts kann dies intensiv geschehen, bspw. mit zwei Terminen pro Woche. Später sollte man es von der Art der Features und den Erfahrungen des Entwicklungsteams abhängig machen.

Die Fachabteilung unterschätzt den eigenen Aufwand

Wie man vielleicht vermuten kann, bedeutet das konkrete Formulieren von Features einen nicht zu unterschätzenden Zeitaufwand. Kann man sich um das Lesen eines 350 Seiten Konzepts noch irgendwie herumdrücken oder überfliegen, ob die eigenen Annahmen getroffen wurden, ist die Zusammenstellung von Features für Fachabteilung und Entwicklungsteam harte Arbeit. Arbeit, die sich lohnt, aber die getan werden muss.

Wieviel dies im Einzelnen bedeutet, wird von vielen Fachabteilungen unterschätzt. Teilweise werden durch Rückfragen des Entwicklungsteams auch Herausforderungen im Prozess aufgezeigt, die vorher noch gar nicht klar wurden. Dies bedeutet an vielen Stellen Hausaufgaben für die Fachabteilung und kann im schlimmsten Fall für Verzögerungen in der Umsetzung sorgen, da noch aufwändige Abstimmungsrunden durchlaufen werden müssen.

Wer kümmert sich beispielsweise um die Anfragen, die über das neue Kontaktformular eintreffen? Die Zentrale? Die Niederlassung? Gibt es in jeder Niederlassung kompetente Ansprechpartner? Gibt es ein professionelles Input Management für Anfragen, die ausgedruckt oder als Fax übermittelt werden? Wie wird auf diese Anfragen geantwortet, wenn der restliche Prozess komplett auf E-Mails ausgerichtet ist?

Wie sieht der Entwicklungsprozess aus?

Heutzutage gibt es viele geeignete Softwareentwicklungs-Tools. Eine sehr weit verbreitete Suite für die Abwicklung verschiedenster Projekte bietet Atlassian an. Hierzu zähle JIRA als Ticketsystem, Stash als Repository-Verwaltung und Bamboo als Build & Delivery Server. Die folgende Beschreibung orientiert sich zwar an Atlassian Produkten, kann aber ohne Probleme auch auf andere Kombinationen übertragen werden.


Ticket wird erstellt und Informationen werden ergänzt – gemeinsam oder asynchron

Als zentrales Dokument während der Umsetzung steht zu Beginn der Entwicklung das Ticket in JIRA. Hier werden, angelehnt an die Tipps aus der Praxis, die Anforderungen an das Feature festgehalten und alle sinnvollen Beschreibungen erfasst.


Feature wird geschätzt

Auf Basis der Informationen im Ticket werden die voraussichtlichen Aufwände geschätzt. Das Verfahren richtet sich hier nach der Projektmethode. Bei Scrum-Projekte würde dies beispielsweise im Rahmen des Planning Pokers stattfinden und das Entwicklungsteam würde die Schätzung gemeinsam vornehmen. Die geschätzten Aufwände werden am Ticket erfasst. JIRA bietet hierfür verschiedene Möglichkeiten, unter anderem auch das Schätzen in Stunden oder Tagen.


Feature wird für die Umsetzung vorgesehen

Damit das Feature auch tatsächlich umgesetzt wird, erfolgt eine Priorisierung der verschiedenen Features für den nächsten Umsetzungszeitraum. Bei einem Scrum-Projekt würde es beispielsweise für das nächste Sprint Backlog vorgesehen, bei Kanban zur Liste der anstehenden Aufgaben hinzugefügt und entsprechend sortiert. In einem Wasserfall-Projekt würde es in den Projektplan aufgenommen.


Feature Branch wird erstellt

Das Entwicklungsteam erstellt auf Basis des Feature Tickets einen eigenen Feature Branch im Git Repository. So ist die Arbeit an dem Feature gekapselt und es kann isoliert entwickelt und getestet werden. In JIRA ist das Erstellen eines neuen Branches bequem über einen Link im Ticket möglich. Dabei übernimmt Stash das Anlegen und Benennen des Feature Branches und das Team kann danach den Feature Branch direkt auschecken und bearbeiten. ID und Bezeichnung des Features werden direkt in den Branchnamen übernommen, so dass jederzeit klar ist, welches Feature in welchen Branch gehört.


Die Umsetzung wird durchgeführt

Das Entwicklungsteam kann nun im entsprechenden Branch das Feature umsetzen, Tests schreiben und das Feature beispielsweise auf eine interne Test-Umgebung deployen. Hierbei können einzelne oder mehrere Entwickler am Feature im Feature Branch arbeiten. So kann ein Frontend Entwickler den View für die Eingabemasken für ein Kontaktformular erstellen und ein Backend Entwickler parallel die Models und Controller für die Verarbeitung erstellen. Während der Arbeiten wird der aktuelle Stand vom CI System gebaut und ein Tool wie bspw. Sonarqube ermittelt die Qualitätsmetriken als Indikator für das Entwicklungsteam.


Ein Pull Request wird erstellt

Nach Abschluss der Arbeiten erstellt der Hauptverantwortliche für das Feature einen Pull Request. Andere Entwickler führen anhand des Pull Requests einen Code Review durch. Je nach Art des Features oder auch nach Art des Projekts kann es ausreichen, wenn ein Teil des Entwicklungsteams den Pull Request genehmigt. Bei kritischen Features sollte jedoch das gesamte Team den Pull Request prüfen. Dies unterstützt wiederum auch die gemeinsame Verantwortung innerhalb des Entwicklungsteams und die sogenannte Collective Code Ownership.

Der Code Review geschieht entweder gemeinsam in einem Meeting oder asynchron und toolgestützt, beispielsweise über Stash. Wobei sich auch bei einem Meeting Stash als zentrale Plattform eignet, damit das Ergebnis des Reviews dokumentiert werden kann.

Nach erfolgreichem Code Review wird der Feature Branch in den aktuellen Entwicklungsstand zurückgeführt. Auch dies kann komplett über die Web Oberfläche von Stash durchgeführt werden.


Der neue Entwicklungsstand wird bereitgestellt

Über Bamboo kann nun der neue Entwicklungsstand, meistens ein Branch mit dem Namen develop, development oder trunk, auf die einzelnen Umgebungen verteilt werden. Hierbei greift der Build & Delivery Server auf die Branches im Stash zu und erstellt auf deren Basis nachvollziehbare Releases. Diese können dann auf ein QA-System oder nach Freigabe durch den Kunden auch auf das Produktionssystem ausgerollt werden.


Das Feature ist fertig

Um im Nachhinein noch Zusammenhänge zu einem Feature nachvollziehen zu können, sind im Ticket nach der Fertigstellung folgende Informationen zu finden:

• Welcher Branch im Repository gehört zu diesem Feature?
• Welche Commits gehören zu dem Feature?
• Wie viele Builds gibt es zu dem Feature und wie ist der Status der Builds?
• In welchen Umgebungen wurde das Feature bereits bereitgestellt (Development, Testing, QA, Production)

Durch den Einsatz des Atlassian Stacks werden viele dieser Informationen automatisiert erfasst und dokumentiert. Aber auch andere Systeme bieten diese Automatisierung. Wenn man keins dieser Systeme einsetzt, bietet es sich trotzdem an, diese Informationen manuell im Ticket zu erfassen.

Hybridansätze

Oft ist es so, dass die eigentliche Feature Entwicklung erst auf einem Basis-System aufsetzt. So kann bspw. ein Intranet Projekt auf einem Portalsystem wie Liferay aufsetzen. Oder ein Website Relaunch wird mit TYPO3 durchgeführt. In beiden Fällen gibt es viele Standardaufgaben, die beim Einrichten des Systems durchgeführt werden müssen, die aber keine konkreten Feature-Definitionen bedeuten. Hier kann das Digital-Projekt in zwei Phasen aufgeteilt werden: Die Setup Phase und die Feature Phase.

In der Setup Phase werden die üblichen Dokumente in abgespeckter Fassung erstellt. So ist nachvollziehbar, was die Ausgangsbasis für die Umsetzung der Features ist. In der Feature Phase gelten dann die oben beschriebenen Vorgehensweisen.
Rollen im Projekt

Entwicklungsteam: Das Team von Entwicklern, das für die Umsetzung des Projekts oder Produkts verantwortlich ist.

Stakeholder: Wichtige Ansprechpartner des Kunden, die Anforderungen an das Projekt definieren. Dies können CEO, CTO, IT Leiter, CFO, Aktionäre, Betriebsrat uvm. sein. Hierzu zählen vor allem aber auch: die Mitarbeiter der Fachabteilungen. Vertrieb, Customer Service, Administration oder Sachbearbeitung.

• Fachabteilungen: Fachliche Ansprechpartner, die konkrete fachliche Anforderungen an das Projekt definieren.
• Projektleiter: In klassischen Projekten organisiert er das Projekt, erstellt Statusberichte und informiert die Stakeholder über den Projektfortschritt
• Scrum Master: In agilen Projekten der Ansprechpartner, der für das Entwicklungsteam Stolpersteine aus dem Weg räumt und für das Einhalten des Scrum Prozesses zuständig ist.
• Product Owner: In agilen Projekten ist er verantwortlich für die Priorisierung der Features/Stories und gibt die Richtung für das Projekt oder das Produkt vor.

Tools für die Umsetzung

• Ticketsystem: JIRA, Redmine, Trello, Mantis. Es eignet sich jedes System, in dem ein Feature gemeinsam beschrieben werden kann. Eine Integration in die anderen Systeme erleichtert das Arbeiten für das Entwicklungsteam. JIRA erlaubt bspw. das direkte erstellen eine Feature Branches in Stash aus dem Ticket heraus.
• VCS: Version Control System. Oftmals Git oder Subversion, bspw. Stash, Gitlab, Github, Bitbucket. Für die Feature getriebene Entwicklung eignet sich besonders ein Tool, das Feature Branches unterstützt und das Branchen und Mergen erleichtert.
• Build und Continuous Integration: Bamboo, Jenkins, Travis CI, Gitlab CI. Mit diesen Tools werden die Feature Branches gebaut, die Tests ausgeführt und Software Metriken erhoben. Idealerweise werden diese dann in einem Tool wie Sonarqube gesammelt.
• Delivery: Bamboo, Jenkins. Hiermit wird das Projekt oder ein bestimmter Feature Branch auf eine der Umgebungen gebracht.

Fazit

Feature getriebene Entwicklung bietet viele Chancen, ein Digital-Projekt erfolgreich zu machen. Seine größten Stärken spielt es sicher in der agilen Entwicklung aus, da viele unterstützende Prozesse bereits vorhanden sind und es mit der User Story ein Instrument gibt, das ideal geeignet für die Beschreibung eines Features ist. Aber auch Wasserfall-Projekte können stark davon profitieren, das Feature in den Mittelpunkt zu stellen.

Anforderungen werden hinterfragt. Der Fokus wird auf den Mehrwert für die Anwender und Nutzer gelegt. Fachabteilung und Entwicklung arbeiten wesentlich enger miteinander.

Hauptgrund für das Scheitern von Digital-Projekten sind oftmals unterschiedliche Vorstellungen von dem, was der Kunden wünscht und dem was der Dienstleister verstanden hat. Diese Kluft wird durch das Fokussieren auf das einzelne Feature stark verkleinert und es werden durch die gemeinsame Arbeit an der Definition des Features eine Menge Brücken gebaut, die das gesamt Projekt in eine konstruktive und offene Atmosphäre versetzen.

Man darf nicht vergessen, dass diese Art der Entwicklung nicht weniger Aufwand für Konzeption und Abstimmung bedeutet. Aber dieser Aufwand wird an der richtigen Stelle eingesetzt und maximiert damit den Output für das Projekt. Auch in Konzeptphasen vorab wird nun über konkrete Features gesprochen und nicht mehr im stillen Kämmerlein “vor sich hin konzipiert”. Das Verständnis beim Kunden ist größer und er hat in diesem Szenario viel eher die Möglichkeit, Einfluss zu nehmen und Missverständnisse zu korrigieren.


 

Autor:
Kai Kroker
Technical Director, TWT Interactive