Agile Denkweise gegen agile Mechanismen

https://flic.kr/p/bkcj5q

Ich stelle wiederholt fest, dass Software-Teams sich zu sehr auf Mechanismen konzentrieren und das Grundprinzip aus den Augen verlieren. Dies gilt insbesondere für agile Methoden. Methoden wie Scrum haben so viele Mechanismen, dass diejenigen, die neu in der Agilität sind, völlig verloren gehen. Ich habe dies ursprünglich als E-Mail an mein Team geschrieben, um zu klären, was ich von Agile halte, aber ich habe es jetzt an so viele Leute gesendet, dass ich es nach dem Rat von Scott Hanselman in einen Blogpost verwandle.

Ich halte mich für etwas qualifiziert, diesen Einblick zu gewähren. Ich bin ein agiler Praktiker aus der Zeit, in der es bei der agilen Entwicklung um die Verwendung eines Schraubenziehers ging - um Ihre eigenen Kabinen abzubauen und einen offenen Sitzplan zu erstellen!

Zu Beginn meiner Karriere arbeitete ich bei einer medizinischen Softwarefirma. Wir haben eine Desktopsoftware für die Bildprüfung entwickelt, die in Krankenhäusern auf dem Desktop von Doctor installiert wurde. Bei der Bereitstellung mussten CDs in eine andere Stadt transportiert und die Desktops sowie die Image-Server installiert werden. Wir waren der FDA-Zulassung unterworfen, daher mussten wir nach Spezifikationen bauen, die die FDA-Zulassung durchlaufen hatten. Dies schuf eine ideale Umgebung für die Top-Down-Methode mit Wasserfällen. Alle Spezifikationen wurden aufgeschrieben, genehmigt und unterschrieben, und wir haben nur nach diesen Spezifikationen und diesen Spezifikationen gebaut. Erst als das Entwicklerteam mit dem Installationsteam auf Reisen ging und den Ärzten beim Einsatz unserer Software zusah, wurde uns klar, dass wir nur dann so viel besser abschneiden können, wenn wir früher im Zyklus mit dem Kunden sprechen können. Wir haben nach genauen Spezifikationen codiert und dennoch etwas geliefert, das nicht so nützlich war, wie es hätte sein können. Diese Grafik zeigt einige meiner Erfahrungen.

Wie Softwareentwicklung schief gehen kann von https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Um diese Zeit hörte mein Team von etwas, das sich Agiles Manifest nennt, und von einer Praxis, die sich Extreme Programming nennt. Da es von Branchenveteranen unterzeichnet wurde, deren Bücher wir aktiv lasen, verlieh es Leuten wie Martin Fowler und Kent Beck viel Legitimität. Mein fünfköpfiges Team baute unsere Kabinen ab, zog unseren PM (Stellvertreter für unseren Kunden) zu sich, stellte ein Brett mit Karteikarten auf und machte sich an die Arbeit, um die XP zu sammeln. Wir hatten einen wöchentlichen Planungs- und Demozyklus, viele Abstimmungen und Diskussionen. Ich habe in verschiedenen Iterationen und Variationen davon gearbeitet, in verschiedenen Firmen für ungefähr 15 Jahre. Ein Team schien überhaupt keine Methodik zu befolgen, aber es lag daran, dass alle Teammitglieder aus einem sehr agilen Umfeld stammten. Iteration und Zusammenarbeit waren ihr Standardzustand und sie benötigten keinen vorgeschriebenen Prozess.

Geht es bei Agile also um offene Grundrisse oder um viel Reden? Wenn Sie Stand-Ups und Retros haben, können Sie behaupten, agil zu sein? Wo passt Scrum oder TDD hin? Oft sind die Leute zu sehr in die Details des Prozesses verstrickt - Scrum oder Kanban? Zwei Wochen oder eine Woche Sprint? Wenn Sie keinen Rückstand haben, sind Sie dann wirklich agil? Als ich mit agilen Methoden aufgewachsen bin und mich mit anderen Entwicklern befasst habe, die sich gleichermaßen mit der Entwicklung und Anpassung von Praktiken befassen, habe ich einen guten Einblick erhalten. Dieser Beitrag dient dazu, die Grundprinzipien zu identifizieren.

Agil sein heißt, schnell auf die Bedürfnisse der Kunden eingehen zu können. Heißt das, wir schreiben Code schneller? Nee. Wir können die Gesetze der Physik nicht übertreffen, und es braucht Zeit, um eine solide multifunktionale Anwendung zu erstellen.

Was wir tun müssen, ist

  1. Identifizieren Sie die wesentlichen Geschäftsprobleme, die wir mit Code lösen möchten
  2. Stellen Sie schnell eine theoretische Lösung bereit, um die Hypothese zu testen
  3. Iterieren Sie und passen Sie sich an, wenn sich die Bedürfnisse ändern, oder wir lernen mehr
  4. Tun Sie es in Zusammenarbeit mit dem Kunden, einem engagierten Teil des Teams

