Wie gehe ich mit verschiedenen Entwicklungsstilen (von oben nach unten und von unten nach oben) in einem Team um?

Nehmen wir an, Sie haben gerade begonnen, in einem sehr kleinen Team an einem {derzeit relativ kleinen, aber später hoffentlich größeren} Projekt zu arbeiten. Beachten Sie, dass dies ein tatsächliches Projekt ist, das von anderen Entwicklern in der realen Welt verwendet werden soll, und kein akademisches Projekt, das am Ende eines Semesters ausrangiert werden soll.
Der Code ist jedoch noch nicht für andere freigegeben, sodass noch keine Entscheidung in Stein gemeißelt ist.

Die Methoden

Einer von Ihnen mag es, mit dem Codieren zu beginnen und die Teile zusammenzufügen, bevor Sie unbedingt eine klare Vorstellung davon haben, wie genau alle Komponenten interagieren (Bottom-up-Design). Ein anderer von Ihnen macht gerne zuerst das gesamte Design und macht die Details aller Komponenten und der Kommunikation fest, bevor er eine Lösung codiert.

Angenommen, Sie arbeiten an einem neuen System, anstatt vorhandene Systeme nachzuahmen, und es ist daher nicht immer klar, wie das richtige Enddesign aussehen sollte. In Ihrem Team haben verschiedene Teammitglieder manchmal unterschiedliche Vorstellungen davon, welche Anforderungen überhaupt für das Endprodukt erforderlich sind, geschweige denn, wie es zu entwerfen ist.

Wenn der Bottom-Up-Entwickler einen Code schreibt, lehnt der Top-Down-Entwickler ihn ab, da möglicherweise zukünftige Probleme im Entwurf auftreten, obwohl der Code das vorliegende Problem möglicherweise löst, da er der Ansicht ist, dass es wichtiger ist, den Entwurf korrekt zu gestalten bevor Sie versuchen, die Lösung für das Problem zu codieren.

Wenn der Top-Down-Entwickler versucht, das vollständige Design und die vorgesehenen Probleme zu erarbeiten, bevor er mit dem Schreiben des Codes beginnt, lehnt der Bottom-Up-Entwickler diesen ab, da der Bottom-Up-Entwickler nicht glaubt, dass einige der Probleme tatsächlich in der Praxis auftreten werden und denkt, dass das Design möglicherweise in Zukunft geändert werden muss, wenn die Anforderungen und Einschränkungen klarer werden.

Das Problem

Dies hat zu dem Problem geführt, dass Bottom-Up-Entwickler am Ende Zeit verschwenden, da der Top-Down-Entwickler häufig entscheidet, dass die Lösung, die der Bottom-Up-Entwickler geschrieben hat, aufgrund eines Konstruktionsfehlers verworfen werden sollte, was zu einem erneuten Bedarf führt -Schreibe den Code.

Der Top-Down-Entwickler verschwendet viel Zeit, denn anstatt die Arbeit zu parallelisieren, setzt sich der Top-Down-Entwickler jetzt häufig zusammen, um mit dem Bottom-Up-Entwickler das richtige Design zu erarbeiten für 1 Person die Arbeit zu erledigen, als 2.

Die beiden Entwickler wollen weiter zusammenarbeiten, aber es scheint nicht, dass die Kombination beiden in der Praxis hilft.

Die Ziele

Die gemeinsamen Ziele sind offensichtlich die Maximierung der Codiereffektivität (dh die Minimierung der Zeitverschwendung) und das Schreiben nützlicher Software.

Die Frage

Einfach ausgedrückt, wie können Sie dieses Problem lösen und mit dieser Situation umgehen?

Die einzige effiziente Lösung, die ich mir vorstellen kann, ist, dass jeder Entwickler seinem eigenen Stil für das Design folgt. Dies ist jedoch schwieriger, als es sich anhört, wenn Sie die Codeüberprüfung durchführen und tatsächlich die Änderungen der anderen genehmigen müssen und wenn Sie versuchen, ein kohärentes Framework für die Verwendung durch andere zu entwerfen.

Gibt es einen besseren Weg?

Offensichtlich sind beide falsch.

