DevOps-Prozess: Arbeitsaufteilung

Die Arbeitsaufteilung ist ein wesentliches Prinzip in jeder Disziplin, in der Feedback-Loops wichtig sind oder Sie schnell aus Ihren Entscheidungen lernen möchten. Durch die Arbeitsaufteilung können Sie schnell Hypothesen darüber testen, ob eine bestimmte Verbesserung wahrscheinlich den gewünschten Effekt hat. Andernfalls können Sie Annahmen korrigieren oder noch einmal bearbeiten. Dieser Artikel lässt sich zwar auf jede Art von Änderung einschließlich der organisatorischen Transformation und Prozessverbesserung anwenden, doch der Schwerpunkt liegt hauptsächlich auf der Softwarebereitstellung.

Die Arbeitsaufteilung ist Teil des schlanken Produktmanagements. Neben Kompetenzen wie Sichtbarkeit der Arbeit im Wertstrom, Teamexperimente und Einblick in das Kundenfeedback kann die Arbeitsaufteilung die Leistung der Softwarebereitstellung und der Organisation vorhersagen.

Ein Grund dafür, in großen Batches zu arbeiten, sind die hohen Fixkosten für die Übergabe von Änderungen. Bei traditionellen gestaffelten Ansätzen der Softwareentwicklung bestehen Handoffs von der Entwicklung zum Test oder vom Test bis hin zum IT-Betrieb aus ganzen Releases, d. h. aus monatelanger Arbeit von Teams aus zehn oder Hunderten von Mitarbeitern. Bei diesem herkömmlichen Ansatz kann das Erfassen von Feedback zu einer Änderung Wochen oder Monate dauern.

Im Gegensatz dazu kann Software dank der DevOps-Praktiken, die funktionsübergreifende Teams und einfache Ansätze verwenden, innerhalb von wenigen Minuten von der Entwicklung über Tests und den Betrieb in die Produktion gelangen. Diese schnelle Entwicklung erfordert jedoch eine Arbeitsaufteilung mit Code.

Die Arbeitsaufteilung hat viele Vorteile:

  • Sie erhalten schneller Feedback zu Änderungen und können Probleme leichter erkennen und beheben.
  • Effizienz und Motivation werden erhöht.
  • Es wird verhindert, dass Ihre Organisation dem Irrtum der gesunkener Kosten erliegt.

Sie können den Ansatz für kleine Batches auf Funktions- und Produktebene anwenden. Zur Veranschaulichung: Ein Minimum Viable Product (MVP) ist ein Prototyp eines Produkts mit gerade genügend Funktionen, um geprüftes Lernen über das Produkt und sein Geschäftsmodell zu ermöglichen.

Die kontinuierliche Bereitstellung basiert auf der Arbeitsaufteilung und versucht, jede Änderung in der Versionsverwaltung so früh wie möglich zu erhalten. Ein Ziel der kontinuierlichen Bereitstellung besteht darin, die Wirtschaftlichkeit des Softwarebereitstellungsprozesses so zu ändern, dass eine Arbeitsaufteilung möglich ist. Mit diesem Ansatz erhalten die Teams schnelles und umfassendes Feedback, um ihre Arbeit verbessern zu können.

Möglichkeiten der Arbeitsaufteilung

Wenn Sie neue Funktionen planen, versuchen Sie, diese in Arbeitseinheiten aufzuteilen, die unabhängig voneinander und innerhalb kurzer Zeit abgeschlossen werden können. Wir empfehlen, dass jede Funktion oder jeder Batch dem agilen Konzept des INVEST-Prinzips folgt:

  • Independent (unabhängig). Gestalten Sie Batches so unabhängig wie möglich von anderen Batches, damit Teams sie in beliebiger Reihenfolge bearbeiten und unabhängig von anderen Batches bereitstellen und prüfen können.
  • Negotiable (verhandelbar). Jeder Batch ist iterierbar und kann aufgrund von Feedback neu verhandelt werden.
  • Valuable (nützlich). Diskrete Batches sind nutzbar und bieten den Beteiligten einen Mehrwert.
  • Estimable (schätzbar). Es sind genügend Informationen zu den Batches vorhanden, um ihren Umfang abschätzen zu können.
  • Small (klein). Während eines Sprints sollten Sie Batches in kleinen Zeitabständen wie Stunden oder einigen Tagen erledigen können.
  • Testable (testbar). Jeder Batch kann getestet, überwacht und daraufhin überprüft werden, ob er wie erwartet funktioniert.

Wenn Funktionen eine geeignete Größe haben, können Sie die Entwicklung der Funktion in noch kleinere Batches aufteilen. Dieser Prozess kann schwierig sein und erfordert Erfahrung. Idealerweise sollten Ihre Entwickler mindestens einmal pro Tag mehrere kleine freigabefähige Änderungen in den Hauptentwicklungszweig aufnehmen.

Es ist wichtig, die Entwicklung auf der Dienst- oder API-Ebene zu starten, nicht auf der UI-Ebene. So können Sie der API Erweiterungen hinzufügen, die Nutzern der App anfangs nicht zur Verfügung stehen, und diese Änderungen in den Hauptentwicklungszweig aufnehmen. Sie können diese Änderungen für die Produktion starten, ohne sie für Nutzer sichtbar zu machen. Mit diesem Ansatz, der als Dark Launch bezeichnet wird, können Entwickler Code für kleine Batches prüfen, die abgeschlossen wurden, jedoch zu Funktionen gehören, die noch nicht vollständig sind. Sie können dann automatisierte Tests für diese Änderungen ausführen, um nachzuweisen, dass sie sich wie erwartet verhalten. So arbeiten Teams immer noch schnell und entwickeln sich aus dem Baumschema heraus anstatt aus langlebigen Feature-Zweigen.

