Was sollten Sie in ein Dokument mit einem Entwicklungsansatz aufnehmen? [geschlossen]

Ich bin gerade dabei, ein "Entwicklungsansatz" -Dokument für Offshore-Ressourcen zu erstellen, während diese auf unser Projekt zugeschnitten sind.

Das neueste (ähnliche) Dokument, das unser Unternehmen verwendet hat, umfasst mehr als 80 Seiten und enthält keine Dokumente zu Codierungsstandards / -konventionen.

Ich mache mir Sorgen, dass dieses Dokument nicht konsumierbar ist und daher fehlschlägt.

Was sollte in einem Entwicklungsansatzdokument enthalten sein? Gibt es zu diesem Thema anständige Richtlinien?

BEARBEITEN: Das Dokument zum Entwicklungsansatz sollte die Praktiken und Techniken beschreiben, die von Softwareentwicklern verwendet werden, während Software entworfen, erstellt und getestet wird.

In einem der Unternehmen, in denen ich gearbeitet habe, hatten wir diesen gesamten prozessorientierten Ansatz mit vielen Dokumenten (von denen die meisten vom Projektmanager ausgefüllt werden mussten). Trotz der Länge und der Erklärungen wurde mir klar, dass es kaum Menschen half - den echten Entwicklern.

Also habe ich mich entschlossen, mich mit dem spezifischen Ziel, "den Entwicklern zu helfen", zurückzuziehen. Das Wichtigste, was ich angefangen habe, ist, die grundlegendsten Fragen zu sammeln - die echten FAQs.

Was ich gelernt habe, ist, dass es für die meisten Menschen wichtig ist, bestimmte Prozesse zu übernehmen, wenn sie bestimmte Prozesse übernehmen möchten, und viele Dinge, die sie möglicherweise nicht vorher wissen, die sie aber sofort schätzen würden, wenn sie die Logik verstehen.

Hier sind die wichtigsten Themen, denen eine solche Dokumentation helfen sollte:

1. Der Prozess der Entwicklung bis zur Bereitstellung - Wie sollte der Code organisiert, kompiliert und veröffentlicht werden (in Form von DLLs, Bibliotheken, ausführbaren Dateien, Installationsprogrammen, Webseiten und wie werden sie bereitgestellt und getestet)?

2. Wie sollen wir die Versionskontrolle durchführen? (und warum, wenn es Neulinge gibt). Verstehen Sie, wie die Struktur des Repositorys, der Verhaltenskodex - wann ein Check-in akzeptabel ist und wann nicht, wann eine Version / ein Tag angekündigt wird, wie der Patch, die Zusammenführungen angewendet werden und welche Sauberkeitserwartungen bei einem Patch oder Release wird für erledigt erklärt

3. Ausführen der Methodik - Sind wir agil, entwerfen wir im Voraus, welche Methodik verwenden wir? Angesichts dessen könnte es sich um eine feste Lösung für ein bestimmtes Unternehmen handeln. Jetzt möchten die meisten Menschen wissen, wie wir es für das jeweilige Projekt implementieren werden . Dies ist sehr spezifisch für das Projekt, das es den Menschen ermöglicht, verschiedene Meilensteine ​​und das, was möglicherweise wichtig ist, zu visualisieren. In einem forschungsorientierten Projekt möchten wir in einer Schrumpffolie angeben, dass "kritische Algorithmen immer validiert werden, bevor darauf aufgebaut wird". Ich würde mich auf die Richtigkeit und Wichtigkeit von Merkmalen konzentrieren.

4. Kommunikationsverantwortung - Festlegen, wie Sie formelle Kommunikation herstellen - dies geschieht nicht damit, ob bestimmte Personen miteinander sprechen können -, sondern die Personen müssen ein Gespür dafür haben, was wichtig genug ist (Probleme, Entwurfsentscheidungen, Einfrieren von Funktionen), um entweder angekündigt zu werden oder sogar diskutiert, bevor mit der Implementierung fortgefahren wird.

5. Schließlich müssen wir alle ein gemeinsames Verständnis der Codequalität, des Codierungsstandards und allgemein dessen haben, was wir für in Ordnung halten oder unter dem Hygienestandard liegen.

Ich wünschte, ich würde jedes Projekt mit solchen Dokumenten beginnen - aber es ist nicht ganz einfach. Wichtig ist jedoch, alle Probleme zu lösen, die sich auf das tägliche Verhalten und die Auswahl der Entwickler beziehen. Dies ist ein langer Weg, wenn mehrere Releases auf den Markt gebracht werden müssen.

Schließlich würde ich auch vorschlagen, dass Sie versuchen, so informell wie möglich zu sein. Normalerweise mögen die prozessorientierten Leute informelle Dokumente nicht so sehr, die außerhalb des Kontexts möglicherweise missverstanden werden können. Dies sollte jedoch so erfolgen, dass die Entwickler miteinander verbunden werden.

Was Sie als "Entwicklungsansatzdokument" bezeichnen, wird normalerweise als Softwareprojektmanagementplan bezeichnet . (Ich habe auch gehört, dass es als Softwareprojektplan oder Softwareentwicklungsplan bezeichnet wird .) Mit diesen Begriffen sollten Sie in der Lage sein, bei Google nach einigen Beispielen zu suchen, die es gibt. Wie Victor Hurdugaci und Donal Fellows erwähnt haben, wird der von Ihnen verfasste Software-Projektmanagementplan (1) auf Ihre Bedürfnisse zugeschnitten und (2) als lebendiges Dokument aktualisiert, wenn sich die Situation entwickelt. Abgesehen davon kann es schwierig sein, eine von Grund auf neu zu schreiben, wenn Sie noch nie zuvor eine geschrieben haben und nicht wissen, was sonst noch in die Sache einfließen soll.

