Verlangsamung, um die Entwicklung voranzutreiben

Vom Übersetzer:
Der Jahresbeginn ist eine gute Zeit, um das vergangene Jahr sorgfältig zu bewerten. Werfen Sie einen umfassenden Blick auf das Geschehen und verstehen Sie, wie Sie 2019 zu einem besseren, ruhigeren und produktiveren Jahr machen können. In diesem Fall fanden wir den von Lemi Orhan Ergin verfassten Artikel Wie man langsamer wird als je zuvor in der Softwareentwicklung . Und wir veröffentlichen ihre Übersetzung unten.

Wichtige Punkte:

• Eile macht uns nicht schneller oder effizienter; es erhöht den Stress und macht es unmöglich, sich zu konzentrieren. Anstatt sich zu beeilen, brauchen Sie einen kreativen Ansatz, Effizienz und Konzentration.
• Stellen Sie die talentiertesten Spezialisten ein, arbeiten Sie zusammen, üben und studieren Sie zusammen. Dies erhöht die Professionalität und schafft eine Kultur der Exzellenz im Unternehmen.
• Bauen Sie Teamflexibilität und Prozesseffizienz auf, indem Sie Pläne erstellen und diese regelmäßig überprüfen. Finden, analysieren und beseitigen Sie Zeitverschwendung.
• Ohne eine Qualitätscodebasis können Sie nicht flexibel sein. Beseitigen Sie Fehler, geben Sie Versionen häufiger frei, schreiben Sie Tests, bevor Sie den Hauptcode schreiben, führen Sie Refactoring durch und konzentrieren Sie sich auf ein einfaches Design.
• Das Ausführen von Software bedeutet nicht gut gestaltet. Nur echte Profis können qualitativ hochwertige Software erstellen, mit der Sie so schnell wie möglich entwickeln können.

Die schnellstmögliche Ausführung von Aufgaben kann zu Ihrem Feind werden, wenn Sie sich unkontrolliert weiterentwickeln. Es gibt drei wichtige Bereiche, die verlangsamt werden müssen: Menschen, Prozesse und Produkte. Bevor ich auf die Details eingehe, möchte ich Ihnen eine Geschichte erzählen.

Soweit ich mich erinnere, war es 2011. Ich bin dem Team beigetreten, das die Plattform für Online-Marketing geschaffen hat. Meine Hauptaufgabe war es, so schnell wie möglich neue Funktionen hinzuzufügen. Ich war ein leitender Entwickler. Wir nennen Entwickler "Senior", wenn sie sich schneller entwickeln als andere, oder? Als ich anfing zu arbeiten, stellten wir jedoch fest, dass es aufgrund technischer Schulden und Mängel im Design des Systems fast unmöglich war, schnell zu arbeiten. Wir haben auch festgestellt, dass wir mit jedem Beschleunigungsversuch die Komplexität erhöhen und die Qualität zerstören. Ich kam zu dem Schluss, dass die einzige Möglichkeit zur Beschleunigung darin besteht, das System von Grund auf neu zu schreiben.

Ich erinnere mich, wie ich während eines Telefongesprächs mit dem Produktmanager sagte, wir müssten das gesamte System neu schreiben. Nach 30 Sekunden Schweigen fragte der Manager: "Sie sagen, dass Ihr Team ein Produkt von so schlechter Qualität entwickelt hat, dass jetzt dasselbe Team dasselbe Produkt erneut schreiben sollte, aber diesmal ist es besser, dies zu tun." Richtig? Entschuldigung, aber das ist nicht akzeptabel. Du hättest es sofort besser schreiben sollen. “

Zombie-Software muss immer wieder neu geschrieben werden

Laut dem Chaos Report der Standish Group wurden 94% der Projekte mehr als einmal von Grund auf neu erstellt. Das ist eine riesige Zahl. Wenn ich mich an die Projekte erinnere, an denen ich gearbeitet habe, verstehe ich, dass fast alle von ihnen mit neuen Technologien, neuer Architektur und neuem Design von Grund auf neu geschrieben wurden. Das Kopieren von Grund auf ist für unsere Branche so typisch, dass Unternehmen es oft als die einzige Möglichkeit ansehen, ein Projekt zu entwickeln und zu verwalten. Zuerst schreiben wir und dann schreiben wir immer wieder neu.

