Zu viel Versionskontrolle und Fehlerverfolgungsaufwand pro Änderung?

Ich arbeite an einem Ort, der CVS-verrückt und Bugzilla-verrückt ist.

1. Es gibt so viele Zweige von jeder Veröffentlichung, dass man sie nicht zählen kann. Jeder verschmilzt ständig automatisch.

2. Es gibt keine Flüssigkeit bei diesem Job. Alles fühlt sich Schritt für Schritt an . Selbst für eine einfache Sache sind 25 Schritte erforderlich. Es ist nicht so, als würde man in einer Fabrik produzieren. Es ist so, als würde man jeden Tag eine eigene Fabrik errichten.

Beispielsituation:

Um einen einzelnen Fehler zu beheben, erhalte ich zunächst eine saubere, neue virtuelle Maschine. Dann erstelle ich einen Zweig für diese einzelne Fehlerbehebung, basierend auf einem anderen Zweig, der im Bugzilla-Bericht beschrieben ist. Ich installiere den Zweig auf der Maschine, richte das ein. Ich behebe den Fehler. Ich checke es ein und lasse es und die Maschine für andere zum Testen. Dann muss ich in die Bug Control Software gehen und erklären, was ich getan habe und einen Testfall mit allen Schritten schreiben. Irgendwann verschmilzt es jemand anderes mit einer Veröffentlichung.

Egal wie klein der Fehler ist, ich muss all diese Dinge tun. Manchmal kombinieren Leute die Arbeit an mehreren Bugs, aber wie gesagt, es gibt so viele Zweige, dass dies kaum möglich ist.

Bei jedem anderen Job gehe ich einfach rein und behebe den Fehler. Ich kann mich kaum daran erinnern, SCM benutzt zu haben, obwohl jeder Job, den ich hatte, es benutzt hat: Das liegt daran, dass sie es bei jedem anderen Job irgendwie aus dem Weg gehalten haben .

Gibt es einen Punkt, an dem der Prozess in die Quere kommt und zum Selbstzweck wird? Ist das überhaupt Technik?

Gibt es einen Punkt, an dem der Prozess in die Quere kommt und zum Selbstzweck wird?

Schwere Prozesse sind leider häufig. Einige Leute - insbesondere das Management - glauben religiös, dass aus Prozessen Produkte entstehen. Sie übertreiben die Prozesse und vergessen, dass es wirklich eine Handvoll fleißiger, kluger Leute sind, die die Produkte tatsächlich herstellen. Für das obere Management ist es beängstigend, zu glauben, dass ihr Geschäft in den Händen weniger Geeks liegt, und deshalb die Augen vor der Realität zu schließen und stattdessen an ihren lieben "Prozess" zu denken, der ihnen die Illusion von Kontrolle gibt.

Aus diesem Grund können agile Startups mit einer Handvoll guter Ingenieure große, etablierte Unternehmen schlagen, deren Mitarbeiter 95% ihrer Energie für Prozesse und Berichterstellung aufwenden. Einige Beispiele von einst kleinen Startups, die ihre Konkurrenten geschlagen und / oder völlig neue Märkte geschaffen haben:

• Apple (Apple I wurde von 1 Ingenieur erstellt; damals waren 3 Männer im Unternehmen).
• Google (ursprünglich von 2 Programmierern erstellt).
• Facebook ( 1- Mann-Aufwand ursprünglich).
• Microsoft ( 2- Mann-Unternehmen im Jahr 1975).

Man könnte leicht sagen, dass dies nur Ausreißer sind, extreme Ausnahmen, und um etwas Ernstes zu tun, ist es besser, ein großes, etabliertes Unternehmen zu sein. Aber die Liste geht weiter. Und weiter. Es ist peinlich lang. Fast jeder heutige Großkonzern begann als Werkstatt, was etwas Ungewöhnliches tat. Etwas Komisches. Sie machten es falsch. Glaubst du, sie haben es dem Prozess entsprechend gemacht?

Unternehmen leiden normalerweise unter dem, was ich als Control-Flexibility-Dilemma bezeichnen möchte. Je weniger Regeln, Strukturen und bürokratischer Aufwand, desto einfacher und schneller ist es, Dinge zu erledigen (es macht auch mehr Spaß). Es ist jedoch genauso einfach, "schlechte" Dinge wie "gute" Dinge zu tun. Das bedeutet, dass es Ihnen nur gut geht, wenn Sie über qualifizierte Mitarbeiter verfügen, die nur wenige unkritische Fehler machen.