Der Bottom-Up-Typ hackt sich in Code ein und wird niemals etwas produzieren, das das tut, was es tun soll - es wird eine ständige Abwanderung sein, wenn die unbekannten Anforderungen ermittelt werden.

Der Top-Down-Typ kann genauso viel Zeit für architektonische Visionen aufwenden und auch nichts Produktives tun.

Ein Mittelweg ist jedoch ideal - wenn Sie die Ziele kennen, auf die Sie hinarbeiten (die Sie durch eine umfassende Entwurfsarbeit erreichen), und mit der Codierung fortfahren (ohne detaillierte Planung), dann profitieren Sie von den Vorteilen eines Systems, das es gibt sowohl organisiert als auch effizient entwickelt.

Es heißt übrigens Agile (nicht die BS-Version von Agile, die manche Leute praktizieren, wenn Prozeduren wichtiger sind als funktionierende Software), sondern echte Agile, die auf ein allgemein beschriebenes und verstandenes Endziel hinarbeitet.

Um das Problem hier zu beheben, versuchen Sie einen agilen Ansatz (Kanban ist wahrscheinlich der beste), der sowohl den Top-Down-Mann zu etwas Arbeit zwingt als auch den Bottom-Up-Mann dazu zwingt, zu planen, was er erreichen will.

Die beiden Entwickler müssen sich gegenseitig respektieren .

Die Person von oben nach unten muss die Tatsache respektieren, dass die Person von unten nach oben möglicherweise etwas gefunden hat, das tatsächlich funktioniert. Einer meiner "quantitativen" Professoren sagte mir: "Ein Arbeitsmodell ist 1000 Annahmen wert." Wenn dies der Fall ist, sollte die Person von oben nach unten in Betracht ziehen, ihr "Design" erneut durchzuführen, um die Arbeit der Person von unten nach oben aufzunehmen.

Die Bottom-Up-Person sollte auch die "Rahmenbedingungen" der Top-Down-Person respektieren und erkennen, dass dies hilfreich sein kann, um unnötigen Aufwand zu vermeiden, das falsche Problem zu lösen, vom Thema abzukommen usw. Der Bottom-Up-Codierer sollte zumindest wissen, woran es liegt Die Top-Down-Person versucht , dies zu tun, und versucht, zumindest die Bedenken der Top-Down-Person zu berücksichtigen, die im Framework zum Ausdruck kommen. Dies wäre auch dann der Fall, wenn der untere und der obere Teil nicht mit Teilen des Gerüsts übereinstimmen würden.

Sie können den Zeitverlust jedes Entwicklers minimieren, indem Sie große Aufgaben in mehrere kleinere und konzentriertere aufteilen. Lassen Sie sie eng zusammenarbeiten, damit keiner zu weit vom anderen abweicht. Kurze Sprints und kleine Leistungen machen einen langen Weg. Es ist einfacher, einen kleinen Fehler zu beheben als einen großen.

Es mag Ihrem Ziel zuwiderlaufen, aber die Paarprogrammierung funktioniert. Es gibt Dinge, die Sie nicht gleich selbst fangen können, manchmal stunden- oder tagelang. Wenn es nicht in Frage kommt, direkt an Aufgaben zusammenzuarbeiten, versuchen Sie, den Code im Verlauf der Woche häufiger zu überprüfen oder aufzurufen.

Halten Sie alle auf dem Laufenden!

Wenn Sie feststellen, dass Entwickler Code wegwerfen, weil sie in ihrer eigenen Welt nicht aktiv waren, müssen Sie die Konflikte so schnell und effizient wie möglich auffangen und miteinander in Einklang bringen. Ihr Chef wird es zu schätzen wissen, und das Team wird es zu schätzen wissen, keine Woche Arbeit wegzuwerfen, weil er nicht wusste, was der andere Typ tat.

Sie sollten sie auch als Segen zusammenarbeiten sehen. Die Tatsache, dass sie zusammenarbeiten und ihre Fehler im Laufe der Zeit beheben, ist ein gutes Zeichen. Ich habe es auf halbem Weg durch deinen Beitrag geschafft und gedacht "Mann, diese beiden hassen sich wahrscheinlich ..." und zu meiner Überraschung hast du gesagt, sie wollen weiter zusammenarbeiten.