Wir müssen unsere Hauptfeinde kennen. Geschwindigkeit ist eine wichtige Eigenschaft in der Softwareentwicklung. Es ist wichtig, nicht nur zuerst in den Markt einzutreten, sondern auch schnell auf Kundenbewertungen zu reagieren, Funktionen hinzuzufügen und Fehler zu beheben, damit die Benutzer mit dem Produkt zufrieden sind.

Aber wir haben alle Probleme mit dem Konzept der "Geschwindigkeit". Wir glauben, dass ein schneller Vorlauf sowie vernünftige und wirksame Maßnahmen in irgendeiner Weise mit der Festlegung von Fristen zusammenhängen. Wir glauben, dass das Ergebnis schneller erzielt wird, wenn Sie härter arbeiten oder mehr Menschen anziehen. Infolgedessen fügen wir dem Projekt entweder neue Mitarbeiter hinzu oder machen Überstunden, um die Arbeit zu beschleunigen. Eile macht uns weder schneller noch produktiver. Eile schafft eine stressige Atmosphäre, beraubt uns der Möglichkeit, uns auf die Arbeit zu konzentrieren, und zerstört die Produktivität. Was benötigt wird, ist Kreativität, Effizienz und Konzentration.

Softwareentwicklung ist eine verdammt komplizierte Sache. Wir können diese Komplexität nicht loswerden. Deshalb müssen wir mit ihr leben. Das Erfordernis, schnell zu arbeiten, schafft eine instabile, turbulente Atmosphäre, versetzt uns in Stress und macht es unmöglich, produktiv und aufmerksam zu arbeiten. Dieser Ansatz funktioniert einfach nicht.

Teamproduktivität (Kapazität), Masterplan, Schätzungen der Arbeitskosten, feste Arbeitszeiten, Fristen und Teamgeschwindigkeit (Teamgeschwindigkeit) - all dies ist illusorisch. Inkompetenz ist real. Die Geschwindigkeit der Lieferung hängt direkt von der Professionalität der Mitarbeiter, der Effizienz der Prozesse und der Qualität der geleisteten Arbeit ab. In den meisten Fällen legen die Entwickler selbst interne Fristen fest, auch wenn dies nicht erforderlich ist.

Als Ergebnis erhalten wir ein Legacy-System. Der Termindruck in Verbindung mit Inkompetenz führt zu einem Legacy-Code - einer Sackgasse für die Weiterentwicklung des Systems. Ich habe früher einen anderen Namen für Legacy-Systeme verwendet - Zombie-Software. Diese Definition funktioniert besser, da Legacy buchstäblich tote Software ist, aber das scheint in der Produktion zu funktionieren. Es funktioniert und bringt sogar Geld, aber es erfordert das Blut, das Leben und die Energie der Entwickler, um irgendwie daran zu arbeiten. Entwickler haben Angst, den funktionierenden Code zu berühren, niemand möchte ihn entwickeln.

Robert C. Martin sprach auf seinem Twitter sehr gut über Legacy-Systeme : „Wenn Ihre Software immer schwieriger zu entwickeln ist, machen Sie etwas falsch.“ Wir arbeiten in Eile und reduzieren die Qualität so sehr, dass die Arbeit mit jedem Schritt immer langsamer wird. Ich bin sicher, dass der einzige Weg, sich schneller zu entwickeln, darin besteht, den Prozess zu verlangsamen, bis wir Stabilität erreichen.

Der Ansturm in der Softwareentwicklung ist böse

In einer CleanCoders-Reihe sagte Robert C. Martin : „Der Hauptwert der Software ist die Fähigkeit des Systems, sich an zukünftige Änderungen anzupassen und deren Implementierung zu vereinfachen.“ Eile ist böse in der Softwareentwicklung. Jeder Versuch, sich zu beeilen, führt zu einem ernsthaften Rückgang der Produktivität, des Fokus, der Effektivität der Mitarbeiter, der Anpassungsfähigkeit an Änderungen und der Flexibilität der Software.

Zum Beispiel haben wir immer Zeit, um Fehler zu beheben, aber es ist keine Zeit, Tests zu schreiben. Wir überarbeiten oder schreiben keine Tests, weil wir wenig Zeit haben. Aber wir haben immer Zeit zum Debuggen, Einfahren von Krücken und Beheben von Fehlern.

