Wir sind ein kleines mobiles Entwicklungsteam (6 Entwickler, 3 QA, 1 Teamleiter). Wir sind ein bisschen neu in der Agilität und lernen gerade die Seile/machen Fehler, während wir gehen. Das gesamte Team berichtet an einen Projektleiter in einem anderen Land, der wiederum direkt mit dem Kunden spricht. Dies geschieht aufgrund von Sprachbarriereproblemen.
Wir versuchen derzeit, ein agiles Vorgehen zu adaptieren, bei dem wir wöchentliche Scrums durchführen. Hier ist der aktuelle Ablauf für jede Version:
Mir ist bewusst, dass nicht jedes Problem oder jeder Fehlerfall in den Spezifikationen in Schritt 2 bestimmt wird und in späteren Phasen der aktuellen Version noch auftreten kann. Es gibt jedoch Zeiten, in denen die Entwickler in Schritt 4 immer noch Fälle (manchmal Randfälle) erhalten, in denen sie behaupten, dass die Fälle behandelt werden müssen, und wir Schritt 2 erneut wiederholen sollten. Es verschafft dem Team derzeit einen schlechten Ruf beim Manager und höchstwahrscheinlich dem Unternehmen beim Kunden. Ist es für diese Art von Problemen besser:
Mir ist bewusst, dass dies von Fall zu Fall gilt, aber allgemein gesagt, was wäre besser? Oder gibt es noch andere Lösungsmöglichkeiten?
Der Hauptgrund, warum Agile entstanden ist, ist, dass die Menschen erkannt haben, dass Veränderungen in der Softwareentwicklung unvermeidlich sind. Diese Änderung stammt aus mehreren Quellen:
Viele Jahre lang haben Menschen versucht, Veränderungen zu bekämpfen. Sie versuchten, die Anforderungen im Vorfeld besser zu erfüllen. Sie versuchten, Kontingenzen für unerwartete Ereignisse zuzulassen. Nichts davon hat wirklich geholfen.
Ihre beiden Vorschläge folgen diesem Muster.
Hier kam Agile ins Spiel. Mit Agile werden Veränderungen nicht nur akzeptiert, sondern sogar gefördert . Sobald Sie akzeptieren, dass Veränderungen stattfinden werden, können Sie Ihre Prozesse darauf aufbauen.
Mein Rat wäre, sich für eine agile Lösung zu entscheiden. Erwarten Sie Veränderungen. Legen Sie nicht fest, wie lange Sie denken, dass die Dinge dauern werden, sondern lassen Sie Flexibilität zu. Erwarten Sie jedes Mal, wenn Sie Ihren Kunden etwas zeigen, Feedback zu erhalten und Änderungen vornehmen zu müssen.
Du läufst also agil. Sie haben eine Sprint-Planungssitzung und der Kunde möchte einen Herd in seiner Küche an der Nordwand zwischen den Schränken installieren. Die Entwickler stellen die richtigen Fragen.... Was ist die Größe des Ofens, welche Farbe, Gas oder Strom, Btu-Leistung usw.
Nun ... siehe da, eine Woche nach der Installation stellen die Entwickler fest, dass die Arbeitsplatteninstallateure etwas Überhang auf ihren Arbeitsplatten hinterlassen haben und der Ofen nicht an seinen Platz passt.
Ihr Lösungsvorschlag lautet: "Die Anforderungen sind festgelegt ... Holen Sie sich einen Abschleppwagen und eine Kette und drücken Sie das Gaspedal, bis der Saugnapf passt".
Meine Frage ist, wenn der Kunde nicht verfügbar ist, wer ist dann der Product Owner? Ein 20-minütiges Gespräch mit einem Product Owner würde entscheiden, ob:
Es hört sich so an, als ob das Problem darin besteht, dass der Kunde nicht verfügbar ist und niemand als Product Owner auftaucht, um in die Fußstapfen des Kunden zu treten und nach bestem Wissen und Gewissen zu entscheiden. Jemand muss nur sagen „Nimm den kleineren Ofen und sag dem Kunden, warum wir das gemacht haben“. Niemand will Eigentum übernehmen.
Es klingt, als würdest du Scrum machen. Das Scrum-Framework bietet Ihnen zwei Antworten, die Sie beide schnellstmöglich umsetzen sollten.
Der springende Punkt eines Product Owners ist jemand, der dem Team in hohem Maße zur Verfügung steht und die Befugnis hat, Entscheidungen zu treffen. Ein Zitat: „Ein guter Product Owner sollte sicherstellen, dass Ihre Fragen in 85 % der Fälle innerhalb von 5 Minuten beantwortet werden.“ - Jim York.
Ihr Projektmanager fungiert möglicherweise als Product Owner, aber dies sollte ausdrücklich klar sein, und diese Person muss verfügbar und befugt sein, Entscheidungen zu treffen.
Wenn Sie keinen richtigen Product Owner finden, sollten Sie vielleicht etwas anderes als Scrum machen.
Transparenz, Inspektion und Anpassung sind die Säulen von Scrum. Der Sinn von Scrum (und Agile im Allgemeinen) besteht nicht darin, jede Frage im Voraus zu beantworten, um „es gleich beim ersten Mal richtig zu machen“. Es geht darum, etwas zu bauen, das funktioniert, Feedback dazu zu erhalten und es dann zu verbessern.
Sie müssen nicht jede einzelne Entscheidung, die Sie treffen müssen, mit dem PO prüfen, bevor Sie mit der Arbeit beginnen. Die Idee ist, dass die Entwickler gute Entscheidungen treffen, ihre Arbeit für Feedback präsentieren, z. B. beim Sprint Review, und dann iterieren, um sie zu verbessern.
Ein Beispiel
Nehmen wir an, die PO bittet Hausbesitzer, den Datumsbereich anzugeben, wie lange sie in ihrem vorherigen Haus gelebt haben.
Bevor Sie den PBI in Ihren Sprint aufnehmen, erhalten Sie eine Klarstellung, dass dies nur Datumsbereiche in der Vergangenheit abdecken sollte und dass es ein Enddatum geben muss, da es sich um das Haus handelt, in dem sie derzeit nicht leben (gute Arbeit!).
Nachdem Sie begonnen haben, fragen Sie nach und bestätigen Sie, dass der Datumsbereich die ausgewählten Daten (einschließlich) enthalten sollte. Der PO antwortet sofort.
Wenn Sie fast fertig sind, stellen Sie fest, dass Ihre Lösung keine einen Tag langen Bereiche zulässt. Der PO ist krank, also treffen Sie die Entscheidung, bei Ihrer derzeitigen Lösung zu bleiben, da es wirklich unwahrscheinlich erscheint, nur einen Tag in einem Haus zu leben.
Beim Sprint Review weisen Sie darauf hin, dass Datumsbereiche mindestens zwei Tage betragen müssen. Der PO gibt zu, dass Sie eine vernünftige Annahme hatten, aber dass es zahlreiche Beispiele für einen eintägigen Aufenthalt im Altsystem gibt, also möchte er sicherstellen, dass das neue System auch damit umgehen kann. Die PO erstellt eine neue PBI, um Hausbesitzern die Eingabe von eintägigen Datumsbereichen zu ermöglichen, und verschiebt sie an die Spitze des Rückstands.
Rundum gute Arbeit!
Sie bauen basierend auf dem, was zu diesem Zeitpunkt bekannt ist. Wenn während der Entwicklung etwas entdeckt wird, kann es in eine weitere „Schritt 2“-Diskussion gehen.
Wenn das Team oder der Produktmanager möchten, dass die Spezifikation vor Arbeitsbeginn fertig ist und Änderungen daran nicht akzeptabel sind, dann stellt sich die Frage, ob Sie keine agile Softwareentwicklung betreiben oder nicht.
Sehen Sie sich das Manifest für agile Softwareentwicklung an: http://www.agilemanifesto.org/ Die vier Werte und zwölf Prinzipien sind mächtig.
du hast recht, es ist immer eine situative entscheidung. Je besser Sie wissen, was der Kunde von dem Projekt/der Phase/dem Sprint erwartet, können Sie als Team lernen, wo Sie als Team aus der Anwendung Nutzen ziehen.
Hoffe das hilft.
Stimme @Barnaby Golden voll und ganz zu
Das sind die Herausforderungen, für die Agile gedacht ist. Es ist immer schwierig für ein Team, sich zu verändern, insbesondere wenn es um die Beratung externer Kunden geht.
Der Schlüssel hier ist die Ausbildung. Investieren Sie in eine qualitativ hochwertige Schulung für das gesamte Team und beziehen Sie auch die BAs und Verkaufsteams mit ein, damit alles verstanden und dem Kunden vermittelt wird.
Gummiente
Garmanarnar