Wie kann man sich in Schwergewichtsentwicklungsmethoden persönlich üben?

Ich bin in einem neuen Job, in dem das Projekt strenge Qualitätsstandards erfüllen, umfassend dokumentiert, detailliert verwaltet werden muss, UML-Diagramme und all die Dinge, die im Gegensatz zur "Cowboy-Codierung" stehen, bei der der größte Teil meiner bisherigen Arbeitserfahrung vorhanden war . Denken Sie an die Art und Weise, wie groß angelegte Software für Luft- und Raumfahrt oder medizinische Geräte entwickelt wird.

Ich bin froh, das Chaos der Cowboy-Codierung hinter mir zu lassen und bin gespannt, wie gut die Methoden des Schwergewichts-Engineerings funktionieren. Aber wie kann man schnell Erfahrungen mit den schweren Methoden sammeln?

Abgesehen davon, dass wir nur einige Monate / Jahre im Job sind.

Mit einer bloßen Sprache oder einer neuen API kann man ein Spielzeug-Testprogramm hacken, lesen, absichtlich Fehler machen, um zu sehen, was passiert usw. Wie man gut Fahrrad fahren oder ein Musikinstrument spielen kann, ist Übung unerlässlich. Es ist leicht, eine Flöte aufzuheben und jeden Tag eine halbe Stunde zu verbringen; Sie müssen weder einem Orchester beitreten noch ein Vollzeit-Flötenberater sein. Aber wie kann man Software-Engineering-Aktivitäten üben, die groß und komplex sind, Teams einbeziehen und bei denen es hauptsächlich um Kommunikation und Planung geht, um Fehlkommunikationen zu vermeiden und Zeitplan- und Budgetgrenzen zu überschreiten?

Dies scheint nicht möglich zu sein, alleine zu machen. Gibt es eine Möglichkeit, wie eine kleine Anzahl von Menschen das Engineering eines ganzen großen Projekts in kleinem Maßstab in kurzer Zeit (eines Tages) simulieren kann?

Gibt es eine Möglichkeit, wie eine kleine Anzahl von Menschen das Engineering eines ganzen großen Projekts in kleinem Maßstab in kurzer Zeit (eines Tages) simulieren kann?

Ja, das ist bis zu einem gewissen Grad möglich. Vor ungefähr 10 Jahren nahm ich an einem Workshop auf der OOP-Konferenz in München teil, bei dem 16 Personen die Aufgabe erhielten, eine grobe Analyse und ein Design für eine Software für kleine Unternehmen zu erstellen. In der ersten Hälfte des Tages ging es hauptsächlich darum, eine Teamstruktur für die Lösung der Aufgabe mit 16 Personen zu finden, und in der zweiten Hälfte des Tages ging es darum, die Aufgabe mit diesem Team zu lösen.

Im ersten Teil wurden wir geführt, um die 16 Personen in Vierergruppen aufzuteilen. Jedes vierköpfige Team musste Vorschläge für die Teamstruktur erarbeiten (unter Zeitdruck). Anschließend wurde ein Schießprozess angewendet, um zu entscheiden, welche Teamstruktur die beste sein könnte und für den zweiten Teil des Workshops verwendet werden sollte .

Leider haben wir im ersten Teil den Fehler gemacht, jeder der 16 Personen einen Job innerhalb der beabsichtigten Teamstruktur zu geben. Dieser Fehler führte in der zweiten Hälfte zu Chaos - denn 16 Menschen sind viel zu viel, um eine solche Aufgabe zu lösen. Eine funktionierende Lösung könnte darin bestanden haben, die 16 Personen erneut in kleinere Teams aufzuteilen oder 3 oder 4 Personen für die Hauptarbeit auszuwählen, aber in der Hitze des Augenblicks haben wir dies nicht gesehen.

Ich habe immer noch den Eindruck, dass ich viel über typische Probleme gelernt habe, mit denen man an diesem Tag in größeren Projektorganisationen konfrontiert sein könnte. Ich weiß nicht, wo Sie einen solchen Workshop in Ihrer Nähe besuchen können oder wer heutzutage so etwas anbietet, aber wenn Sie eine Chance haben, würde ich Ihnen wärmstens empfehlen, daran teilzunehmen.

Beginnen Sie mit einer Checkliste . (Sie wussten, dass dies der erste Schritt war, oder?)
Stellen Sie sicher, dass in der Checkliste alle Standarddokumentationen für Ihr aktuelles Projekt aufgeführt sind. dh. UML-Diagramm, Funktionsspezifikation, High-Level- und Low-Level-Designs usw. Der Systemingenieur in mir wird die Verwendung eines RTVM (Matrix zur Überprüfung der Rückverfolgbarkeit von Anforderungen) vorschlagen.

Wählen Sie ein Beispielprogramm aus, an dem Sie arbeiten möchten. Wenn Sie keine finden können, googeln Sie "Code Katas" oder sehen Sie sich das Codejam-Archiv der Herausforderungen von Google an. Oder bauen Sie einfach einen Taschenrechner. :-)

Erstellen Sie die Funktionsspezifikation für Ihr Beispielprogramm. Wechseln Sie dann in das übergeordnete Design, das UML-Diagramm usw. Erstellen Sie es gemäß den Spezifikationen. Probier es aus. Jedes Mal, wenn Sie einen signifikanten Fehler in Ihrer Spezifikation finden (wie durch Ihre aktuellen Arbeitspraktiken definiert), müssen Sie zu dieser Phase des SDLC zurückkehren und diese überarbeiten, bevor Sie fortfahren.

Gehen Sie für Ihre erste Runde voran und halten Sie sie klein. Das Durchlaufen des Prozesses ist in einem bestimmten Stadium wichtiger als ein Overkill. Fügen Sie für nachfolgende Runden die Funktionen hinzu, die Sie ausgelassen haben. Rückverfolgung, Protokollierung, Leistungsanalyse, Testgerüst usw. Was Sie hinzufügen möchten, hängt davon ab, was Ihr Arbeitgeber für Ihre eigentliche Arbeit erwartet.

Nachdem Sie den Entwurfs- / Bau- / Test- / Wiederholungszyklus mehrmals durchlaufen haben, haben Sie Fähigkeiten und Erfahrungen mit den "Schwergewichts" -Komponenten gesammelt, die Sie jetzt beunruhigen. Die Iterationen zeigen Ihnen auch die Verbindung zwischen den verschiedenen Phasen und der generierten Dokumentation. Die wertvolle Lektion dort zeigt, wie eine 5-minütige Codeänderung aufgrund von Dokumentaktualisierungen und Testanforderungen an anderer Stelle einen mehrstündigen Welligkeitseffekt haben kann.

Erfahrung mit "Schwergewichts" -Praktiken kommt nur von der realen Sache. Es gibt keine Möglichkeit, es isoliert effektiv zu üben. Sie können es jedoch studieren. Es gibt viele Fallstudien und Quellen, die Sie studieren und überlegen können.

Nicht alle Praktiken, die Sie sehen oder studieren, sind jedoch notwendigerweise positiv. Softwareentwicklung ist eine fließende Sache, und was heute hardcore und streng erscheint, mag morgen albern und überflüssig erscheinen. Dies geschieht sowohl durch neue Tools als auch durch experimentelle Erfahrungen, die von Startups zu konservativeren Organisationen aufsteigen.

Grundsätzlich scheint das Veränderungs- und Risikomanagement für jede Organisation eine einzigartige Form zu haben. Ihre beste Wette ist es, offen zu bleiben, aber nicht zu viele Annahmen von Team zu Team zu tragen.