it-swarm.com.de

Designdokumente als Teil von Agile

An meinem Arbeitsplatz stehen wir vor der Herausforderung, dass "agil" zu oft "vage Anforderungen, schlechte Akzeptanzkriterien, viel Glück" bedeutet. Wir versuchen, dies als allgemeine Verbesserungsmaßnahme anzugehen.

Als Teil davon schlage ich vor, dass wir Designdokumente erstellen, die über die User Story-Ebene hinaus das Ergebnis vorläufiger Untersuchungen der Wirkung eines bestimmten Features innerhalb des Systems genau widerspiegeln und Antworten auf Fragen enthalten, die wir haben fragte das Geschäft.

Gibt es dafür einen wirksamen Standard?

Wir sind derzeit mit einer Situation konfrontiert, in der eine neue Funktion mehrere Bereiche in unserem "großen Schlammball" System betreffen kann und die Schätzungen aufgrund dieser technischen Verschuldung allmählich steigen. Hoffentlich können durchdachtere Designprozesse helfen.

25
asthasr

"vage Anforderungen, schlechte Akzeptanzkriterien, viel Glück!"

ja, das ist die gleiche Art von Anforderungen, die Sie bekommen, auch wenn Sie versuchen, sie auch festzunageln! (Zum Beispiel war ein 10.000-Anforderungsdokument, für dessen Erstellung ein Regierungskunde 4 Jahre gebraucht hat, immer noch voller Inkonsistenzen, Unbestimmtheiten und sogar intern widersprüchlicher Aussagen. Wenn 4 Jahre Anforderungsdokumentation Ihnen keine anständige, genaue Anforderung liefern können, tun Sie dies Hast du jemals gedacht, dass du etwas Unbestimmtes bekommen kannst?)

Also ... wurde der agile Weg erfunden, um zu verstehen, dass dies nicht passiert, und um damit zu arbeiten, anstatt zu versuchen, dagegen zu arbeiten.

Sie fragen zunächst "Was möchten Sie?" Und der Kunde antwortet mit "So etwas in der Art". Sie arbeiten und gehen dann zurück zum Kunden und sagen "Ist das wie das, was Sie wollten?", Und der Kunde sagt normalerweise "Ja, aber ...", woraufhin Sie fragen "Was möchten Sie".

Schließlich erhalten Sie genau das, was der Kunde wollte, auch wenn er nicht weiß, was das ist! (Hölle, sie nie wissen, was sie wollen, nicht genau).

18
gbjbaanb

Seit wir agil sind, versuchen wir in unserem Team auch einzugrenzen und zu verstehen, wie viel Dokumentation tatsächlich benötigt wird. Ich kann Ihnen mitteilen, was wir bisher gelernt haben.

Lesen Sie vor allem Folgendes Artikel über Agile/Lean-Dokumentation . Sehr gut gelesen.

Zweitens würde ich Ihnen dringend raten, die Erstellung von Designdokumenten nach Vorarbeiten an Geschichten zu überdenken. Wir haben das schon einmal versucht und es hat sich als Verschwendung erwiesen. In der Mitte der letzten Version haben wir beschlossen, die Designdokumente NUR zu aktualisieren, nachdem der Code für die Story geliefert wurde. Und jetzt denke ich, auch das ist zu früh.

Sie müssen sich vor dem Codieren fragen, warum Sie Designdokumente erstellen möchten. Für uns waren dies die Gründe:

  1. Wir als Team müssen verstehen, wie sich die Geschichte auf das Design auswirkt.
  2. Konstruktionsdokumente haben sich als nützlich erwiesen, wenn neue (oder temporäre) Mitglieder dem Team beitreten oder wenn sie zu Code zurückkehren, an dem seit über einem Jahr niemand mehr gearbeitet hat. Sie sind daher nützlich für das organisatorische Gedächtnis, um zu verstehen, wie der Code funktioniert.
  3. Konstruktionsdokumente sind nützlich für Wartungstechniker, die möglicherweise nach der Freigabe Fehler im Code beheben müssen.

