Fertigung vs Softwareentwicklung [geschlossen]

Es wird oft gesagt, dass die Softwareindustrie im Vergleich zur Fertigung noch nicht ausgereift ist. Speziell im Hinblick auf Prozessorientierung.

Frage : Können wir als Entwickler aus den Prozessen der Fertigungsindustrie lernen? Kann die Übernahme ihrer Prozesse die Erfolgsrate der Softwareentwicklung erhöhen?

Mein Standpunkt : Bei der Herstellung ist die Erstellung eines Produkts stark prozessgesteuert. Möglicherweise haben Sie eine Fabrik, in der jede Person bestimmte Aufgaben hat, denen sie folgt. Ein Arbeiter (oder Roboter) kann den ganzen Tag eine Schraube festziehen. Dann wird die nächste Aufgabe im Prozess vom nächsten Spezialisten ausgeführt. Die Arbeiter (und Roboter) halten sich nicht vom Prozess ab und erfinden nichts "on the fly". Die Teile durchlaufen den gesamten Prozess und die Ausgabe ist ein fertiges Produkt. Es funktioniert gut und Unternehmen erzielen 99,99966% fehlerfreie Produkte. Unternehmen bügeln Ineffizienzen im Laufe der Zeit aus. Dies ist beeindruckend und kann durchaus das Zeichen einer reifen Industrie sein.

Bei der Herstellung kann ein definierter Prozess buchstäblich das fertige Produkt erzeugen. Ich glaube nicht, dass dies bei Software der Fall ist. Möglicherweise verfügen wir über Prozesse zur Quellcodeverwaltung, Codeüberprüfung, Einchecken von Blättern, Sammeln von Anforderungen, SDLC usw. Die Ausführung dieser Prozesse führt jedoch nicht an und für sich zu einem fertigen Produkt. Diese Prozesse können vorteilhaft sein, sind jedoch orthogonal zur tatsächlichen Erstellung.

Angenommen, Ihr Unternehmen ist mit der Erstellung von Software beauftragt, die Millionen von Bildern durchsucht, um die Gesichter von Kriminellen zu finden. Trotz der starken prozessgesteuerten Umgebung muss der Entwickler "on the fly" Dinge erstellen. Dinge im laufenden Betrieb zu tun, widerspricht dem Geist der Herstellung. Ein guter Herstellungsprozess kann ohne Gedanken eines Roboters ausgeführt werden.

Für die Erstellung komplexer Algorithmen, die im Kopf eines Menschen noch nicht ergründet wurden, ist es eine Notwendigkeit, Dinge im laufenden Betrieb zu erstellen. Softwareentwicklung ist nicht die Folge eines Prozesses, sondern die Erstellung von Prozessen, die von einem Computer ausgeführt werden sollen. Das ist ein grundlegender Unterschied. Unabhängig davon, wie viele orthogonale Prozesse wir für die Entwicklung einsetzen, werden wir bei der Erstellung immer "on the fly" darauf zurückgreifen.

Jeder, mit dem ich spreche, scheint der Einstellung zur Fertigung zuzustimmen. Bin ich allein in meinen Gedanken?

Der grundlegende Unterschied zwischen Softwareentwicklung und -herstellung besteht darin, dass für Software die Entwurfsphase praktisch das Ganze ist. Bei der eigentlichen Produktion (Fließbandteil in der traditionellen Fertigung) müssen einige Dateien kopiert werden. In der Software das Produktdesign ist das Produkt.

Ja, wir können aus Herstellungsprozessen lernen, aber nur, wenn wir bedenken, dass wir die Entwurfsphase und nicht die Produktionsphase betrachten müssen und dass viele Herstellungsprozesse so aufgebaut sind, dass sie den spezifischen Einschränkungen einer teuren Produktionskette gerecht werden , was einfach nicht für Software gilt.

Ein Beispiel für ein Prozessmodell, das in Software sehr gut funktioniert, im Produktdesign jedoch häufig schrecklich versagt, ist das iterative Design. Sie beginnen mit einem minimalen Prototyp und fügen mit jeder Iteration Funktionen hinzu. Ein Prototypauto zu bauen, um zu sehen, wie das neue Design des Heckscheibenknopfs aussieht, ist lächerlich, aber in der Software macht es Sinn (drücken Sie einfach F5 und warten Sie ein paar Sekunden - voilà, bereit für eine Probefahrt).