Wir konzentrieren uns so auf den Prozess, dass wir oft vergessen, was für die Softwareentwicklung am wertvollsten ist - Menschen. Prozesse helfen Menschen, bessere Produkte herzustellen, die Motivation zu steigern und ein gesundes Arbeitsumfeld zu schaffen. Letztendlich ist Prozesseffizienz wichtig, aber es gibt nichts Wertvolleres als Menschen.

Sie müssen verstehen, dass niemand und nichts perfekt ist. Kunden, Führungskräfte, Manager, Teammitglieder, Unternehmensvertreter, auch Sie, sind nicht alle perfekt. Anforderungen, Dokumentation, Tools, Code, ein entwickeltes System und sein Design werden ebenfalls niemals ideal sein. Wir müssen also in Eile aufhören und die Entwicklung gedankenlos beschleunigen. Die einzige Möglichkeit, sich in einem gleichmäßigen Tempo schneller zu bewegen, besteht darin, in drei wichtige Richtungen zu verlangsamen:

• Menschen - Steigerung der Professionalität und des Könnens,
• Der Prozess verbessert die Flexibilität und Effizienz,
• Produkt - Qualitätsverbesserung und Automatisierung.

Wo man langsamer wird, wenn es um Menschen geht

Prozesse und Tools erstellen kein Produkt. Die Leute machen es. Es ist erwähnenswert, dass die Einstellung von Talenten die wichtigste Aufgabe des Unternehmens ist, die sich direkt auf die Zukunft des gesamten Unternehmens und insbesondere auf das zu schaffende Produkt auswirkt.

Stellen Sie die talentiertesten in Ihrer Organisation ein. Mit "am meisten" meine ich nicht das klügste und erfahrenste. Ich suche zumindest enthusiastisch, diszipliniert und motiviert. Wenn eine Person diese drei Eigenschaften hat, wird sie leicht ihre Talente entwickeln.

Die Einstellung sollte für beide Seiten von Vorteil sein. Verlangsamen Sie daher den Einstellungsprozess und nehmen Sie sich Zeit, um ihn zu verbessern. Menschen schließen sich Unternehmen an, an die sie glauben. Simulieren Sie, welche Art von Personen Sie in Ihrem Team erwarten. Und bringen Sie talentierte Menschen dazu, an Sie zu glauben und Ihre Kultur, Ihre Vorstellung von der Zukunft und Ihre Mitarbeiter zu betrachten.

Das Ego ist das Gift, das Ihre Organisation langsam tötet. Lassen Sie es niemals in Ihre Organisation eindringen. Ausgehend von Dummköpfen, die angenehm in der Kommunikation sind und mit brillanten Idioten enden - lassen Sie Extreme nicht Teil Ihres Teams werden. Stellen Sie keine Leute mit einem aufgeblähten Ego ein. Mit ihnen schaffen Sie niemals eine Unternehmenskultur, die andere begeistert.

Hör auf alleine zu arbeiten, arbeite zusammen. Erlaube keine Fragmentierung im Team. Einzelgänger und Heldenentwickler sind ein Zeichen für eine gestörte Organisation. Setz dich in die Nähe. Setzen Sie mit dem gesamten Team Maßstäbe. Arbeiten Sie zu zweit oder in Gruppen. gemeinsam überprüfen. Erlauben Sie allen Teilnehmern des Prozesses, für das Ergebnis verantwortlich zu sein.

Gemeinsames Üben ist der effektivste Weg, um Ihre Fähigkeiten zu verbessern. Durch die Interaktion inspirieren wir nicht nur andere Menschen, sondern lernen auch voneinander. Führen Sie regelmäßig Code Retreat , Coding Dojo und Randori mit Ihrem gesamten Team aus. Verbringen Sie jeden Tag 30 Minuten damit, nur zu üben.

Lassen Sie Wissen unter Menschen verbreiten. Gemeinsam lernen. Ich habe Brown Bag / Lunch & Learn- Sitzungen mit allen Teams abgehalten, in denen ich seit 2010 gearbeitet habe. Zweimal hörte ich von meinen Kollegen: "Wenn ich mittwochs an Sitzungen teilnehme, kann ich pumpen, und das motiviert mich sehr." Dies spiegelt deutlich die Vorteile des Haltens regelmäßiger interner Mitaps wider.