Auf der anderen Seite neigen Unternehmen dazu, sich auf immer mehr Regeln zu stützen, wenn Sie eine Menge niedriger bis angelernter Mitarbeiter haben und / oder die Kosten für Fehler zu hoch sind (wie das Risiko von Space-Shuttle-Trümmern über der nördlichen Hemisphäre) "und" Prozesse ", um sie zu minimieren.

Das einzige Problem ist, dass der kumulative Aufwand dieser Prozesse es schwierig macht, irgendetwas zu erreichen, was dazu führen wird, dass talentiertere Mitarbeiter das Unternehmen verlassen. Dies führt dazu, dass die durchschnittliche Kompetenz noch weiter sinkt, was noch mehr Prozesse und Bürokratie erfordert. So geht die Todesspirale so lange weiter, bis etwas Radikales passiert oder die Firma auf den Beinen ist.

Wenn Sie sich in einem Unternehmen befinden, das in diesem Punkt anscheinend über den Punkt hinausgegangen ist, an dem es kein Zurück mehr gibt, können Sie sich entweder dazu entschließen, sich nicht um Ihren Job zu kümmern (was die meisten, die geblieben sind, getan haben) oder verdammt noch mal rauszukommen von dort mit deiner Seele intakt :)

Wenn die Firma nicht zu weit gegangen ist und Sie die Mittel haben, können Sie versuchen, den Kurs durch bloße Entschlossenheit und Willenskraft umzukehren. Beachten Sie jedoch, dass es eine enorme Menge an Arbeit und persönlicher Energie erfordern kann, ohne dass ein Erfolg garantiert ist. Stellen Sie also sicher, dass es sich lohnt. Manchmal ist es besser, nur den Verlust zu verringern und sich eine Erfahrung reicher zu machen.

Es gibt nur einen gültigen Grund für einen solchen Entwicklungsstil: Die entwickelte Software ist absolut geschäftskritisch und darf unter keinen Umständen Fehler enthalten. Denken Sie an die Firmware für die Einspritzung von Düsentriebwerken in Passagierflugzeugen, an die Firmware für Herzschrittmacher oder an das Nuklearraketen-Startsystem.

In allen anderen Situationen wird der Aufwand das Geschäft töten. Zeit zum Weitermachen.

Diese Frage enthält wirklich zwei Fragen, die separat behandelt werden müssen:

Warum haben einige Teams einen strengen Entwicklungsprozess?

Die einfache Antwort lautet: Wenn nicht, passieren Fehler. Kostspielige Fehler. Dies gilt sowohl für die Entwicklung als auch für den Rest des IT-Bereichs (Sysadmins, DBAs usw.).

Dies ist für viele Entwickler und IT-Mitarbeiter sehr schwer zu verstehen, da die meisten von uns bisher nur an einem der "Extreme" gearbeitet haben - entweder großen Unternehmen im Fortune-Stil mit mindestens einem Dutzend Entwicklern und strengen Prozessen, die befolgt werden müssen, oder kleine, Mikro-ISVs oder sogar freiberufliche Arbeiten, bei denen die Leute einfach nicht schlecht duschen oder die Kosten für eine Drecksau sind gering.

Wenn Sie jedoch jemals ein Unternehmen zwischen diesen Phasen gesehen haben - sogar ein Unternehmen mit hochqualifizierten und talentierten IT-Mitarbeitern -, werden Sie die Gefahren eines fehlenden oder halbherzigen Prozesses verstehen. Sie sehen, die Kommunikation zwischen den Mitarbeitern leidet unter einem kombinatorischen Explosionsproblem . Sobald Sie das Niveau von 6 bis 10 Entwicklern in einem Team erreicht haben, ist die Hauptursache für schwerwiegende oder kritische Mängel nicht ein Mangel an Talent oder Know-how, sondern ein Mangel an Kommunikation.

Alice erkundigt sich am Montagmorgen und beschließt, dass es in Ordnung ist, eine rekonstruktive Operation im Kofferraum durchzuführen, da sonst niemand an diesem Teil arbeitet. Bob kommt eine Stunde später, zurück aus dem Urlaub und voller Energie, und beschließt, eine neue Hauptfunktion in genau demselben Bereich zu implementieren. Warum sollte er sich mit einer Filiale beschäftigen, weil sowieso niemand diesen Code berührt? Also zahlt Alice diese "technische Schuld" aus, Bob implementiert seine Killer-Funktion, die seit 6 Monaten auf dem Spiel steht, und als beide endlich ihren Code einchecken (natürlich kurz vor Ladenschluss am Freitag!), Das Ganze Das Team muss zurückbleiben und versuchen, die albtraumhafte Hölle der Konflikte zu meistern, die in den nächsten Wochen als Bugs und Regressionen weiterleben.

