Wie kann eine große Anzahl von Entwicklern Software schreiben, ohne dass ein umständlicher Prozess oder eine schlechte Software erforderlich ist?

Question

Ich arbeite in einem Unternehmen mit hunderten von Leuten, die Software für im Wesentlichen das gleiche Produkt schreiben. Die Qualität der Software muss hoch sein, weil so viele Leute davon abhängen (nicht zuletzt die Entwickler selbst). Aus diesem Grund hat jedes größere Problem zu einer neuen Überprüfung geführt - entweder automatisch oder manuell.

Als Ergebnis wird der Prozess der Bereitstellung von Software immer lästiger. Das erfordert mehr Entwickler, die ... nun, Sie können sehen, dass es ein Teufelskreis ist.

Wir haben jetzt ein Problem mit der schnellen Freigabe von Software - die Vorlaufzeit, sogar um eine Zeile Code für ein sehr ernstes Problem zu ändern, ist mindestens einen Tag.

Mit welchen Techniken beschleunigen Sie die Bereitstellung von Software in einem großen Unternehmen bei gleichbleibender Softwarequalität?

Answer 1

Ich arbeite auch in einer großen und umständlichen Organisation. Ich hatte Erfolg, mehrere Methodologien zu implementieren, aber es gibt zwei besonders, die ich besonders wertvoll gefunden habe.

Iterative und inkrementelle Entwicklung - Halten Sie Ihren Release-Zyklus kurz und fest. Wenn in einem großen Team zwischen den Releases zahlreiche Änderungen vorgenommen werden, können Sie sich in einem Albtraum der Integration wiederfinden.

Große Organisationen neigen zu großen Projektplänen mit langen Entwicklungszeiten. Bekämpfe das. Ein Projekt über ein ganzes Jahr hinaus zu planen, macht keinen Sinn, wenn sich nach den ersten zwei Wochen der Entwicklung die gesamte Wahrnehmung ändert. Bedienen Sie Ihre Stakeholder, um sich daran zu gewöhnen, kleine inkrementelle Releases zu erstellen und sich an die sich ständig ändernden Anforderungen anzupassen.

Automatisierte Komponententests - Dies ist ein guter Weg, um sicherzustellen, dass Sie hochwertige Software veröffentlichen. Die schlimmsten Fehler werden durch scheinbar unschuldige Codeänderungen verursacht, die an anderer Stelle unbeabsichtigte Konsequenzen haben. Umfassende Komponententests sind vielleicht der beste Weg, um diese Art von Bug zu fangen. Wenn Sie zu test driven development oder behavior driven development graduieren können, noch besser.

Jede große Organisation wird einige mittelmäßige Entwickler haben. Es ist eine Tatsache des Lebens. Das automatische Komponententesten ist eine gute Möglichkeit, sie im Auge zu behalten. Lassen Sie einen Ihrer besseren Entwickler ihre Komponententests für sie schreiben. Sie werden Gewissheit haben, dass zumindest ihr Code funktioniert (auch wenn es hässlich ist).

Answer 2

Siehe Continuous-Integration

Und bitte lesen The Joel Test: 12 Steps to Better Code.

Answer 3

Es gibt viele Möglichkeiten, den Prozess zu verbessern, aber die Schlüsselkomponente ist modularity. Durch die klare Trennung der Verantwortlichkeiten (sowohl im Code als auch in der Organisation) und die Definition klarer und konsistenter Schnittstellen kann ein großes Team aus vielen kleinen Teams bestehen, die alle miteinander verbunden sind.

Answer 4

Wise aber düster Sprüche:

• Fred Brooks: Adding programmers to a late project makes it later.

• Gerry Sussman: Programmierer kombinieren wie Widerstände parallel.

• Jemand anderes: Die Kosten eines Projekts ist die Anzahl der Programmierer mal die Länge des Zeitplans.

Etwas, das funktionieren könnte:

das Projekt so organisieren, dass es eine Kernanwendung von einer oder zwei Personen aufgebaut ist, vorzugsweise über eine Sprache betrieben. Lassen Sie dann alle Programmierer effektiv Benutzer des Kerns sein, indem Sie in dieser Sprache kodieren.

Ich denke an sprachbasierte Produkte: SAS, S/R, MATLAB usw.