Softwareentwicklung leicht gemacht

10 Tipps zur Optimierung der Softwareentwicklung – eine Persiflage

Softwareentwicklung ist ein großartiges Betätigungsfeld. Gute Software macht Produkte lebendig; aus Uhren werden Computer am Handgelenk, TV-Geräte wandeln sich zu Online-Videotheken und Autos mutieren zu Algorithmen auf Rädern. Software ist unsere Luft zum Atmen, sie ist Motor und Energieträger in einem. Gut, wenn Unternehmen wissen, wie erfolgreiche Software entwickelt wird. Besser, wenn sie wissen, wie sich Softwareentwicklung optimieren lässt.

Der Trend zum hyperagilen Vorgehen

Es gibt eine ganze Reihe von Methoden und Techniken zur Entwicklung von Software. Zahlreiche Bücher, Blogs und Vorträge bieten Orientierung und liefern tolle Ideen, was Unternehmen in unterschiedlichen Branchen und Settings tun können. In den letzten Jahren hat sich ein agiles Mindset¹ durchgesetzt und viele Organisationen schwärmen von Geschwindigkeitsvorteilen.

Natürlich gibt es auch kritische Geister, die mahnen, dass Agilität nicht überall angemessen sei und nennen dann bspw. sicherheitskritische Infrastrukturen. In gewisser Weise liegen sie damit nicht falsch, doch die Richtung ist eine andere: der Trend geht weg von agil hin zu hyperagil. Das agile Vorgehen ist regelintensiv und nicht so schnell, wie es Kunden wünschen. Geschwindigkeit wird zum alles entscheidenden Wettbewerbsfaktor. Und ein hyperagiles Vorgehen ist Geschwindigkeit pur, denn es basiert auf fast-validen Erfahrungen und vielen Best Practices.

Ein kleines Beispiel:

Kennen Sie die Frage nach „kompliziert oder komplex“? Sie galt lange als Indikator für die Wahl eines passenden Vorgehens in der Softwareentwicklung. Kurz gesagt postuliert „kompliziert“ eine Herausforderung mit zahlreichen Abhängigkeiten, die Unternehmen im Grunde kennen, und die sie durch ein strukturiertes Arbeiten sowie die Verwendung bekannter Methoden im Laufe der Zeit meistern können. „Komplex“ meint hingegen Situationen, bei denen sowohl Auftraggeber als auch Auftragnehmer nicht genau wissen, wohin die Reise geht, welche Ausrüstung sinnvoll ist und was sich auf dieser Reise alles ergibt. Vieles ist mehrdeutig, volatil und ungewiss.²

Aus dieser Erklärung lässt sich leicht ableiten, dass Kunden nicht wissen, was sie wollen. Etwas überraschend kommt diese anmaßende Erkenntnis bei vielen Kunden nicht gut an. Eine klare Vision und ein kreatives Werteversprechen sind hier deutlich zielführender. Und hyperagile Softwareentwicklung verspricht genau ein solches Vorgehen, passend sowohl für komplizierte als auch für komplexe Vorhaben.

Softwareentwicklung auf dem Prüfstand

Das hyperagile Vorgehen stellt Konstrukte auf den Prüfstand, die in der agilen Softwareentwicklung etabliert sind, jedoch keinen wirklichen Nutzen bieten, oder die mehr Nutzen versprechen als allgemein vermutet. Nachfolgend finden Sie 10 Tipps zur Optimierung der Softwareentwicklung:

#1 Stakeholdermanagement

Das Stakeholdermanagement adressiert die zielgerichtete, kontinuierliche Auseinandersetzung eines Unternehmens mit seinen Stakeholdern. Seien wir mal ehrlich: „mit seinen Stakeholdern“? Wie viel Input benötigen Organisationen denn für die Entwicklung von Software? In der gelebten Praxis reicht es oftmals, wenn die Entwicklungsabteilung mit dem Geschäftsführer oder Inhaber des Unternehmens spricht, denn der weiß allein schon aufgrund seiner erfolgreichen Vergangenheit, was Kunden heute und auch morgen wollen!

