Berater in einer Firma, die die Technik nicht versteht! [geschlossen]

Ich habe den Job als Berater in einer Firma bekommen, die 3 andere Programmierer hat. Meine Aufgabe ist es, das gesamte alte System in Java, Spring usw. neu zu schreiben, aber die Programmierer des Personals kennen nur Perl und der Manager kennt keine Programmierung.

Ich versuche, sie dazu zu bringen, zu verstehen, dass ich hier 6 Projekte umschreiben muss, aber niemand hat Designdokumente oder Spezifikationen. Die Personalprogrammierer mussten nie irgendwelche Dokumente schreiben. Außerdem kann ich den Manager nicht dazu bringen, das neue Java-Tech-Zeug zu verstehen. Er fragt immer wieder einige Mitarbeiter nach Ansichten zu Dingen, aber die Mitarbeiter wissen es nicht oder verstehen es nicht.

Wohin gehe ich von hier aus, damit der Manager versteht, dass die Programmierer des Personals oder jemand ein Designdokument schreiben muss, damit ich weiß, was zu erstellen ist. oder wenn ich die Dokumente schreiben muss, wie bekomme ich die Informationen?

Es scheint seltsam, dass die Mitarbeiter die Plattform nicht kennen, auf der Sie aufgefordert wurden, ihre Arbeit neu zu schreiben. Was passiert, nachdem Sie gegangen sind? Wer wird Ihre Arbeit unterstützen?

Sie haben also ein komplexes System, das nicht über die richtige Dokumentation verfügt, und Sie müssen das System auf einer anderen Plattform neu erstellen. Was ich in Ihrer Position tun würde, ist, die einzelne Person zu identifizieren, die das neue System "abmelden" muss. Lesen Sie von dort aus User Stories, um herauszufinden, wie Anforderungen in bitgroße Abschnitte unterteilt werden können, die im Klartext beschrieben werden können. Ihr Format ist so etwas wie "Als USERROLE möchte ich in SYSTEM X AKTIONEN ERFÜLLEN, damit ZIEL ERREICHT wird."

Um eine User Story weiter zu erläutern, fügen Sie 'Erfolgskriterien' im Format "Gegeben, wenn ZUSTAND, dann ERGEBNIS" hinzu, um zu erklären, was mit verschiedenen Aktionen in der übergeordneten User Story geschieht. Dies ist eine anständige Methode, um die Funktionalität in Teile zu unterteilen, die einzeln verstanden werden können, und Sie können Hilfe beim Schreiben verschiedener Geschichten aus verschiedenen Gruppen erhalten (stellen Sie nur sicher, dass die Person auf höchster Ebene, die die Arbeit abzeichnet, dieselbe bleibt).

Holen Sie sich also alle alten Funktionen des Systems als User Stories neu und fragen Sie den Projektbesitzer, ob die Java-Version NEUE Funktionen enthält. Fügen Sie Geschichten hinzu, um dies zu befriedigen, falls vorhanden, und beginnen Sie dann mit dem Codieren.

Grundsätzlich müssen Sie in der Lage sein, die Hilfslosigkeit der Programmierer aufzudecken. Lassen Sie den Projektbesitzer verlangen, dass er Ihnen die Erfolgskriterien für einige der Geschichten zur Verfügung stellt. Wenn er Ihnen beschissene Beiträge liefert, können Sie dies einfach als Ihre offiziellen Anforderungen hochhalten. Alles, was sie weglassen, wird ihre Schuld sein, nicht deine.

Ich war an einem Projekt beteiligt, bei dem das gesamte System in Oracle Forms geschrieben wurde, jedoch ohne Dokumentation. Die Technologie hätte leicht Perl sein können. Hier ist der Angriffsplan für die Migration des Systems auf Oracle ADF (könnte aber genauso gut jede andere Plattform sein):