Sammeln Sie Feedback und geben Sie es an andere weiter. Um kollektives Feedback zu sammeln, arrangieren Sie eine großartige Retrospektive. Ich mache das seit mehr als einem Jahr. Dies ist übrigens eine großartige Möglichkeit, mit einer Gruppe von 20 oder mehr Personen in die Problemlösung einzutauchen.

Anderen beizubringen und Wissen zu teilen ist der beste Weg, um Meisterschaft zu erlangen. Sprechen Sie öffentlich und tragen Sie zur Gemeinschaft bei.

Es ist allgemein anerkannt, dass Entwickler das Schreiben von Dokumentation hassen. Aber die Realität sagt das Gegenteil. Jedes Ergebnis, das andere Leute lesen, ist Dokumentation. Ausgehend vom Systemcode und endend mit dem Testcode, von Nachrichten über Commits bis hin zum Commit-Diagramm im Repository, von Protokollnachrichten bis hin zu Fehlermeldungen, erstellen Entwickler eine Vielzahl von Dokumentationen, ohne es zu merken. Und egal was Sie dokumentieren, wenn die Leute es lesen - dokumentieren Sie so gut wie möglich.

Sie sind keine Kinder. Organisation ist nicht deine Eltern. Jeder sollte seine Karriere unabhängig gestalten und in sich selbst investieren. Wenn Ihr Beitrag Zeit oder Geld verschwendet, tun Sie es selbst.

Wie man den Prozess verlangsamt und verbessert

Jeden Tag stehen wir vor neuen Herausforderungen. Dies sind nicht nur Marktbedürfnisse und neue Produktanforderungen. Technische Herausforderungen wirken sich auch auf unseren Fortschritt aus.

Pläne sind nichts, aber Planung ist alles. Machen Sie einen Plan und überprüfen Sie ihn ständig. Besonders in den frühen Phasen eines Projekts, wenn maximale Flexibilität erforderlich ist. Eine tägliche Abstimmung mit einem Plan wie Daily Scrum oder Daily Standup reicht nicht aus. Es ist notwendig, enger im Team zusammenzuarbeiten, paarweise zu arbeiten und den Plan noch häufiger zu konsultieren. Halten Sie die minimale Iterationslänge bis zu einer Woche. Organisieren Sie mehrere Feedback-Kanäle mit regelmäßigen Überprüfungs- und Demo-Sitzungen.

Definieren Sie kurz- und langfristige Ziele. Kurzfristige Ziele stellen den Fokus des Teams dar, langfristige Ziele verhindern dessen Verlust.

Wenn Sie verstehen möchten, warum etwas schief geht, visualisieren Sie den Arbeitsablauf sowohl aus technischer als auch aus organisatorischer Sicht. Visualisieren Sie Fehler und Misserfolge, um das Lernen aus erster Hand zu maximieren.

Treffen Sie niemals Entscheidungen, die auf Gefühlen beruhen. Sammeln Sie immer Daten, analysieren Sie und treffen Sie darauf basierende Entscheidungen. Es ist auch wichtig, jedem Entwickler Zugriff auf Produkt- und technische Metriken zu gewähren. Dies erhöht die Beteiligung und das Verständnis des zu entwickelnden Produkts.

Abfall ist alles, wofür Sie Zeit aufwenden, aber das hat keinen Wert für das Geschäft. Finden und beseitigen Sie Abfälle im Büro, im Code und in Geschäftsprozessen.

Pfadfinder verlassen den Parkplatz sauberer als bei ihrer Ankunft. Die gleiche Philosophie gilt für die Softwareentwicklung. Befolgen Sie die Scout-Regel und halten Sie den Code nach jeder Änderung sauberer. Wenn Sie neue Funktionen hinzufügen und Fehler in der Datei sehen möchten, die behoben werden können, tun Sie dies ohne Erlaubnis. Denken Sie daran, zuerst Tests zu schreiben. Dies gibt Ihnen Vertrauen in Änderungen.

