Bewältigung eines unfixierbaren Endlosprojekts

Wir haben eine große Website (über 1200 Stunden) mit vielen technischen Schulden. Dies wird hauptsächlich durch die folgenden (üblichen) Gründe verursacht.

1. Mehrere Programmierer, die während der Entwicklung kommen und gehen.
2. Änderung der Spezifikationen während der Entwicklung.
3. Zahlreiche zusätzliche Funktionen hinzugefügt (in kurzer Zeit).

Der Kunde wünscht sich viele neue Funktionen, und das bedeutet im Grunde, dass er mehr als 10 Stunden wöchentlich an diesem Projekt arbeitet .

Aufgrund der technischen Verschuldung verbringen wir viele Stunden damit, Probleme zu beheben oder zu untersuchen, die normalerweise ihren Ursprung in einer der folgenden Ursachen haben:

1. Ein schamloser, alberner Käfer, der die Leute zum Weinen bringt.
2. Ein neues Feature führt zu dem oben genannten Ergebnis, da wir nicht alle Stellen vorhergesehen hatten, an denen das neue Feature einen Einfluss haben würde.
3. Einige andere Probleme, mit denen wir konfrontiert waren (z. B. Servermigration, Upgrades)

Wir haben täglich Probleme und haben versucht, folgende Dinge zu tun, um dies zu stoppen:

1. Erstellung einer technischen Dokumentation zum Import, zur Zahlung und zur allgemeinen Funktionsweise der Website.
2. Treffen Sie sich zu Beginn der Woche und besprechen Sie die aktuellen Probleme oder Verbesserungen und wie sie angegangen werden sollten.
3. Habe einen Testplan. Programmierer A testet B, B testet C und C testet A. Dann wird unser Projektmanager einige Tests durchführen. In Bezug auf die Auswirkungen der Funktion werfen wir sie auf eine Staging-Umgebung und lassen den Kunden dies selbst überprüfen.

Das Problem ist, dass die Probleme immer wieder auftreten ... und wir es irgendwie nicht in den Griff bekommen können. Neue Funktionen verursachen immer noch Fehler, und alte Fehler sagen immer wieder Hallo. Irgendwie - vielleicht aufgrund der Größe des Projekts - scheinen wir dieses Projekt nicht in den Griff zu bekommen.

Ich gehe davon aus, dass viele Programmierer an größeren Projekten arbeiten. Deshalb komme ich zu meiner Frage:

Was können wir tun oder was tun Sie , um diese Probleme bei großen Projekten zu vermeiden?

Kleinere Änderungen, zusätzliche Informationen:

1. Wir verwenden die Versionskontrolle (SVN).
2. Wir haben einen DTAP-Entwicklungsprozess.

Ich werde Devil's Advocate spielen, nachdem ich viel zu oft gesehen habe, wie sich das herausstellt: Man kann damit nicht fertig werden. Ich garantiere Ihnen, dass Sie der einzige sind, der tatsächlich ein echtes Problem mit dem System sieht, oder Sie müssten sich nicht fragen, wie Sie damit umgehen sollen, da die Unternehmenskultur darin besteht, Fehler auszumerzen und den Code zu beheben wo immer möglich, dh wie echte Profis arbeiten.

Ich wette, es ist zu groß, um Unit-Tests zu schreiben, weil es noch niemanden gab, der weiß, wie man Unit-Tests durchführt (und mit etwas Glück andere Leute in Ihrem Team), und es unmöglich ist, zu wissen, wo man anfangen soll, und vielleicht sogar unmöglich Testen, da es auf exakten Implementierungen und konkreten Daten basiert. Daher würde es viel zu lange dauern, all dies auf Schnittstellen, Mocks, Stubs und dergleichen zu übertragen, um es überhaupt testen zu können. Ich wette auch, dass Sie nicht einfach umgestalten können, was umgestaltet werden muss, weil es zu eng gekoppelt ist und da es keine Tests gibt, wer weiß, was durch das Beheben von fehlerhaftem Code beschädigt wird. Kurz gesagt, es ist wahrscheinlich zu krebsartig geworden, um es ernsthaft zu reparieren, aber natürlich kann es nicht einfach herausgeschnitten werden und neu anfangen.