Alice und Bob haben beide großartige Arbeit bei den Codierungsaufgaben geleistet, aber sie haben beide mit einer schlechten Entscheidung begonnen ("Was ist das Schlimmste, was passieren könnte?"). Der Teamleiter oder Projektmanager führt sie post mortem durch und erstellt eine Checkliste, um dies zu verhindern:

• Check-ins müssen täglich erfolgen, um die Auswirkungen von Konflikten zu minimieren.
• Änderungen, die deutlich länger als 1 Tag dauern, müssen in Zweigstellen vorgenommen werden.
• Alle wichtigen Aufgaben (einschließlich nicht funktionsbezogener Arbeiten wie Refactoring) müssen ordnungsgemäß nachverfolgt und im Bug-Tracker zugewiesen werden.

Ich wette, für viele von uns scheint dieser "Prozess" nur ein gesunder Menschenverstand zu sein. Es ist ein alter Hut. Aber wussten Sie, dass viele kleinere Teams dies nicht tun? Ein Zwei-Mann-Team kümmert sich möglicherweise überhaupt nicht um die Quellcodeverwaltung. Wen interessiert das? Es ist ehrlich gesagt nicht notwendig. Die Probleme treten erst auf, wenn das Team wächst, der Prozess jedoch nicht.

Prozessoptimierung ist natürlich wie Leistungsoptimierung; es folgt einer inversen Exponentialkurve. Die obige Checkliste beseitigt möglicherweise 80% der Fehler, aber nachdem Sie sie implementiert haben, stellen Sie fest, dass die verbleibenden 80% der Fehler auf etwas anderes zurückzuführen sind . In unserem fiktiven, aber vertrauten Beispiel handelt es sich möglicherweise um Erstellungsfehler aufgrund unterschiedlicher Erstellungsumgebungen, was wiederum darauf zurückzuführen ist, dass es keine Standardhardware gibt und Entwickler Open-Source-Bibliotheken verwenden, die alle zwei Wochen aktualisiert werden.

Sie haben also drei Möglichkeiten: Entweder (a) die Hardware standardisieren und die Bibliotheksnutzung von Drittanbietern stark einschränken, was kostspielig ist und die Produktivität erheblich beeinträchtigen kann, oder (b) einen Build-Server einrichten, für den die Sysadmin-Gruppe und a zusammenarbeiten müssen Vollzeit-Entwickler, um es zu warten, oder (c) lassen Sie Entwickler dies selbst tun, indem Sie eine standardmäßige virtuelle Maschine verteilen und die Entwickler auffordern, darauf aufzubauen. Es ist klar, dass (b) die beste langfristige Lösung ist, aber (c) kurzfristig ein besseres Gleichgewicht zwischen Zuverlässigkeit und Zweckmäßigkeit aufweist.

Der Zyklus geht weiter und weiter. Jede "Politik", die Sie sehen, wurde im Allgemeinen eingeführt, um ein echtes Problem zu lösen. Wie Joel Spolsky bereits im Jahr 2000 schrieb (zu einem ganz anderen Thema wohlgemerkt , aber dennoch relevant):

Wenn Sie in ein Restaurant gehen und ein Schild mit der Aufschrift "No Dogs Allowed" (Keine Hunde erlaubt) sehen, denken Sie vielleicht, dass dieses Schild rein kritikwürdig ist: Mr. Restaurant mag keine Hunde, also hat er dieses Schild aufgestellt, als er das Restaurant gebaut hat.

Wenn das alles wäre, würde es auch ein "No Snakes" -Schild geben. Schliesslich mag niemand Schlangen. Und ein "No Elephants" -Schild, weil sie die Stühle zerbrechen, wenn sie sich setzen.

Der wahre Grund, warum das Schild dort ist, ist historisch: Es ist ein historischer Marker, der darauf hinweist, dass die Menschen früher versuchten, ihre Hunde in das Restaurant zu bringen.