Sie können Abfall zu jedem Zeitpunkt im Systementwicklungszyklus entdecken. Befolgen Sie klar definierte Kriterien für die Bereitschaft (Definition von erledigt) und beseitigen Sie Aufgaben im Sinne von „90% erledigt, 90% übrig“.

Lassen Sie nicht zu, dass langlebige Zweige entstehen - sie gelten als böse. Überprüfen Sie Ihren Code nicht manuell. Beim manuellen Testen überprüfen Sie wahrscheinlich ein erfolgreiches Ausführungsskript. Alle anderen Skripte können nur mit Code überprüft werden. Nehmen Sie dieses Problem daher ernst.

Wie eine Verlangsamung die Produktqualität verbessern kann

Eines ist sicher - ohne eine hochwertige Codebasis können Sie leider nicht flexibel sein. Das erste, was zu tun ist, ist, technische Schulden zu beseitigen und Fehler zu beheben. Unterbrechen Sie gegebenenfalls die Entwicklung neuer Funktionen und konzentrieren Sie sich auf die Behebung von Fehlern.

Der Ansatz "Ich werde es schnell beheben, dann werde ich es beheben" funktioniert in der aktuellen Realität nicht, da er zu riskant ist. Bei der Beseitigung von Fehlern ist ein disziplinierterer Ansatz erforderlich. Schreiben Sie zunächst einen Test, der das Problem reproduziert. Beheben Sie danach den Fehler und stellen Sie sicher, dass der Test jetzt erfolgreich ist. Jetzt können Sie den Patch sicher an die Produktion senden.

Ich habe in Teams gearbeitet, die fast die ganze Zeit damit verbracht haben, Fehler zu beheben und das Projekt zu warten. Der Grund für ihr Leiden ist instabile Arbeit in der Produktion. Um weiterhin neue Funktionen zu entwickeln und gleichzeitig Fehler zu korrigieren, müssen Sie das Team in virtuelle Teams aufteilen. Zum Beispiel wählen wir in jeder Iteration zwei Typen aus, die an der Unterstützung und Behebung von Fehlern beteiligt sind. Wir nennen sie Batman und Robin. Unabhängig davon, welche Funktionen Sie schnell fertig stellen müssen, werden Fehler ohne Unterbrechung durch die Hauptentwicklung behoben.

Entwickler verwenden häufig eine der Verzögerungsmethoden, um weitere Pull-Anforderungen zu beschleunigen. Sie stoppen die laufende Entwicklung, führen Überprüfungen durch und führen Codeüberprüfungen durch, um die Qualität des Codes zu verbessern. Nicht verifizierter Code wird niemals die Produktion treffen.

Unser oberstes Ziel sollte der Übergang zu Continuous Delivery und häufigen Veröffentlichungen sein. Angefangen bei der Verwendung von Git-Zweigen bis hin zu Bereitstellungsstrategien, von der Bereitstellung von Feedback bis hin zu automatisierten Testpraktiken - all dies erfordert einen speziellen Ansatz.

Die Praktiken, die Sie in verschiedenen Phasen des Softwareentwicklungszyklus anwenden, zeigen, wie schnell Sie sich entwickeln. Verwenden Sie bei der Arbeit mit Zweigstellen den Ansatz "Frühzeitig festschreiben, häufig festschreiben, später perfektionieren, einmal veröffentlichen". Wenn Sie ohne Zweige arbeiten, verwenden Sie Feature Toggles. Dadurch wird Zeitverschwendung vermieden.

Ich benutze TDD seit Jahren. Oft beschweren sich Leute bei mir, dass TDD die Entwicklungsgeschwindigkeit negativ beeinflusst. Joe Rainsberger teilte seine Gedanken zu TDD auf Twitter mit : „ Befürchten Sie, dass TDD Ihre Programmierer verlangsamen wird? Nicht nötig. Sie müssen wahrscheinlich langsamer werden. “

TDD ist mehr Refactoring als Testen; mehr Gedanken als Kodierung; mehr Einfachheit als Eleganz. Deshalb führt TDD zu einer höheren Qualität. Wenn Sie TDD verwenden, haben Sie nur die minimale Anzahl von Tests und ein einfaches Design.