Wenn wir uns Produktdesignprozesse ansehen, fallen die besten Branchen in zwei Kategorien:

• diejenigen, bei denen die Produktion zu Rohstoffpreisen realisiert werden kann; zB die Plattenindustrie (1% oder weniger des Preises für eine CD wird gebacken und gedruckt), grafische Medien usw.
• diejenigen, bei denen die Mengen so gering sind, dass die Designphase der wichtigste Kostenfaktor ist (Luxusartikel, hochgradig maßgeschneiderte Produkte, Nischenmärkte ...)

Es ist ein grundlegender Fehler, Prozesse von der physischen Fertigung auf die Softwareentwicklung anzuwenden: Die Softwareentwicklung wiederholt sich nicht (wenn sie an Ihrem Arbeitsplatz ist, suchen Sie einen anderen Arbeitsplatz), sie ist nur teilweise vorhersehbar, es gibt nur sehr wenige physische Einschränkungen ( Hardware-Geschwindigkeit ist eins), und sowohl der Ansatz als auch die Ergebnisse können sehr persönlich sein. Die Anwendung von Fließbandphilosophien auf das, was im Grunde genommen eine Frage des analytischen und kreativen Denkens ist, kann (und tut dies oft) verheerende Auswirkungen haben.

Wenn Sie dieselbe exakte Software immer und immer wieder schreiben möchten (anstatt sie einfach zu kopieren), können Sie dies sehr effizient über eine Montagelinie tun.

Die Erstellung von Software ist jedoch keine sich wiederholende Aufgabe, sondern jedes Modul ist einzigartig. Deshalb ist der Vergleich zur Fertigung ungültig.

Ich denke, dass die Antwort, die Sie suchen, hier zutreffend oder realistisch ist. Ich denke, Sie möchten wissen, wie wir unsere Prozesse so einrichten können, dass sie der Fertigungsindustrie ähnlicher sind. Stattdessen denke ich, dass die eigentliche Frage lautet: "Wissen, was das verarbeitende Gewerbe und andere Branchen tun, um Qualitätsprodukte herzustellen, was können wir lernen?" oder "Was kann die Softwareindustrie tun, um die Qualität zu verbessern?"

Leider ist die Antwort darauf unklar, da die Softwareindustrie selbst die Antwort immer noch nicht kennt. Um dies beantworten zu können, muss die Softwareindustrie nachforschen, was funktioniert und warum? Zum Beispiel gab es Studien, die zeigen, dass Test Drive Design (TDD) zu einer Qualitätsverbesserung führt. Obwohl die Frage der Produktivität noch unbeantwortet oder zumindest noch nicht vollständig verstanden zu sein scheint. Soweit die Beweise bisher zeigen:

• Code-Überprüfungen sind ausgezeichnet und zeigen die meisten Fehler, aber die Wirksamkeit einer Überprüfung nimmt nach der ersten Stunde der Überprüfung ziemlich stark ab. Angesichts der Tatsache, dass die durchschnittliche Person nur einige hundert Codezeilen pro Stunde lesen kann, empfiehlt es sich, dass Entwickler Änderungen in kleinere Teile aufteilen.
• Je länger es dauert, einen Fehler zu finden, desto teurer (Zeit und Geld) wird es sein, ihn zu beheben. Wenn ein Entwickler es beim Schreiben des Codes findet, sagen wir, dass die Kosten 1 sind. Wenn ein Unittest es später findet, betragen die Kosten 10, wenn EVT es findet, betragen die Kosten 100 und so weiter.
• Es gibt Hinweise darauf, dass je komplexer die Anforderungen sind, desto komplexer die Lösung ist und je komplexer die Lösung ist, desto wahrscheinlicher sind Fehler.

Es gibt einen Mann namens Greg Wilson, der vor einigen Jahren einen ausgezeichneten Vortrag darüber gehalten hat. Hier ist ein Link zum Vortrag: Greg Wilson Talk

Darüber hinaus würde ich sagen, schauen Sie auf Ihre eigene Arbeit zurück und finden Sie die Themen mit den Arten von Fehlern, die Sie einführen, sowie mit den Teilen, mit denen Sie zu kämpfen haben. Stellen Sie diese Ergebnisse zusammen und erstellen Sie dann eine Checkliste, die Sie an verschiedenen Stellen in Ihren Prozess einfügen können, um bessere Arbeit zu leisten. Persönlich habe ich auf die letzten Jahre meiner Arbeit zurückgeblickt und festgestellt, dass die von mir eingeführten Probleme einige gemeinsame Themen haben. Insbesondere habe ich das gefunden