In den meisten Softwareteams (ich werde nicht alles sagen) ist es das Gleiche: Richtlinien wie "Sie müssen für jede Fehlerbehebung einen Testfall hinzufügen" weisen fast immer darauf hin, dass das Team in der Vergangenheit Probleme mit Regressionen hatte. Regressionen sind ein weiteres Problem, das eher auf Kommunikationsstörungen als auf Inkompetenz zurückzuführen ist. Solange Sie die Richtlinie verstehen, können Sie möglicherweise legitime Verknüpfungen verwenden (z. B. musste ich 6 kleine Fehler beheben, aber sie waren alle in derselben Funktion, sodass ich nur einen Testfall für alle 9 von ihnen schreiben kann).

Das erklärt, warum die Prozesse dort sind, aber es ist nicht die ganze Geschichte. Die andere Hälfte ist:

Warum ist der Prozess so schwer zu verfolgen?

Dies ist eigentlich die einfachere Frage: Das Team (oder sein Management) konzentriert sich auf wiederholbare Ergebnisse und die Minimierung von Fehlern (wie oben), hat jedoch der Optimierung und Automatisierung dieses Prozesses nicht genügend Aufmerksamkeit geschenkt .

In der ursprünglichen Frage sehe ich beispielsweise mehrere Probleme:

• Das Revisionskontrollsystem (CVS) ist nach heutigen Maßstäben ein Erbe. Bei neuen Projekten wurde es fast vollständig von Subversion (SVN) abgelöst, die selbst von verteilten Systemen wie Mercurial (Hg) schnell in den Schatten gestellt wird. Der Wechsel zu Hg würde Branching und Merging weit einfacher und sogar in meinem hypothetischen Beispiel oben, die täglich begeht Anforderung würde viel weniger schmerzhaft. Der Code muss nicht einmal kompiliert werden, da das Repository lokal ist. - Die faulen Entwickler könnten diesen Schritt sogar automatisieren, wenn sie dies wünschen, und ein Abmeldeskript einrichten, um Änderungen automatisch in das lokale Repository zu übernehmen.

• Es wurde keine Zeit für die Automatisierung des Prozesses der virtuellen Maschine aufgewendet. Der gesamte Vorgang zum Abrufen, Konfigurieren und Herunterladen von Quellen / Bibliotheken auf eine virtuelle Maschine kann zu 100% automatisiert werden. Dies kann ein unbeaufsichtigter Prozess sein, den Sie irgendwo auf einem zentralen Server ausführen, während Sie an der Fehlerbehebung auf Ihrem lokalen Computer arbeiten (und die VM nur verwenden, um einen sauberen Build sicherzustellen).

• Auf der anderen Seite wird die VM-per-Developer-Lösung ab einer bestimmten Größe langsam albern und Sie sollten nur einen Continuous Integration-Server haben. Hier kommen die eigentlichen Produktivitätsvorteile zum Tragen, da einzelne Entwickler sich (meistens) keine Gedanken mehr über die Builds machen müssen. Sie müssen sich keine Gedanken über das Einrichten sauberer virtueller Maschinen machen, da der Build-Server immer sauber ist.

• Der Wortlaut der Frage ("Testfall mit allen Schritten") impliziert, dass einige manuelle Tests durchgeführt werden. Dies mag wiederum für kleine Teams mit einer relativ geringen Arbeitsbelastung funktionieren, macht aber in größerem Maßstab überhaupt keinen Sinn. Regressionstests können und sollten automatisiert werden. Es gibt keine "Schritte", nur eine Klasse oder Methode, die der Unit / Integration-Testsuite hinzugefügt wurde.

• Es erübrigt sich zu erwähnen, dass ein Wechsel von Bugzilla zu einem neueren (besseren) Bug-Tracking-System diesen Teil der Erfahrung weniger schmerzhaft machen würde.

Unternehmen sind nicht unbedingt billig oder dumm, nur weil sie diese Probleme nicht gelöst haben. Sie wissen nur, dass der derzeitige Prozess funktioniert , und in einigen Fällen sind sie risikoavers und zögern, etwas daran zu ändern. Aber sie müssen wirklich nur von den Vorteilen überzeugt sein .