Alles andere, was wir tun, macht 2 und 3 weniger schmerzhaft - um zu wissen, ob wir den Bedarf so schnell wie möglich decken und wenn wir nicht in der Lage sind, uns schnell zu ändern. Wenn Sie sich für ein Build entschieden haben (im Gegensatz zum Kauf), schreiben Sie eine benutzerdefinierte Software. Dies bedeutet, dass es spezielle Anforderungen und Umgebungen hat.

Wenn wir etwas sichtbar machen, auch wenn es sich um einen kleinen Teil der Funktionalität handelt, können wir dem Kunden so schnell wie möglich Feedback geben. Aus diesem Grund empfehle ich immer, mich darauf zu konzentrieren, ein kleines Stück der Funktion zu erstellen, und dies bis zur Produktion zu schaffen. Angenommen, Sie erstellen eine Seite für Ihre Support-Mitarbeiter, auf der alle Daten zu einem Kunden angezeigt werden. Versuchen Sie, eine Teilmenge der Daten auf der Seite bis zur Produktion zu erhalten, anstatt viel Zeit damit zu verbringen, die Datenquellen für die gesamte Seite zu recherchieren und zuerst alle APIs zu schreiben. Sie können Ihre Integrations- und Bereitstellungsmechanismen ausüben, Feedback zum UI-Framework erhalten, wie diese Seite zum Rest Ihrer Anwendung passt usw. Diese Dinge lassen sich leichter anpassen, wenn Sie nur wenig Code haben bis, wenn Sie ein gesamtes API-Framework erstellt haben.

Hier sind einige der anderen Mechanismen, die für die Beweglichkeit wesentlich sind

Sprints: Durch die Entwicklung in Zeitrahmenzyklen können wir in regelmäßigen Abständen Daten überprüfen und anpassen sowie neue Daten integrieren, um sicherzustellen, dass wir weiterhin an den relevanten Funktionen arbeiten. Software ist eine Haftung. Wir sollten nur das bauen, was wir brauchen, und in der Lage sein, das Notwendige hinzuzufügen, wenn es gebraucht wird. Daher ist es wichtig, regelmäßig zu prüfen, was wir bisher gebaut haben und wohin wir als nächstes gehen. Dies führt zum zweiten Punkt.

Da wir vorhaben, unsere Software ständig zu evaluieren und zu ändern, sollte es einfach sein, sie zu ändern. Was ist, wenn ein Kunde nach dem Start der Anwendung möchte, dass einige Daten anders als ursprünglich entworfen angezeigt werden? Könnten wir das tun, ohne alles andere auf der Seite zu berühren? Oder wir müssen eine andere API aufrufen, um Daten abzurufen - können wir diese Änderung sicher vornehmen? Hier setzen gute Entwicklungspraktiken und -mechanismen an

Unit Testing: Wir haben automatisierte Tests auf verschiedenen Ebenen, sodass ein Sicherheitsnetz für Änderungen vorhanden ist. Es ist auch wichtig zu bedenken, was die Unit-Tests tatsächlich testen. Unit-Tests sollten die Logik testen. Wenn Sie im obigen Beispiel eine andere API zum Abrufen von Daten verwenden, sollte im Idealfall keine Änderung der Komponententests für unsere API erforderlich sein, die Daten für die Benutzeroberfläche bereitstellt. Unit-Tests geben Ihnen die Gewissheit, den Code zu überarbeiten, was Ihnen die Freiheit gibt, nur das zu schreiben, was Sie jetzt brauchen, und sich später auszuruhen, um ohnehin keine 100% ige Abdeckungsmetrik zu erstellen.

CI / CD: Dies ermöglicht es uns, den Abstand zwischen Festschreiben und Lieferung zu verkürzen. Dies ist wichtig für die Beweglichkeit. Wenn Hemmnisse für die Bereitstellung beseitigt werden und wir kleine Änderungen an der Produktion vornehmen können, wird das Risiko durch Änderungen erheblich verringert. Wenn Bereitstellungen mühsam sind, sind sie weniger häufig. Weniger häufige Bereitstellungen drücken eine Menge Änderungen aus, berühren eine große Oberfläche und sind daher riskanter. Wenn Sie mehr darüber erfahren, warum die Leistung der Softwarebereitstellung wichtig ist und welche Metrik zur Optimierung verwendet werden muss, empfehle ich dieses Buch von Nicole Forsgren.

Trennung von Bedenken: Eine lose gekoppelte Architektur ist für eine leicht zu ändernde Software unerlässlich. Es reduziert die Oberfläche einer Änderung. Mikrodienste und Container sind einige der Mechanismen, die zur Trennung von Anliegen eingesetzt werden. Beachten Sie dies unbedingt, und achten Sie beim Erstellen von APIs, Komponenten und Anwendungen auf die Trennung von Bedenken.

Merken
Guter Code kann leicht geändert werden

Besserer Code kann einfach gelöscht werden

Der beste Code ist der, der überhaupt nicht geschrieben wurde

Es ist wichtig, dass die Bits, die Sie erstellen, so schnell wie möglich der realen Welt entsprechen, damit Sie wissen, wie Ihre neuen Bits aussehen müssen, und dass Sie keine Zeit damit verschwenden, unnötige Bits herzustellen.