Du kämpfst einen verlorenen Kampf, mein Freund. Entweder brennen Sie vor Frustration aus und hören schließlich auf oder werden verrückt, oder wenn Sie sich lange genug darüber beschweren und versuchen, andere dazu zu bringen, die Probleme zu erkennen, denken sie, dass das einzige Problem Sie sind und Ihnen die Tür gezeigt wird.

Unit-Tests sind ein guter Ausgangspunkt, wenn Sie keine durchführen. Zumindest schützen sie Sie vor dem Hinzufügen neuer Fehler, wenn Sie alte Fehler beheben.

Die Quellcodeverwaltung hilft auch, es sei denn, Sie verwenden sie nicht. Insbesondere die Schuld- und Protokollfunktionen sind wunderbar, um festzustellen, wie / warum ein fehlerhafter Code jemals begangen wurde.

Beim Kunden habe ich festgestellt, dass das Besprechen des Preises und (langwieriger) Verzögerungen, sobald Änderungen / zusätzliche Funktionen angefordert werden, ziemlich gut funktioniert, ebenso wie das Aufladen der Zeit, die Sie mit dem Besprechen / Entwerfen verbringen. Häufig entscheiden Kunden, dass sie beim zweiten Gedanken warten können.

(Wenn Sie sich dagegen sofort mit ihm in Spezifikationen und Implementierungsideen vertiefen, werden Sie in der Regel auf ein "Oh, ich dachte, wir hätten uns darauf geeinigt, dass Sie dies trotzdem tun" oder (schlimmer noch, nach einigen Tagen zurück und) eingestellt weiter auf die Besonderheiten) "aber schau, es ist schon entworfen und wir, was wir besprochen haben, klingen nicht so schwer!".)

Last but not least habe ich festgestellt, dass es zu einer enormen Produktivitätssteigerung führt, wenn ich im Voraus nur einmal am Tag (bei der Arbeit) E-Mails lese und ein Telefon für dringendere Dinge habe.

Ich schlage vor, dass Sie einige CI-basierte Tests hinzufügen, vor allem in den Bereichen, die am häufigsten brechen. Dies wird Ihnen helfen, die Qualität zu steigern, während an dem Projekt gearbeitet wird.

Es wird auch deutlicher, welche Bereiche / Funktionen häufiger unterbrochen werden, und somit ist es einfacher zu entscheiden, welche Teile umgestaltet oder zumindest verstärkt getestet werden müssen.

Das Hinzufügen weiterer manueller Testrisiken führt dazu, dass das Projekt in Bezug auf $$$ und Zeitaufwand pro hinzugefügtem Feature in die falsche Richtung geht.

Einige Codeüberprüfungen sind gut, aber vielleicht ist das Teil des A-> B-> C-> A-Testschemas. (Vielleicht Codeüberprüfung in die andere Richtung?)

Lass mich eine Fabel auf dich werfen. Sie haben früher am Tag einen Spaziergang mit einer Person gemacht und erreichen Ihr Ziel. Die Person, mit der Sie gehen, stellt schnell fest, dass sie irgendwo auf dem Weg ihren Ring verloren hat, sodass Sie beide beschließen, sich zurückzuziehen und danach zu suchen. Die Person, mit der Sie gehen, bleibt schnell an einem Laternenpfahl stehen und beginnt verzweifelt zu schauen. Sie sagen: "Warum schauen Sie dort auf den Laternenpfahl, wenn ich glaube, Sie haben ihn verloren, als wir die Gasse durchschnitten?" Er antwortet: "Ich weiß, aber das Licht ist hier besser."

