Hallo Bewohner! Jedes Unternehmen möchte eine effizientere Softwareentwicklung erreichen, da sich dies direkt auf den Gewinn auswirkt. Ein Großteil der agilen Literatur richtet sich an große, wachstumsstarke Unternehmen. Was ist, wenn Ihr Unternehmen nicht an der Spitze der IT steht? Die gute Nachricht ist, dass jedes Unternehmen die Leistung verbessern kann. Dieses Buch hilft Ihnen dabei, bestimmte Wege und Lösungen zu finden, um Agile optimal zu nutzen. „Ich bin kein agiler Evangelist. Ich bin ein Befürworter dessen, was funktioniert, und ein Gegner dessen, was viel verspricht, aber keine Ergebnisse bringt. In diesem Buch wird die agile Methodik nicht als eine Bewegung vorgestellt, die ein gesteigertes Bewusstsein erfordert, sondern als eine Reihe spezieller Management- und technischer Methoden, deren Wirkung und Interaktion für jeden Geschäftsmann oder IT-Spezialisten verständlich sind.Agile Enthusiasten kritisieren dieses Buch möglicherweise dafür, dass es nicht für agile Best Practices wirbt. Aber das ist der Punkt - eine Betonung auf praktische Methoden, die sich als wirksam erwiesen haben. Die Geschichte von Agile steckt voller Ideen, die von einigen Enthusiasten in einigen Organisationen erfolgreich umgesetzt wurden, aber nicht von allen anderen genutzt werden können “, sagt Steve McConnell. Das neue Buch von Steve McConnell, Autor der legendären Bücher Code Complete und Software Estimation, vereint die realen Erfahrungen von Hunderten von Unternehmen. Verwenden Sie eine einfache, unkomplizierte Anleitung zu den modernen und effektivsten agilen Praktiken.die von einigen Enthusiasten in einigen Organisationen erfolgreich implementiert wurden, aber nicht von allen anderen verwendet werden “, sagt Steve McConnell. Das neue Buch von Steve McConnell, Autor der legendären Bücher Code Complete und Software Estimation, vereint die realen Erfahrungen von Hunderten von Unternehmen. Verwenden Sie eine einfache, unkomplizierte Anleitung zu den modernen und effektivsten agilen Praktiken.die von einigen Enthusiasten in einigen Organisationen erfolgreich implementiert wurden, aber nicht von allen anderen verwendet werden “, sagt Steve McConnell. Das neue Buch von Steve McConnell, Autor der legendären Bücher Code Complete und Software Estimation, vereint die realen Erfahrungen von Hunderten von Unternehmen. Verwenden Sie eine einfache, unkomplizierte Anleitung zu den modernen und effektivsten agilen Praktiken.
Noch effizientere Projektabwicklung
Im vorherigen Kapitel haben wir uns mit der Organisation und Unterstützung von Entwicklern bei der Arbeit in Agile befasst. In diesem Kapitel wird erläutert, wie Sie den Entwicklungsprozess bei der Arbeit in Agile ordnungsgemäß organisieren und warten.
Die meiste Softwareentwicklung ist in Projekten organisiert. Unternehmen verwenden eine Vielzahl von Begriffen, um projektbezogene Konzepte zu beschreiben, darunter Produkt, Programm, Release, Release-Zyklus, Funktion, Wertstrom, Workflow und mehr. ...
Die Terminologie variiert erheblich. Einige Unternehmen glauben, dass Release gleichbedeutend mit Projekt ist. Andere denken, Release bezieht sich auf fortschreitende Entwicklung, deshalb haben sie es nicht mehr verwendet. Wieder andere definieren das Konzept der "Funktion" als den Arbeitsaufwand für 3 bis 9 Personen und 1 bis 2 Jahre. In diesem Kapitel meine ich mit dem Wort "Projekt" eine der aufgelisteten Arten von Arbeit, dh die Arbeit einer bestimmten Anzahl von Mitarbeitern für eine lange Zeit.
Schlüsselprinzip: kleine Projektgrößen
In den letzten 20 Jahren die bekanntesten Fälle der erfolgreichen Anwendung von Agile in kleinen Projekten. In den ersten 10 Jahren seines Bestehens legte Agile großen Wert darauf, Projekte klein zu halten, dh 5 bis 10 Personen in einem Team (z. B. 3 bis 9 Entwickler, ein Product Owner und ein Scrum Master). Die Betonung der Größe kleiner Projekte ist sehr wichtig, da kleine Projekte einfacher zu handhaben sind als große, wie in Abb. 1 dargestellt. 9.1.
Capers Jones postuliert seit 20 Jahren, dass kleine Projekte erfolgreicher sind als große [Jones, 1991; 2012]. Ich habe die meisten Untersuchungen zum Projekterfolg im Verhältnis zur Größe in meinen Code Perfect-Büchern zusammengefasst [McConnell, 2004; SPb .: Peter, 2007] und Software Estimation: Demystifying the Black Art [McConnell, 2006].
Kleinere Projekte sind aus mehreren Gründen sicherer. Große Projekte erfordern die Einbeziehung von mehr Spezialisten, und die Anzahl der Beziehungen zwischen Personen in Teams und zwischen Teams selbst nimmt in einem nichtlinearen Verlauf zu. Und je komplexer die Beziehung wird, desto mehr Fehler werden in der Interaktion gemacht. Interoperabilitätsfehler führen zu Fehlern bei Anforderungen, Design, Codierung - im Allgemeinen bei anderen Fehlern.
Je größer das Projekt wird, desto mehr Fehler werden gemacht (Abbildung 9.2). Dies bedeutet nicht nur, dass die Gesamtzahl der Fehler wächst, sondern dass es bei großen Projekten unermesslich mehr Fehler gibt!
Je höher die Fehlerrate ist, desto geringer ist die Wirksamkeit der Fehlererkennungsstrategien. Dies bedeutet, dass die Anzahl der Mängel am fertigen Produkt überproportional zunimmt.
Es erfordert auch mehr Aufwand, um Fehler zu beseitigen. Daher ist, wie in Fig. 9.3, kleinere Projekte haben eine höhere Produktivität pro Person, aber je größer das Projekt, desto mehr Produktivität sinkt. Dieses Phänomen wird als Skalierungskosten bezeichnet.
Diese umgekehrte Beziehung zwischen Größe und Leistung wurde über 40 Jahre lang intensiv erforscht und getestet. Fred Brooks diskutierte die Kosten der Skalierung in der Softwareentwicklung in der ersten Ausgabe seines Buches The Mythical Man-Month [Brooks, 1975; SPb.: Peter, 2021]. Larry Putnams Arbeit zur Schätzung der Softwareentwicklungskosten hat Brooks 'Beobachtungen bestätigt [Putnam 1992]. Die Untersuchung des Entwicklungskostenmodells (Cocomo) bestätigte empirisch das Vorhandensein von Skalenkosten zweimal - in einer Studie aus den späten 1970er Jahren und in einer aktualisierten Studie aus den späten 1990er Jahren [Boehm, 1981; 2000].
Um die Wahrscheinlichkeit eines erfolgreichen agilen Projekts zu maximieren, sollten Sie versuchen, das Projekt (und das Team) klein zu halten.
Natürlich ist es unmöglich, jedes Projekt klein zu machen. In Kapitel 10, „Noch effizienter große Projekte ausführen“, werden Ansätze für große Projekte beschrieben, einschließlich Vorschläge für deren Verkleinerung.
Schlüsselprinzip: Kurze Sprints
Die natürliche Schlussfolgerung, dass kleine Projektgrößen vorzuziehen sind, ist, dass Sprints nicht lange dauern sollten. Sie könnten denken, dass ein kleines Projekt bereits ein Erfolgsrezept ist. Kurze Sprints von 1-3 Wochen tragen jedoch zu einem rundum erfolgreichen Projektmanagement bei. Dies wird in den nächsten Abschnitten beschrieben.
Kürzere Sprints reduzieren die Anzahl der Zwischenanforderungen und verbessern die Reaktionsfähigkeit auf neue Anforderungen.
In Scrum können zwischen den Sprints neue Anforderungen hinzugefügt werden. Sobald der Sprint gestartet ist, können Sie erst beim nächsten Sprint Anforderungen hinzufügen. Dies ist sinnvoll, wenn der Sprint 1–3 Wochen dauert.
Wenn Entwicklungszyklen länger dauern, fordern die Stakeholder immer eindringlicher dazu auf, Anforderungen hinzuzufügen, sodass Anfragen, das Hinzufügen von Anforderungen zu verschieben, nicht mehr so gerechtfertigt sind. Wenn der Zyklus mit einem sequentiellen Entwicklungsmodell sechs Monate dauert, bedeutet die Aufforderung an den Stakeholder, die Implementierung der neuen Anforderung auf den nächsten Zyklus zu verschieben, dass die Arbeit an der Anforderung erst im nächsten Zyklus beginnt - das heißt, zu Beginn des Zyklus wird diese Anforderung erst hinzugefügt, und Sie müssen am Ende auf die Lieferung des Produkts warten Zyklus. Im Durchschnitt dauert es 1,5 Zyklen, dh 9 Monate.
Im Gegensatz dazu dauern normale Scrum-Sprints zwei Wochen. Dies bedeutet, dass ein Stakeholder, der eine neue Anforderung hinzufügen möchte, durchschnittlich drei Wochen warten muss.
Es ist oft unangemessen, einen Stakeholder zu bitten, 9 Monate auf die Umsetzung einer Anforderung zu warten. Und drei Wochen sind fast immer angemessen. Dies bedeutet, dass das Scrum-Team ruhig arbeitet, ohne Angst vor neuen Anforderungen mitten im Sprint zu haben.
Kurze Sprints bieten eine bessere Reaktionsfähigkeit bei der Arbeit mit Kunden und Stakeholdern
Jeder Sprint bietet eine neue Gelegenheit, funktionierende Software zu präsentieren, Anforderungen zu validieren und Feedback von Stakeholdern zu generieren. Mit zweiwöchigen Standard-Sprints geben sich die Teams die Möglichkeit, 26 Mal im Jahr schneller zu sein! Bei einem dreimonatigen Entwicklungszyklus wird diese Gelegenheit nur viermal im Jahr angeboten. Vor fünfzehn Jahren galt ein dreimonatiges Projekt als kurz. Heutzutage bedeutet ein solcher Zeitplan, dass Sie nicht schnell auf Rückmeldungen von Stakeholdern, Kunden und dem Markt reagieren können.
Kurze Sprints stärken das Vertrauen der Stakeholder
Da Teams häufiger Ergebnisse liefern, werden die Fortschritte transparenter, sodass Fortschritte für die Stakeholder sichtbar sind, was das Vertrauen zwischen ihnen und dem Team stärkt.
Kurze Sprints beschleunigen die Entwicklung durch Lern- und Anpassungszyklen.
Je höher die Iterationsrate, desto mehr Möglichkeiten hat das Team, über die gewonnenen Erkenntnisse nachzudenken, Schlussfolgerungen zu ziehen und die Ergebnisse auf praktische Arbeitsmethoden anzuwenden. Die Gründe für diesen Bereich sind die gleichen wie für die Reaktionsfähigkeit der Kunden: Was ist besser, wenn Ihre Teams 26 Mal im Jahr oder nur vier Mal lernen und sich anpassen können? Kurze Sprints helfen Ihrem Team, sich schneller zu verbessern.
Kurze Sprints verkürzen die Experimentierzeit
Im Zusammenhang mit Cynefins Wirren Fragen müssen die Fragen zuerst untersucht werden, bevor der volle Umfang der Arbeit verstanden werden kann. Diese Forschung sollte wie folgt charakterisiert werden: "Um eine Antwort auf diese oder jene Frage zu erhalten, müssen Sie den geringsten Arbeitsaufwand leisten." Leider besagt das Parkinson-Gesetz, dass die Arbeit die gesamte verfügbare Zeit in Anspruch nimmt. Und bis das Team die Eisendisziplin entwickelt, wird die Lösung des Problems, wenn ein Monat dafür vorgesehen ist, genau einen Monat dauern. Wenn es jedoch nur zwei Wochen gibt, dauert die Lösung des Problems meistens zwei Wochen.
Kurze Sprints ermöglichen die rechtzeitige Erkennung von Kosten und Risiken
Mit kurzen Sprints können Sie den Fortschritt häufiger verfolgen. Nach nur wenigen Sprints wird bei der Arbeit an einer neuen Aufgabe die "Geschwindigkeit" des Teams oder das Tempo des Fortschritts bestimmt. Die Möglichkeit, den Arbeitsfortschritt zu überwachen, erleichtert die Vorhersage des Zeitpunkts der Produktfreigabe. Wenn die Arbeit länger dauert als ursprünglich geplant, wird dies in nur wenigen Wochen kristallklar. Kurze Sprints sind ein mächtiges Werkzeug, um auf dem Laufenden zu bleiben. Kapitel 20, "Noch bessere Vorhersagbarkeit", geht näher darauf ein.
Kurze Sprints fördern die Verantwortlichkeit des Teams
Wenn ein Team alle zwei Wochen für die Bereitstellung von Arbeitsfunktionen verantwortlich ist, hat es nicht die Möglichkeit, lange im Dunkeln zu arbeiten. Sie zeigt die Ergebnisse ihrer Arbeit bei Sprint-Review-Meetings und berichtet alle zwei Wochen an die Stakeholder.
Der Produktbesitzer sieht die Früchte der Arbeit noch häufiger.
Der Produktbesitzer akzeptiert die Arbeit oder lehnt sie ab, der Fortschritt der Arbeit ist deutlich sichtbar. Somit sind Teams besser für ihre Arbeit verantwortlich.
Kurze Sprints fördern die Verantwortlichkeit
Seit Generationen litten Entwicklungsteams monatelang unter "Sternen", die in einem dunklen Raum eingeschlossen waren, und es war völlig unklar, ob die Arbeiten voranschritten. Im Fall von Scrum besteht dieses Problem nicht mehr. Jeder unterstützt die Ziele des Teams im Sprint. Außerdem müssen Sie jeden Tag aufstehen und darüber sprechen, was gestern getan wurde - Sie können sich nicht mehr einsperren. Entweder beginnt der Entwickler zu kooperieren, wodurch das Problem auf eine Weise gelöst wird, oder er kann die Bedingungen nicht aushalten und verlässt das Team, das das Problem immer noch löst, wenn auch auf andere Weise. Aus eigener Erfahrung kann ich sagen, dass eines der Ergebnisse günstiger ist als in dem Fall, in dem jemand wochen- oder monatelang ohne Berichte arbeitet, und am Ende stellt sich heraus, dass nichts wirklich getan wurde.
Kurze Sprints fördern die Automatisierung
Da Teams häufig Abstimmungen durchführen, können kurze Sprints Aufgaben automatisieren, die sich sonst wiederholen und zeitaufwändig wären. Automatisierung ist in der Montage, Integration, Prüfung und statischen Code-Analyse weit verbreitet.
Kürzere Sprints sorgen eher für Zufriedenheit Ein
Team, das alle zwei Wochen funktionierende Software liefert, ist eher mit seiner Arbeit zufrieden und hat auch eher die Möglichkeit, seine Erfolge zu feiern. Dies trägt zu einem Gefühl der Professionalität bei, das die Motivation fördert.
Kurze Sprints. Zusammenfassung
Im Allgemeinen lassen sich die Vorteile von kurzen Sprints wie folgt zusammenfassen: "Die Liefergeschwindigkeit hilft in jeder Hinsicht, das Arbeitsvolumen zu bewältigen." Die Bereitstellung von Funktionen in kleinen Stapeln und kurzen Kadenzen bietet eine Vielzahl von Vorteilen gegenüber der Bereitstellung von Funktionen in großen Stapeln und langen Kadenzen.
Planen Sie basierend auf der Geschwindigkeit der Aufgaben
Story-Schwierigkeitsgrade sind ein Maß für die Größe und Komplexität einer Aufgabe. Die Geschwindigkeit ist ein Maß für den Fortschritt, basierend darauf, wie oft Aufgaben erledigt und in Einheiten mit Schwierigkeitsgrad gemessen werden. Bei der geschwindigkeitsbasierten Planung werden Arbeiten basierend auf den Schwierigkeitsgraden und der Arbeitsgeschwindigkeit geplant und nachverfolgt.
Geschwindigkeitsplanung und -verfolgung sind nicht Teil des Scrum-Tutorials, aber meiner Erfahrung nach wäre es eine gute Idee, sie einzubeziehen. Als nächstes werde ich darüber sprechen, wie Story-Schwierigkeitsgrade und Geschwindigkeitsschätzungen angewendet werden.
Schätzung der Größe des Product Backlogs
Die Schwierigkeitsbewertung wird verwendet, um die Größe des Produktrückstands zu bestimmen. Die Größe der Probleme im Produkt-Backlog wird normalerweise anhand der Schwierigkeitsgrade der Storys geschätzt. Anschließend werden die Komplexitätseinheiten der Storys hinzugefügt, um die Gesamtgröße des Product-Backlogs zu berechnen. Dies sollte zu Beginn des Release-Zyklus erfolgen und wenn Arbeit zum Backlog hinzugefügt oder daraus entfernt wird. Dies geschieht in dem Maße, in dem das Team vorhersehbar sein muss. Mehr dazu in Kapitel 20, "Noch bessere Vorhersagbarkeit".
Geschwindigkeitsberechnung
Der vom Team in jedem Sprint geleistete Arbeitsaufwand wird in Einheiten des Schwierigkeitsgrads der Geschichte berechnet. Die Anzahl der in jedem Sprint erreichten Story-Schwierigkeitsgrade entspricht der Geschwindigkeit des Teams. Die Geschwindigkeit wird basierend auf den Ergebnissen jedes Sprints berechnet, indem der Durchschnitt berechnet wird.
Sprint-Planung
Das Team plant den Arbeitsumfang pro Sprint, ebenfalls gemessen in Schwierigkeitsgraden, basierend auf Beobachtungen der Geschwindigkeit des Teams.
Wenn das Team durchschnittlich 20 Story-Schwierigkeitsgrade pro Sprint absolviert hat und sich im nächsten Sprint das Ziel gesetzt hat, 40 Story-Einheiten zu absolvieren, müssen sie ihre Pläne kürzen. Wenn ein Teammitglied in den Urlaub fährt oder mehrere Teammitglieder an Schulungsveranstaltungen teilnehmen, sollte das Team weniger Story-Schwierigkeiten pro Sprint einplanen als im Durchschnitt. Wenn es dem Team dank schlafloser Nächte und Arbeit am Wochenende gelungen ist, 20 Schwierigkeitsstufen der Geschichten zu erreichen, sollte auch die Messlatte gesenkt werden. Wenn Ihr Team konsequent und mühelos Sprintziele erreicht, planen Sie mehr Story-Schwierigkeiten als der Durchschnitt. In jedem Fall plant das Team basierend auf der tatsächlichen Geschwindigkeit.
Release verfolgen
Basierend auf der Durchschnittsgeschwindigkeit können Sie die Zeit berechnen oder vorhersagen, die zum Ausführen von Aufgaben im Product Backlog benötigt wird. Wenn das Produkt-Backlog 200 Story-Schwierigkeitsgrade hat und die durchschnittliche Geschwindigkeit des Teams 20 Story-Schwierigkeitsstufen pro Sprint beträgt, benötigt das Team 10 Sprints, um alle Aufgaben im Backlog zu erledigen. Weitere Informationen dazu finden Sie in Kapitel 20, "Noch bessere Vorhersagbarkeit".
Berücksichtigung der Auswirkungen von Änderungen im Prozess, der Teamzusammensetzung und anderen Änderungen
Basierend auf der Geschwindigkeit können Sie die Auswirkungen von Änderungen im Prozess, der Teamzusammensetzung und anderen Änderungen verfolgen. Die Einzelheiten hierzu werden in Kapitel 19, Prozess noch besser verbessern, erläutert.
Schlüsselprinzip: Produktlieferung in vertikalen Scheiben
Damit Sprints effektiv sind, muss das Team die Fähigkeit entwickeln, häufig kleine Mengen funktionaler Funktionen bereitzustellen. Der Entwurfsansatz, der dies erleichtert, wird als "Verwenden vertikaler Schichten" bezeichnet. Dies bedeutet, dass Änderungen an jeder Architekturebene vorgenommen werden, um ein Inkrement oder einen Wert zu erhalten.
Der vertikale Schnitt repräsentiert die gesamte Funktionalität des Stapels, z. B. das Hinzufügen eines Felds zu einem Kontoauszug oder das Beschleunigen der Transaktionsbestätigung eines Benutzers um eine Sekunde. Für jedes dieser Beispiele muss normalerweise der gesamte Technologie-Stack ausgeführt werden (siehe Abbildung 1). 9.4.
Vertikale Schichten helfen nichttechnischen Stakeholdern, den Geschäftswert besser zu verstehen, zu beobachten und zu messen. Sie geben dem Team die Möglichkeit, Releases schneller zu veröffentlichen, den tatsächlichen Wert des Produkts für das Unternehmen zu erkennen und echtes Feedback von den Benutzern zu erhalten.
Teams, die horizontale Scheiben verwenden, laufen Gefahr, mehrere Sprints hintereinander in den Dschungel zu stürzen und an Geschichten zu arbeiten, die einige Fortschritte widerspiegeln, aber keinen sichtbaren Geschäftswert bringen.
Teams zögern manchmal, vertikale Scheiben zu verwenden, normalerweise wegen geringerer Effizienz. Sie werden zum Beispiel argumentieren, dass es effizienter ist, mehr Arbeit in der Geschäftslogikschicht zu erledigen und dann zur Schnittstellenschicht überzugehen. Dieser Ansatz wird mit horizontalen Schichten bezeichnet.
In einigen Fällen kann es aus technischer Sicht effizienter sein, an horizontalen Schichten zu arbeiten, aber eine solche technische Effizienz führt in der Regel zur Optimierung einzelner Teile des Produkts, was nicht so wichtig ist wie die Erlangung wertvoller Funktionen. Entgegen der Behauptung, dass die Verwendung horizontaler Schnitte zu einer höheren Effizienz führt, hat unser Unternehmen festgestellt, dass viele Teams bei der Verwendung horizontaler Schnitte mit erheblichen Korrekturen konfrontiert sind.
Vertikale Slices bieten ein engeres Feedback Mit
vertikalen Slices können Sie Geschäftsbenutzern schnell Funktionen bereitstellen, sodass Sie schnell Feedback erhalten, wie die Funktionen ordnungsgemäß funktionieren.
Da vertikale Slices eine End-to-End-Entwicklung erfordern, müssen die Teammitglieder bei Design und Implementierung zusammenarbeiten, was dem gesamten Team nützliches technisches Feedback liefert.
Die Verwendung vertikaler Schnitte erleichtert auch End-to-End-Tests, wodurch ein enges Feedback gewährleistet wird.
Vertikale Slices bieten mehr Geschäftswert
Vertikale Slices werden von Stakeholdern, die die technischen Details nicht kennen, besser verstanden. Dies führt zu besseren Qualitätsentscheidungen, die das Unternehmen hinsichtlich der Priorität und Reihenfolge der Implementierung neuer und überarbeiteter Funktionen trifft.
Da vertikale Slices ein volles Funktionsinkrement bieten, bieten sie häufig die Möglichkeit, Benutzern Arbeitsfunktionen zu präsentieren, was den Geschäftswert erhöht.
Die Verwendung horizontaler Schichten führt dazu, dass Entwickler beginnen, Architektur als Produkt wahrzunehmen. Dies kann dazu führen, dass Aktivitäten belohnt werden, die für die Bereitstellung von Funktionen völlig unnötig sind, und dass andere Methoden zu einer Wertminderung führen.
Was ein Team benötigt, um vertikale Slices zu verwenden Die
Bereitstellung von Funktionen mit vertikalen Slices kann schwierig sein. Dies hängt von der Zusammensetzung des Teams, seinen Geschäfts-, Entwicklungs- und Testfähigkeiten ab, einschließlich der Fähigkeiten über den gesamten Technologie-Stack.
Möglicherweise müssen Teams auch ihr Design- und Implementierungsdenken ändern, um mit vertikalen Schichten zu arbeiten, die sich von der Arbeit mit Komponenten oder horizontalen Ebenen unterscheiden. Einige Teams verfügen nicht über Designfähigkeiten, um dies zu tun, und müssen Fähigkeiten entwickeln (und entwickeln), um damit fertig zu werden.
Schließlich müssen die Teams ihre Arbeit in vertikalen Schichten erledigen. Der Product Owner und das Entwicklungsteam müssen einen Ansatz finden, um den Rückstand so zu verfeinern, dass das Ergebnis vertikale Schichten sind.
Schlüsselprinzip: Verwalten von technischen Schulden
"Tech-Schulden" beziehen sich auf die Anhäufung von qualitativ schlechter Arbeit in der Vergangenheit, die das Arbeitstempo in der Gegenwart verlangsamt. Das klassische Beispiel ist eine fragile Codebasis, bei der jeder Versuch, einen Fehler zu beheben, eine oder mehrere neue generiert. Selbst das Beheben eines einfachen Fehlers ist zeitaufwändig und das Beheben zusätzlicher Fehler.
Technische Schulden können Code von geringer Qualität, Design von geringer Qualität, eine schwache Testsuite, einen schwierigen Designansatz, eine umständliche Build-Umgebung, langsame manuelle Prozesse und andere Möglichkeiten umfassen, mit denen ein Team die langfristige Leistung zugunsten kurzfristiger Gewinne opfert.
Folgen der technischen Verschuldung
Schulden entstehen normalerweise aufgrund des Drucks, kurzfristige Freisetzungen auf Kosten der Qualität zu priorisieren. Eine ganzheitliche Betrachtung der investierten Ressourcen und der erzielten Renditen umfasst die Berücksichtigung der Auswirkungen der technischen Verschuldung im Zeitverlauf.
Technische und geschäftliche Teams können zwingende Gründe haben, diese Schulden zu akkumulieren. Einige Veröffentlichungen sind zeitkritisch genug, um später zusätzliche Arbeiten zu rechtfertigen, da die Arbeit in der Gegenwart schneller erledigt werden soll.
Ein Modell, mit dem sich technische Schulden im Laufe der Zeit ansammeln können, ohne dass geplant ist, diese Schulden abzubauen, verringert letztendlich die Teamgeschwindigkeit. Das Team muss einen Schuldenmanagementplan entwickeln, um seine Geschwindigkeit aufrechtzuerhalten oder zu erhöhen.
Kruchten, Nord und Ozkaya haben ein hervorragendes Diagramm entwickelt, wie technische Schulden entstehen, welchen (wahrscheinlichen) Geschäftswert sie haben und wie sie letztendlich eher zu einer Verbindlichkeit als zu einem Vermögenswert werden (Abbildung 9.5).
Wenn Teams von Grund auf neu arbeiten, können sie in erster Linie vermeiden, technische Schulden zu machen. Bei bereits begonnenen Arbeiten haben die Teams oft keine andere Wahl, als mit den bereits angesammelten technischen Schulden zu arbeiten. Wenn das Team bei allen Arten von Arbeiten mit technischen Schulden nicht gut zurechtkommt, nimmt die Geschwindigkeit mit der Zeit ab.
Tilgung technischer Schulden
Verschiedene Teams verfolgen unterschiedliche Ansätze zur Tilgung technischer Schulden. Einige Teams verteilen die Schulden zur Tilgung in Aktien für jeden Entwicklungszyklus (Sprint oder Release). Andere Teams fügen dem Produktstau oder der Lückenliste Schulden hinzu und priorisieren die Schulden und den Rest der Arbeit. In jedem Fall ist das Hauptmerkmal, dass die technischen Schulden offen verwaltet werden.
Arten von Schulden und wie man damit umgeht
Nicht alle technischen Schulden sind gleich, und es gibt verschiedene Klassifikationen. Ich finde diese Kategorien nützlich:
- Vorsätzliche Verschuldung (kurzfristig). Schulden, die aus taktischen oder strategischen Überlegungen stammen, z. B. die rechtzeitige Freigabe einer zeitkritischen Freigabe.
- Vorsätzliche Verschuldung (langfristig). Schulden, die sich aus strategischen Überlegungen ergeben, z. B. die anfängliche Unterstützung einer einzelnen Plattform anstelle der plattformübergreifenden Unterstützung.
- Unbeabsichtigte Schulden (böser Glaube). Schulden, die zufällig aufgrund von Entwicklungsmethoden von schlechter Qualität entstehen. Diese Art der Verschuldung verlangsamt die Arbeit sowohl in der Gegenwart als auch in der Zukunft, daher sollte sie vermieden werden.
- Unbeabsichtigte Schulden (Treu und Glauben). Schulden, die zufällig aufgrund natürlicher Fehler in der Softwareentwicklung entstehen („Unser Designansatz hat nicht so gut funktioniert, wie wir es geplant hatten“ oder „Die neue Version der Plattform wies schwerwiegende Designfehler auf“).
- Vererbte Schulden. Schulden, die das neue Team von der alten Codebasis geerbt hat.
Tabelle 9.1 zeigt, welche Ansätze für die Reaktion auf diese Arten von Schulden empfohlen werden.
Vorteile der Diskussion über technische Schulden
Nach meiner Erfahrung war die Metapher „technische Schulden“ hilfreich, um Diskussionen zwischen Technikern und Geschäftsleuten zu erleichtern. Geschäftsleute wissen im Allgemeinen nicht, wie hoch die Kosten für die Tilgung technischer Schulden sind, und Techniker kennen die Geschäftsinteressen im Allgemeinen nicht. In einigen Fällen kann es eine gute Idee sein, absichtlich den Aufbau technischer Schulden zuzulassen, in anderen nicht. Schulden erleichtern den Meinungsaustausch über technische und geschäftliche Überlegungen und machen sie aussagekräftiger. Dies verbessert die Qualität der Entscheidungen darüber, wann und warum Schulden aufgenommen werden sollen und wann und wie sie zurückgezahlt werden sollen.
Bauen Sie Ihre Arbeitsstruktur auf, um Burnout zu vermeiden
Die puristische Sichtweise von Agile geht von derselben Sprintdauer aus (bekannt als „geteilte Trittfrequenz“). Wenn das Team mit der Gesamtkadenz gut zurechtkommt, macht es keinen Sinn, Änderungen vorzunehmen. Gemeinsame Kadenzen erleichtern die Berechnung der Geschwindigkeit und anderer Faktoren bei der Planung eines Sprints.
Eine häufige Beschwerde bei der Implementierung von Scrum ist, dass eine endlose Folge von Sprints zu Müdigkeit und dem Gefühl führt, im Rad zu laufen. Bei konsequenter Entwicklung kommt es zu natürlichen Leistungsmängeln, insbesondere zwischen den Disziplinen, sowie zu einem Ausgleich in Zeiten hoher Intensität.
Konstante Sprints lassen keine Zeit für Ruhe, wenn jeder Sprint tatsächlich im Sprinttempo läuft.
Eines der Gegenmittel gegen Müdigkeit nach Sprints ist die Änderung der Sprintdauer nach Bedarf. Der systematische Weg, dies zu tun, besteht darin, ein 6x2x1-Muster, sechs Sprints von zwei Wochen plus einen Sprint von einer Woche für insgesamt 13 Wochen zu verwenden, was genau einem Viertel entspricht.
Eine Alternative dazu wäre die Verwendung verkürzter Sprints nach größeren Veröffentlichungen, an Feiertagen und zu anderen Zeiten, wenn die Geschwindigkeit des Teams immer noch nicht stabil ist. Während eines einwöchigen Sprints arbeitet ein Team möglicherweise an Infrastruktur oder Tools, nimmt an Vorbereitungs- oder Teamevents, Hackathons, technischen Schulden, Verbesserungen teil, die zu groß sind, um in einem Sprint abgeschlossen zu werden, oder an etwas anderem.
Die unterschiedliche Länge der Sprint-Trittfrequenz steht im Einklang mit dem in Agile verwendeten Konzept des anhaltenden Tempos. Viele agile Forschungen setzen ein gleichmäßiges Tempo mit einem Mangel an freien Abenden und Wochenenden gleich. Aber ich denke, dies ist eine ärgerliche Vereinfachung, die Unterschiede in den Präferenzen für die Arbeitsbedingungen verschiedener Menschen ignoriert. Einige schlagen eine 40-stündige Arbeitswoche als gleichmäßiges Tempo vor, für andere ist es ein Weg zur Langeweile. Persönlich habe ich den größten Teil meiner besten Arbeit im Sprengstoffmodus geleistet - 55 Stunden über zwei Wochen und dann 30 Stunden über die nächsten zwei Wochen. Im Durchschnitt können ungefähr 40 Arbeitsstunden pro Woche geleistet werden, aber verschiedene Teams haben nicht immer 40 Arbeitsstunden. Das Verständnis eines gleichmäßigen Tempos ist für jeden anders.
Andere Überlegungen
Off-Design-Softwareentwicklung Trotz
der vielen Definitionen am Anfang dieses Kapitels ist nicht jede Softwareentwicklung in Projekten organisiert. Manchmal gibt es Situationen, in denen normalerweise eine Person arbeitet. Beispielsweise ist es üblich, technische Supportanrufe zu bearbeiten, Release-Probleme zu lösen, Patches zu erstellen und dergleichen.
Diese Arbeit bezieht sich natürlich auf die Softwareentwicklung und eignet sich auch für agile Praktiken. Sie können durch die Einführung praktischer agiler Methoden wie Lean Manufacturing und Kanban effizienter, qualitativ und methodisch durchgeführt werden. Nach meiner Erfahrung haben Unternehmen jedoch weitaus weniger Probleme mit dieser Art von Arbeit als mit der projektweiten Softwareentwicklung. Daher konzentriert sich dieses Buch eher auf die Arbeit an Projekten als auf die Ad-hoc-Arbeit.
Empfehlungen
Studie:
- Überprüfen Sie den Verlauf der Projektsummen. Entspricht die Erfahrung Ihres Unternehmens der allgemeinen Auffassung, dass kleine Projekte eher erfolgreich sind als große?
- Durchsuchen Sie Ihr Projektportfolio. Welches Ihrer großen Projekte kann in mehrere kleinere Projekte unterteilt werden?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»Weitere Details zum Buch finden Sie auf der Website des Verlags.
» Inhaltsverzeichnis
» Auszug
für Einwohner 25% Rabatt auf den Gutschein - Agil
Nach Zahlung der Papierversion des Buches wird ein E-Book an die E-Mail gesendet.