Produktentwicklung

Viele Produkte werden für einen spezifischen Bedarf entwickelt oder sind so konzipiert, dass man testen kann, ob eine Idee funktioniert, oder es handelt sich einfach um den Ansatz „bau es und sie werden kommen“. Beim ersten Mal, wenn das MVP (Minimum Viable Product) erstellt wird, hat man keine Zeit, über Skalierung oder die Arbeit mit komplexeren Funktionen und Funktionalitäten nachzudenken. In jedem Fall ist es eine gute Idee, einen standardisierten und transparenten agilen Produktentwicklungsprozess zu verfolgen, um vorhersehbare Ergebnisse zu erzielen.
Für die Wartung und kontinuierliche Verbesserung eines Produkts hilft ein Prozess, der Anforderungen sowie Fehlerbehebungen behandelt, dabei, Dinge zu erledigen und freizugeben.

Unser Produktentwicklungsprozess beginnt in der Ideenphase.

Ideenphase

In dieser Phase werden alle Ideen von jedem im Unternehmen erfasst. Es können kurze Ideen oder große Ideen sein, die in einem Ideen- oder Brainstorming-Meeting besprochen werden. Da jeder diese Ideen erstellen kann, ist es auch eine Möglichkeit, die Produktentwicklung offen zu halten. Wie Dinge von dieser Phase weitergeleitet werden, hängt davon ab, ob es durch Stimmabgabe oder einfach durch Qualifizierung durch den Produktinhaber geschieht.

Anforderungsphase

Normalerweise landen hier alle Anfragen; Fehler, Änderungen, neue Funktionen. Es ist die Anlaufstelle für alles, was Mitarbeiter oder Führungskräfte erledigt haben möchten. Ein gut erfasste Anfrage enthält einen Screenshot, eine kurze Beschreibung und einen URL. Die Person, die hinter den Anfragen steht, wird als Reporter bezeichnet und übernimmt die Ticketführung während des gesamten Prozesses. 

Backlog-Phase

Nur durchgegangene, gut verstandene und überprüfte Tickets können in diese Phase gelangen, und nur der Produktinhaber oder wer immer die Rolle hat, kann sie hierher verschieben. Sobald sie verschoben wurden, werden sie von oben nach unten priorisiert. Entwickler wählen von oben, soweit sie können, jedoch nach eigenem Ermessen. Dies ist ein weiterer großartiger Motivator. Niemand außer dem Produktinhaber darf priorisieren oder Dinge in dieser Phase verschieben. Das ist es wert, zu wiederholen.

In-Progress-Phase

Ab dieser Phase sind die Entwickler selbst verantwortlich, das Ticket in den Zustand „erledigt“ zu überführen. Dies hilft dem gesamten Prozess, da der Entwickler es so bearbeitet und weitergeleitet, wie er es möchte. Daher gibt es keine Neuzuweisungen. Der leitende Entwickler, der das Ticket übernommen hat, ist der Verantwortliche. Mehrere Entwickler können an demselben Ticket arbeiten, aber der Assigned (Zuständige) wird niemals geändert. Die Entwickler teilen täglich im Rahmen eines Stand-up-Meetings Informationen mit dem Rest des Teams und beantworten die drei Scrum-Fragen: 1) Was habe ich bis heute erledigt? 2) Was werde ich bis morgen erledigen? 3) Habe ich Probleme, bei denen ich Hilfe benötige.

Blocked-Phase

Wenn ein Entwickler nicht weiterkommen kann, wird das Ticket in die Blocked-Phase verschoben. Es könnte fehlende Inhalte geben, auf einen Reporter gewartet werden müssen oder die Lösung ist nicht gefunden. Etwas in der Blocked-Phase in einem Kanban-Projekt bedeutet, dass etwas nicht so weitergeht, wie es sollte, und dass es beachtet werden muss.

Testphase

Sobald ein Ticket in ein Staging- oder Testumfeld zusammengeführt wurde, wird der Reporter eingeladen, es zu testen. Natürlich wird es vorher vom Entwickler getestet, wie es sein sollte. Ich möchte die Verantwortung vom Entwickler nicht auf ein QA-Team übertragen, das länger dauert. Aber für einige größere und komplexere Tests könnte es nötig und schneller sein. Automatisierte Tests werden ebenfalls durchgeführt.

Done-Phase

Sobald etwas in den Hauptbranch zusammengeführt wurde und somit in die Produktion freigegeben wurde, wird es als „erledigt“ markiert. Dies ist eine klare Definition von „erledigt“.

Wow, du hast gerade ein altes Schulprojekt beschrieben! Halt dich mal zurück, was wir hier haben, ermöglicht es, dass einzelne Ideen/Tickets unabhängig von den anderen durch den Prozess laufen. Das ist der Hauptunterschied. Außerdem können wir jederzeit nach hinten und vorne, für jeden gültigen Grund, wechseln. Dies kann nicht mit einem Wasserfallprojekt mit all seinen Abhängigkeiten und Testproblemen verglichen werden.