Ich war mehr als ein paar Mal in dieser Situation und habe einige Gemeinsamkeiten bemerkt. Diese Art von Wartungs-Albtraumprojekten wird normalerweise in einer prozesslastigen Umgebung mit starker Überwachung und Prozessverbesserungen durch das Management ausgeführt. Ich sage nicht, dass Prozessverbesserungen eine schlechte Sache sind, aber meistens haben die Arten von Prozessverbesserungen, die das Management normalerweise durchführen möchte, zwei Hauptpunkte.

1) Sie stören im Allgemeinen nicht die Büropolitik und das Kräfteverhältnis. 2) Es gelingt ihnen, die Illusion der Kontrolle durch das Management zu erzeugen, anstatt im Mittelpunkt des Problems zu stehen.

Das Management denkt, "Licht ist hier besser", sagt normalerweise: "Jede neue Funktion muss eine detaillierte technische Spezifikation haben" oder "Lassen Sie uns jeden Tag eine stündliche Statusbesprechung abhalten, um Probleme zu besprechen und wie sie überwunden werden können."

Keines dieser Dinge steht wirklich im Mittelpunkt der Probleme und sie verringern möglicherweise nur die Produktivität, aber sie bestätigen zweifellos die Illusion der Kontrolle durch das Management.

Die einzigen wirklichen Veränderungen, auf die Sie drängen können, sind solche, die die Dinge durcheinander bringen. Ich vermute jedoch, dass Ihre Monstrosität einer Website zu diesem Zeitpunkt wahrscheinlich nicht mehr zu reparieren ist und Sie weiter voraus sind, um sie neu zu entwerfen und neu zu schreiben. Für die Zukunft können Sie jedoch die Bedeutung der agilen Methodik, der kontinuierlichen Integration, der testgetriebenen Entwicklung, der Codeüberprüfungen und der Geschäftsanforderungsspezifikationen berücksichtigen, die unter strengen Änderungskontrollverfahren geregelt sind, um das Kriechen des Bereichs ohne Zeitplananpassungen zu minimieren.

Diese Art von Änderungen erfordert wirklich eine Änderung der Denkweise auf Managementebene, und in meiner gesamten Berufserfahrung bin ich nie darauf gestoßen, dass dies ohne eine Art Umstellung des mittleren Managements geschehen würde. Ich hoffe, das ist nicht zu entmutigend, da Sie versuchen sollten, das Richtige zu finden, unabhängig davon, ob Sie einen harten Kampf führen, denn Sie werden wahrscheinlich auf heftigen Widerstand von Menschen stoßen, die den Status Quo lieben.

Ich war vor einiger Zeit am selben Ort. Ich bin nicht mehr dank zweier einfacher Regeln:

• Jede Woche werden ein oder zwei Tage damit verbracht, die meisten haarigen Teile der App zu reparieren / neu zu schreiben. Keine Fehlersuche, keine Entwicklung neuer Funktionen.
• Bei der Implementierung neuer Funktionen bemühen wir uns, diese auch dann richtig zu machen, wenn wir mehr Zeit verbracht haben, als der Kunde erwartet.

Das einzige Problem ist, andere Menschen dazu zu bringen, sie zu respektieren. Der einfache Teil war überraschenderweise Kunde. Ich kann nicht wirklich erklären warum, aber irgendwie haben wir ihn überzeugt, dass es für alle besser ist, wenn wir ein bisschen länger an einem Feature arbeiten. Das Respektieren der ersten Regel stellt sich als problematischer heraus, aber wir glauben auch, dass es uns sehr hilft. Es garantiert einen stetigen Fortschritt, da verschiedene Teile der Anwendung besser werden.

Code-Bewertungen. Unit-Tests. Echte QS-Tests. Spezifikationserfassungsprozess und inkrementelle Entwicklung - dies sind einige Dinge, die die meisten Ihrer Probleme lösen sollten.