• Ich erinnere mich nicht oft daran, alle Varianten zu bauen, die dazu führten, dass ich den Build brach.
• Oft denke ich nicht bei jeder Änderung an Folgendes. Der gute Fall, der schlechte Fall und die Ausnahmefälle.
• Alle möglichen Szenarien, die auftreten können. Beachten Sie, dass dies sehr schwierig ist, da es viele davon gibt.

Da ich einige Themen zu meinen Fehlern gefunden habe, habe ich Checklisten erstellt, die ich automatisch verwende, da ich sie in meine Skripte einfüge, um diese Probleme zu umgehen. Über diesen Aufruf wurde ein Buch geschrieben, das "Checklisten-Manifest", in dem detailliert beschrieben wird, wie sie sinnvoll eingesetzt werden können. Persönlich fand ich es sehr aufschlussreich.

Es geht nicht darum, "ihre" Prozesse zu übernehmen. Es geht darum, "einige" Prozesse zu übernehmen, die nicht die üblichen und geschätzten Nachteile haben, Fließbandprozesse für kreative Zwecke einzusetzen. Das Wichtigste dabei ist die Idee, dass sich die Qualität der Prozesse direkt auf die Qualität des Produkts auswirkt.

Die besten Prozesse oder Produkte für diese Angelegenheit sind diejenigen, die wie Hand in Hand zum beabsichtigten Verwendungsszenario passen. Die Sache, über die man nachdenken sollte, ist, dass der eigentliche Teil zum Schreiben von Code der einzige ist, der sich zumindest auf makroskopischer Ebene nicht wiederholt. Alle anderen Aspekte wie Versionskontrolle, Fehlerverfolgung, Planung, Schätzungen, Messungen usw. und die Verwendung eines standardmäßigen, maßgeschneiderten und bewährten Prozesses können Ihnen zumindest in diesen Bereichen helfen.

Nein, der Softwareentwicklungsprozess kann nicht mit der Produktion am Fließband verglichen werden, und als solche sind "ihre Prozesse" nicht in Ordnung, aber die Phase des Produktionsdesigns / Produktdesigns des Produkts in einer Fertigungsindustrie kann diejenige sein, von der man sich inspirieren lässt.

Frage: Können wir als Entwickler aus den Prozessen der Fertigungsindustrie lernen? Kann die Übernahme ihrer Prozesse die Erfolgsrate der Softwareentwicklung erhöhen?

Antwort: Ja natürlich. Es gibt viele Lektionen, die Softwareentwickler aus der Fertigung lernen können, obwohl Softwareentwicklung ein kreativer Prozess ist. Softwareentwicklung ist selbst ein Prozess und umfasst viele andere Prozesse. Je besser Sie diese Prozesse definieren und steuern können, desto besser können Sie den Prozess der Softwareentwicklung insgesamt steuern. Das bedeutet nicht, dass Sie jeden Tastendruck eines Entwicklers vorschreiben sollten. Dies bedeutet lediglich, dass Sie als Entwickler Aufgaben natürlich in einer bestimmten Reihenfolge ausführen und diese Aufgaben häufig verwaltet werden können. Hier sind einige Beispiele:

• Fehlerverfolgung: Was passiert damit, wenn ein Fehler beobachtet oder gemeldet wird? Schreiben Sie es auf ein Stück Papier und kleben Sie es auf einen "Nachforschungs" -Spike? Entfernen Sie diese Reste später einzeln, untersuchen Sie sie und verschieben Sie sie schließlich auf die "aufgelöste" Spitze? Wenn Sie dies jedes Mal tun, wenn Sie einen Fehlerbericht erhalten, haben Sie einen genau definierten, messbaren Prozess und sind wahrscheinlich viel besser dran als jemand, der über ein ausgefallenes High-Tech-Fehlerverfolgungssystem verfügt, das so lästig ist dass einige Teammitglieder Fehler auf andere Weise oder gar nicht verfolgen.

• Versionskontrolle: Es besteht eine gute Chance, dass Sie die Versionskontrolle dort verwenden, wo Sie arbeiten, und die Versionskontrolle ist offensichtlich viel nützlicher, wenn jeder sie auf die gleiche Weise verwendet.