Es gibt einige Anleitungen durch den IEEE-Standard 1058 (IEEE-Standard für Software-Projektmanagementpläne, 1998). Es gibt eine Kopie des Standard geschrieben hier . Ich finde diesen Plan ziemlich schwer, aber es ist ein anständiger Ort, um Ideen zu sammeln - und Sie benötigen möglicherweise das zusätzliche Gewicht, wenn Sie alles schriftlich für ein Offshore-Team wünschen. Es gibt auch einen ziemlich guten Überblick - und einige großartige Informationen zum Planen von Softwareprojekten - in einem Buch, an das ich mich bei traditionellen (nicht agilen) Softwareprojekten häufig wende: Quality Software Project Management von Futrell, Shafer und Shafer.

Ein Annäherungsdokument ist ein Dokument "Weder hier noch dort" . Dies ist ein Dokument, das im Allgemeinen von Projektmanagern (Lieferantenmanagern) von Unternehmensorganisationen von Projektmanagern (Softwareentwicklungsmanagern) von Softwareanwendungsentwicklungsorganisationen angefordert wird.

Der Zweck dieses Dokuments hängt von den Anforderungen der Business Org PM ab.

Kann Hardware-Architektur, Systemfunktionen, Kommunikationspläne, Konfigurationspläne, Ressourcenladepläne, Technologie-Stack, Anwendungsarchitektur usw. enthalten.

Auch hier ist die obige Liste je nach Bedarf variabel. :)

Ich muss noch formale Literatur zu einem solchen Dokument sehen. wenn es welche von den Standardautoren gibt Pressman etc. teilen ..

oder fehlt mir etwas

Das neueste (ähnliche) Dokument, das unser Unternehmen verwendet hat, umfasst mehr als 80 Seiten und enthält keine Dokumente zu Codierungsstandards / -konventionen.

Da Sie bereits einige Dokumente haben, ist dies Ihr Ausgangspunkt. Frag dich selbst:

1. Was ist in diesem Dokument nützlich?
2. Was fehlt?
3. Warum sollte ich dieses Dokument verwenden?

Nachdem Sie die Antworten erhalten haben, schneiden Sie das Unerwünschte aus und fügen Sie die fehlenden Teile hinzu.

Der tatsächliche Inhalt des Dokuments hängt von den verfügbaren Ressourcen ab, und ich glaube, dass es schwierig ist, anhand der bereitgestellten Informationen zu spekulieren.

Nur ein Hinweis: Sie sollten dieses Dokument im Laufe der Zeit anpassen, schreiben Sie also nicht zu viel;)

Die Entwicklungspraktiken ändern sich im Laufe der Zeit, wenn sich Ihre Anforderungen ändern und wenn sich die von Ihnen verwendeten Sprachen, Bibliotheken und Frameworks ändern. Diese Änderung ist unvermeidlich und bedeutet, dass alles, was Sie auf Papier bringen, (fast) sofort veraltet sein wird. Wie gehe ich damit um? Bewahren Sie alles in einem Wiki auf und ermutigen Sie alle Mitglieder Ihres Teams - sowohl intern als auch extern -, es auf dem neuesten Stand und relevant zu halten.

Sobald Sie den Schritt von einem toten Dokument zu einem lebenden Dokument getan haben, wird die Debatte darüber, was eingefügt werden soll, weniger dringend: Sie geben nur das ein, woran Sie jetzt denken können, und kommen zu einem späteren Zeitpunkt darauf zurück. (Das Gute ist, dass Sie nicht alles verstehen müssen, um das Dokument überhaupt zu schreiben.) Vielleicht möchten Sie auch alles mit dem veralteten Inhalt des alten 80-seitigen Dokuments versehen. Das gibt Ihnen viel Umrissmaterial, wenn nichts anderes, und erspart Ihnen das Nachdenken über das Schreiben großer Mengen langweiliger Dinge.

Halten Sie das Dokument kurz. Verwenden Sie die Strukturierung im Zeitungsstil - beginnen Sie mit Details auf hoher Ebene und folgen Sie den Einzelheiten. Anstatt Standardpraktiken einzubeziehen, verweisen Sie einfach auf diese und geben Sie Abweichungen vom Standard an.

1: Wenn Sie bereits Projekte in Ihrem Unternehmen durchführen, nehmen Sie an diesem Prozess teil. Vielleicht vergeben Sie sogar das Management Ihrer Projektentwicklung an sie. Erfinde das Rad nicht neu.

2: Wenn Sie noch keine Eigenentwicklung durchführen, bestehen Sie darauf, dass der von Ihnen verwendete Auftragnehmer über eine gute Methodik verfügt, die er für Projekte verwendet. Verwenden Sie dann diese Methode.

Vertrauen, aber überprüfen. Sie versuchen, den Müll langfristig auszusortieren. Lassen Sie sie also nichts tun, folgen Sie einem Prozess, der erst am Ende zu liefern ist. Bestehen Sie darauf, dass die frühzeitige Lieferung erfolgt und überprüft wird, bevor sie fortgesetzt wird.

Darüber hinaus habe ich im Grunde auch auf @Dipan