Wie misst ich die Projekt Vollständigkeit? [abgeschlossen

Question

Gibt es formelle/informelle Maßnahmen zum Vergleich der abgeschlossenen Funktionen im Vergleich zu den ersten Anforderungen eines Projekts? Insbesondere ist mein Ziel, alle verpassten Anforderungen frühzeitig in einem Projekt zu identifizieren. Nachdem ich viele Artikel und Bücher von Agile/Scrum Methodik durchgemacht hatte, wäre eine Möglichkeit, dies zu tun, während eines "Sprint -Review" eine Anforderungenüberprüfung, aber ich habe mich gefragt, ob es da draußen andere Techniken/Tools gab.

Vielen Dank,

Answer 1

Gibt es formelle/informelle Maßnahmen zum Vergleich der abgeschlossenen Funktionen im Vergleich zu den ersten Anforderungen eines Projekts?

Das Wort, nach dem Sie suchen, ist "erledigte Kriterien". Es hat eine tiefere Bedeutung als die Worte selbst in der agilen Welt. Es ist oft das erste, was in einer agilen Organisation repariert werden kann, wenn festgestellt wird, dass es fehlt. Unten (am Ende) befindet sich ein Link zu einem Artikel, der ihn ausführlicher erläutert.

Die meisten agilen Teams verwenden Benutzergeschichten als "anfängliche Anforderungen". Die Benutzergeschichte wäre Ihre ersten Anforderungen, die gerade ausreichen würden, um das Team zu starten. Die verwendete Maßnahme sollte das sein, was die meisten Teams als "Kriterien" bezeichnen. Jede Benutzergeschichte sollte ein Kriterium erstellen. Für zB. Um einen Backlog zu rufen, der erledigt ist, müssen diese Liste der Dinge erledigt werden. Während wir dies festlegen, machen wir uns keine Sorgen darüber, wie es getan werden würde, sondern nur, was getan werden muss.

Während des Sprint -Reviews würde das Team eine Show machen und über die Arbeitssoftware erzählen, und wenn es die erledigten Kriterien erfüllt, sollte die PO sie genehmigen, um offiziell ausgeführt zu werden.

Ohne Kurs haben Benutzergeschichten manchmal Kriterien geändert, insbesondere für neue Teams oder Projekte, aber das ist völlig normal, da ein Zeichen einer guten Benutzergeschichte ist, dass sie verhandelbar ist. Die erledigten Kriterien können nach der Genehmigung des Teams leicht geändert werden. Die Teams missbilligen diese selten, es sei denn, die Änderung führt zu einer dramatischen Zunahme der Komplexität der Arbeit.

Also zusammenfassen:

Erste Anforderungen, dh Benutzergeschichten müssen über "Was" Kriterien erledigt werden "müssen. Wenn während des Sprint etwas verpasst und entdeckt wird, kann die PO die erledigten Kriterien einer Benutzergeschichte ändern, nachdem sie eine Genehmigung des Teams erhalten hat.

Während der Sprint -Bewertungen kann die Arbeitssoftware anhand der erledigten Kriterien gemessen werden, und wenn sie misst, kann die Benutzergeschichte bezeichnet werden.

http://scrumalliance.org/articles/105-what-is-definition-of-done-dod

Answer 2

In einem agilen Ansatz werden Änderungen der Anforderungen erwartet und als gesund angesehen. Die Reaktion auf Veränderungen wird als wichtiger angesehen als ein Plan zu folgen.

Eine Sprint -Überprüfung ist ein Ort, um Feedback und neue Anforderungen zu sammeln. Usability -Tests helfen ebenfalls. Was aber am meisten hilft, ist die Software durch ein QA -Team und/oder die tatsächlichen Benutzer.

Wenn Sie JIRA und Greenhopper für die Verwaltung Ihrer Anforderungen (als Geschichten) verwenden, finden Sie möglicherweise hilfreich eine Suche nach Geschichten, die nach einem bestimmten Datum erstellt wurden. Das Finden modifizierter Anforderungen wäre interessanter.

Answer 3

Ist Software jemals vollständig? Offensichtlich ist der eigentliche Maßstab für Vollständigkeit der Denkansicht eines Menschen, was die Software sollte tun.

Der Versuch, gegen das mentale Bild einer Person zu messen, wird letztendlich eine Herausforderung sein, und keine formelle Methode wird es jemals wirklich gut machen. Das einzige, woran Sie messen können, sind die Anforderungen, die sie Ihnen geben. Sie können sich nicht adressierte Anforderungen ansehen, aber Sie können niemals die Lücke dessen messen, was sie Ihnen nicht gesagt haben.

Die Botschaft, die ich von der Agile School of Denk erhalten habe, ist, dass die Messung der Vollständigkeit eine Art Zeitverschwendung ist - es ist wirklich die falsche Frage.

Beispielsweise machen Sie mit Scrum einen priorisierten Rückstand aller Anforderungen und beginnen einfach auf der Liste zu arbeiten. Wenn das Geld/Wunsch ausgeht ... hörst du auf.

Answer 4

Wenn Sie die agile/scrum -Route besuchen, wie Sie es implizieren, sollten Sie das Projekt im Allgemeinen in kleine diskrete Anstrengungseinheiten zerlegen. Ein Projekt enthält Epen (oder ist ein Epos), ein Epos enthält Geschichten, eine Geschichte enthält Aufgaben. (Eine Aufgabe sollte idealerweise 4-8 Stunden Arbeit sein. Etwas, das jemand in einem Arbeitstag tun kann.)

Nach Abschluss jeder Geschichte sollte sie getestet und verifiziert werden. Dies wird im Allgemeinen nicht für Aufgaben erledigt, da häufig eine einzige Aufgabe von einem Benutzer getestet werden kann, wenn andere Aufgaben für die Geschichte abgeschlossen sind. Von einem Benutzer kann nicht erwartet werden, dass er "eine Methode schreiben, um eine Bestellung in die Datenbank zu bestehen", sondern stattdessen testen ", wenn diese Schaltfläche klickt, die Bestellung in der Datenbank bestehen und dem Benutzer ein aktualisierter Einkaufswagen angezeigt werden, um einbezogen zu werden Neukalkulierte Steuern und Versand. "

Diese Prüfung/Überprüfung ist nicht vom Entwickler gemacht. Es sollte von jedem überprüft werden, der für das Produkt/Projekt oder einen Delegierten verantwortlich ist. Der Entwickler wird es natürlich so testen, wie er oder sie es geschrieben hat, und erwartet, dass es so funktioniert. Wenn irgendetwas in den Anforderungen falsch interpretiert würde, würde es nur wieder falsch interpretiert.

Da jede Geschichte als vollständig überprüft wird, ist sie ein diskreter und messbarer Schritt in Richtung Projektabschluss. (Messbar durch die Anzahl der Aufgaben und damit, wie viel Arbeit in Richtung der Summe abgeschlossen wurde.)

Beachten Sie, dass solche Messungen von einem Sprint zum nächsten ändern können. Wenn das obere Management nach einer einzelnen Straße mit vervollständigen Schritten auf dem Weg bis zum Ende des Projekts sucht, versteht sie möglicherweise ein grundlegendes Konzept in der agilen Entwicklung. Die Geschichten weiter unten wurden noch nicht vollständig definiert. Sie können mehr oder weniger Arbeiten beinhalten als ursprünglich geschätzt, basierend auf der Entwicklung (und Änderungen an) der unmittelbaren Geschichten.

Eine Möglichkeit, sich dem Konzept von fließenden Geschichten und sich ändernden Anforderungen zu nähern, besteht darin, nicht an "Projekte" zu denken, sondern nur Epen und Geschichten. Diese diskreten Einheiten sollten für sich genommen vollständig bearbeitbar und überprüfbar sein (obwohl einige natürlich andere als Voraussetzungen haben). Das Ändern der Prioritäten kann die Geschichten nach Belieben verschieben. Ein "Projekt" muss nicht "auf Eis gelegt" werden, wenn sich die Prioritäten ändern. Seine Geschichten werden einfach anstelle anderer Geschichten auf den Rückstand verschoben.

Die Idee ist, dass das Management steuert, wohin Sie als nächstes gehen, und nicht nur eine Liste von Zielen zu geben und zu hoffen, dass Sie sie in der richtigen Reihenfolge ankommen.

In diesem Sinne verliert die "Vollständigkeit" eines "Projekts" fast ausschließlich seine Bedeutung. Wie viel ist "vollständig" an jedem, der das Produkt/Projekt gehört? Sie können es hinzufügen oder nach Belieben aus dem Willen entfernen, die Prioritäten leicht verschieben usw. Wenn sie wissen möchten: "Wann werden wir am Ziel A ankommen?" Dann liegt das an ihnen. Sie haben ihnen Schätzungen gegeben, wie viel Arbeit in jeden Schritt auf dem Weg involviert ist.