Ich denke, dass dieses Zitat angesichts Ihres Szenarios angemessen ist.

"Wenn sich zwei Leute über alles einig sind, ist einer von ihnen unnötig." ~ Ein alter Typ

Das klingt für mich nach einem idealen Szenario. Andererseits bin ich beide Entwickler gleichzeitig. Ich entwerfe das "große Ganze" gerne in Form von Notizen, die schließlich in einen Issue-Tracker gelangen. Dann beginne ich von unten nach oben über die Implementierungsdetails nachzudenken. Das Gesamtbild entwickelt sich, wenn ich besser verstehe, wie die Teile zusammenpassen, und die Teile entwickeln sich, wenn sich die Anforderungen ändern und ich neue Ideen bekomme.

Vielleicht ist das ein gutes Modell für mehrere Gehirne.

Meiner Meinung nach sind sie komplementäre Profile und können sich sehr gut entwickeln. Sowohl das Codieren als auch das Entwerfen sind notwendige Phasen in der Programmierung und Sie möchten nicht in einem Team landen, in dem niemand X machen möchte. Alles, was Sie brauchen, ist ein bisschen Organisation (siehe, ich kann auch ein kühnes Wort haben!).

Dies kann durch Überwachung geschehen, wie andere betont haben, aber noch besser durch gegenseitige Vereinbarung eines Iterationsplans, wann zu entwerfen und wann zu codieren ist, und generell zu vermeiden, zu codieren, was derzeit entworfen wird.

Bonuspunkt: Sobald ein Projekt in kleinere Module aufgeteilt ist, kann der Top-Down-Programmierer Dinge entwerfen, an denen der Bottom-Up-Programmierer gerade nicht arbeitet, und so eine Phase schaffen, in der beide das tun, was sie wollen. Dies setzt jedoch die Fähigkeit beider voraus, notwendige Anpassungen vorzunehmen, wenn die Zeit gekommen ist, um alles zusammenzusetzen.

Eine Anmerkung: Sie sagten

Angenommen, Sie arbeiten an einem neuen System, anstatt vorhandene Systeme nachzuahmen, und es ist daher nicht immer klar, wie das richtige Enddesign aussehen sollte.

Dies ist ein Teil des Problems: Wenn Sie nicht an einem winzigen Projekt für ein bereits gelöstes Problem arbeiten, gibt es eigentlich kein richtiges Enddesign . Es gibt viele mögliche Designs. Denken Sie daran, dass das Endziel eine funktionierende App ist, es sei denn, Sie tun dies für einen Ego-Schub aufgrund der Schönheit Ihres Codes. Das ist es. Wie Sie dorthin gelangen, ist irrelevant, und der beste Weg, diese beiden Dinge schnell gehen zu lassen, besteht darin, sie in komplementärer Weise zusammenarbeiten zu lassen.

Wie andere gesagt haben, können beide Ansichten in gewisser Weise richtig sein. Es ist alles andere als ungewöhnlich, dass sich zwei Entwickler über Praktiken nicht einig sind, insbesondere über etwas Subjektives wie Design- und Entwicklungsprozesse. Sie haben zwei Leute hier, die sich leidenschaftlich mit dem auskennen, was sie tun, und wissen, wie es geht: Nehmen Sie das an!

Hier besteht ein großes Potenzial für Sie, beiden Personen die Möglichkeit zu geben, auf ihre eigene Weise zu arbeiten, und dennoch die Teile zusammenzufügen, um eine funktionierende Bewerbung zu erhalten.

1. Ich möchte, dass die beiden sich hinsetzen und diskutieren und sie ermutigen, es aus der Sicht des anderen zu sehen.

2. Nach dieser Diskussion können Sie über die Planung sprechen: Dies sollte als Team erfolgen, mit dem Verständnis, dass keiner dem anderen „nachgeben“ muss, aber Kompromisse eingegangen werden müssen. Es gibt viele Möglichkeiten, die Architektur für eine Codebasis zu planen, sodass sie später problemlos erweitert werden kann, ohne dass eine Tonne zusätzlichen Codes erforderlich ist.

