Qgelm

Agile Softwareentwicklung: Entwickler und Controller gehören an einen Tisch

<html> <header class=„article-header“><h1 class=„articleheading“>Agile Softwareentwicklung: Entwickler und Controller gehören an einen Tisch</h1><div class=„publish-info“> Stefan Adolf</div></header><figure class=„aufmacherbild“><img src=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/4/1/5/8/4/playmobil_Sitzung_Beirat_Gremium_Konferenz-ceb62c78e9b78c28.jpeg“ srcset=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/4/1/5/8/4/playmobil_Sitzung_Beirat_Gremium_Konferenz-ceb62c78e9b78c28.jpeg 700w, https://heise.cloudimg.io/width/1050/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/4/1/5/8/4/playmobil_Sitzung_Beirat_Gremium_Konferenz-ceb62c78e9b78c28.jpeg 1050w, https://heise.cloudimg.io/width/1500/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/4/1/5/8/4/playmobil_Sitzung_Beirat_Gremium_Konferenz-ceb62c78e9b78c28.jpeg 1500w, https://heise.cloudimg.io/width/1920/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/4/1/5/8/4/playmobil_Sitzung_Beirat_Gremium_Konferenz-ceb62c78e9b78c28.jpeg 1920w“ alt=„5 Playmobil-Figuren um einen runden Tisch“ class=„img-responsive“ referrerpolicy=„no-referrer“ /></figure><p><strong>Mit agiler Softwareentwicklung und Controlling sollen Projekte reibungslos ablaufen. In der Praxis geht das aber häufig schief – warum eigentlich?</strong></p><p>Klassisches Controlling und agile Development-Methoden entstammen unterschiedlichen Welten, verfolgen aber grundsätzlich dasselbe Ziel: Softwareentwicklungsprojekte detailliert planen und flexibel aussteuern. In der Praxis erweist sich das Zusammenspiel aufgrund der unterschiedlichen Ansätze aber häufig als schwierig. Viel zu oft laufen Aufwand und Kosten aus dem Ruder, obwohl das Coding in kleinen, agilen Schritten stattfindet und dank regelmäßiger Meetings scheinbar jedes Problem besprochen wird. Was läuft da schief und wie lässt sich das verhindern?</p><p>Dass Projekte egal welcher Art und Größe von einer soliden Planung profitieren, wissen sowohl Projektmanager als auch Entwicklerinnen und Entwickler. Jedoch ist die jeweilige Herangehensweise durchaus verschieden. Die Anforderungen kommen aus unterschiedlichen Richtungen, und nicht zuletzt gehen auch die Meinungen darüber auseinander, wann ein erreichtes Ergebnis als gut bewertet werden kann. Das führt häufig zu einer unüberschaubaren Lage – ein Blick auf die Details verrät, warum.</p><h3 class=„subheading“ id=„nav_trotz_agiler0“>Trotz agiler Entwicklung werden Probleme zu spät erkannt</h3><p><a href=„https://www.heise.de/thema/Agile-Softwareentwicklung“><strong>Agile Development-Methoden [1]</strong></a> haben die Art und Weise, wie Software entwickelt wird, in den letzten Jahren entscheidend verändert. Auch wenn nicht in jedem Unternehmen ausschließlich Scrum Master und Agile Coaches für die Strukturierung der Entwicklungsprojekte verantwortlich sind, ist die von Major Releases getriebene Softwareentwicklung in der unternehmerischen Praxis kaum noch anzutreffen. Und das hat gute Gründe: Agile Methoden sind effizienter, transparenter und führen schneller zu verwertbaren Ergebnissen.</p><p>Im Wesentlichen geht es darum, durch iterative Schritte, Code Reviews und Tests potenzielle Fehlerquellen früher zu erkennen und entsprechend gegenzusteuern. So werden zu Beginn Projektvisionen klar ausformuliert, Anforderungen katalogisiert und Aufgaben priorisiert. In regelmäßigen Meetings diskutiert das Team möglichst alle Details der in kleinere Stücke zerlegten Projekte – von Akzeptanzkriterien über Integrationsanforderungen bis hin zu Umsetzungsschwierigkeiten.</p><p>Wieso passiert es trotzdem, dass die Verantwortlichen oft erst spät im Verlauf des Projektes Budget- und Zeitengpässe erkennen? Das Problem liegt meist nicht bei der Entwicklung, sondern vielmehr an deren ungenügender Integration ins Gesamtprojekt. Denn während DevOps-Initiativen versuchen, Entwicklung und Betrieb schon früh eng miteinander zu verzahnen, um spätere Operations-Anforderungen von Beginn an in den Entwicklungsprozess einfließen zu lassen, finden sich entsprechende Initiativen auf der Business-Seite eher selten. Mit anderen Worten: Entwicklerinnen und Entwickler gestalten Software heute zumeist mit klar definiertem Scope, maßgeschneidert für die Kundenanforderungen. Jedoch sitzen sie in den seltensten Fällen von Beginn an mit am Planungstisch – obwohl das sinnvoll wäre, denn ihre Einschätzungen und bevorzugten Herangehensweisen können sowohl Zeit- als auch Kostenpläne entscheidend beeinflussen. Allzu oft beschränkt sich das gewünschte Feedback auf die Anzahl der benötigten Sprints. Das greift allerdings zu kurz, denn die Softwareentwicklung ist ein kreativer Prozess, der sich schwer planen oder in enge Vorgaben pressen lässt – zumindest dann nicht, wenn der Anspruch an die Qualität der Software hoch ist.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Lesen Sie auch</header><div class=„a-boxtarget a-boxcontent“ data-collapse-target=„“><article class=„a-article-teaser a-article-teaser–horizontal-layout article-teaser–articlebox a-u-no-margin-bottom a-theme“ data-cid=„0“><a class=„a-article-teaserlink“ data-google-interstitial=„false“ href=„https://www.heise.de/ratgeber/Agile-Softwareentwicklung-Auf-welche-Arten-Agilitaet-schiefgehen-kann-5054837.html“ name=„meldung.newsticker.inline.article-teaser.1“ title=„Agile Softwareentwicklung: Auf welche Arten Agilität schiefgehen kann“><figure class=„a-article-teaserimage-container“><div><strong><img alt=„“ height=„1031“ src=„https://static.wallabag.it/7862d1b7aff4c3b00f37212fefade4e0e2c4cf00/64656e6965643a646174613a696d6167652f7376672b786d6c2c253343737667253230786d6c6e733d27687474703a2f2f7777772e77332e6f72672f323030302f7376672725323077696474683d273639367078272532306865696768743d2733393170782725323076696577426f783d2730253230302532303639362532303339312725334525334372656374253230783d273027253230793d27302725323077696474683d27363936272532306865696768743d273339312725323066696c6c3d27253233663266326632272533452533432f726563742533452533432f737667253345/“ class=„c1“ width=„1834“ referrerpolicy=„no-referrer“ /></strong></div></figure><div class=„a-article-teasercontent-container“><header><h1 class=„a-article-teasertitle a-u-mb-1“><strong>Agile Softwareentwicklung: Auf welche Arten Agilität schiefgehen kann</strong></h1></header></div>[2]</a></article></div><h3 class=„subheading“ id=„nav_technical_debt1“>Technical Debt definieren und einpreisen</h3><p>Es ist unvermeidlich, dass Softwareprojekte im Laufe der Zeit <a href=„https://www.heise.de/developer/artikel/Technische-Schulden-entstehen-einfach-so-3969279.html“><strong>Technical Debt (technische Schulden) anhäufen [3]</strong></a>. Bedingt durch Projektziel und Geschwindigkeit lassen sich im Prozess trotz überzeugender Vorteile nicht immer vollständige Testabdeckung, automatisiertes Testing, vollautomatische Main-Deployments und eine clevere Architektur sowie die reibungslose Orchestrierung von Updates aller Komponenten gewährleisten. Um ein schnell wachsendes Projekt später zu stabilisieren, müssen solche Aufgaben unweigerlich nachgeholt werden.</p><p>Da sich technische Schulden nicht vermeiden lassen, gilt es für das Controlling, sie einzupreisen und bei der regelmäßigen und mittelfristigen Planung zu berücksichtigen. Im Idealfall räumen Projektverantwortliche Entwicklerinnen und Entwicklern regelmäßige Sprints ein, um den Schuldenberg abzutragen. Wer das nicht tut, riskiert ein zunehmend instabiles System, das sich schwerer verändern und erweitern lässt. Je konsequenter und liberaler das Controlling technische Schulden behandelt, desto leistungsfähiger agiert das Entwicklerteam im langfristigen Projektverlauf. Auftretende Probleme lassen sich beseitigen, ohne das gesamte Projekt aus der Bahn zu werfen.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Lesen Sie auch</header><div class=„a-boxtarget a-boxcontent“ data-collapse-target=„“><article class=„a-article-teaser a-article-teaser–horizontal-layout article-teaser–articlebox a-u-no-margin-bottom a-theme“ data-cid=„0“><a class=„a-article-teaserlink“ href=„https://www.heise.de/hintergrund/Fachliche-Schulden-als-Kontrapunkt-zu-Technical-Debt-4284588.html“ name=„meldung.newsticker.inline.article-teaser.1“ title=„Fachliche Schulden als Kontrapunkt zu "Technical Debt"“><figure class=„a-article-teaserimage-container“><div><strong><img alt=„Fachliche Schulden als Kontrapunkt zu "Technical Debt"“ height=„1726“ src=„https://static.wallabag.it/7862d1b7aff4c3b00f37212fefade4e0e2c4cf00/64656e6965643a646174613a696d6167652f7376672b786d6c2c253343737667253230786d6c6e733d27687474703a2f2f7777772e77332e6f72672f323030302f7376672725323077696474683d273639367078272532306865696768743d2733393170782725323076696577426f783d2730253230302532303639362532303339312725334525334372656374253230783d273027253230793d27302725323077696474683d27363936272532306865696768743d273339312725323066696c6c3d27253233663266326632272533452533432f726563742533452533432f737667253345/“ class=„c2“ width=„3071“ referrerpolicy=„no-referrer“ /></strong></div></figure><div class=„a-article-teasercontent-container“><header><h1 class=„a-article-teasertitle a-u-mb-1“><strong>Fachliche Schulden als Kontrapunkt zu „Technical Debt“</strong></h1></header></div>[4]</a></article></div><h3 class=„subheading“ id=„nav_developer2“>Developer gehören ins Planungsteam</h3><p>Entwicklerinnen und Entwickler sind längst mit dafür verantwortlich, dass Kunden die gewünschten Features in der Form bekommen, die sie möchten. Der agile Ansatz umfasst die frühe und kontinuierliche Auslieferung von Software, Offenheit gegenüber Änderungswünschen in jeder Projektphase – wenn diese vorteilhaft für die Kunden sind –, ständige Rücksprache mit allen Beteiligten, wie beispielsweise den Fachabteilungen, die die Software als Kunden in Auftrag gegeben haben.</p><p>In der Praxis werden Entwicklerteams meist aber erst später im Prozess eingebunden, sodass bei ihnen häufig das Gefühl aufkommt, die Planung erfolge von oben herab und die Kunden könnten sich wünschen, was sie wollen – weil sie ja schließlich dafür bezahlen. Unter solchen Bedingungen neigen auch Entwicklerinnen und Entwickler, die sich agile Methoden auf die Fahnen geschrieben haben, dazu, nur noch Dienst nach Vorschrift zu leisten und stumpf alle Aufgaben abzuarbeiten. Das führt in der Regel zu Frustration und wenig zufriedenstellenden Ergebnissen.</p><p>Die wichtigste Konsequenz aus diesen Überlegungen ist, das Development-Team von Beginn an vollständig miteinzubeziehen. Wenn diejenigen, die das Projekt maßgeblich umsetzen sollen, bereits Zeit- und Budgetplanung mitverantworten, ergeben sich klarere Rahmenbedingungen für die Umsetzungsphase. So können außerdem die Erkenntnisse der agilen Meetings des Dev-Teams in die Gesamtplanung zurückfließen. Wenn sich beispielsweise die Herausforderung ergibt, weitere Sprints oder Code Reviews einzufügen oder unvorhergesehene Inkompatibilitäten auflösen zu müssen, kann sich das gesamte Projekt verzögern. Erfolgt jedoch die Rückkopplung aus dem Entwicklerteam direkt mit den Business-Verantwortlichen, lässt sich unmittelbarer nachsteuern oder zumindest rechtzeitig umplanen.</p><h3 class=„subheading“ id=„nav_was_kann3“>Was kann Controlling und was nicht?</h3><p>Die Rückkopplung sollte fachlicher Natur sein: Wo muss beispielsweise nachgebessert werden, damit sich die Anforderungen der Kunden effizient umsetzen lassen? Welche technischen Spezifikationen sind zu überdenken? Softwareprojekte unterliegen allerdings wie andere Projekte dem anfangs definierten Zeit- und Budgetrahmen. Dessen Einhaltung zu gewährleisten, ist die Kernaufgabe des Controllings, die üblicherweise über die reine „Kontrolle“ hinausgeht. Viele Unternehmen verstehen Controlling jedoch nur als Kontrollmechanismus, der an bestimmten Meilensteinen prüft, wie viel Budget das Projekt bereits verschlungen hat und ob der Zeitplan eingehalten werden kann. Das ist jedoch zu kurz gedacht, denn Controlling kann mehr.</p><p>Projektbeteiligte sollte das Controlling eher als Steuerungsfunktion verstehen und nutzen. Nach der Anfangsplanung gehört es zu den Aufgaben des Controllers, den Projektfortgang laufend zu analysieren und, falls sich generelle Engpässe oder Veränderungen ergeben, entgegenwirkende Maßnahmen vorzuschlagen. Wichtig dabei ist, nicht nur den Status quo des Budget- und Zeitverbrauchs zu betrachten, sondern auch weitere Informationen zu sammeln. Hier schließt sich der Kreis: Je enger das Entwicklerteam und alle anderen Projektbeteiligten mit dem Controlling zusammenarbeiten, umso effizienter lässt sich der Projektverlauf steuern.</p><p>Ist beispielsweise frühzeitig absehbar, dass die Entwicklung wegen unterschätztem Integrationsaufwand länger dauert als geplant, muss dies nicht zwingend in mehr Zeitdruck für die Entwicklerinnen und Entwickler oder gar eine Verschiebung der Auslieferung münden. Das Controlling könnte auch zu dem Ergebnis kommen, dass es insgesamt vorteilhafter ist, zusätzliche Entwicklerkräfte in das Projekt einzubeziehen – oder andere Projekte mit geringerer Priorität vorübergehend zurückzustellen. Auch lassen sich die Kosten für ein benötigtes Tool gegebenenfalls als Effizienz-Maßnahme begreifen, die das gesamte Projekt voranbringt, und nicht als zusätzlichen Kostenaufwand. Solche Entscheidungen können Controller aber nur treffen, wenn sie frühzeitig und umfassend informiert sind.</p><h3 class=„subheading“ id=„nav_microcontrolling4“>Microcontrolling, ohne den kreativen Raum einzuengen</h3><p>Wie kleinteilig muss das Controlling sein? Es gilt, die Balance zwischen harten Zahlen, Fakten und Steuerungsmaßnahmen auf der einen Seite und kreativem Freiraum für die <a href=„https://www.heise.de/thema/Softwareentwicklung“><strong>Softwareentwicklung [5]</strong></a> auf der anderen Seite zu wahren. Während zu viel Planung behindert, engt zu viel Standardisierung ein. Manche Probleme lassen sich nur mit kreativem Coding und flexiblen Methoden lösen. Die Bereitschaft, Dinge auch auf andere Weise anzugehen, gehört zum modernen Software-Engineering. Gerade in Zeiten der Containerisierung und des Cloud Deployments stehen viele Tools, Optionen und Workarounds zur Verfügung. Warum nicht auch einmal in der Gruppe vor dem Bildschirm sitzen und über Einzelheiten im Quellcode oder die richtige Interpretation von StackOverflow-Antworten diskutieren – wie es beim Mob-Programming vorgesehen ist. Den dafür nötigen Freiraum dürfen Controlling-Kriterien nicht zu stark einengen oder gar ausschließen.</p><p>In den agilen Entwicklungsprozess integriertes Microcontrolling empfiehlt sich als praktikabler Lösungsansatz. Die Idee dabei ist, die Variablen, die insbesondere für das Controlling wichtig sind, beim täglichen Ausbalancieren des Entwicklungsprozesses einzubeziehen. Wenn also das Dev-Team im Scrum-Meeting Sprints umplant oder Änderungen am Product-Backlog vornehmen muss, sollten auch die Auswirkungen auf die Zeit- und Kostenplanung beziffert werden – und zwar möglichst genauso kleinteilig, wie es für den Coding-Prozess erfolgt. Denn wenn sich im Sprint-Review ergibt, dass ein zusätzlicher Sprint angehängt oder weitere Anpassungen umgesetzt werden müssen, dann verschiebt sich alles Nachfolgende. Sobald es Entwicklerinnen und Entwicklern gelingt, solche Aspekte standardmäßig in ihre Planung zu integrieren und mit dem Controlling abzustimmen, lassen sich Abweichungen früher erkennen. Das wiederum erleichtert sinnvolles Gegensteuern, ohne die gesamte Planung über den Haufen werfen zu müssen.</p><h3 class=„subheading“ id=„nav_erwartungs_und5“>Erwartungs- und Anforderungsmanagement: den Auftraggeber stärker einbinden</h3><p>Sprint-Reviews sind eine Gelegenheit – und im Sinne der Methode auch dafür vorgesehen –, sämtliche Stakeholder eines Projektes an einen Tisch zu bringen. Auftraggeber und Nutzer können Features testen und ihre Funktionalität sowie praktische Anwendbarkeit beurteilen. In den Reviews treten regelmäßig gerade jene Probleme zutage, die nur im Zusammentreffen der verschiedenen Disziplinen entdeckt werden. Ein typisches Beispiel dafür ist eine Funktion in der Software, die auf dem Papier alle definierten Kriterien erfüllt, bei Anwenderinnen und Anwendern aber durchfällt, weil sie den entsprechenden Button nicht finden. Denn den hat das Entwicklerteam zwar an einer technisch sinnvollen, aber aus Sicht einer optimalen User Experience (UX) wenig geeigneten Stelle platziert. Dann entscheidet das Feedback in den Sprint-Reviews darüber, wie es weitergeht – mit den beschriebenen Auswirkungen auf die Dauer und die Kosten des Gesamtprojekts.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Lesen Sie auch</header><div class=„a-boxtarget a-boxcontent“ data-collapse-target=„“><article class=„a-article-teaser a-article-teaser–horizontal-layout article-teaser–articlebox a-u-no-margin-bottom a-theme“ data-cid=„0“><a class=„a-article-teaserlink“ data-google-interstitial=„false“ href=„https://www.heise.de/hintergrund/Requirements-Engineering-in-der-agilen-Softwareentwicklung-4617665.html“ name=„meldung.newsticker.inline.article-teaser.1“ title=„Requirements Engineering in der agilen Softwareentwicklung“><figure class=„a-article-teaserimage-container“><div><strong><img alt=„Requirements Engineering im agilen Umfeld“ height=„2104“ src=„https://static.wallabag.it/7862d1b7aff4c3b00f37212fefade4e0e2c4cf00/64656e6965643a646174613a696d6167652f7376672b786d6c2c253343737667253230786d6c6e733d27687474703a2f2f7777772e77332e6f72672f323030302f7376672725323077696474683d273639367078272532306865696768743d2733393170782725323076696577426f783d2730253230302532303639362532303339312725334525334372656374253230783d273027253230793d27302725323077696474683d27363936272532306865696768743d273339312725323066696c6c3d27253233663266326632272533452533432f726563742533452533432f737667253345/“ class=„c3“ width=„3744“ referrerpolicy=„no-referrer“ /></strong></div></figure><div class=„a-article-teasercontent-container“><header><h1 class=„a-article-teasertitle a-u-mb-1“><strong>Requirements Engineering in der agilen Softwareentwicklung</strong></h1></header></div>[6]</a></article></div><p>Andererseits haben dadurch auch Entwicklerinnen und Entwickler die Möglichkeit, ihrerseits auf erforderliche Anpassungen aufmerksam zu machen. Nicht selten schließen technische Notwendigkeiten bestimmte Funktionen gänzlich aus oder verändern sie so stark, dass die Nutzer unzufrieden sind. In der gemeinsamen Diskussion lässt sich Verständnis aufbauen und – in den meisten Fällen – eine angemessene oder sogar bessere, neue Lösung finden. Beinahe automatisch entwickelt sich dabei ein aktiv gelebtes Erwartungs- und Anforderungsmanagement: eine Balance zwischen dem Gewünschten und dem Möglichen – stets unter der Beobachtung des Controllings.</p><h3 class=„subheading“ id=„nav_so_früh_wie6“>So früh wie möglich „positiv enttäuschen“: Softwareprojekte wieder auf Kurs bringen</h3><p>Dabei müssen Controller vor allem im Auge behalten, dass das <a href=„https://www.heise.de/thema/Projektmanagement“><strong>Projektmanagement [7]</strong></a> nicht zu agil über alle Planungsgrenzen hinweg arbeitet, damit sich die Auswirkungen von Änderungen im Projekt möglichst frühzeitig quantifizieren und mit der Gesamtplanung in Einklang bringen lassen. Unumgänglich ist, dass das Controlling auch bremsend eingreift. Wenn beispielsweise der Aufwand für eine neue, erweiterte Funktion im Verhältnis zum Nutzen zu groß wird, muss es die Möglichkeit geben, abzubrechen und einen neuen Ansatz zu entwerfen.</p><p>Je früher im Projektverlauf das geschieht, umso besser: Auch wenn solche Einschnitte sich im ersten Moment wie eine Enttäuschung oder Einschränkung anfühlen, bewahren sie das Gesamtprojekt häufig vor schlimmeren Folgen. Oft treten im Projektalltag Probleme erst zutage, wenn sie bereits hohen Aufwand und entsprechende Kosten verursacht haben. Häufig ist es dann zu spät, die Dinge zurückzurollen. Viel Arbeit ist vergebens getan, schlimmstenfalls muss das Projekt eingestellt werden. Frühes „positives Enttäuschen“ kann das verhindern. Mit geeigneten strategischen, organisatorischen und technischen Maßnahmen – von der Anpassung der Anforderungen über die Aufstockung der Ressourcen bis hin zum Erwerb weiterer Tools oder geeigneter Infrastruktur – lässt sich das Projekt besser aussteuern.</p><h3 class=„subheading“ id=„nav_gemeinsam7“>Gemeinsam stärker</h3><p>Agile Entwicklungsmethoden eignen sich gut, um das Projekt-Controlling granular und praxisnah umzusetzen. Voraussetzung ist allerdings, dass alle Stakeholder von Beginn an an einem Tisch sitzen und gemeinsam die Anforderungen und die Aufwandsplanung unter einen Hut bringen.</p><ul class=„rtelist rtelist–unordered“><li>Entwicklerinnen und Entwickler gehören ebenso wie die Fachabteilungen (beziehungsweise die Kunden) und Vertreter des Controllings ins Kernteam für die Planung und Budgetierung.</li><li>Microcontrolling bedeutet, Controlling in die einzelnen Teilphasen des Entwicklungsprozesses einzubinden: Wenn in jedem Entwickler-Meeting die Auswirkungen auf Kosten und Ressourcen bedacht und geplant werden, lassen sich frühzeitig steuernde Maßnahmen ergreifen.</li><li>Die technischen Schulden des Projekts müssen in der Planungsphase erhoben, eingeplant und budgetiert werden, damit sie nicht das Projekt in Verzug bringen.</li><li>Die in der Praxis üblichen Zeiträume zwischen definierten Meilensteinen sind für ein sinnvolles Microcontrolling zu lang. Sinnvoller ist es, tägliche Status-Updates zu erstellen, um den Zeit- und Kostenaufwand für alle Teil- und Unteraufgaben zu erfassen und den Restaufwand zu kalkulieren.</li><li>Auftraggeber sollten ebenso eng in alle Phasen eingebunden sein. Das schafft Verständnis für die Abhängigkeiten des jeweils anderen, vermeidet Missverständnisse und erleichtert Anpassungen des Produkts.</li><li>Eingefahrene Kommunikationsprozesse gilt es regelmäßig kritisch zu hinterfragen. Kollaborations-Tools sind in der Praxis oft weniger sinnvoll als gedacht. Es lohnt sich, zu überprüfen, ob die bestehenden Prozesse effizient sind, und ob sich Tools so nutzen lassen, dass sie Zeit sparen, statt zusätzliche Kosten zu verursachen.</li></ul><p>Ein agiler Prozess ist immer nur so agil wie sein am wenigsten dynamischer Teilnehmer. Der Sinn hinter <a href=„https://www.heise.de/thema/Scrum“><strong>Werkzeugen wie Scrum [8]</strong></a> ist es nicht, aus Entwicklerarbeit Burndown-Charts zu erstellen. Es geht vielmehr um die Beteiligung aller Stakeholder, mit Rücksicht auf die jeweiligen Bedürfnisse und Aufgaben: Entwicklerinnen und Entwickler brauchen Freiräume, um schwierige Probleme zu lösen – sowohl im zeitlichen Ablauf als auch bei der Wahl ihrer Werkzeuge.</p><p>Softwareentwicklung bleibt bei allem notwendigen Controlling eine kreative, schwer planbare Aufgabe. Zugleich müssen Auftraggeber und Projektcontroller in der Lage sein, Zwischenergebnisse detailliert nachzuvollziehen, um Anforderungen gegebenenfalls zu überdenken und neu zu priorisieren. Dann gelingt es, gemeinsam eine Software zu entwickeln, die ein bestmöglicher Kompromiss aus Erwartetem und technisch Machbarem ist und die weder den Zeit- noch den Budgetrahmen sprengt.</p><p><em>Stefan Adolf<br />ist Developer Ambassador bei Turbine Kreuzberg. Als Fullstack-Entwickler mit Schwerpunkt auf Applikationen, IoT und Integration ist die Kommunikation mit der Developer-Community seine primäre Aufgabe.</em></p><p>() </p><hr /><p><strong>URL dieses Artikels:</strong><br /><small>