Natürlich können verantwortliche Mitarbeiterinnen und Mitarbeiter zusätzlich mit dem einen oder anderen Stakeholder sprechen, aber mehr als drei Meinungen benötigt niemand, wenn es um die Inhalte einer zu entwickelnden Software geht. Zusätzlich erleichtert der konzentrierte Austausch die spätere Zielerreichung, er reduziert den Kommunikationsaufwand und die Anforderungen liegen fast automatisch im Scope.

#2 Anforderungen

Apropos Anforderungen. Anforderungen sind wichtig für eine erfolgreiche Softwareentwicklung. Da sich diese aber regelmäßig ändern und auch neue hinzukommen, die stets wichtiger als bestehende und natürlich unmittelbar umzusetzen sind, lohnt es sich nicht, alle Anforderungen zu spezifizieren. Kunden fordern Flexibilität und intern wird ein Klima der kurzfristigen Richtungsänderung benötigt. Das ist spannend und abwechslungsreich. Sicherheitshalber sollte daher auch die Priorisierung von Anforderungen angepasst werden.

#3 Priorisierung

Die MoSCoW-Methode ist ein bekanntes Priorisierungsverfahrungen zur Bewertung von Anforderungen. Es kennt vier Kategorien – Must, Should, Could und Won’t – doch das ist deutlich zu umfangreich. Viel effizienter ist eine zweitstufige Einordnung, die nur Must und Won’t kennt. Es gibt bereits Forderungen, auch direkt die Won’t-Kategorie wegzulassen. Damit gäbe es nur noch „Muss-Anforderungen“ und das ist bereits heute vielfach in Organisationen Status quo. Und so entfällt auch der Bedarf zur Priorisierung. Großartig, oder?

#4 User Storys und Use Cases

User Storys und Use Cases – bzw. Use Case Storys für die Freunde von Use Case 2.0 – sind bekannte Hilfsmittel, um die Perspektive von Anwenderinnen und Anwendern zu verstehen. „Ich als Mittelstürmer möchte den Ball so zugespielt bekommen, dass ich leicht ein Tor erzielen kann“ – die Formulierung solcher Sätze ist so simpel, dass Beteiligte damit unterfordert werden. Es ist ein Wert der hyperagilen Softwareentwicklung, dass Beteiligte nicht wie Anfängerinnen und Anfänger behandelt werden. Die Kunden-Perspektive ist wichtig, die Zufriedenheit der Mitarbeitenden ist im Zweifel aber wichtiger. In der Praxis sind daher oftmals Stichworte und verbale Absprachen ausreichend.

#5 Overengineering und Gold Plating

Haben Sie schon einmal von Overengineering oder Gold Plating gehört? Falls nicht – das macht gar nichts, denn beide Begriffe adressieren nichts anderes als die übertriebene Sorge vor Features, die Kunden nicht erwarten – da sie nicht spezifiziert wurden – diese dann später doch lieben lernen. Grundsätzlich gilt jede Leistung als Gold Plating, die über einen beschriebenen Leistungsumfang – bspw. in Form eines Lastenhefts – hinausgeht. Ein Lastenheft? Das ist nun wirklich Old Work und passt nun ganz und gar nicht zur hyperagilen Entwicklung von Software. Überraschen Sie Ihren Kunden, mit großer Wahrscheinlichkeit wird er sich darüber freuen.

#6 Prototyping