Um (1) zu erfüllen, müssen Sie kein tatsächliches Konstruktionsdokument erstellen. Ihr Team sollte vor dem Codieren noch eine Entwurfsphase haben. Diese Phase kann jedoch so einfach sein wie eine 15-minütige Sitzung vor einem Whiteboard oder einer Serviette. Sie müssen kein tatsächliches Dokument erstellen, dessen Erstellung Stunden (wenn nicht Tage) in Anspruch nimmt, nur um die Designänderungen zu besprechen.

(2) oder (3) werden während der Entwicklung der aktuellen Geschichte nicht benötigt und werden höchstwahrscheinlich nicht für mehrere nachfolgende Iterationen benötigt.

Denken Sie auch daran, dass jedes Mal, wenn ein Teammitglied Designdokumente schreibt/aktualisiert, zu diesem Zeitpunkt kein Code geschrieben wird. Wenn Sie Dokumente vor dem eigentlichen Code schreiben, besteht eine fast 100% ige Wahrscheinlichkeit, dass sie aktualisiert werden müssen, da das Design nach dem Start des Codierungsdesigns immer geändert wird. Und selbst wenn Sie Designdokumente nach dem Code schreiben, wie unser Team erfahren hat, ändert das Refactoring aus nachfolgenden Storys das Design.

Also was würde ich empfehlen:

  1. Erstellen Sie zunächst genügend temporäre Designs/Modelle, damit Ihr Team vor dem Codieren ein intelligentes Gespräch führen kann. Erwarten Sie nicht, diese zu behalten, und verschwenden Sie keine Zeit damit, sie zu formalisieren.
  2. Erstellen Sie offizielle Designdokumentationen nur, wenn jemand sie benötigt (d. H. Ihr Team benötigt dringend organisatorisches Gedächtnis).
  3. Erstellen Sie nur Konstruktionsdokumentationen für Code, der stabilisiert wurde. Es macht keinen Sinn, ein Modul zu dokumentieren, das bei jeder Iteration ständig geändert wird.
  4. Erstellen Sie Konstruktionsdokumente, die ein Modul (oder einen Teil des Produkts) vollständig beschreiben. In der Vergangenheit haben wir Designdokumente geschrieben, die die Änderungen dokumentierten, die vorgenommen werden müssen. Diese Dokumente waren völlig wertlos, sobald die Veröffentlichung abgeschlossen war.
  5. Halten Sie das Dokument sehr hoch. Wenn Sie 20 Seiten über Architektur und Design auf sehr hoher Ebene schreiben, wird dieses Dokument a) tatsächlich von anderen Personen gelesen und b) den Personen dabei helfen, sich mit dem allgemeinen Layout Ihres Codes vertraut zu machen. Für Details können die Leute direkt in den Code gehen. Wenn Sie 700 Seiten mit detaillierten Spezifikationen schreiben, stimmen diese fast immer nicht mit der Realität überein. Es ist zu viel für jedermann zum Lesen und Sie müssen 700 statt 20 Seiten pflegen und aktualisieren, wenn zukünftige Änderungen vorgenommen werden.
14
DXM

Das agile "Mantra" darf nicht ganz auf Dokumentation verzichten.

Das Agile-Mantra lautet " Arbeitssoftware gegenüber umfassender Dokumentation ". Beachten Sie jedoch das Bit am Ende des Manifests.

Das heißt, während die Elemente auf der rechten Seite einen Wert haben , schätzen wir die Elemente auf der linken Seite mehr. "

Onkel Bob hat ein gute Richtlinie für die Dokumentation

Erstellen Sie kein Dokument , es sei denn, der Bedarf ist unmittelbar und signifikant .

Sie haben Recht, dass einige Leute Agile als Entschuldigung dafür verwenden, keine Dokumentation zu erstellen, aber das ist schlecht, Agile. Es ignoriert die Bits, die ich in den obigen Zitaten hervorgehoben habe.

Wenn Sie jedoch sagen, dass wir derzeit mit einer Situation konfrontiert sind, in der eine neue Funktion mehrere Bereiche in unserem "Big Ball of Mud" -System betreffen kann, müssen Sie etwas dagegen tun, wenn Sie agil sein möchten.