Haben Sie jemals eine 100% ige Abdeckung des Codes mit Tests erreicht? Ich habe es in einem dreimonatigen Projekt erreicht und jede Zeile des Produktionscodes mit Tests abgedeckt. In diesem Moment fühlte ich mich wie ein Held mit Superkräften. Als wir das System jedoch für Abnahmetests in der Vorproduktion einsetzten, stellten wir fest, dass die vier Funktionen nicht funktionierten. Ich habe Integrations- und Funktionstests geschrieben, um Fehler zu finden und zu beheben. In diesem Moment wurde mir klar, dass Unit-Tests kein gutes Design und keine gute funktionale Funktionalität garantieren. Hören Sie auf, den Prozentsatz der Codeabdeckung als Test zu zählen. Diese Metrik zeigt nichts.

Korrigieren Sie Fehler sofort, wenn es 30 Minuten oder weniger dauert. Verwenden Sie außerdem 20% der Zeit, um technische Schulden zu beseitigen.

In der Regel schreiben wir Code, ohne ihn in Zukunft ändern zu wollen. Beim Entwurf eines Systems wählen wir ebenfalls Technologien und Tools aus und planen, diese in Zukunft nicht mehr zu ändern. Aber wir irren uns. Refactoring sollte in jeder Phase des Projekts möglich sein. Wie Kent Beck sagt, müssen wir einfache Änderungen vornehmen, damit weitere Änderungen einfach sind. Um dies zu ermöglichen, speichern wir den Code aller unserer Microservices in einem Mono-Repository. Dies macht das Refactoring einfach und wirklich notwendig.

Jede Entscheidung im Entwurf ist falsch, wenn sie früher als nötig getroffen wird. Sie sollten auf den letzten akzeptablen Moment warten, um eine Entscheidung zu treffen. Wir verwenden die Architektur „Ports and Adapter“, um eine geringe Kopplung und eine hohe Kohäsion auf der Designebene des gesamten Systems zu erreichen. Dadurch erhalten wir perfekt gestaltete Monolithen.

Ein Monolith ist nicht böse, böse ist ein schlechtes Design. Wir beginnen immer mit der Entwicklung eines Monolithen und extrahieren dank der Architektur „Ports und Adapter“ Teile der Funktionalität in Microservices. Wie Martin Fowler in einem ersten Artikel über Monolithen sagte: „Es ist riskant, sofort mit der Microservice-Architektur zu beginnen. Beginnen Sie besser mit einem Monolithen. Teilen Sie sich nur dann in Microservices auf, wenn und falls erforderlich. “

Verlangsamen, um als Annäherung an das Leben zu beschleunigen

Andreas Möller teilte seine Gefühle zur Softwareentwicklung in einem Tweet mit : „Ich möchte keinen Code schreiben, der einfach funktioniert. Ich möchte Code schreiben, der sauber, wartbar, leicht verständlich und gut getestet ist. “

Um dies zu erreichen, müssen wir uns auf drei Bereiche konzentrieren: Menschen, Prozesse und Produkte. Wir verlangsamen die Arbeit der Menschen und bemühen uns, Professionalität und Können zu verbessern. Durch die Verlangsamung des Prozesses bemühen wir uns, die Flexibilität und Effizienz zu erhöhen. Indem wir die Arbeit am Produkt verlangsamen, bemühen wir uns, den Automatisierungsgrad und den Qualitätsgrad zu erhöhen. Wenn wir uns auf diese drei Bereiche konzentrieren, beginnen wir, eine Kultur zu pflegen, die eine schnelle Entwicklung ermöglicht.

Wir müssen uns an Folgendes erinnern:

• Ein funktionierendes System ist nicht unbedingt gut geschrieben
• Nur echte Profis können ein gut gestaltetes System erstellen
• Nur ein gut gestaltetes System ermöglicht es Ihnen, neue Funktionen so schnell wie möglich freizugeben

Über den Autor

Lemi Orhan Ergin ist ein Softwareentwicklungsassistent, der versucht, das Niveau seiner Branche zu verbessern und seine Erfahrungen mit der Community zu teilen. Craftbase Mitbegründer und Gründer der Turkish Software Craftsmanship Community . Ist seit 2001 in der Softwareentwicklung tätig. Er praktiziert und betreut aktiv Bereiche wie Scrum, extreme Programmierung, Entwicklungsmethoden und Webtechnologien.