Ein Konstrukt, das keinen Platz in einem hyperagilen Vorgehen hat, ist das Prototyping. Erfahrene Softwareentwicklerinnen bzw. Softwareentwickler können sich das Prototyping sparen, indem sie Kunden wirklich zuhören. Das ist einfach und fördert den natürlichen Austausch zwischen Auftraggeber und Auftragnehmer. Neuerdings fällt in Unternehmen häufiger der Ausdruck Pretotyping, doch alleine die Tatsache, dass der Begriff fast unaussprechbar ist, zeigt den Irrsinn der zugrunde liegenden Idee. Und da wir ja ehrlich sein wollen: warum sollte man eine Idee umfangreich testen, wenn man von ihr überzeugt ist?

#7 Bananenprinzip

Es gibt eine ganze Reihe von Praktiken, die sich Organisationen sich im Zuge der Softwareentwicklung sparen können: Tests und Reviews, sämtliche Überlegungen zu Clean Code, generell die Arbeit mit UML- oder SysML-Modellen, oder einen aufwendigen Architekturentwurf – die Liste lässt sich beliebig verlängern.

Individuell entwickelte Software darf vor Ort – beim Kunden im Einsatz – reifen. Das Bananenprinzip ist schließlich nicht nur bei Bananen sinnvoll.

#8 Wissen und Qualität in der Breite

Eine hyperagile Softwareentwicklung basiert auf Qualität, Leistungsbereitschaft und der Erfahrung der Softwareentwicklerinnen und Softwareentwickler. Wie lässt sich Erfahrung am schnellsten aufbauen? Indem jedes Mitglied des Entwicklungsteams möglichst viele Techniken erlernt. Zwar beherrscht niemand einen Themenbereich im Detail, aber in der Breite ist das Team gut aufgestellt.

Zahlreiche Auftraggeber freuen sich auch über wechselnde Ansprechpartner. Hier hilft es unternehmensintern ein rollierendes System zu etablieren, sodass auch Vertriebler an Pair Programmings teilnehmen oder Studienanfänger Code Reviews selbständig durchführen können. Vertrauen ist hier das Zauberwort.

#9 Feedback in aller Kürze

Was ist der größte Vorteil der agilen Softwareentwicklung? Die lange Antwort lautet: kurze Feedbackzyklen. Leider sind diese sehr anstrengend und reißen Auftraggeber oftmals auch aus ihren Tagesgeschäften heraus. Hier ist es besser, Auftraggeber nicht zu überfordern, und stattdessen kurze Management-Zusammenfassungen per Mail oder idealerweise telefonisch zu liefern. Feedback 4.0 wird beim hyperagilen Vorgehen großgeschrieben.

#10 Temporäre Einschätzungen

Und zu guter Letzt: Kein Kunde erwartet von einem Lieferanten oder Hersteller ein Release zu einem vorab angekündigten Termin. Wer solche Terminzusagen einhält, hat meist die Menge der neuen Features reduziert und Kunden registrieren dies.

Ähnlich verhält es sich auch mit Deadlines von Kunden, denn oftmals sind dies nur Terminwünsche, die auch noch um den einen oder anderen Personenmonat verschoben werden können, insbesondere wenn Kunden bereits schon sehr lange auf zugesagte Features warten. Release-Termine und Deadlines sind lediglich temporäre Einschätzungen, nicht mehr, nicht weniger.

Fazit

Der hyperagilen Softwareentwicklung gehört die Zukunft. Sie ist deutlich flexibler als ein agiles Vorgehen. In vielen Unternehmen wird der Trend bereits – vielleicht auch unbewusst – genutzt und mit Leben gefüllt. Vermutlich dürften viele weitere Konstrukte aus der Vergangenheit der Software- und Produktentwicklung zukünftig auf den Prüfstand kommen. Vieles wird sich ändern – schöne, hyperagile Welt!

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

[1] Unser Blogpaper Mindset bietet sechs Perspektiven auf Mindsets.
[2] VUKA lautet der Begriff für eine sich schnell ändernde Geschäftswelt und die damit einhergehenden Herausforderungen für Unternehmen.

Dies war eine Persiflage. Nichts davon möchte ich real für Ihre Softwareentwicklung empfehlen.

Michael Schenkel hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.