1. Erstellen Sie eine Reihe von Codekategorien für Geschäftsanforderungen (Funktionen, Fehler, Validierung, Benutzeroberfläche usw.).
2. Erstellen Sie eine Reihe von Kategorien für die Bildschirme (gruppieren Sie sie nach ähnlichen Funktionen).
3. Erstellen Sie eine Liste aller Bildschirme für die gesamte Anwendung und führen Sie sie in einer Tabelle auf.
4. Weisen Sie jedem Bildschirm eine Codekategorie und einen Codetyp zu (z. B. Geschäftsregel, Systemanforderung, technisch).
5. Reverse Engineering des Codes zum Extrahieren der Geschäftsanforderungen und Erstellen einer einsatzigen Beschreibung jeder Anforderung.

Zu diesem Zeitpunkt haben Sie die Geschäftsregeln für die Anwendung dokumentiert . Dies allein ist Gold für jeden, der als nächstes das System warten muss. Darüber hinaus können Sie sehen, welche Teile des Systems dupliziert wurden. (In meinem Fall haben wir festgestellt, dass über 60% der Codebasis dupliziert wurden.)

Von hier aus können Sie die Geschäftsanforderungen mit dem Management sortieren. Dies kann beispielsweise das Erstellen von User Stories beinhalten. Dies wird auch doppelte Funktionen auf hoher Ebene aufzeigen und Möglichkeiten bieten, das System während der Migration sowohl zu vereinfachen als auch zu verbessern. Ich habe einen Screenshot der Tabelle beigefügt, um einen Weg zur Verfolgung und Dokumentation der Anforderungen aufzuzeigen.

Möglicherweise müssen Sie Ihren Perl auffrischen. ;-);

Sobald Sie das Projekt rückentwickelt haben, können Sie eine Reihe von Tools einsetzen, die Sie beim Lebenszyklus der Softwareentwicklung unterstützen. (Wir verwenden JIRA , aber es gibt viele andere Software-Suiten, die funktionieren würden.) Möglicherweise müssen Sie einige Kämpfe führen, aber sobald Sie die Anforderungen erfüllt haben, möchten Sie in die folgenden Umgebungen wechseln:

• Erstellen Sie eine Dokumentationsumgebung (z. B. ein Wiki).
• Erstellen Sie eine Entwicklungsumgebung (DEV). Webserver, Datenbankserver, Quell-Repository usw.
• Erstellen Sie eine Testumgebung (TEST), die die Entwicklung widerspiegelt.
• Erstellen Sie eine Vorproduktionsumgebung (PREPROD), die die Produktion genau widerspiegelt und als Failover für das Produktionssystem fungieren kann.
• Erstellen Sie eine Produktionsumgebung (PROD).

Überlegen Sie, ob Sie einen Community-orientierten Dienst verwenden möchten, um die Anforderungen der Endbenutzerdokumentation zu erfüllen. Ein ausgezeichnetes Softwarepaket ähnlich der StackExchange-Suite ist OSQA . Lassen Sie die Benutzer das Hilfesystem erstellen (es ist eine ziemlich clevere Strategie).

Der SDLC wird:

1. Entwickler nehmen Anwendungsänderungen in DEV vor und testen sie (mithilfe eines Repositorys ).
2. Systemtools stellen regelmäßig reguläre Builds in TEST bereit.
3. Sobald die Tester mit der Anwendung zufrieden sind, wird die Anwendung in PREPROD bereitgestellt. Dadurch kann auch der Bereitstellungsprozess getestet werden. Weitere Tests finden in PREPROD statt.
4. Sobald die Tester mit PREPROD zufrieden sind, wird die Anwendung schließlich in PROD gerollt.

Ich finde, dass dies ein hoch organisierter Ansatz ist, der mit verschiedenen Entwicklungsmethoden gut funktioniert. Der erste Durchgang, den ich hier beschrieben habe, sollte als "breiter Pinselstrich" betrachtet werden - Sie möchten an dieser Stelle nicht zu detailliert (festgefahren) mit technischen Details werden. (Die Anforderungen an die Benutzeroberfläche werden beispielsweise von jedem Bildschirm erfasst. Solange die Bildschirme aufgelistet sind, müssen Sie nicht jedes einzelne Eingabefeld durchlaufen, sondern nur einen Link zu einem Screenshot oder einer Arbeits-URL erstellen.)