3. Sobald du sie zu einer Art Waffenstillstand bringen kannst, lass sie wild werden! Lassen Sie den "Top-Down-Typ" die Planung der Architektur, Schnittstellen, Hierarchien usw. auf hoher Ebene vorantreiben. Lassen Sie den "Bottom-Up-Typ" einspringen und mit dem Schreiben von Code beginnen, sobald ein paar Module geplant sind. Lassen Sie sie formal zustimmen, die Methoden des anderen als gut für das Gesamtprojekt zu akzeptieren: Die Planung für einfache zukünftige Änderungen ist gut, muss jedoch nicht sofort auf diese Weise codiert werden. Erstellen Sie Schnittstellen und Stub-Out-Methoden, um die Struktur des Codes abzurufen, und akzeptieren Sie, dass ein guter Teil des Codes für die Zukunft erst bei Bedarf geschrieben wird.

4. Lassen Sie sie Design und Code häufig gemeinsam überprüfen. Durchlaufen Sie Zyklen, in denen Sie tief in einige Segmente der Architektur eintauchen, detaillierter planen und diese Teile schreiben.

5. Dies ist wahrscheinlich der wichtigste Punkt: Erleichtern Sie Punkte im Zyklus, in denen nur über den Prozess und nicht über die geleistete Arbeit gesprochen wird. Denken Sie über die Dynamik nach, die gerade aufgebaut wird: Es gibt vier Fragen, die Sie stellen sollten. Was ist gut gelaufen, dass wir weitermachen sollten? Was ist schlecht gelaufen, dass wir aufhören sollten? Was fehlt uns? Was können wir gegen das tun, was uns fehlt?

Dies erfordert einige Arbeit: Sie müssen sie dazu bringen, sich darauf zu einigen, auf ihre eigene Weise zusammenzuarbeiten. Für manche Menschen ist es nicht einfach zuzugeben, dass es nicht eine einzige, korrekte Vorgehensweise gibt. Wichtig ist nicht, wie Sie arbeiten oder wie der Code am Ende aussieht. Das Wichtigste ist, dass diese beiden erfahrenen Leute lernen, wie man am besten zusammenarbeitet. Das kann man ihnen nicht einfach sagen. Alles, was Sie tun können, ist, sie durch einen Prozess zu führen, in dem sie lernen, wie man es selbst macht. So wie es kein richtiges Design gibt, gibt es auch keinen richtigen Weg für Menschen, um zu arbeiten.

Generell gibt es nach meiner Berufserfahrung im Vorfeld nicht genügend Design. Und das Design, das sich im Vorfeld abspielt, ist von geringer Qualität . Das ist schlecht. Meistens, weil das Ergebnis ist (mehr oder weniger), Schlamm an die Wand zu werfen und zu sehen, was klebt. Technische Schulden werden von Anfang an eingebrannt.

Top-Down ist in der Regel besser als Bottom-Up. Obwohl ich Bottom-up nicht ganz ausschließen würde. Der Grund dafür ist, dass Sie von oben nach unten gezwungen sind, über das Problem nachzudenken und bessere Fragen zu stellen . Dies verstärkt den ersten Punkt oben ... führt zu einer höheren Designqualität und beeinflusst normalerweise einen Großteil der Arbeit auf niedrigerer Ebene. Dies reduziert beträchtliche Nacharbeiten, die sonst häufig erforderlich sind, wenn die Komponenten der unteren Ebene zuerst gebaut werden.

Es besteht ein nicht unerhebliches Risiko, dass der Entwicklungsdruck bei der erstmaligen Erstellung von Bottom-up-Komponenten die Geschäftsanforderungen an die entwickelten Komponenten anpasst. Das ist auch schlecht. Geschäftsanforderungen sollten das Design und die Implementierung bestimmen. Alles, was in die andere Richtung geht, führt zu schlechteren Ergebnissen.

Kein Ansatz ist ausreichend. Es scheint, dass jeder von ihnen klug oder erfahren genug ist, um die Mängel des anderen Ansatzes zu erkennen (vielleicht haben sie sich verbrannt?), Aber die Mängel ihres eigenen gewählten Ansatzes nicht zu erkennen ...

Die Wahrheit ist, dass ein gemischter Ansatz notwendig ist:

