Wo würden Sitzungen zur gemeinsamen Anwendungsentwicklung in das Scrum-Framework passen?

Ich arbeite daran, die Projektmethodik meines Teams vom Wasserfallmodell auf ein agiles Modell umzustellen. Ich betrachte das Scrum-Framework als Ausgangspunkt.

Derzeit haben wir diese Sitzungen zur gemeinsamen Anwendungsentwicklung , bei denen das Team mit unseren Stakeholdern zusammenkommt, um Anforderungen zu definieren. Diese Sitzungen werden häufig bei "traditionellen" IT-Regierungsprojekten verwendet, daher möchte ich sie beibehalten, um die Reibung zu verringern. Ich bin mir jedoch nicht sicher, welcher Scrum-Zeremonie diese Meetings zugeordnet sind, oder ob es besser wäre, die Stakeholder davon zu überzeugen, sie loszuwerden.

Gute Frage, aber verwenden Sie bitte keinen nicht verknüpften Initialismus für Joint Application Design , was kein Scrum-Begriff ist.
@NathanCooper: Ich weiß, das ist kein Scrum-Begriff.

Antworten (4)

Die Erfassung der Anforderungen wird während der gesamten Lebensdauer des Projekts vom Product Owner durchgeführt. Typischerweise findet ein Großteil davon statt, bevor das Entwicklungsteam mit dem Sprint beginnt, aber am Ende jedes Sprints findet ein Sprint-Review-Meeting statt, bei dem der Product Owner und die Stakeholder den aktuellen Status des Projekts und des Produkts einsehen können. Dadurch können die Anforderungen dann verfeinert werden.

Was offizielle, formelle Meetings anbelangt, die Teil von Scrum sind, gibt es nur solche aus dem Scrum Guide . Das Daily Standup, die Retrospektive, das Planungsmeeting und der Review. Alles darüber hinaus ist Teil der Vorgehensweise einer bestimmten Organisation, nicht Teil von Scrum selbst.

Ich weiß das, aber ich war mir nicht sicher, ob es einen formellen Ort für Sitzungen zur gemeinsamen Anwendungsentwicklung geben sollte, da Regierungsprojekte sie lieben.
@J.Bauer Nicht offiziell, nein. Ich habe meine Antwort aktualisiert.

In diesem Fall ist JAD also eine Version der Erfassung von Anforderungen. Der PO kann diese jederzeit einplanen, um seine Anforderungen zu erfüllen und seine Epic-/User-Story-Details zu verbessern.

Das Scrum-Team sollte jedoch so weit wie möglich davor geschützt werden. Wenn sie die Entwicklungszeit des Teams im aktuellen Sprint stehlen, würden sie gegen die Scrum-Bedingungen verstoßen.

Es kann notwendig sein, sich mit dem Scrum-Team zu beraten, um einige Aspekte der Anforderungen zu klären ... sollte aber nur in Ausnahmefällen erfolgen.

In agilen Teams gibt es normalerweise 5 Planungsebenen:Geben Sie hier die Bildbeschreibung ein

Diese Ebenen sind in der Regel an einen Zeitrahmen oder einen sogenannten „Planungshorizont“ gebunden, dh die Menge an Details, auf die wir in diesem Moment eingehen, basiert auf der Zeitachse unserer Ziele und Erwartungen. Die Genauigkeit unserer Diskussionen reicht von einer Meile Breite und einem Fuß Tiefe für die Produktvision bis zu 100 Fuß Breite und 1000 Fuß Tiefe für jede Iteration.

In Scrum finden Anforderungsdiskussionen auf allen Ebenen der Planung statt und finden täglich statt. Kadenzbasierte Zeremonien setzen klare Erwartungen für die größeren Diskussionen. In Scrum haben Sie normalerweise alle paar Monate ein Release-Planungsereignis, mit Sprint-Planung alle 2-3 Wochen und Backlog-Refinement-Sitzungen ~ 2 oder mehr Mal pro Sprint und dann täglichen Standups.

Die meisten Scrum-Teams beginnen mit einer Iteration 0, die kein Sprint ist, und während der das Team die Produktvision, die Produkt-Roadmap und die Release-Planungsaktivitäten für den ersten Sprint weiter konkretisiert. Dies geschieht normalerweise durch Workshops und Aktivitäten im Laufe von ein paar Tagen. Ich empfehle, Jonathan Rasmussons The Agile Samurai zu lesen, da es eine Menge großartiges Material zum Aufbau eines agilen Teams mit einem „Inception Deck“ enthält.

https://www.amazon.com/Agile-Samurai-Software-Pragmatic-Programmers/dp/1934356581/ref=sr_1_1?ie=UTF8&qid=1514494663&sr=8-1&keywords=the+agile+samurai

Lassen Sie mich fragen, warum Sie den Wechsel zu Scrum in Betracht ziehen? Der Übergang zu Scrum ist im Vergleich zu einem Übergang zu Kanban viel schwieriger . In diesem Artikel sprechen wir über die Implementierung eines Kanban -Projektstrukturplans mithilfe der Kanban-Methode und die schnellstmögliche Ausführung der Arbeitselemente. Mit anderen Worten, wir schlagen einen Übergang von Wasserfall (PSP ist ein typischer Wasserfallansatz) zu Kanban vor, einem leichtgewichtigen agilen Ansatz.

Dieser Ansatz ermöglicht es Ihnen nicht nur, das zu tun, was Sie bisher getan haben (und sich kontinuierlich zu verbessern), sondern beschleunigt die Dinge auch lächerlich (bis zu 700 %). Ich hoffe, das klingt nicht wie ein Verkaufsgespräch, denn das ist es nicht, aber Kanban kann wirklich Wunder für Sie bewirken.

Ich bin der Meinung, dass diese Antwort die Frage nicht beantwortet, obwohl Sie einen guten Punkt zu Überlegungen bei der Auswahl einer Prozessmethodik ansprechen.
Wo würden Sitzungen zur gemeinsamen Anwendungsentwicklung in das Scrum-Framework passen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v