Wenn Entwickler eine Woche damit verbracht haben, ihre Zeit für alle nicht-codierenden Aufgaben zu erfassen, können Sie dem Management auf einfache Weise zeigen, dass (zum Beispiel) eine Investition von 100 Mannstunden in ein Upgrade auf Mercurial ohne Kapital erforderlich ist Eliminieren Sie bis zu 10 Mannstunden pro Woche bei der Lösung von Zusammenführungskonflikten, dann ist dies eine 10-wöchige Auszahlung und sie werden dem mit ziemlicher Sicherheit zustimmen. Gleiche Idee mit Build-Servern (CI) oder besserer Fehlerverfolgung.

Um es noch einmal zusammenzufassen: Die Teams haben diese Dinge noch nicht getan, weil niemand die Geschäftsführung davon überzeugt hat, dass es wichtig genug ist, dies heute zu tun . Ergreifen Sie also die Initiative und verwandeln Sie sie in eine Kosten-Nutzen-Gleichung. Finden Sie heraus, wie viel Zeit für Aufgaben aufgewendet wird, die mit minimalem Risiko vereinfacht / automatisiert werden könnten, und berechnen Sie den Break-Even-Punkt und die eventuelle Auszahlung eines neuen Werkzeugs oder einer neuen Technik. Wenn sie immer noch nicht zuhören, wissen Sie bereits, welche Optionen Ihnen noch zur Verfügung stehen.

Wenn Entwickler eine Woche damit verbracht haben, ihre Zeit für alle nicht-codierenden Aufgaben zu erfassen, können Sie sie einfach addieren, dem Management anzeigen ... und sie in eine Kosten-Nutzen-Gleichung umwandeln usw.

Der obige Teil ist es wert, weiter ausgebaut zu werden.

Ich kann bestätigen, dass es funktioniert. Programmierer haben es einige Male in einem der Projekte verwendet, an denen ich gearbeitet habe, und jedes Mal hat es zu gewünschten Änderungen geführt.

Mein Gesamteindruck war, dass dieser Trick, wenn er richtig gemacht wird, ziemlich große Mengen an Management-Ignoranz und Trägheit außer Kraft setzen kann .

Ich möchte jedoch darauf hinweisen, dass das Unternehmen, in dem wir (Entwickler) auf diesen DIY- Ansatz zurückgreifen mussten, in Bezug auf die IT sehr unausgereift war. Bei erfahreneren Softwareanbietern sah ich, dass solche Dinge meistens von Managern selbst erledigt wurden. Und in der Regel waren sie dabei produktiver als wir Programmierer. Viel produktiver.

Wenn Sie in einer stark regulierten Branche arbeiten, gibt es möglicherweise einen Grund für diesen umständlichen Prozess: Eines Tages könnten Sie auditiert werden und Sie müssen alle Ihre Aufzeichnungen anzeigen, um zu erklären, wer diesen Fehler behoben hat, wie, wer ihn überprüft und wer getestet hat es, etc ...

Es könnte also ein notwendiges Übel sein.

Auf der anderen Seite sollten Sie versuchen, mit Ihrem Manager zu sprechen und ihm zu sagen, wie Sie Zeit (und damit Geld) für das Unternehmen sparen können, wenn es keine Rechtfertigung für diesen Prozess gibt, abgesehen von möglicherweise mangelndem Vertrauen des Managements.

Niemand mit Verstand, der einen schnelleren und besseren Prozess ablehnt, wenn er richtig erklärt wird.

Aber seien Sie bereit, Ihr Argument zu verteidigen, um die Änderung zu rechtfertigen.

Die Hälfte des Problems besteht darin, dass Sie veraltete Tools in einem Prozess verwenden, für die sie nicht entwickelt wurden. Was Sie beschreiben, ist in modernen DVCS sehr einfach zu haben, ohne die mühsame Aufgabe, einen Zweig pro Fehler zu erstellen.

Ein weiteres Problem ist, dass Sie eindeutig nicht in der Branche sind, in der Sie gerne arbeiten. Sie arbeiten in der Wartung, während Sie die Entwicklung möchten. Es gibt wenig, was man dagegen tun kann, außer den Job zu wechseln.

Die Disziplin des Software-Engineerings dreht sich inhärent um den Prozess. Wenn man sich also fragt, ob er auf diese Weise "geworden" ist, kommt das nicht in Frage.

Während sich die meisten Programmierer lieber mit dem absoluten Minimum an Prozessen beschäftigen, ist es für ein Unternehmen durchaus möglich , sich zu entscheiden, ob sie agile Methoden anwenden, auch wenn sie die Probleme ihrer Organisation nicht lösen. " schwere "Prozesse aus betriebswirtschaftlichen Gründen, wie" der Kunde es verlangt ". Dies ist häufig der Fall, wenn Ihre Kunden Fortune 500-Unternehmen, Universitäten oder Regierungsbehörden sind. Die Belohnungen des Verkaufs an diese Kunden können so hoch sein, dass sie den zusätzlichen Prozessaufwand rechtfertigen.