• Es ist fast unmöglich, das "richtige" Design im Voraus zu finden. Ein gewisses Maß an Experimenten ist erforderlich, um die Schmerzpunkte, Engpässe usw. zu identifizieren. (Hinweis: Sie sind niemals dort, wo Sie glauben, dass sie sein werden.)
• Es ist fast unmöglich, irgendwohin zu gehen, indem man einfach "geht". Es ist wahrscheinlicher, dass man irgendwo endet, wo man nicht hin wollte, oder einfach nur im Kreis läuft als irgendetwas

Wenn Sie beides mischen, können Sie:

• Haben Sie eine grobe Skizze mit Anweisungen und ein Gerüst der Infrastruktur
• und Komponenten zu entwickeln, die zu dieser Vision passen

Da es kein vorhandenes System gibt, das diesen Zweck erfüllt, ist es wichtig, im Voraus zu erkennen, dass:

• Experimentieren / Prototyping ist erforderlich
• Iteration wird daher notwendig sein

Daher sollte der Schwerpunkt darauf gelegt werden, so schnell wie möglich ein "funktionierendes" System zu erreichen, auch wenn dies bedeutet, Eckfälle usw. zu ignorieren. Dies ist das Konzept der "dünnen vertikalen Scheibe": Anstatt die Fundamente des Hauses zu errichten , dann die Wände, dann die Dachkonstruktion, ... und erst am Ende etwas Nutzbares erhalten (oder nie bekommen, oder es auch nicht wirklich nutzbar sein) ... es ist besser, zuerst einen voll ausgestatteten Raum zu bauen , wie das Badezimmer. Es ist sofort einsatzbereit und kann zum Sammeln von Feedback verwendet werden.

Damit Feedback jedoch wertvoll ist, ist es am besten, zuerst einen Kernbereich zu behandeln.

Also, was machen Sie mit Ihren Mitarbeitern?

Das erste ist, dass beide die Notwendigkeit der Zusammenarbeit und die Notwendigkeit einer Einigung über einen Weg nach vorne verstehen müssen: Ständige Zurechtweisung muss, so wie sie sind, auf die Nerven gehen und die Motivation beeinträchtigen. Ich habe oben dargestellt, was sich in der Praxis für mehrere Projekte bewährt hat. Sie können es als Vorschlag verwenden.

Dann müssen sie sich darüber einigen, wer was tut. Beachten Sie, dass im oben unterstrichenen Mittelweg-Ansatz beide Aufgaben ausführen sollten, die sie zu schätzen wissen.

Beachten Sie, dass sowohl das Bauen der Skelette als auch das Bauen der Steine ​​am besten schrittweise angegangen wird.

1. Beide sollten eine grobe Skizze des Skeletts erhalten und dann gemeinsam entscheiden, auf welche "dünne Schicht" sie sich zuerst konzentrieren sollen
2. Der Bottom-Up-Typ sollte anfangen, an dem am besten verstandenen Stück "dünne Scheibe" zu arbeiten.
3. Der Mann von oben nach unten sollte anfangen, das Skelett auszuforschen, und am besten zuerst die blockierendsten Teile angreifen, um die Scheibe fertigzustellen

Spülen und wiederholen, bis die Scheibe funktioniert. Sammeln Sie Feedback auf dem Weg zur Optimierung nach Bedarf.

Achtung: Dies ist ein Prototyp. Beide müssen bereit sein, ihn wegzuwerfen und bei einem völlig anderen Design von vorne zu beginnen.

Was Sie brauchen, ist ein Leiter (oder Vorgesetzter), der die Softwareentwicklung versteht und entscheidet, welcher Ansatz im Projekt verwendet werden soll. Falls erforderlich, der Führer leitet die Entwickler an der Arbeit in einer bestimmten Art und Weise, unabhängig von ihren persönlichen Vorlieben.

Die einzige effiziente Lösung, die ich mir vorstellen kann, ist, dass jeder Entwickler seinem eigenen Stil für das Design folgt.

Eigentlich könnte es sehr ineffizient sein ... denn es besteht die Möglichkeit, dass es zu vielen Konflikten und Nacharbeiten kommt. Schlimmer noch, es kann sein, dass Sie ein totales Projektversagen haben.