Betrachten Sie einen agilen Ansatz. Ich meine, wenn Sie die Zeitressourcen und die hervorragenden Schreibfähigkeiten haben, um jede Designentscheidung aufzuschreiben, die Sie mit ihren Begründungen treffen, dokumentieren Sie einfach alles. Realistisch gesehen gehe ich davon aus, dass Sie nicht in einer solchen Position sind. Ein agiler Ansatz kann bei einer zentralen Herausforderung für die Dokumentation von Rationalen hilfreich sein: Oft wissen Sie erst später, welche Rationalen wichtig waren.
Gehen wir das Problem ganzheitlich an. Ihr habt Gründe für eure Entscheidung. Sie sind gerade in Squishyware gefangen, dem Gehirn des Teams. Trotz der Menge an Kreditdokumenten ist das Speichern von Rationalen in sqishyware gar nicht so schlecht. Wir sind als Spezies wirklich gut darin, uns an die wichtigen Dinge zu erinnern. Deshalb verfügt jedes große Unternehmen über "Stammeswissen", auch wenn diese Unternehmen versuchen, all dieses Stammeswissen zu dokumentieren.
Jetzt hast du ein Problem. Sie stellen fest, dass die sqiushyware nicht gut genug an den Begründungen festhält. Gut für Sie, wenn Sie feststellen, dass es ein Problem gibt und feststellen, dass es gelöst werden muss! Das ist nicht immer ein einfacher Schritt! Wir sind uns ziemlich sicher, dass die Lösung darin besteht, einige dieser Überlegungen in die Dokumentation zu verlagern. Das reicht jedoch nicht aus. Wir können niemals die zweite Hälfte des Puzzles vergessen, die darin besteht, das Grundprinzip in die Squishyware zu laden, wenn Sie eine Entscheidung treffen müssen. Ich habe viele Teams gesehen, die alles wie verrückt dokumentieren, aber der Inhalt ist eigentlich nicht so organisiert, dass er gute Entscheidungen ermöglicht. Deshalb vergessen sie Rationales , obwohl sie aufgeschrieben sind .
Sie haben also einen zweistufigen Prozess. Sie müssen die Gründe aus der Squishyware heraus und in die Dokumentation einfließen lassen. Dann müssen Sie sicherstellen, dass die Dokumentation gut genug organisiert ist, um das Rationale bei Bedarf wieder in Squishyware umzuwandeln! Jetzt haben wir meines Erachtens genug von einer Problemstellung, um zu erkennen, wo die Herausforderungen liegen werden. Wenn Sie dokumentieren, wissen Sie normalerweise nicht, wer es später ansehen wird oder wonach sie suchen. Wenn Sie auf die Dokumentation zurückblicken, wissen Sie in der Regel nicht, wonach Sie suchen (bestenfalls wissen Sie, wann).
Ein großes Unternehmen könnte versuchen, dies in zwei großen Blöcken zu handhaben. Erstens können sie Anforderungen entwickeln, die auf den Bedürfnissen der Benutzer bei der Recherche der Dokumentation basieren. Dann verwenden sie diese Anforderungen, um einen Prozess für die Entwicklung dieser Dokumentation zu erstellen. Und wenn ich es so sagen darf , dann beschwert sich jeder, denn fast niemand weiß genau, wie die Dokumentation am ersten Tag aussehen soll. Die Dokumentation ist immer unvollständig und die Entwickler beschweren sich immer, dass der Prozess zu aufwändig ist.
Zeit, agil zu werden.
Mein Rat wäre, agile Anstrengungen zu unternehmen, um Ihren Dokumentationsprozess zu verbessern: Die gesamten neun Meter von Squishyware über Dokumente bis hin zu Squishyware. Erkennen Sie im Voraus, dass Sie einige Informationen verlieren werden, weil Ihr Prozess nicht perfekt ist, aber das ist in Ordnung, weil Sie immer noch versuchen, den Prozess herauszufinden! Sie würden mehr vermissen, wenn Sie versuchen, eine Einheitsgröße zu schaffen.
Ein paar besondere Leckerbissen, die ich mir ansehen möchte: * Informelle Dokumentation durchsehen. Formale Dokumentation ist großartig, aber zeitaufwändig. Zu den Zwecken der Dokumentation gehört es, Informationen von Entwickler-Squishyware freizugeben und auf Papier zu bringen. Informelle Dokumentation reduziert die Kosten auf ein Minimum.
- Akzeptieren Sie unzuverlässige Dokumentationsformate. Nichts wird beim ersten Mal richtig sein. Es ist besser, die Daten abzurufen und später herauszufinden, wie sie zuverlässig sind. Beispielsweise könnten Sie Ihre Begründungen in einem <rationale> </ rationale> Block oder einem ähnlichen Dokument dokumentieren, wodurch es einfacher wird, diese Daten später zu sammeln. Das Speichern der Rationales in einer User Story ist vorerst in Ordnung!
- Vergessen Sie niemals den Wert der Organisation. Finden Sie heraus, wie Sie als Team nach Begründungen in der Dokumentation suchen und versuchen, diese zu dokumentieren. Jedes Team wird einen anderen Prozess haben. In einem meiner Teams konnten wir das Ticket, das die Gründe hatte, nicht sofort finden. Was wir tun könnten, ist, eine wichtige Codezeile
svn blamezu finden, herauszufinden, wann sie geändert wurde und warum, und dann die Tickets anzusehen. Sobald wir dort waren, haben wir in der Regel alle Gründe, die wir brauchten, direkt auf das Ticket geschrieben. Das hat gerade bei uns geklappt, finde heraus, was bei dir funktioniert.
- Organische Dokumentation kann im Laufe der Zeit wachsen. Es ist selten, dass Entwickler wissen, welche Überlegungen an dem Tag, an dem sie sie schreiben mussten, am wichtigsten sind. Wir finden normalerweise später heraus, welche wichtig waren. Wenn Sie einen Aufbereitungsprozess für die Dokumentation haben, der es den Entwicklern ermöglicht, ihren eigenen kleinen Garten von Begründungen zu verwalten, tauchen die wichtigen auf. Noch wichtiger ist, dass sich die Gründe ändern können. Sie werden vielleicht feststellen, dass zwei unterschiedliche Änderungen mit zwei unterschiedlichen Begründungen am besten durch eine einzige Begründung beschrieben werden können, die für beide gilt. Jetzt gibt es weniger Inhalt zwischen Ihnen und Entscheidungen!