Ihr Unternehmen ist ein Datenpunkt, und es ist unmöglich, Ihre Erfahrungen auf einen branchenweiten Trend hin zu schwereren Prozessen oder von diesen weg zu verallgemeinern. Die eigentliche Frage ist, welche Balance für Ihr Unternehmen, Ihre Produkte, Ihre Kunden und Sie als Programmierer am besten geeignet ist. Wenn Sie nicht gerne für dieses Unternehmen arbeiten, stiften Sie Veränderungen an oder suchen Sie sich einen anderen Job.

Aus der anderen Frage, die ich heute von Ihnen gesehen habe, geht hervor, dass Sie mit Ihrer Arbeit ziemlich unzufrieden sind. Sie sind noch nicht lange dort. Sie können Ihrem Vorgesetzten lediglich mitteilen, dass Sie einen Fehler begangen haben, und es ist an der Zeit, dass Sie sich früher als erwartet trennen.

Wenn Sie gut in Ihrem Job sind, wird es Ihnen wirklich nicht schwer fallen, einen neuen zu finden, und wenn es keinen guten Grund dafür gibt, würde ich wahrscheinlich auch in Betracht ziehen, umzuziehen. CVS überhaupt zu benutzen, wäre für mich wirklich ein Deal Breaker, aber ich stelle beim Interview immer die Frage nach der Quellcodeverwaltung. Natürlich kann ich Ihre Situation nicht kennen und es kann unmöglich sein, einen Job zu verlassen, wenn Sie andere Verpflichtungen haben.

Ich wollte darüber sprechen, wie die Softwareentwicklung mit sehr schlechten Programmierern überschwemmt wird, aber die Situation, die Sie beschreiben, ist schrecklich.

Nach meiner persönlichen Erfahrung geht ein Teil dieses von Ihnen beschriebenen "Prozesses" damit einher, dass Management und Systemadministration sich der Ineffizienz der Systeme, die sie den Programmierern auferlegen, überhaupt nicht bewusst sind. Beispiele hierfür sind die Einschränkung der Auswahl des Betriebssystems, die Einschränkung der verwendeten Software, der Internetzugriff und die Administratorrechte für den persönlichen Desktop. All diese Dinge sind für eine gute Entwicklung unerlässlich .

Darüber hinaus Kompatibilitätsanforderungen zwischen den "magischen Lösungen", die von verschiedenen Zweigen von Unternehmen eingesetzt werden. Beispiele hierfür sind Hauptniederlassungen mit zentraler Quellcodeverwaltung, externe Outlook-Server sowie Codierungsrichtlinien oder -sprachen, die möglicherweise nicht für jedes Problem geeignet sind.

Es macht nicht viel Spaß, die Räder der Enterprise Juggernauts am Laufen zu halten, aber ich habe festgestellt, dass es in einigen Unternehmen kleine Blasen aus Innovation, Kreativität und Brillanz gibt.

Sie arbeiten wahrscheinlich in einem prozessorientierten Unternehmen. Ich würde stattdessen versuchen, ein ergebnisorientiertes Unternehmen zu finden , bei dem es darauf ankommt, was Sie tun, nicht wie Sie es tun.

In meiner Firma haben wir auch einen "Prozess" (aber es ist sehr einfach). Aber wenn es in die Quere kommt, breche ich die Regeln und überspringe Schritte. Niemand wird mir jemals etwas sagen, solange ich nichts mit Abkürzungen unterbreche, weil ich Ergebnisse erhalte.

Gibt es einen Punkt, an dem der Prozess in die Quere kommt und zum Selbstzweck wird? Ist das überhaupt Technik?

Im wahrsten Sinne des Wortes stellen die meisten Ingenieure gut eingeführte Teile in einer festgelegten Reihenfolge zusammen, um auf ein bestimmtes Problem zu reagieren. Dies ist am offensichtlichsten, wenn Sie einen ME fragen, was er den ganzen Tag macht. Sie verwechseln Engineering mit Architektur oder Produktentwicklung in einem frühen Stadium (in jedem Bereich). Ich habe zwei Anmerkungen zu Ihrer Frage.

