Lassen Sie mich zunächst klarstellen, dass ich ein Softwareentwickler bin und diese ISO-Hilfe mit dem Wunsch schreibe, mein Projektmanagement agil zu gestalten und eine Zustimmung für die Änderung einer allgemeinen requirements documentationTechnik zu erhalten, der mein Team folgt. Bitte verwechseln Sie es nicht mit der Suche nach Ratschlägen zum Personalmanagement, ich bin mir bewusst, dass dies in diesem Forum kein Thema ist.
Ich werde versuchen, es einfach und klar zu machen. Als ich vor ein paar Monaten in meine Vertragsposition eingestellt wurde, wurde mir gesagt, dass das Team folgte Agile, aber nicht ganz, und dass sie offen dafür seien, weitere Fortschritte in dieser Richtung zu machen. Einmal begonnen, stellte ich fest, dass die eingeflößten Arbeitsgewohnheiten und -verfahren immer noch sehr gut sind waterfallund dass sehr umfassende Anforderungsdokumente manchmal mehrere Monate vor Beginn einer Entwicklung geschrieben werden. Mit „umfassend“ meine ich, dass eine Anforderung zwar eine kohärente und zusammenhängende Funktionseinheit abdeckt, aber keinesfalls atomar ist und weiter in eine Hierarchie individuell atomarer, wenn auch voneinander abhängiger Arbeitseinheiten zerlegt werden kann.
Meine Hoffnung war, dass jede atomare Einheit des Fortschritts, was bedeutet, dass es nicht möglich ist, sie weiter in kleinere Stücke zu zerlegen, ihr eigenes sprint/iterationund ihr eigenes Anforderungsdokument haben sollte. Aus der Entwicklungsperspektive besteht ein klarer Vorteil darin, dass ich kein umfassenderes Anforderungsdokument erfassen muss, wodurch ich mich mehr auf die unmittelbar anstehende Aufgabe konzentrieren kann, was zu einer besseren Arbeitsqualität führt. Es ist, als würde man zwei verschiedene Aufgaben für den Einbau einer Tür und das Streichen eines Raums erhalten, wenn die beiden bequem in zwei Aufgaben aufgeteilt werden können: Sie montieren zuerst die Tür, dann streichen Sie den Raum. In unserem aktuellen Setup handelt es sich um ein einzelnes Anforderungsdokument, was es schwierig macht, die Besonderheiten der konkreten Aufgabe in einem Dokument zu erfassen oder gar zu finden, das auch andere Aufgaben umfasst.
Ich stelle diese Frage, um zu bestätigen, dass meine Idee der offiziellen Agile-Doktrin entspricht und ich mich nicht missverstehe. Sollten die agilen Anforderungen immer so gering wie möglich sein oder bringt es Vorteile, mehrere voneinander abhängige Arbeitsaufgaben in einem umfassenden Dokument zu bündeln? Aus der Perspektive meiner kognitiven Stile und Vorlieben würde es mir ermöglichen, die Projektmanagementseite des Teams break down the work into individual atomic taskszu haben, es mir ermöglichen, weniger Projektmanagement selbst zu machen und mich tatsächlich mehr auf das Kodieren zu konzentrieren, anstatt Inkremente in Richtung des endgültigen Ziels zu strukturieren. Ein weiterer Vorteil besteht darin, dass es viel einfacher wäre, LOE- und Fertigstellungsschätzungen für eine enger gefasste Aufgabe als für ein ganzes Projekt zu geben.
Verweise:
Wo ist der Work Breakdown Structure (WBS) in Agile?
Wie überzeugen Sie einen Kunden, agile Methoden zu verwenden?
Es hört sich so an, als würden Sie die Unterschiede zwischen einem Product Backlog und einem Sprint Backlog und vielleicht einem Release Backlog in der Mitte beschreiben.
Product Backlog- Alles, was im Produkt gewünscht wird. Dies kann eine endliche Liste (eine PRD) oder eine lebende Liste sein, die ständig ergänzt und neu priorisiert wird.
Release Backlog – Dies ist nicht in den grundlegenden Scrum-Richtlinien enthalten, aber denken Sie daran, dass Scrum ein Framework ist, das angepasst werden kann. Eine häufige Änderung, insbesondere bei großen Projekten, besteht darin, das Projekt in "Releases" aufzuteilen. Wenn das Produkt so ist, dass es nicht in jedem Sprint „lieferbar“ sein kann (Legacy-Code, tiefe Integration in andere Systeme usw.). Die „Freigabe“ ist dann ein vorläufiger Meilenstein, an dem das Produkt potenziell versandfähig wäre. Releases haben oft ein Kernthema wie „Kerninfrastruktur erstellen“. Das Release Backlog enthält alle Storys, die für ein bestimmtes Release gewünscht werden. Ingenieure würden immer noch entscheiden, in welcher Reihenfolge und wie sie gebaut werden.
Sprint Backlog – Dies ist, was die Entwickler in einem bestimmten Sprint aufbauen möchten. Sie ziehen von der Spitze des Backlogs, ziehen aber möglicherweise nicht immer das oberste Element basierend auf Gruppierungen wie Storys, technische Abhängigkeit usw. Dies sollte mit dem Product Owner (Manager) erfolgen.
Basierend auf Ihrer Frage könnten Sie also, wenn Sie Releases einrichten, Release Backlogs erstellen.
Ich bin mir jedoch nicht sicher, ob dies Ihr Problem lösen wird. Von dem, was Sie beschrieben haben, klingt es so, als ob Ihr Anforderungsprozess ziemlich weit von Agilität entfernt ist. Dies neutralisiert so ziemlich alle Vorteile, die das Engineering durch das Arbeiten in einem Sprint-/Iterationsmodell hat. Das beste agile Entwicklungsteam der Welt kann keine Spitzenleistung erreichen oder einen großen Wert liefern, wenn es Müllanforderungen oder starre Anforderungen erhält.
Im agilen Ansatz gibt es nichts, was die Größe der Anforderungen vorgibt. Scrum, ein agiles Framework, legt fest, dass der für einen Sprint geplante Arbeitsaufwand innerhalb des Sprints erledigt werden sollte. Das würde eine maximale Größe einer Anforderung implizieren, die einen Sprint (typischerweise 1-4 Wochen) nicht überschreitet.
In der Praxis wird in der agilen Community jedoch viel über eine angemessene Größe der Anforderungen beim agilen Arbeiten diskutiert. Denken Sie daran, dass eine der Grundlagen von Agile die Fähigkeit ist, auf Veränderungen zu reagieren. Wenn Sie auf Veränderungen reagieren wollen, ist eine umfassende, grobkörnige Anforderungsdokumentation eher ein Hindernis als ein Vorteil.
Ein beliebter Ansatz zur Größenbestimmung ist die INVEST-Mnemonik . Dies steht für
„Skalierbar“ bezieht sich darauf, die Anforderungen klein genug zu machen, um sie mit einiger Sicherheit abschätzen zu können. Viele agile Teams verstehen darunter eine typische Größe von wenigen Personentagen.
Hier können Sie mehr über die INVEST-Mnemonik lesen
Eine weitere Überlegung ist das agile Prinzip, häufig funktionierende Software auszuliefern. Dies würde darauf hindeuten, dass kleiner besser ist, da dies eine häufigere Lieferung ermöglichen würde.
Lassen Sie mich versuchen, Ihre Frage im Zusammenhang mit Scrum zu beantworten, dem beliebtesten agilen Prozess.
Ja, Sie sollten User Stories in Form kleiner, vertikaler Funktionsabschnitte haben, die dem Benutzer einen kleinen Mehrwert beschreiben. Wenn Sie jedoch Ihre Frage lesen, sieht es so aus, als würden die folgenden Erläuterungen zum agilen User-Story-Prozess hilfreich sein:
User Stories, wie sie ursprünglich vom Product Owner geschrieben wurden, sind keine schriftlichen Verträge oder Anforderungen, die die Software erfüllen muss. Vor dem Sprint Planning treffen sich der Product Owner und das Entwicklungsteam, um die priorisierten Stories im Backlog zu verfeinern. Sie brauchen etwas Flexibilität, damit Sie anpassen können, wie viel von der Geschichte implementiert wird. User Stories richtig gemacht: Anforderungen. Siehe die Folie mit dem Titel „Verhandelbar“.
Der Product Owner sollte mit dem Entwicklungsteam zusammenarbeiten, um die Geschichten zu verfeinern und Akzeptanzkriterien hinzuzufügen, was Mike Cohn Bedingungen der Zufriedenheit nennt .
Es liegt jedoch ganz beim Entwicklungsteam, herauszufinden, wie die User Story implementiert und in kleinere technische Aufgaben aufgeteilt wird. Ein gutes Beispiel finden Sie in diesem Artikel How to Break a User Story into Tasks .
Tob