Sie können auch einen Dark Launch für Änderungen durchführen, indem Sie einen Funktionsumschalter verwenden, eine bedingte Anweisung, die auf Konfigurationseinstellungen basiert. Sie können beispielsweise die Elemente der Nutzeroberfläche ein- oder ausblenden oder die Dienstlogik aktivieren oder deaktivieren. Die Konfiguration des Funktionsumschalters kann entweder während der Bereitstellungs- oder der Laufzeit gelesen werden. Mit diesen Konfigurationseinstellungen können Sie das Verhalten des neuen Codes weiter unten im Stack ändern. Sie können auch ein ähnliches Verfahren verwenden, das als Branch-by-abstraction bezeichnet wird, um größere Änderungen am System vorzunehmen und gleichzeitig die Entwicklung und Freigabe außerhalb des Hauptentwicklungszweigs ohne die Verwendung langlebiger Feature-Zweige fortzusetzen.

Bei diesem Ansatz werden Batches erst abgeschlossen, wenn sie für die Produktion bereitgestellt wurden und der Feedbackprozess die Änderungen überprüft hat. Das Feedback stammt aus vielen Quellen und in vielen verschiedenen Formen, z. B. von Nutzern, der Systemüberwachung, Qualitätssicherung und von automatisierten Tests. Ihr Ziel ist es, die Geschwindigkeit so zu optimieren, dass Sie die Taktzeit reduzieren, in der Sie Änderungen an die Nutzer weitergeben. So können Sie Ihre Hypothese so schnell wie möglich prüfen.

Häufige Probleme bei der Arbeitsaufteilung

Wenn Sie die Arbeit in kleine Batches aufteilen, können zwei Hindernisse auftreten:

  • Die Arbeit wurde in zu große Batches aufgeteilt. Ihre erste Aufgabe besteht darin, die Arbeit sinnvoll aufzuteilen. Wir empfehlen, Code unabhängig vom Status der Funktion zuzuweisen und für die Entwicklung einzelner Funktionen nicht mehr als ein paar Tage vorzusehen. Alle Code-Batches, deren Erledigung und Überprüfung mehr als eine Woche benötigen, sind zu groß. Während des gesamten Entwicklungsprozesses ist es wichtig, zu analysieren, wie Ideen in Schritte aufgeteilt werden können, die Sie iterativ entwickeln können.

  • Die Arbeit wird aufgeteilt, doch die Batches werden vor der Weiterleitung zum Testen oder zur Freigabe neu gruppiert. Durch die Umgruppierung verzögert sich das Feedback, ob die Änderungen fehlerhaft sind, und ob Ihre Nutzer und Ihre Organisation der Meinung sind, dass die Änderungen von Anfang an richtig waren.

Größe von Arbeitspaketen verringern

Wenn Sie Aufgaben in kleine Batches aufteilen, die innerhalb von Stunden abgeschlossen werden können, lassen sich diese Batches normalerweise in weniger als einer Stunde testen und für die Produktion bereitstellen (PDF). Es ist wichtig, die Arbeit in kleine Funktionen zu unterteilen, die eine schnelle Entwicklung ermöglichen, anstatt komplexe Funktionen für Zweige zu entwickeln, die dann nur selten freigegeben werden.

Wenn Sie die Entwicklung kleiner Batches verbessern möchten, prüfen Sie Ihre Umgebung und bestätigen Sie, dass die folgenden Bedingungen erfüllt sind:

  • Die Arbeit ist so aufgeteilt, dass Teams häufigere Produktionsfreigaben erteilen können.
  • Entwickler können die Arbeit in kleine Änderungen unterteilen, die sich innerhalb von Stunden und nicht innerhalb von Tagen abschließen lassen.

Wenn Sie Experte bei der Entwicklung der Arbeitsaufteilung werden möchten, müssen alle diese Bedingungen in allen Entwicklungsteams erfüllt sein. Diese Vorgehensweise ist für die kontinuierliche Integration und die Entwicklung nach Baumschema erforderlich.

Größe von Arbeitspaketen messen

Wenn Sie sich mit der kontinuierlichen Integration und dem Monitoring auskennen, können Sie Möglichkeiten zur Messung kleiner Batchentwicklungen in Ihren Systemen und Ihrer Entwicklungsumgebung beschreiben.

  • Anwendungsfunktionen werden so aufgeteilt, dass häufige Releases unterstützt werden. Wie oft sind Releases möglich? Wie unterscheidet sich dieser Releaserhythmus zwischen den Teams? Sind die Verzögerungen in der Produktion auf Funktionen zurückzuführen, die größer sind?
  • Anwendungsfunktionen werden so aufgeteilt, dass Entwickler die Arbeit in maximal einer Woche erledigen können. Welchen Anteil an Funktionen können Sie innerhalb einer Woche fertigstellen? Welche Funktionen können Sie nicht innerhalb einer Woche fertigstellen? Können Sie Änderungen übernehmen und freigeben, bevor die Funktion fertiggestellt ist?
  • MVPs werden als Ziele für Teams definiert und festgelegt. Wird die Arbeit in Funktionen aufgeteilt, die MVPs und eine schnelle Entwicklung ermöglichen anstatt zu komplexen und langwierigen Prozessen führen?

Ihre Beurteilung hängt von folgenden Faktoren ab:

  • Kenntnis der Prozesse Ihrer Organisation
  • Festlegung von Zielen für die Reduzierung von Verschwendung
  • Suche nach Möglichkeiten, die Komplexität im Entwicklungsprozess zu reduzieren

Weitere Informationen