1. Sie wurden anscheinend mit der Behebung von Fehlern beauftragt, nicht mit Architektur- oder Designarbeiten.
2. Ihre Mitarbeiter haben anscheinend begrenzte Problemumgehungen (Kombination von VMs zur Fehlerbehebung) gefunden, um sie effizienter zu machen. Sie scheinen nicht ihrem vernünftigen Beispiel zu folgen.

Es ist einfach eine Tatsache, dass bei jedem konstruktiven Unterfangen, an dem eine große Anzahl von Leuten beteiligt ist, einige Leute das Design übernehmen und eine größere Gruppe die Implementierung übernehmen muss. Sorry, aber du bist in der zweiten Gruppe.

Wie andere Kommentatoren angemerkt haben, ist CVS nicht das beste Tool für ein hochverzweigtes Entwicklungsmodell, aber ich stelle auch fest, dass Sie nicht für das Zusammenführen verantwortlich sind. Machen Sie sich also keine Sorgen.

Die meisten Ihrer Beschwerden scheinen im Wesentlichen zu lauten: "Ich möchte nicht vor, während oder nach der Entwicklung testen!" Lassen Sie uns Ihre Schritte Punkt für Punkt aufschlüsseln.

• Um einen einzelnen Fehler zu beheben, erhalte ich zunächst eine saubere, neue virtuelle Maschine. Eine Testumgebung
• Dann erstelle ich einen Zweig für diese einzelne Fehlerbehebung, basierend auf einem anderen Zweig, der im Bugzilla-Bericht beschrieben ist. - Du duplizierst die Umgebung, in der der Fehler gefunden wurde ... wie ist das unvernünftig?
• Ich installiere den Zweig auf der Maschine, richte das ein. Ich behebe den Fehler. Ich checke es ein - Der grundlegende Entwicklungsprozess
• ... lassen Sie es und die Maschine für andere zum Testen. - Ihr Merge-Team möchte wahrscheinlich, dass dies in der Lage ist, den Fix zu überprüfen, wenn der Merge nach Süden geht.
• Dann muss ich in die Fehlerkontrollsoftware gehen und erklären, was ich getan habe - Wenn Sie in einem Geschäft sind, das dies nicht tut ... warum verfolgen Sie überhaupt Fehler?
• und schreiben Sie einen Testfall mit allen Schritten. - Ich könnte mich irren, aber das scheint die Richtung zu sein, in die alle 'coolen Kinder' gehen
• Irgendwann verschmilzt es jemand anderes mit einer Veröffentlichung. - Und einige der oben genannten Schritte dienen dazu, ihre Arbeit zu erleichtern

Jemand anderes vor Ihnen führt offensichtlich eine Fehlersuche durch, um sicherzustellen, dass ein gefundener Fehler in einer anderen Version nicht erneut behoben oder in einer späteren Version nicht mehr behoben wird (dafür sind die Testfälle gedacht).

Das einzige, was an diesem Prozess auch nur annähernd ungewöhnlich oder übereifrig ist, ist die VM-Sache. Es gibt eine faire Chance, die als vernünftig angesehen wird, wenn wir wissen, in welcher Domäne Sie gearbeitet haben.

Interessant. Hast du Tester? Sie sollten etwas davon tun. Ich bin einer, und wo ich arbeite, haben wir eine anständige Lösung.

Für einen Funktionsfehler, wie Sie ihn erklären, läuft unser Prozess folgendermaßen ab:

1. Ich teste auf den Defekt in einer virtuellen Maschine (entweder von einem Kunden gemeldet oder während meiner Erkundungstests oder w / e)
2. Bug gefunden / repro'd.
3. Ich erstelle den Bug. Bugs beinhalten:
   • Voller Nachbau, vom Zeitpunkt der Installation bis zum Zeitpunkt des Erkennens des Fehlers.
   • Ein Link zu einem Schnappschuss der VM (wenn ich glaube, dass der Entwickler ihn benötigt ... ich mache trotzdem einen Schnappschuss, nur für den Fall, dass sie danach fragen).
   • Systeminfo, alle speziellen Einstellungen, die ich vornehmen musste.
4. Dieser Fehler wird dem Entwickler zugewiesen. Während sie an einem Fix arbeiten, habe ich:
   • Erstellen Sie einen Testfall
   • Schreiben (oder konvertieren) Sie den manuellen Test in einen automatisierten Test