Um den Quellcode zu überprüfen, haben wir schließlich eine Reihe von Webseiten automatisch generiert (eine Webseite pro funktionalem "Bildschirm"). Dies funktionierte gut, da der PL / SQL-Code in separate Dateien aufgeteilt und automatisch mit Syntaxhervorhebung in HTML konvertiert werden konnte. Mit Perl funktioniert dies möglicherweise nicht so gut für Sie. Die Idee ist jedoch, dass Sie Ankerlinks innerhalb der Tabelle erstellen können, die auf den Codeabschnitt verweisen, der die Geschäftsanforderungen erzwingt. (Abgesehen davon würde dies auch mehreren Entwicklern ermöglichen, die Systemanforderungen parallel rückzuentwickeln, da jeder Entwickler gleichzeitig verschiedene Bildschirme bearbeiten kann.)

Ein Beispiel für einen Quellcode-Ausschnitt (das + ist ein Ankerlink):

Sie können empfehlen, ein paar Perl-Gurus zu engagieren, um bei der Analyseaufgabe zu helfen.

Ich denke nicht, dass es sehr produktiv ist, darauf hinzuweisen, dass andere Leute "beschissene Arbeit" machen; Vielmehr sollten Sie versuchen, das Produkt zu verbessern und den Menschen die Möglichkeit zu geben, bei diesem Ziel zu helfen (und vielleicht zu lernen, wie sie ihre Fähigkeiten in diesem Prozess verbessern können). Das heißt, Sie wissen nicht, was die anderen Entwickler wissen, und Sie waren auch nicht dort, als sie das System entwickelten. Dieser Ansatz macht den gesamten Prozess offen und gut sichtbar, wobei jeder einen Beitrag leisten kann.

Manager werden sich selbst davon überzeugen, wer wirklich hilfreich ist und wer sich verbessern möchte.

Sie haben keine Dokumentation und ihr Code ist so schlecht, dass sie jemanden beauftragt haben, ihn in einer anderen Sprache umzuschreiben. Sammeln Sie Anforderungen aus der Quelle. Sie werden feststellen, dass viele Features und Funktionen nicht mehr verwendet werden oder möglicherweise nicht richtig funktionieren. Es ist ebenso wichtig zu wissen, was nicht gebaut werden soll.

Wenn Sie herausgefunden haben, was die Benutzer benötigen, bestimmen Sie, was bereits in der aktuellen Anwendung enthalten ist und was von Grund auf neu erstellt werden muss. In den vorhandenen Teilen können Sie sich den Code ansehen und mit den Entwicklern sprechen.

Wer verkündet, alles zu brauchen, hat sich nie die Mühe gemacht, es zu überprüfen. Es gibt ein Argument, eine Anwendung niemals neu zu schreiben, aber dies setzt voraus, dass alles so funktioniert, wie Benutzer es möchten, und das ist nicht immer wahr. Sie benutzen es, weil es keine Alternative gibt. Gib ihnen eine bessere Alternative.

Ich würde damit beginnen, mit Ihrem Manager zu sprechen und die Verantwortung für das Sammeln der Anforderungen und das Definieren der Spezifikationen zu übernehmen. Sie müssen ihn von der Notwendigkeit dieser Dokumente und deren Bereitstellung überzeugen. Ich würde wahrscheinlich online ein Beispiel finden. Anschließend übernehmen Sie die Montage der Anforderungen und Spezifikationen für das System. Treffen Sie sich dann erneut mit Ihrem Manager, um das Dokument zu überprüfen. Sobald Sie ihnen das erste Dokument gezeigt haben, können Sie möglicherweise Unterstützung beim Erstellen des anderen Dokuments erhalten. 5. Wenn es effektiv ist, sind Sie wahrscheinlich auch dafür verantwortlich, diese Anforderungen zu erfassen, aber zumindest jemand wird es tun.