Lassen Sie die Kunden auch nicht direkt Ihre Entwickler anpingen - Dies ist normalerweise die unproduktivste Methode zur Lösung von Problemen. Stellen Sie einen guten Programmmanager ein, der die Schnittstelle zwischen Ihren Kunden und Entwicklern bildet. Seine Aufgabe wäre es, das Produkt von Ende zu Ende, den aktuellen Status, zukünftige Richtungen usw. zu kennen. Jedes Mal, wenn der Kunde eine weitere neue Funktion wünscht, sollte er in der Lage sein, die aktuelle Liste der Artikel anzugeben und den Kunden zu zeigen, was passiert, wenn diese neue Anfrage angenommen wird.

Prozess ist schlecht, wenn es zu wenig oder zu viel verwendet wird. Ich denke du bist im ehemaligen Staat.

Wie Deni erwähnt, würde dies Ihnen helfen, wenn Sie dem Projekt Komponententests hinzufügen können. Führen Sie einen Test durch, der einen Teil des Systems abdeckt, den Sie ändern / reparieren möchten. Wenn Sie also Ihren Refactoring-Code verwenden, verwenden Sie diesen Test als Leitfaden, um sicherzustellen, dass Sie nichts beschädigen.

Durchsuchen Sie auch die am meisten beschädigten Teile des Codes. Versuchen Sie, die am schlimmsten Betroffenen in eine Liste von Risiken aufzunehmen und diese Risiken unabhängig zu verwalten. Versuchen Sie, eine Vorstellung davon zu bekommen, wie viel fehlerhafter Code in der Codebasis vorhanden ist, indem Sie abfragen, wo die Fehler am häufigsten auftreten. Sie können dann den betroffenen Bereich anhand der Anzahl der Fehler (oder der gemeldeten Probleme, je nachdem, was für Sie funktioniert) auflisten.

Das Patchen und Bereinigen des Codes wird einige Zeit dauern, aber wenn jeder Entwickler im Team den Code ein wenig sauberer lassen kann, als es war, bevor er ihn bearbeitet hat, wird sich die Codebasis im Laufe der Zeit verbessern. Wenn Sie nach einem schnellen Armeestil suchen, lassen Sie ihn jetzt sortieren. Ich bezweifle, dass es irgendetwas Praktisches (oder Empfohlenes) gibt, das helfen würde.

Prost. Jas.

Schreiben Sie klare Funktionsspezifikationen. pedantisch also, wenn Sie es ertragen und die Funktionalität regelmäßig anhand dieser Spezifikationen überprüfen können. Je weniger Ahnung ein Entwickler von dem hat, was er entwickeln soll, desto geringer ist die Wahrscheinlichkeit, dass es so ist, wie es sich entwickeln soll.

Bevor Sie mit dem Schreiben von Code beginnen, führen Sie einige Vorarbeiten durch. Dies muss nicht perfekt oder riesig sein oder UML enthalten, aber es sollte eine ziemlich solide Lösung für das Problem darstellen, das gelöst werden muss. Soweit ich das beurteilen kann, ist es umso schlimmer, je weniger Software geplant ist. Besprechen Sie das Design, bevor Sie daran arbeiten.

Wenn Sie anfangen, an einem Bereich des Codes zu arbeiten, der eindeutig schlecht ist und Ihren Fortschritt wirklich behindert; Hören Sie auf, etwas hinzuzufügen, treten Sie vom Problem zurück und finden Sie heraus, wie Sie die Architektur neu gestalten können, damit die Hindernisse nicht vorhanden sind und sie in Zukunft anpassungsfähiger wird. Je länger Sie es verlassen, bevor Sie sich mit technischen Schulden befassen, desto schwieriger wird es, es ohne eine vollständige Neufassung zu beheben. Ich würde sagen, es ist eine exponentielle Sache.

