Inhaltsverzeichnis:
Ein agiles Softwareentwicklungsteam zu sein, bedeutet für verschiedene Menschen sicherlich verschiedene Dinge. Es gibt Grade der Akzeptanz in einem sehr breiten Spektrum, mit anscheinend sehr wenigen Organisationen, die glauben, dass sie es gut machen. Laut der State of Agile-Umfrage von VersionOne (veröffentlicht im April 2017) geben 80% der Befragten an, „auf oder unter einem noch ausgereiften Niveau“ zu sein. Leider geben sich Entwicklungsteams oft nicht viel Mühe, um den Teil der Iteration zu lernen. Wir möchten uns beeilen und die Scrum-Zeremonien hinter uns bringen, damit wir wieder Code schreiben können. Immerhin gibt es so viel zu tun! Aber ist unzureichende Codierungszeit wirklich das Problem?
Für viele von uns könnte die Brandbekämpfung genauso gut in unserer Stellenbeschreibung aufgeführt sein. Wir gehen jeden Tag zur Arbeit und wissen, dass wir bereit sein müssen, sofort die Stange herunterzurutschen, unsere Hüte zu greifen und auf den Lastwagen zu springen. Wir akzeptieren es so wie es ist und gehen davon aus, dass wir nichts dagegen tun können. Aber was ist, wenn die Hauptursache unserer Kämpfe ein schwerer Mangel an Effizienz ist? Jeder weiß, wie wichtig es ist, es besser zu machen als das andere Unternehmen dort. Wir scheinen einfach nicht dorthin zu gelangen - wir scheinen nicht die Bandbreite zu haben. Manager fügen mehr Personen hinzu und vergrößern ihre Organisation und haben immer noch die gleichen Probleme. Sie scheinen nicht über den Berg zu kommen, weil Ihre Teams Software nicht effizient entwickeln (und Sie nicht allein sind).
Prinzipien für eine effiziente Entwicklung
Pixabay
Was führt dazu, dass wir ineffizient sind? Für die meisten von uns fällt zunächst die mangelnde Automatisierung ein (automatisierte Builds, Bereitstellungen, Tests). "Sobald wir genug Automatisierung haben, wird das Leben besser." Leider ist das nur ein Teil der Lösung. Berücksichtigen Sie die Auswirkungen von Nacharbeiten auf Ihr Projekt. Der effizienteste Weg, ein Feature zu erstellen, besteht darin, es einmal korrekt zu erstellen und es nie wieder zu berühren. Bugs, Refactoring und ähnliche Aktivitäten öffnen den Patienten im Wesentlichen wieder, nachdem er den Operationssaal verlassen hat, und damit ist ein inhärentes Risiko verbunden. Wir können Nacharbeiten nicht beseitigen, aber wir sollten uns auf jeden Fall bemühen, sie zu minimieren.
"Aber umarmt Agile nicht Nacharbeit (z. B. Refactoring)?" Dies geschieht tatsächlich in gewisser Weise, da die Entwickler von Agile verstanden haben, dass zwei Hauptursachen für Nacharbeiten unvorhergesehene Umstände und sich ändernde Geschäftsanforderungen sind. Es stellt sich heraus, dass Menschen schrecklich darin sind, die Zukunft vorherzusagen. Agile Entwickler haben auch verstanden, dass das, was Entwickler als „Vergoldung“ bezeichnen, einen großen Beitrag zur Ineffizienz leistet. Wir glauben, dass jemand diese nutzen wird, obwohl Endbenutzer nie danach gefragt haben. Es ist wie Schweinefleisch für Ihr Softwareprodukt - eine völlige Zeitverschwendung. "Baue keine Raumstation, wenn sie nur nach einem Volvo fragen." Daher haben Unternehmen mit Bedacht begonnen, das Schweinefleisch wegzulassen und stattdessen das Refactoring zu übernehmen, und nur dann Funktionen hinzugefügt, wenn ein klarer Bedarf besteht. Aber die Unvorhersehbarkeit des Lebens ist nicht der einzige Treiber für Nacharbeiten, oder?
Fehlende Details in jeder Phase der Funktionsentwicklung verschwenden letztendlich Zeit und Geld. Eine effektive Zusammenarbeit im Voraus erspart Ihnen im Laufe der Zeit eine Menge Nacharbeit (Umgang mit fehlenden Anforderungen, kurzsichtigem Design usw.). Wir haben alle blinde Flecken und wir brauchen alle zusätzliche Augenpaare. Viele Entwicklungsteams nutzen dies im Backend während der Codeüberprüfung, investieren jedoch viel weniger Energie in die frühzeitige Zusammenarbeit, wenn Probleme kostengünstig und nach minimalen Investitionen gelöst werden können.
Wie oft haben Sie eine Funktion implementiert und gegen Ende erhebliche Fehler festgestellt, die bei Anforderungs- / Konstruktionsdiskussionen hätten festgestellt werden müssen? Es ist, als würde man versuchen, von Atlanta nach Montgomery zu fahren und nach einigen Stunden feststellen, dass man stattdessen versehentlich nach Birmingham gefahren ist. Wie viel Zeit wurde damit verbracht, den Code genau richtig zu machen, um den Patienten später wieder zu öffnen, weil wichtige Anforderungen übersehen wurden? Die Nutzung kollektiver Intelligenz würde absolut Zeit und Geld sparen. Stattdessen arbeiten Entwickler häufig isoliert an Funktionen.
Traditionelles Schwärmen
Pixabay
Traditionelles Schwärmen bedeutet, dass das Team gemeinsam an Geschichten mit mehreren Personen arbeitet, die gleichzeitig an einem kleinen Feature arbeiten, wodurch die Rückkopplungsschleife verkürzt und die Gesamtabschlusszeit für das Feature verkürzt wird (dh Teilen und Erobern). Dies ist im Wesentlichen eine Schwärmerei innerhalb jeder Disziplin (Backend-Entwickler, UI-Entwickler usw.). Bevor die Entwicklung beginnt, arbeiten die UI-Entwickler daran, unabhängige Aufgaben zu identifizieren, die gleichzeitig ausgeführt werden können. Sie diskutieren Schnittstellenpunkte, damit jede Person weiß, wie ihr Stück in das Ganze passt. Die Teammitglieder können dann ihre zugewiesenen Aufgaben erledigen und am Ende während der Integration alles zusammenführen. Häufige Commits und regelmäßige Codeüberprüfungen sorgen dafür, dass alles auf den Schienen bleibt. Dieser Ansatz erfordert die Zusammenarbeit zwischen den Entwicklern,Das hilft sowieso, ein besseres Endergebnis zu erzielen. Wir priorisieren häufig die Zeit, die für das Schreiben von Code (beliebiger Code) aufgewendet wird, gegenüber der Zeit, die aufgewendet wird, um sicherzustellen, dass wir nicht den falschen Code schreiben. Wenn Sie die möglicherweise eingesparte Zeit berücksichtigen, wird der Wert klar.
Entsperrt werden
Pixabay
Ein weiterer wertvoller Ansatz für das Schwärmen besteht darin, das Team frühzeitig auf die Verringerung von Abhängigkeiten zu konzentrieren, um die gleichzeitige Entwicklung in allen Disziplinen zu erleichtern. Betrachten Sie den natürlichen Entwicklungsfluss einer UI-Funktion. Die Automatisierungstester (SDETs) sind auf eine funktionierende Benutzeroberfläche zum Testen angewiesen, die Benutzeroberflächenentwickler auf eine funktionierende Backend-API und die Backend-Entwickler auf Konfiguration, Datenbankaktualisierungen und automatisierte Builds / Bereitstellungen. Daher beginnen UI-Entwickler möglicherweise erst mit der Arbeit, wenn die APIs fertig sind, und SDETs beginnen ihre Arbeit möglicherweise erst, wenn die Funktion abgeschlossen ist. Jede Disziplin arbeitet isoliert, was die Zusammenarbeit behindert, da die Personen, mit denen Sie interagieren müssen, an anderen Dingen arbeiten.Aber was wäre, wenn Sie die Abhängigkeiten früher verringern und den Disziplinen erlauben könnten, alle gleichzeitig an derselben Funktion zu arbeiten?
Hier sind einige Beispiele:
1. Bereitgestellte funktionale Benutzeroberfläche mit Stubs
Um SDETs zu entsperren, können UI-Entwickler ihnen eine funktionierende UI geben, die gerade so funktioniert, dass sie Tests schreiben können. Backend-API-Integration und CSS-Stile können noch ausstehen, da automatisierte Test-Frameworks wie Selenium sich nicht darum kümmern, ob diese Dinge noch nicht abgeschlossen sind. Es kann alles Rauch und Spiegel sein. Während Änderungen auftreten können, die einige Nacharbeiten verursachen, überwiegt der Vorteil eines frühen Starts der Tests dieses Risiko.
2. Bereitgestellte Backend-APIs (gestoppelte, fest codierte Daten)
Durch die Bereitstellung von Backend-APIs, mit denen die UI-Entwickler testen können, können Integrationsprobleme zwischen dem Frontend und den APIs frühzeitig erkannt werden. Manchmal stellen Sie fest, dass die bereitgestellte API nicht den Anforderungen der Front-End-Entwickler entspricht. Ganze Anrufe könnten fehlen, die Signatur könnte falsch sein oder die Struktur der Daten könnte Probleme haben. Wenn es eine Unterbrechung gibt, können Sie dies auch frühzeitig herausfinden, bevor sich etwas verhärtet hat.
3. Erstellen Sie eine HelloWorld-Version neuer Anwendungen und Dienste.
Wenn ein neuer Dienst benötigt wird (z. B. ein Microservice), erstellen Sie das Repo und erstellen Sie eine "Hallo Welt" -Version des Dienstes. Auf diese Weise können Entwicklungsressourcen für Jenkins-Jobs und Bereitstellungsskripts gestartet werden, bevor der Dienst tatsächlich entwickelt wird.
Diese Optimierungen ermöglichen eine frühe Rückkopplungsschleife, in der jemand sagen kann, dass ich etwas anderes brauche, bevor die Entwicklung der Komponente abgeschlossen ist, für die die Änderung erforderlich ist.
Verpacken
Es ist unglaublich wichtig, dass wir herausfinden, wie wir die Markteinführungszeit für Funktionen, an denen wir arbeiten, verkürzen können. Das Unternehmen profitiert nicht davon, dass eine Reihe von Funktionen in Bearbeitung sind, und Entwickler benötigen dringend Funktionen, die schnell implementiert werden müssen, damit Fehler so nahe wie möglich am Injektionspunkt behoben werden können. Entwickler müssen auch dringend miteinander interagieren, obwohl sie nur Code schreiben möchten. Es ist besser für alle Beteiligten, einschließlich des Endbenutzers, der nur ein besseres Produkt möchte. Wenn Sie es ihnen nicht geben, werden sie woanders hingehen, um es zu finden.
Das Schwärmen ist ein äußerst wertvolles Werkzeug in der Toolbox Ihres Unternehmens, wenn sich die Mitarbeiter die Zeit nehmen, um zu lernen, wie es geht. Es ist kein Rahmen oder gar eine Aktivität - es ist eine Denkweise. Für jede User Story stellen sich die Teammitglieder zwei Fragen:
- Wie organisieren wir Aufgaben für diese Geschichte, damit mehrere Personen gleichzeitig Beiträge leisten?
- Was muss ich mindestens tun, um jemanden zu entsperren, der auf mich wartet?
Was wäre, wenn Ihr Team Features schnell zusammenstellen würde, anstatt langsam eine Reihe von Features unabhängig voneinander zu erstellen? Sie könnten tatsächlich auf sich ändernde Geschäftsanforderungen reagieren und die Anforderungen des Unternehmens erfüllen, wenn das Unternehmen sie erfüllen muss. Konkurrenten würden Sie fürchten - Kunden würden Sie lieben. Das ist ein Rezept für ein erfolgreiches Geschäft.
© 2017 Mike Shoemake