Viele Produkte werden für einen spezifischen Bedarf entwickelt oder als Test, ob eine Idee funktioniert, oder es ist einfach ein "bau es und sie werden kommen" -Ansatz. Wenn das MVP (Minimum Viable Product) das erste Mal gebaut wird, hat man keine Zeit, über Skalierung oder die Arbeit mit komplexeren Funktionen und Funktionalitäten nachzudenken. In jedem Fall ist ein standardisierter und transparenter agiler Produktentwicklungsprozess eine gute Idee, um vorhersehbare Ergebnisse zu erzielen.
Für die Wartung und kontinuierliche Verbesserung eines Produkts hilft ein Prozess, der Anfragen sowie Fehlerbehebungen handhabt, dabei, Dinge zu erledigen und freizugeben.
Unser Produktentwicklungsprozess beginnt im Ideenstadium.
In dieser Phase werden alle Ideen von jedem in der Firma erfasst. Dies können kurze oder große Ideen sein, die in einem Ideen- oder Brainstorming-Treffen 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, vielleicht durch Abstimmungen oder einfach durch Qualifizierung durch den Product Owner.
Normalerweise landen hier alle Anfragen; Bugs, Änderungen, neue Funktionen. Es ist der Aufnahmeschacht für alles, was Mitarbeiter oder Führungskräfte erledigt haben möchten. Ein gut erfasste Anfrage enthält ein Screenshot, eine kurze Beschreibung und eine URL. Die Person, die hinter Anfragen steht, wird als Reporter bezeichnet und begleitet das Ticket während des gesamten Prozesses.
Nur durchgegangene, gut verstandene und geprüfte Anfragen können in dieses Stadium gelangen, und nur vom Product Owner oder von jemandem mit der Rolle verschoben werden. Sobald sie verschoben wurden, werden sie von oben nach unten priorisiert. Entwickler wählen von oben, so weit sie können, jedoch nach ihrem eigenen Ermessen, was sie bearbeiten möchten (ein weiterer großartiger Motivator). Niemand außer dem Product Owner darf Prioritäten ändern oder Dinge in dieses Stadium verschieben. Es ist wert, dies zu wiederholen.
Ab diesem Stadium sind die Entwickler selbst verantwortlich, das Ticket in den "Abgeschlossen"-Status zu verschieben. Dies hilft dem gesamten Prozess, da der Entwickler sich anpasst und es so bearbeitet, wie er es erledigt haben möchte. Daher gibt es keine Neuverteilung. Der leitende Entwickler, der das Ticket übernommen hat, ist der Assignee. Mehrere Entwickler können an demselben Ticket arbeiten, aber der Assignee wird nie geändert. Die Entwickler teilen täglich mit dem Rest des Teams Informationen in Form eines Stand-up-Meetings und beantworten die drei Scrum-Fragen: 1) Was habe ich heute erledigt? 2) Was werde ich morgen erledigen? 3) Habe ich Probleme, bei denen ich Hilfe benötige?
Wenn ein Entwickler nicht weiterkommen kann, wird das Ticket in das Blockierte-Stadium verschoben. Es könnte fehlendes Inhaltmaterial geben, es könnte auf den Reporter gewartet werden müssen, oder die Lösung wurde nicht gefunden. Etwas im Blockierten-Stadium in einem Kanban-Projekt bedeutet, dass etwas nicht so bewegt, wie es sollte, und dass es sich darum kümmern sollte.
Sobald eine Anfrage in eine Staging- oder Testumgebung zusammengeführt wurde, wird der Reporter eingeladen, es zu testen. Es wird natürlich vorher vom Entwickler getestet, wie es die Standardverhalten jedes Entwicklers sein sollte. Persönlich möchte ich nicht die Verantwortung vom Entwickler auf ein QA-Team übertragen, was länger dauert. Aber für einige größere und komplexere Tests könnte dies erforderlich sein und schneller sein. Automatisierte Tests werden ebenfalls durchgeführt.
Sobald etwas in den Hauptbranch zusammengeführt wurde und somit in die Produktion freigegeben wurde, wird es als "Abgeschlossen" markiert. Dies ist eine klare Definition von "Abgeschlossen".
Wow, Sie haben gerade ein altmodisches Projekt beschrieben! Warten Sie einen Moment, was wir hier haben, ermöglicht es, dass einzelne Ideen/Tickets unabhängig von den anderen durch den Prozess laufen. Das ist der Hauptunterschied. Auch können wir jederzeit zurück und vorwärts bewegen, wann immer wir einen gültigen Grund dafür haben. Dies kann nicht mit einem Wasserfall-Projekt mit all seinen Abhängigkeiten und Testproblemen verglichen werden.
Wir helfen Unternehmen bei ihrer Technologie, indem wir CTO-Dienstleistungen und Produktmanagement anbieten. Aufgrund unserer CTO-Dienstleistungen arbeiten wir sowohl mit Start-ups als auch etablierten Unternehmen in den Nordics, der Schweiz und den USA.
Wir sind eine Schweizer Gesellschaft (LLC) mit Sitz in 
Schweiz.