• Produktdesign: Entscheiden Sie, welche Funktionen implementiert werden sollen, indem Sie Pfeile auf eine mit Haftnotizen bedeckte Wand werfen? Wenn ja, haben Sie einen Prozess. Ich glaube nicht, dass irgendjemand argumentieren würde, dass es ein großartiger Prozess ist, aber zumindest ist es ein Ausgangspunkt. Wenn Sie den Prozess ändern, wie können Sie dann sicher wissen, dass Ihre Änderung tatsächlich eine Verbesserung war, es sei denn, Sie messen vorher und nachher? Das kannst du nicht.

• Codeüberprüfungen: Wäre eine Codeüberprüfung hilfreich, wenn sich der Überprüfungsprozess und die Codierungskriterien für jede Überprüfung ändern würden? Natürlich nicht.

• Lebenszyklus der Softwareentwicklung: Die gesamte Analyse -> Design -> Implementierung -> Test -> Wartungszyklus ist ein Prozess, der klar definiert werden sollte.

In jedem dieser Fälle können Sie mit einem vorhandenen Prozess die Ein- und Ausgaben messen und feststellen, ob die von Ihnen vorgenommenen Änderungen den beabsichtigten Effekt haben. Wenn keine Prozesse vorhanden sind, raten Sie nur, wenn Sie versuchen, Ihre Arbeitsweise zu verbessern. Genau darum geht es in der Fertigung, und es ist nur dann sinnvoll, die aufeinanderfolgenden Verfeinerungswerkzeuge der Fertigung auszuleihen, wenn sie angemessen sind.

Es gibt ein ganzes Feld, das sich der Definition und Verbesserung von Prozessen widmet, die zum Erstellen und Verwalten von Software verwendet werden. Es heißt Software Engineering . Es ist keine Überraschung, dass Sie beim Lesen von CMMI Fragen zum Entwicklungsprozess haben - CMMI ist ein Produkt des Software Engineering Institute .

Die Softwareentwicklung hat bereits viele Fertigungskonzepte übernommen:

• Es ist schwer, den Einfluss der austauschbaren Teile von Eli Whitney auf die OOP- und komponentenbasierte Entwicklung nicht zu erkennen .

• Die in der Softwareentwicklung verwendeten Projektmanagementtechniken unterscheiden sich nicht wesentlich von den für die Fertigung entwickelten. Als nur zwei Beispiele hat die Software-Welt erst kürzlich das Kanban-Konzept übernommen, das vor Jahrzehnten bei Toyota entwickelt wurde, und Gantt-Diagramme wurden lange vor dem Bau des ersten elektronischen Computers in der Fertigung verwendet.

• Qualitätsmanagementmethoden wie Six Sigma, die für die Fertigung entwickelt wurden, wurden an die Softwareentwicklung angepasst.

Trotz der starken prozessgesteuerten Umgebung muss der Entwickler "on the fly" Dinge erstellen.

Wollen Sie mir sagen, dass jemand selbst entscheiden wird, dem Gesichtserkennungspaket einen Patch hinzuzufügen, und ihn in den Produktions-Build einfügt, ohne zuvor ein Problem im Tracking-System zu verursachen und das Design überprüfen zu lassen? den Code in die Versionskontrolle einchecken oder die Testleute ihn zuerst ansehen lassen? Unser Prozess erfordert diese Dinge aus sehr guten Gründen. Wenn Sie mit "on the fly" "außerhalb des Prozesses" meinen, ist dies nicht akzeptabel.

Dinge im laufenden Betrieb zu tun, widerspricht dem Geist der Herstellung.

Wenn "on the fly" "außerhalb des Prozesses" bedeutet, haben Sie wieder Recht. Wenn Sie jedoch der Meinung sind, dass die Fertigung kein schnelles Denken und die Entwicklung kreativer Problemlösungen erfordert, liegen Sie falsch. Bei der Herstellung treten alle möglichen Probleme auf - die Cupcakes haben nicht genügend Cremefüllung, lackierte Oberflächen bestehen plötzlich nicht mehr den Kratztest der Qualitätssicherung, 20% der fertigen Teile haben keinen wichtigen Haltering mehr, das Teigmischsystem ist defekt kritische Stelle...