Ist Requirement Engineering in Scrum wegweisend?

Question

Die Fragen mögen seltsam erscheinen!

In dem Projekt arbeite ich jetzt, Scrum Methodik wurde von den letzten drei Monaten angepasst. Wir folgten einem V-Modell, wie es in der Embedded-Industrie Standard war.

Unser Projekt geriet in Schwierigkeiten und diese Entscheidung wurde getroffen. Was derzeit getan wird, ist, dass der Kunde (Product Owner) dem Entwicklungsteam die höchste Anforderung direkt erteilt, das Anforderungs-Team ist nur ein Teil davon.

Das Entwicklungsteam arbeitet daran und zeigt dem Product Owner das Endergebnis, und wenn Änderungen erforderlich sind, wird es gemacht. Sobald der Product Owner mit dem Ergebnis zufrieden ist, werden die vorgenommenen Änderungen an die Anforderungen gemeldet und sie werden dokumentiert und an das Testteam weitergegeben.

Was mein Problem mit einem solchen Ansatz ist, dass wir in diesem Prozess technische Anforderungen machen Team und Test-Team obsolet. Sie kommen zu spät in den Prozess.

Funktioniert Scrum so? In diesem Prozess wird alles vom Entwicklungsteam gesteuert und andere sind grundsätzlich mehr oder weniger Zuschauer.

Einige, wo ich sah, dass wir noch das V-Modell innerhalb der Scrum-Methode haben könnten?

Edit:

Ich verstehe die kleinen V-Modell Releases jeden Sprint. Aber meine Frage ist, ob sie alle parallel arbeiten? Zum Beispiel: In dem traditionellen V-Modell, das ein modifizierter Wasserfall ist, gab es immer einen Flow - das Anforderungs-Team wird die Anforderung zu Entwicklung und Test freigeben und sie arbeiten parallel im Design und dann, sobald die Entwicklung abgeschlossen ist, beginnt das Test-Team mit dem Testen . Wie wird dieser Flow in Scrum-Arbeitsweise gehandhabt?

Sie haben erwähnt, dass "der Sprint ist nicht abgeschlossen, bis die Anforderungen und Testteile für jede Geschichte getan werden." In unserem Projekt wird mindestens die Anforderung Teil getan (Test-Team ist völlig aus und die Prüfung ist mehr oder weniger vom Entwicklungsteam auf dem Produkt gemacht). Aber der Anforderungsauftrag ist mehr oder weniger ein Dokumentationsauftrag.,

Das gesamte Gedränge wird von der Perspektive des Entwicklungsteams gesteuert. Wir sehen Szenarien, in denen das Entwicklungsteam entscheidet, wie bestimmte Funktionen funktionieren (weil das ursprüngliche Konzept zu schwierig für sie zu implementieren ist oder komplexer sein kann).

Es gibt keine Erstellung von Grenze auf irgendeiner Ebene! Soll Scrum so arbeiten?

Das Testteam im Projekt ist derzeit mehr oder weniger demoralisiert. Sie wissen sehr genau, dass jedes Problem, das sie auf dem Systemtest-Level finden, nicht viel beachtet wird. Die übliche Entschuldigung vom Entwicklungsteam ist, dass sie das Problem normalerweise nicht auf der Maschine sehen.

Answer 1

Ein separates Requirement-Engineering-Team ist in der Scrum-Arbeitsweise obsolet. Sie sollten alle zusammen arbeiten.

Scrum schlägt vor, dass Sie in multidisziplinären Teams arbeiten und in kleinen Schritten arbeiten sollten. Du kannst dir das so vorstellen, als ob du in jedem Sprint ein kleines V-Modell veröffentlichst. Der Sprint ist erst abgeschlossen, wenn die Anforderungen und Testteile für jede Geschichte erfüllt sind. Sie sollten sie als Teil Ihrer Definition von done betrachten.

Ich würde vorschlagen, ein guter Punkt für Sie ist eigentlich die Scrum Guide zu lesen.Es hat folgendes zu sagen über das Make-up von Entwicklungsteams:

• Entwicklungsteams sind funktionsübergreifende, mit all den Fähigkeiten als Team notwendig, ein Produkt Erhöhungsschritte zu schaffen;
• Scrum kennt keinen Titel für Entwicklung Teammitglieder andere als Entwickler, unabhängig von der Arbeit von der Person durchgeführt wird; dort sind keine Ausnahmen zu dieser Regel;
• Scrum erkennt keine Unterteams im Entwicklungsteam, unabhängig von bestimmten Domänen, die untersucht werden müssen, wie z. B. Test- oder Geschäftsanalysen Analyse; Es gibt keine Ausnahmen von dieser Regel. und,
• Individuelle Entwicklungs-Team-Mitglieder können spezialisierte Fähigkeiten und Schwerpunkte haben, aber die Verantwortung gehört dem Entwicklungsteam als ein Ganzes.

Als Nebenwirkung habe ich einige Erfahrung in einem eingebetteten System mit Agile Methoden arbeiten und wir hatten großen Erfolg automatisierte Tests mit manuellen Testern zu ersetzen. Unsere Tester waren so ziemlich dafür verantwortlich, dass sie die Test-Suite auf verschiedenen Hardware-Systemen laufen ließen und die Tests physisch durchführten. Wir haben die Tests sogar vollständig in den Produktionsprozess eingebaut; Jedes neue Stück Hardware ging (eine Teilmenge davon) durch unsere Testsuite direkt vom Fließband!