Wenn Sie Ihre Dokumentation haben, verwenden Sie sie, um Ihren Code zu modularisieren. Auf diese Weise beseitigen Sie die langfristige Notwendigkeit, die Dokumentation zu pflegen (was nicht der Fall ist), indem Sie die langfristige Notwendigkeit für die Dokumentation beseitigen.

dh. Machen Sie die Notwendigkeit sofort und signifikant.

3
pdr

Wenn Sie von schlechten Anforderungen sprechen, fällt mir als Erstes ein, dass Sie die Testkriterien haben. Wenn möglich, erstellen Sie wiederverwendbare automatisierte Testfälle für vorhandene Teile des Systems. Sobald sich alle damit vertraut gemacht haben, schreiben Sie die Testfälle, bevor der Code geschrieben wird. Gute Testfälle können viel dazu beitragen, das Verhalten eines Systems zu dokumentieren.

Welche spezifischen Konstruktionsdokumente verwendet werden sollen, hängt, wie andere bereits gesagt haben, stark von den Bedürfnissen des Teams und der nächsten Aufgabe ab, die sie übernehmen werden. Versuchen Sie nach Möglichkeit, Tools zu verwenden, mit denen Sie die von Ihnen verwendeten Dokumente (aus Code) oder den Code aus dem Dokument generieren können. Die Wartung der Dokumentation kann sehr teuer werden. Wählen Sie daher mit Bedacht aus, wenn Sie ein Designdokument beibehalten.

Persönlich hatte ich gute Erfolge mit Klassendiagrammen, die aus Code- und Fitness-Testfällen generiert wurden. Das Team druckt einige Klassendiagramme aus, führt eine Markup-Sitzung mit dem Product Owner durch und formuliert von dort aus eine Schätzung. Was Fitness betrifft, habe ich das Glück, mit einigen Produktbesitzern zusammenzuarbeiten, die sehr gut darin sind, ihre Wünsche in Tabellen auszudrücken, die dann in Tabellen für Fitness umgewandelt werden.

0
Abstract Class

Die Sache mit Agile ist, dass die Dokumentationsbemühungen wirklich vom Scrum-Team vorangetrieben werden müssen. Wenn die Entwickler nicht der Meinung sind, dass externe Dokumentation für ihre Anforderungen ausreicht, wird die User Story blockiert, bis sie dies tun. Wenn das Unternehmen der Ansicht ist, dass Entwickler keine angemessene Dokumentation erstellen, besteht der Product Owner darauf, diese Teil der Akzeptanzkriterien zu machen. Aus diesem Grund habe ich festgestellt, dass unsere Dokumentation seit dem Wechsel zu Scrum fokussierter und effektiver ist.

Wir verwenden VersionOne , um unsere User Stories zu verfolgen, aber ich bin sicher, dass unsere Methoden auch für andere Systeme gelten. Sie können Dateien an User Stories anhängen. Wir haben festgestellt, dass dies ein äußerst nützlicher Ort ist, um Konstruktionsdokumente zu platzieren.

Für ein Beispiel, das für uns sehr gut funktioniert hat, mussten wir nach dem Bau des Prototyps so schnell wie möglich ein neues Leiterplattendesign testen. Wir haben zwei User Stories für alles erstellt, was getestet werden muss: eine zum Entwerfen des Tests und eine zum Ausführen des Tests. Ein Akzeptanzkriterium für die Entwurfsgeschichte war, dass das Testverfahren vollständig in der Ausführungsgeschichte dokumentiert wurde.

Als wir zum Testteil kamen, lief es reibungsloser als je zuvor. Wir haben gerade die User Story geöffnet und sind Schritt für Schritt vorgegangen. Die Dokumentation war genau das, was wir brauchten, um die Geschichte zu vervollständigen, nicht mehr und nicht weniger.

Wir haben eine andere Geschichte in unserem Rückstand, nur um die Dokumentation für einen von uns verwendeten Chip zu verbessern, damit andere Teams ihn leichter für ihre eigenen Produkte abholen können.

Zusammenfassend lässt sich sagen, dass die Lösung, wenn Sie der Meinung sind, dass Ihre Dokumentation darunter leidet, so einfach ist, wie eine separate User Story zu erstellen und/oder sie zu einem Teil der Akzeptanzkriterien zu machen.

0
Karl Bielefeldt