Dann warte ich auf eine Lösung und helfe den Entwicklern in jeder Weise, die sie brauchen. Wenn es wie gelöst zurückkommt, habe ich:

1. Führen Sie den automatisierten Testfall und (manchmal) eine manuelle Version aus, um den Fix zu bestätigen.
2. Schließen Sie den Fehler.

TL; DR: Wenn Sie keine Tester haben, brauchen Sie welche. Wenn Sie welche haben, dann tun sie ihren Teil nicht.

Tom DeMarco:

... Mein frühes Metrikbuch ... Die am häufigsten zitierte Zeile ist der erste Satz: "Sie können nicht steuern, was Sie nicht messen können." Diese Zeile enthält eine echte Wahrheit, aber ich habe mich zunehmend unwohl damit gefühlt. Das Zitat (und auch der Titel des Buches) impliziert, dass Kontrolle ein wichtiger Aspekt, vielleicht der wichtigste, eines Softwareprojekts ist. Ist es aber nicht.

... Je mehr Sie sich auf die Kontrolle konzentrieren, desto wahrscheinlicher ist es, dass Sie an einem Projekt arbeiten, das einen relativ geringen Wert erzielen möchte.

Meiner Meinung nach ist die Frage, die viel wichtiger ist als die Steuerung eines Softwareprojekts, warum um alles in der Welt machen wir so viele Projekte, die einen so geringen Wert liefern?

Software Engineering: Eine Idee, deren Zeit vergangen ist?

"Dann erstelle ich einen Zweig für diese einzelne Fehlerbehebung"

Es ist nicht erforderlich, einen Zweig für die einzelne Fehlerbehebung zu erstellen. Erstelle zuerst den Bug in Bugzilla. Überprüfen Sie den Release-Zweig. Machen Sie das Update. Führen Sie die Festschreibung mit der Festschreibungsmeldung aus, die die Fehlernummer enthält. Dadurch wird der Fehler aktualisiert und entsprechend abhängig von den in der Festschreibungsmeldung geschriebenen Textschlüsselwörtern als "behoben, muss geprüft werden" oder "behoben, muss geprüft, muss zusammengeführt werden" gekennzeichnet. Die Bug-Datenbank ist der perfekte Verfolgungsmechanismus für alle vorgenommenen Änderungen und deren Gründe. Berichte können aus der Fehlerdatenbank ausgeführt werden, um diese Informationen zu extrahieren.

Ich denke, der größte Teil des Prozesses könnte automatisiert werden , sodass die Erstellung der virtuellen Maschine und des Zweigs (einschließlich des Kompilierens von Code, Einrichten von Debuggern usw.) für Sie erledigt wurde, bevor Sie mit der Arbeit an dem Fehler begonnen haben.

Es lohnt sich für alle Fehlerbehebungen, zu beschreiben, was Sie getan haben und wie es getestet werden sollte. Ich habe festgestellt, dass das Schreiben des Textes Probleme verursachen kann , da ich über Risiken usw. nachdenke.

Ich denke, der Prozess ist vielleicht etwas übertrieben, aber das eigentliche Problem ist der Mangel an benutzerdefinierten automatisierten Tools, die den Prozess unterstützen.

Yo man, Ihr Denkprozess ist richtig in dem, was Sie beschrieben haben, absolut beschissen und eine echte Demonstration, wie falsch Dinge in Software sein können. Hier ist die gute Nachricht: Es gibt so viele Unternehmen, die Agile in echter Stimmung praktizieren. Die Firma, für die ich arbeite, ist eine solche. Heutzutage gibt es viele und das sind wirklich gute Nachrichten.

Wenn Sie spüren, dass die Dinge an Ihrem Arbeitsplatz wirklich nicht stimmen, können Sie zwei Dinge tun: Entweder Sie können positive Veränderungen beeinflussen oder Sie verlassen diesen Ort und schließen sich einem besseren an.

CVS oder ein Konfigurationsmanagementsystem ist nicht schlecht. Leider verursacht die Art und Weise, wie es verwendet wird, ohne seinen Zweck wirklich zu kennen, diese Art von Schmerz im! @ # $ Für die gesamte Organisation.

Lesen Sie das Buch "Praktiken eines agilen Entwicklers" von Venkata Subramaniam, um schnell zu verstehen, worum es bei Agile wirklich geht. Es ist schön in leicht verständlicher Sprache geschrieben.

Wünsche dir viel Glück!