Ist Feature-driven Development das Ticket zum Erfolg?

Chancen einer featuregetriebenen Entwicklung
Kommentare

Eine featuregetriebene Entwicklung bietet sowohl Chancen als auch Fallstricke für ein Digitalprojekt. Dieser Artikel liefert hilfreiche Tipps aus der Praxis und zeigt die Vorteile der featuregetriebenen Entwicklung im Überblick. Wichtige Fragestellungen, die beantwortet werden, sind beispielsweise: Welchen Nutzen hat der Dienstleister? Welchen Nutzen hat der Kunde, und in welcher Projektmethode kann die featuregetriebene Entwicklung eingesetzt werden.

Beinahe jedes IT-Projekt setzt auf die eine oder andere Art und Weise Features um. Jedes Softwareprodukt brüstet sich mit einer umfangreichen Featureliste, und featuregetriebene 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 Digitalprojekt aus einer Kombination aus verschiedenen Anforderungen – sowohl fachlicher 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 so genannten User Story. Kommt die featuregetriebene Entwicklung also aus dem agilen Umfeld? Und kann sie nur dort angewendet werden? Definitiv nein.

Vielmehr hat die agile Entwicklung das Feature wieder in den Fokus der Entwicklung gerückt. Auch die klassischen Konzeptpapiere sind Sammlungen von Features und deren Beschreibungen. 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, Kanban oder eine Mischform – sind Definition und Umsetzung wesentlich näher beieinander.

Die featuregetriebene 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?

Als Dienstleister zieht man langfristig meist den Kürzeren.

Durch die Aufteilung der Konzeption in Pflichtenheft und Lastenheft sowie 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. Teilweise fehlt auch einfach die Zeit, es in der Tiefe durchzugehen. Und wer kann die Komplexität eines so umfangreichen Projekts anhand eines 350 Seiten starken Konzepts noch erfassen? Es bleibt trotz einer Unmenge an produziertem Papier viel Raum für Interpretation und Missverständnisse.

Dadurch kommt es im Projektverlauf durchaus zu Auseinandersetzungen, weil den Erwartungen nicht entsprochen wurde. 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 (einen Überblick zu den verschiedenen Projektrollen gibt der Infokasten „Rollen im Projekt“). 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. Diese könnten auch in einem verknüpften Ticket gesammelt werden. Es kann aber sinnvoll sein, die Rückfragen zu Dokumentationszwecken direkt im eigentlichen Featureticket 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

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 u.v.m. sein. Hierzu zählen vor allem 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 dieser 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.

Ein Wort zur Aufwandsschätzung

Die Schätzung in Stunden ist letztendlich auch eine Komplexitätsbewertung.

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 selbst 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 zwei Stunden und einer sechs 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 Featuretickets nach dem gleichen Schema an. So ist sichergestellt, dass kein Aspekt vergessen wird und alle Projektmitarbeiter sich jederzeit zurechtfinden.
  • Lieber eine Frage zu viel als eine Frage zu wenig stellen: 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ätscheck. 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 einen 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 mehr als acht Stunden Aufwand im Backend bedeuten, kann es durchaus von Vorteil sein, dies trotzdem so beizubehalten. Wenn beispielsweise die Umsetzung mehrerer Webservices gebündelt sinnvoll und die Vorgehensweise klar ist, dann dürfte auch das Risiko für dieses Feature nicht besonders hoch sein. Es handelt sich um „Fleißarbeit“, die gut abzuschätzen und planbar ist.

Chancen und Herausforderungen beim Dienstleister

Digitalprojekte sind meistens komplexe Abläufe in komplexen Umfeldern, die nicht am Fließband abgearbeitet werden können.

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 man es in der schönen Welt von Nullen und Einsen vermuten würde. Schließlich sind Digitalprojekte 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 featuregetriebenen Entwicklung für Dienstleister? Findet die Entwicklung komplett inhouse 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 Klaren 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 infrage 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 Digitalprojekt 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 sie gemeint ist. Ein Entwicklungsteam mit einer großen Domain-Knowledge, also Vorerfahrung im betroffenen Fachbereich, kann hier helfen. Es kann nützlich 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 Beispielfeatures 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, beispielsweise 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 vor dem Lesen eines 350 Seiten umfassenden Konzepts noch irgendwie drü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 waren. Dies bedeutet an vielen Stellen Hausaufgaben für die Fachabteilung. Im schlimmsten Fall kann es 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 Inputmanagement 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 Softwareentwicklungstools. Eine sehr weit verbreitete Suite für die Abwicklung verschiedenster Projekte bietet Atlassian an. Dazu zählt JIRA als Ticketsystem, Stash als Repository-Verwaltung und Bamboo als Build- und Delivery-Server. Einen detaillierten Überblick liefert der Infokasten „Tools für die Umsetzung“. Die folgende Beschreibung orientiert sich zwar an Atlassian-Produkten, kann aber ohne Probleme auch auf andere Kombinationen übertragen werden.

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 beispielsweise das direkte Erstellen eines Feature-Branches in Stash aus dem Ticket heraus.

VCS: Version Control System. Oftmals Git oder Subversion, z. B. Stash, GitLab, GitHub, Bitbucket. Für die featuregetriebene 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 Softwaremetriken 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.

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-Projekten 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 im 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 Wasserfallprojekt würde es in den Projektplan aufgenommen.

Feature-Branch wird erstellt: Das Entwicklungsteam erstellt auf Basis des Featuretickets einen eigenen Feature-Branch im Git Repository. So ist die Arbeit am 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 Branch-Namen übernommen, sodass 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 Testumgebung deployen. Hierbei können einzelne oder mehrere Entwickler am Feature im Feature Branch arbeiten. So kann ein Frontend-Entwickler die 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 z. B. 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 Codereview 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 so genannte Collective Code Ownership.

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

Nach erfolgreichem Codereview wird der Feature-Branch in den aktuellen Entwicklungsstand zurückgeführt. Auch dies kann komplett über die Weboberflä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- und 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 bezüglich eines Features 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 Featureentwicklung erst auf einem Basissystem aufsetzt. So kann z. B. ein Intranetprojekt 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 Featuredefinitionen bedeuten. Hier kann das Digitalprojekt in zwei Phasen aufgeteilt werden: Die Set-up-Phase und die Featurephase.

In der Set-up-Phase werden die üblichen Dokumente in abgespeckter Fassung erstellt. So ist nachvollziehbar, was die Ausgangsbasis für die Umsetzung der Features ist. In der Featurephase gelten dann die oben beschriebenen Vorgehensweisen.

Fazit

Featuregetriebene Entwicklung bietet viele Chancen, um ein Digitalprojekt erfolgreich zu machen. Ihre größten Stärken spielt sie sicher in der agilen Entwicklung aus, da viele unterstützende Prozesse bereits vorhanden sind und es mit der User Story ein Instrument gibt, das für die Beschreibung eines Features ideal geeignet ist. Aber auch Wasserfallprojekte 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 Digitalprojekten sind oftmals unterschiedliche Vorstellungen darüber, was der Kunde wünscht und 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 Featuredefinition eine Menge Brücken gebaut. Diese verleihen dem gesamten Projekt eine konstruktive und offene Atmosphäre.

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 nur 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.


Aufmacherbild: ticket to success concept illustration design over a white background von Shutterstock / Urheberrecht: alexmillos

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -