Entwerfen Sie in einem Team, programmieren Sie in einem anderen

Ich werde an einem Projekt beteiligt sein, bei dem das gesamte Softwaredesign von einem lokalen Team erstellt und diese Entwürfe zur Codierung an ein Offshore-Team gesendet werden.

Es ist das erste Mal, dass ich einem Projekt mit diesen Merkmalen gegenüberstehe, und für mich ist es merkwürdig: Die Manager erwarten, dass wir sehr detaillierte Konstruktionsdokumente erstellen, damit das Offshore-Team keinen Platz für Fehler hat. Aus meiner Sicht lassen sie uns auf Papier codieren, während wir dies in einer IDE tun können.

Meine Frage ist also, ob dieser Ansatz gut oder richtig ist. Was sind die Hauptaspekte, die unser Softwareprozess haben muss, um in unserem Projekt erfolgreich zu sein?

Meine Meinung:

Wenn alles, was Sie den Offshore-Leuten geben, Dokumente und Diagramme sind, werden Sie eine Menge Missverständnisse und Enttäuschungen haben .

Meine Empfehlung

• Geben Sie ihnen nicht so viele Dokumente, sondern Interfaces und abstrakte Klassen, um sie in Ihre Designziele zu integrieren .

• Fordern Sie sie auf, einen bekannten Namensstandard zu verwenden.

• Fordern Sie sie auf, Komponententests durchzuführen.

• Schicken Sie einen Ihrer Designer / Architekten ins Ausland, um den Prozess zu überwachen. Es ist immer noch billiger als das interne Codieren, aber Sie erhalten bessere Ergebnisse.

Es heißt Big Design Up Front, auch bekannt als Wasserfall. Es wird nicht allgemein als sehr erfolgreiche Methode angesehen. Aber ich habe gesehen, dass es funktioniert, und wenn es funktioniert, funktioniert es sehr gut. Es ist sehr teuer, es richtig zu machen.

Es ist auch, was Ihre Arbeitgeber Sie gebeten haben, zu tun.

Offshore-Teams arbeiten nicht so wie Onshore-Teams. Sie müssen sehr, sehr genau wissen, was Sie wollen, sonst bekommen Sie nicht, was Sie wollen.

Das letzte Projekt war ich der Software-Designer. Die gesamte Entwicklung war offshore. Wir waren erfolgreich Dieser Prozess kann also funktionieren.

Ich habe eine Menge Dokumentation erstellt, diese war jedoch keineswegs umfassend und keineswegs schrittweise oder detailliert bis auf Klassennamen, Funktionsnamen usw. Ich habe beispielsweise Sequenzdiagramme, Anwendungsfälle, Workflows, Systeme und Integrationen erstellt Diagramme sowie eine detailliertere Konstruktionsdokumentation nach Bedarf.

Es hängt wirklich davon ab, wie sehr Sie der Offshore-Entwicklung vertrauen. Ich vertraue darauf, dass mein Offshore-Team kompetente Entwickler sind. Trotzdem habe ich die allgemeine Richtung vorgegeben, ihnen aber Spielraum für die Umsetzung eingeräumt, was das Offshore-Team als angenehm zufriedenstellend empfand. In der Vergangenheit wurden sie eher im Mikrobereich verwaltet. In bestimmten Situationen führte ich sie nach Bedarf anhand der Entwurfsmuster. Ich habe außerdem regelmäßig Codeüberprüfungen und -analysen für den von ihnen geschriebenen Code durchgeführt und empfahl, den Code zu überarbeiten oder zu bereinigen. Da ein Teil des Teams Unfälle mit Freizeitfahrzeugen hatte, habe ich einige der Storys während der Implementierung codiert, da uns einige Ressourcen fehlten.

Darüber hinaus denke ich, dass dieser Prozess wirklich nur aufgrund der Stärke Ihrer technischen Leads im Projekt und der Kommunikation zwischen Unternehmen, Designern, Leads und Entwicklern erfolgreich ist. Wir haben viel Zeit damit verbracht, die einzelnen Features und Storys durchzugehen und sicherzustellen, dass die Offshore-Leads / -Ressourcen mit den jeweiligen Anforderungen bestens vertraut sind. Wenn sie während der Überprüfung des Features / der Story keine Fragen stellen, erwarten Sie einige Probleme. Auch die Arbeit wurde erst als abgeschlossen betrachtet, als es eine Geschäftsfreigabe gab. Das machte jeden zur Rechenschaft, da alles in einem Tool verfolgt wurde, das die agile Entwicklung verwaltete.

Wie eine der anderen Antworten bereits angedeutet hat, umfasste der Entwicklungsprozess Benennungsstandards (eingebaute Resharper-Regeln), Testfallabdeckung (es wurde TDD, Mocking usw. verwendet). Wenn also ein guter Kodierungsprozess und eine gute Prozedur vorhanden sind, werden diese erhöht Ihre Chancen für ein erfolgreiches Projekt.

Die Hauptkosten der Offshore-Entwicklung sind die Kommunikationskosten. Dokumentation ist eine Art der Kommunikation, jedoch können Dokumente normalerweise nicht alle Details und möglichen Änderungen abdecken.

Nicht sicher, wie groß Ihr Projekt ist. Ich gehe davon aus, dass es groß ist, sonst ist es nicht wertvoll, das Offshore-Entwicklungsteam einzusetzen. So ist meine Erfahrung

1. Definieren Sie den Skelettcode, die öffentliche Schnittstelle, die Dienstschnittstelle usw. und überprüfen Sie sie gemeinsam
2. Definieren Sie die Abnahmetests mit der anderen Seite
3. Teilen Sie das große Dokument in kleine Geschichten auf, und arbeiten Sie basierend auf den kleinen Geschichten. Das große Dokument ist nur ein Gesamtbild des gesamten Systems
4. Richten Sie die Kontrollpunkte der Geschichten ein, eine Woche oder zwei Wochen

In 1 und 2 geht es eigentlich um die Entwicklung, um sicherzustellen, dass die andere Seite die Anforderung gut versteht und beide Seiten dasselbe Muster verwenden. 3 und 4 sind Teil der agilen Entwicklungsmethodik, aber für die Offshore-Entwicklung ist es schwierig, den vollständigen agilen Prozess zu verwenden.

Ich denke, bis zu einem gewissen Grad arbeiten wir alle so. Jemand entwirft irgendwo etwas und wir codieren etwas, das Teil des Systems ist oder mit ihm arbeitet. Beispiele sind das Erstellen von Apps auf der Basis eines Frameworks, z. B. Anwendungen, die keine Spiele sind, auf Mobilgeräten. Viele Entscheidungen über die Benutzeroberfläche wurden vom Designteam der Personen getroffen, die das Framework erstellt haben. Sie kontrollierten alles vom Lernen, eine App zu schreiben, bis zum Verkauf Ihrer App. Wenn Sie wissen möchten, warum dieses Modell erfolgreich war, schauen Sie sich die Dokumentation und die Tools einiger Anbieter an.

Ein weiteres Beispiel sind Webanwendungen, bei denen viele versuchen, den REST-Stil zu implementieren. Dieser Teil erklärt nicht wirklich, wie etwas implementiert werden soll, obwohl es Spezifikationen für die Verwendung von HTTP gibt. Wie auch immer, es gibt Spezifikationen und Richtlinien, die befolgt werden müssen. Wenn Sie sehen, wie viele Diskussionen über die REST-Implementierung beim Stapelaustausch oder am Arbeitsplatz geführt werden, ist das so, als ob ein Architekt die Leute auffordert, etwas auf bestimmte Weise zu implementieren. Es ist immer noch ein erfolgreiches Modell, denke ich, mit so vielen Leuten, die dem Stil folgen.

An diesen beiden Beispielen können Sie sehen, wie Designs verbreitet werden, einige als Papierspezifikationen, andere mit Büchern, Werkzeugen und Beispielen. Sie können sehen, wie Leute nachfragen (in Volumen) und versuchen, das Verständnis in unterschiedlichem Maße zu verbessern, je nachdem, welchen Standards / Designs sie folgen möchten. Gehe einfach auf stackoverflow und schau;)

Wenn Sie mir Ihre Spezifikation geben, werde ich fragen. Wenn Sie mir einen Komponententest geben, werde ich codieren und testen.