Produktentwicklung

Vieli Produkt isch für e spezifischs Bedürfnis entwicklet oder wird zom Testen vo eme Idee baut, oder es isch es "build it and they will come" -Ansatz. Dä ersti MVP (Minimum Viable Product) wird ufgebaut, ohni zom Ufskala oder zom Arbetä mit komplexere Funktione z dänke. In allne Fäll isch es standardisierte und transparent agile Produktentwicklung ein guets Idee z folge, zom vorhersägbari Ergebnis z erziele.
Für s Erhalte und kontinuierlich Verbessere vo eme Produkt hilft es Prozess zom Behandla vo Anfrag und Bugfixe, zom Sache z mache und z veröffentliche.

Unser Produktentwicklung Prozess fangt i de Idee Phase a.

Idea Stage

Dii Phase fangt alli Idee vo jedere i de Firma uf. Das chönne churzi Idee oder grossi Idee si, wo zom Bispil zuegschtandig i eme Idee oder Brainstorming Meeting gschtellt wärde. Will jedere Idee chönne, es isch es au es Wäg zom Produktentwicklung offe z halte. Wie Sache vo dr Idee Phase in d Produktentwicklung iigschtellt wärde, hängt ab, möglig isch es durchs Upvote oder durchs Qualifiziere vo de Produktbesitzer.

Request Stage

Normalerwiis lande alli Anfrag do; Bugs, Änderige, neui Funktion. Es isch d Anfragebahn für alles, was Angestellte oder Führigskraft mache wöue. E guet erfasste Problem enthält e Screenshot, e churzi Beschriibig und e URL. D Person, wo hinter de Anfrag schtand, wird als Reporter bezeichnet und folgt em Ticket während em ganze Prozess.

Backlog Stage

Nur durchgohni, guet verstande und kontrolliert Tickets chönne i dii Phase cho, und nume vom Produktbesitzer oder wem au immer mit de Rolle verschobe. Eimol verschobe, wärde si vo uf dr Spitz agforderet und abwärts priorisiert. Entwickler wähle vo dr Spitz abwärts, wie viu si chönne, aber si entscheide, uf was si schaffe wöue (es au es guete Motivator). Keini usser em Produktbesitzer isch erlaube, d Priorisierig z ändere oder Sache in dii Phase z verschiebe. Es lohnt sich, das z wiederhole.

In Progress Stage

Vo dr In Progress Phase a isch de Entwickler sälber verantwortlech, s Ticket z "Done" z mache. Das hilft em ganze Prozess, will de Entwickler es berücksichtigt und es durefüert, wie si s mache wöue. So git's kei Neuverteilerig. D Leitende Entwickler, wo s Ticket ufgnoh het, isch de verantwortlech. Mehre Entwickler chönne uf em glyche Ticket schaffe, aber de Zuordner wird nie gändert. D Entwickler teile Information mit dr andere Team jedes Tag in dr Form es Stand-up Meeting und beantworte d drei Scrum Froge: 1) Was ha i hüt gmacht? 2) Was mach i bis morgen? 3) Habe i Problem, bi dr ich Hilf bruche?

Blocked Stage

Wenn en Entwickler nöd weiter chönne, wird s Ticket uf Blocked verschobe. Es cha Fehlende Inhalt si, es cha wärtet wärde uf es Reporter oder d Lösung isch nöd gfunde. I eme Kanban Projekt bedütet s In dr Blocked Stage, dass es sichtbar isch, dass es nöd wie erwartet vorwärts goht und bsunders berücksichtigt wärde söll.

Testing Stage

Eimol es Ticket in es Staging oder Testumgebung fusioniert worde isch, wird dr Reporter ufglade, mit em Test z helfe. Es wird natierlech vorher vo de Entwickler gtestet, will das s Standardverhalten vo jedem Entwickler si sött. Persenlich wöue i d Verantwortig vo de Entwickler uf e QA-Team verschiebe, was länger duret. Aber für es paar gröberi und komplexeri Test cha das nödig si und es cha schneller si. Automatischi Test wärde au duregführt.

Done Stage

Eimol es Ticket in d Hauptzweig fusioniert worde isch und somit in Produktion freigee worde isch, wird es als "Done" markiert. Das esch es klari Definition vo "Done".

Wow, du beschribsch es alte Schule Projekt! Haltet a es Bissli, was mir do hei, erlaubt es, dass individuelli Idee/Tickets unabhängig vo de andere dur dr Prozess goht. Das esch d Hauptunterschiid. Au chönne mir jederzit zrugg und vorwärts goh, wenn es gültigi Grund do isch. Das cha nöd mit em Wasserfall Projekt mit allne si Abhängigkeit und Testprobleme vergliche wärde.