Entwerfen Sie Tests, die das Verhalten testen und nicht eng mit Ihrer Architektur verbunden sind. Es ist nicht sehr in Mode, aber ich würde sagen, beginnen Sie nicht mit dem Testen, bis der wahre Zweck Ihres Codes klar ist. Beginnen Sie erst mit dem Testen, wenn Sie wissen, was Sie wirklich testen möchten. IMO ist ein schlecht durchdachter Test schlechter als kein Test. Und je mehr Tests Sie haben, desto schwieriger ist es, Ihren Code intern zu ändern. Behandeln Sie Ihren Testcode wie einen Produktionscode. es muss geplant und gut geschrieben sein.

Führen Sie regelmäßige / tägliche Codeüberprüfungen durch: Hier geht es mehr um die Überprüfung der Gesundheit, um sicherzustellen, dass der Entwickler nicht zu weit vom Kurs abgekommen ist. Verwenden Sie diese Sitzungen, um die Arbeit der nächsten Tage zu planen. Es kann Tage geben, an denen diese 5 Minuten oder 1 Stunde dauern. Es geht darum, einen offenen Dialog zu führen und Entwicklern die Möglichkeit zu geben, ihre Arbeit mit anderen Entwicklern zu diskutieren und Rat einzuholen. Führen Sie einige Pairing-Sitzungen zu schwierigen Teilen des Codes durch oder um Ideen zu prototypisieren, aber lassen Sie den Leuten ihre eigene Zeit zum Arbeiten.

Erleichtern Sie das Erstellen und Bereitstellen Ihres Codes. Versuchen Sie, die Bauzeiten kurz zu halten. Je einfacher es zu bauen ist, desto mehr wird es gebaut, desto schneller wird es gebaut, desto mehr wird es gebaut.

Codierungsstandards übernehmen und strikt durchsetzen. Dies sollte alles abdecken, von dem Ort, an dem ein Projekt im Dateisystem gespeichert werden soll, bis hin zum Gehäuse einer privaten Konstante. Dies mag sinnlos und ärgerlich erscheinen, aber gute Gewohnheiten sind der Eckpfeiler eines Entwicklungsprozesses.

Grundsätzlich denke ich nicht, dass der Prozess, den Sie verwenden, so wichtig ist, Mode kommt und geht. Was wirklich wichtig ist, ist, dass Sie professionell in der Entwicklung von Software sind und in Ihrer Praxis diszipliniert sind.

Zunächst entwarf und automatisierte ich Rauchtests und warf sie in die CI-Umgebung. Diese sollten funktionsfähig sein. Wenn der Kunde Ihnen sagt, dass etwas so und so funktionieren soll, bitten Sie darum, es aufzuschreiben, damit Sie später darauf zurückgreifen können. Wenn Sie eine bestimmte Lösung in der Software sehen, stellen Sie Fragen, und sobald Sie Antworten erhalten, integrieren Sie diese in die Wissensdatenbank und machen Sie sie nachvollziehbar.

Stellen Sie sicher, dass die Grundfunktionalität für positive Fälle funktioniert. Beginnen Sie dann mit der Erstellung inkrementeller Tests für eine falsche Datenverarbeitung, und platzieren Sie Fehler, wenn dies als notwendig erachtet wird. Besprechen Sie die Prioritäten ausführlich und ausführlich, und machen Sie den Testmanager darauf aufmerksam, damit er die Testzeit entsprechend zuweisen kann. Versuchen Sie nicht, alles zu automatisieren, aber sobald einige Testfälle sinnvoll sind, zögern Sie nicht.

Verwenden Sie Tests im Allgemeinen, um das Vertrauen in das Produkt zu stärken, und nicht als Werkzeug, mit dem Sie die Qualität sofort steigern können. Sei ruhig und doch selbstbewusst :). Versuchen Sie vielleicht, agil zu werden, aber nur, wenn Sie absolut positiv einen zertifizierten PM engagieren. Die Einführung von Agile durch eine Person, die Agile nicht kennt, wird das Projekt höchstwahrscheinlich beenden.