https://www.heise.de/-6144036

</small></p><p><strong>Links in diesem Artikel:</strong><br /><small>

<strong>[1]</strong>&#160;https://www.heise.de/thema/Agile-Softwareentwicklung

</small><br /><small>

<strong>[2]</strong>&#160;https://www.heise.de/ratgeber/Agile-Softwareentwicklung-Auf-welche-Arten-Agilitaet-schiefgehen-kann-5054837.html

</small><br /><small>

<strong>[3]</strong>&#160;https://www.heise.de/developer/artikel/Technische-Schulden-entstehen-einfach-so-3969279.html

</small><br /><small>

<strong>[4]</strong>&#160;https://www.heise.de/hintergrund/Fachliche-Schulden-als-Kontrapunkt-zu-Technical-Debt-4284588.html

</small><br /><small>

<strong>[5]</strong>&#160;https://www.heise.de/thema/Softwareentwicklung

</small><br /><small>

<strong>[6]</strong>&#160;https://www.heise.de/hintergrund/Requirements-Engineering-in-der-agilen-Softwareentwicklung-4617665.html

</small><br /><small>

<strong>[7]</strong>&#160;https://www.heise.de/thema/Projektmanagement

</small><br /><small>

<strong>[8]</strong>&#160;https://www.heise.de/thema/Scrum

</small><br /><small>

<strong>[9]</strong>&#160;mailto:map@ix.de

Qgelm

Seiten-Werkzeuge

Webseiten-Werkzeuge

Benutzer-Werkzeuge

Agile Softwareentwicklung: Entwickler und Controller gehören an einen Tisch