Dokumentation des Projekts, wenn es um viele Geschäftslogikregeln geht. Wie organisiert man es?

Question

Ich arbeite an einem ziemlich komplizierten Projekt, in Bezug auf die Geschäftslogik Menge und Quantität der Komponenten.

Jeder Entwickler arbeitet meist an "seiner eigenen" Komponente. Ich verstehe, dass dies nicht sehr funktionsübergreifend ist, aber es ist unmöglich, die Details aller Komponenten zu kennen.

Team Sostav ändert sich von Zeit zu Zeit. So haben wir Situationen, in denen eine Person an der "Komponente einer anderen Person" arbeiten muss. Und das kann im periodischen Keller sein, so dass Sie einen Monat später wieder zum Thema kommen können - in diesen Momenten können Sie dem Besitzer der Komponente Business Logik immer wieder die gleichen Fragen stellen, weil Sie jeden Monat ein paar winzige, aber wichtige Details vergessen können später.

Diese Situation ist manchmal nervig.

Wir haben tägliche Stand-up-Meetings, wenn die Person erzählt, was er getan hat und tun wird. Wir haben Projekt Wiki F.A.Q. Seite - wir extrahieren die am häufigsten gestellten Fragen.

Was denken Sie über das Problem?

Und wie würden Sie uns empfehlen, es zu lösen?

Answer 1

die Komponente Natur I mit gehen würde:

1.) Ein Rahmendokument unter Angabe der Anwendungen Zweck, Aufbau, Anforderungen usw. 2.) Modul Dokumente für jede Komponente in einem gemeinsamen Format und indiziert durch Name.

Blick auf die http://docs.python.org für ein gutes Beispiel für allgemeine Dokumente und http://docs.python.org/modindex.html für ein gutes Beispiel für Modul/Komponente docs

Oh, und täglichen Treffen im Allgemeinen schlecht sind, nehmen sie viel Zeit und Antworten aufstehen vergessen . Neuankömmlinge oder kranke Menschen vermissen die Treffen und müssen neu eingeplant werden. Es ist 100x besser, alles aufzuschreiben und einen Papier-/E-Mail-Trail zu führen, wenn keine Diskussion/Feedback erforderlich ist.