Softwareentwicklung leicht gemacht

von | 04.04.2019 | Softwareentwicklung | 1 Kommentar

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 vier Rädern. Software ist unsere neue Luft zum Atmen, sie ist Motor und Energieträger in einem. Gut, wenn Unternehmen wissen, wie gute Software entwickelt wird. Besser, wenn sie wissen, wie sich Softwareentwicklung optimieren lässt. Eine Persiflage.

Hyperagiles 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 den Geschwindigkeitsvorteilen. Natürlich gibt es auch immer wieder kritische Geister, die mahnen, dass Agilität nicht überall angemessen sei und nennen dann bspw. sicherheitskritische Infrastrukturen, das autonome Fahren oder den Bau von komplexen Systemen, die aus Hardware und Software bestehen. 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 allerwichtigsten 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, 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. Aus dieser Erklärung lässt sich leicht ableiten, dass Kunden nicht wissen, was sie wollen. Das ist sehr anmaßend und kommt bei den meisten Kunden nicht gut an. Eine klare Vision und ein kreatives Werteversprechen sind deutlich zielführender. Und hyperagile Softwareentwicklung verspricht genau das passende Vorgehen, sowohl für komplizierte als auch für komplexe Vorhaben. Darüber hinaus stellt es auch zahlreiche Konstrukte auf den Prüfstand, die in den letzten Jahren genutzt wurden, jedoch ohne wirklichen Nutzen zu bieten. Hier eine Auswahl:

Die Top 10 der modernen Softwareentwicklung

Das Stakeholdermanagement adressiert die zielgerichtete, kontinuierliche Auseinandersetzung eines Unternehmens mit seinen Stakeholdern. Sind wir mal ehrlich: „mit seinen Stakeholdern“? Wie viel Input benötigen Sie denn für Ihre Softwareentwicklung? In der gelebten Praxis reicht es oftmals, wenn die Entwicklungsabteilung mit dem Geschäftsführer oder Inhaber des Unternehmens spricht, denn der weiß alleine schon aufgrund seiner erfolgreichen Vergangenheit, was Kunden heute und auch morgen wollen! Ja, natürlich können Sie zusätzlich mit dem einen oder anderen Stakeholder sprechen, aber mehr als drei Meinungen benötigt niemand, wenn es um die Strategie und Ausrichtung der zu entwickelnden Software geht. Darüber hinaus erleichtert der konzentrierte Austausch die spätere Zielerreichung, er reduziert den Kommunikationsaufwand und die Anforderungen liegen fast automatisch im Scope.

Apropos Anforderungen. Anforderungen sind sehr 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 im Detail 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.

Die MoSCoW-Methode ist ein bekanntes Priorisierungsverfahrungen zur Bewertung von Anforderungen. Es kennt 4 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 erste Stimmen, die gerne auch die zweite Kategorien und konsequenterweise auch die Dokumentation entsprechender Anforderungen weglassen würden. Damit gäbe es nur noch „Muss-Anforderungen“, die zwar in einer optimalen und rationalen Welt dann logischerweise ebenfalls entfallen könnten, aber gänzlich ohne Anforderungen mit ohne Prioritäten zu arbeiten, ist dann vielen Organisation noch zu radikal. Auf der anderen Seite: den Mutigen gehört die Welt.

User Storys und Use Cases – bzw. Use Case Storys für die Freunde von Use Case 2.0 – sind bekannte Hilfsmittel, um die Perspektive der Anwender 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 alle Beteiligten damit unterfordert werden. Es ist ein Wert der hyperagilen Softwareentwicklung, dass alle Entwicklerinnen und Entwickler nicht wie Anfänger behandelt werden. Die Perspektive von Kunden bzw. Anwendern ist wichtig, die Zufriedenheit der eigenen Angestellten ist im Zweifel aber wichtiger. Sicherheitshalber sollten Unternehmen daher auch nicht zu Entwicklungsbeginn den Systemkontext fixieren, denn der liegt ebenfalls schnell auf der Hand. Und gibt es im Laufe des Projekts Veränderungen, dann ist das halt mal so, schließlich ist der Kunde König.

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 der Kunde am Anfang nicht erwartet – da er sie nicht spezifiziert hat – später dann aber doch lieben lernt. 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 mal ganz und gar nicht in die agile Welt der Dokumentation.

Ein weiteres Konstrukt, das keinen Platz in einem hyperagilen Vorgehen hat, ist das Prototyping. Als erfahrene Softwareentwicklerin bzw. erfahrener Softwareentwickler können Sie sich das Prototyping sparen, indem Sie Ihrem Kunden gut 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 Pretotyping fast unaussprechbar ist, zeigt den Irrsinn der zugrunde liegenden Idee. Und da wir ja ehrlich sein wollen: warum sollten Sie eine Idee testen, wenn Sie von ihr überzeugt sind?

Was ist der größte Vorteil der agilen Softwareentwicklung? Die Antwort lautet: kurze Feedbackzyklen. Leider sind diese sehr anstrengend und reißen den Auftraggeber oftmals auch aus seinem Tagesgeschäft heraus. Hier ist es besser, wenn Sie ihn nicht überfordern und manchmal einfach kurz und knapp eine Management-Summary per Mail oder noch besser telefonisch liefern. Dazu brauchen Sie zwar etwas Erfahrung, aber die werden Sie und Ihre Kollegen schnell sammeln können.

Apropos Erfahrung. Die Qualität einer Softwareentwicklung hängt unmittelbar von der Qualität, der Leistungsbereitschaft und der Erfahrung der Softwareentwicklerinnen und Softwareentwickler ab. Qualität entsteht oftmals durch Erfahrung. Und wie lässt sich Erfahrung am schnellsten aufbauen? Indem jedes Mitglied Ihres Entwicklungsteams möglichst viele Techniken erlernt. Zwar beherrscht niemand einen Themenbereich im allerletzten Detail, aber in der Breite sind Sie sehr gut aufgestellt. Vielleicht müssen Sie Ihre Auftraggeber davon überzeugen, die Vorteile in wechselnden Ansprechpartnern zu erkennen. Zögern Sie nicht, es lohnt sich. Und wenn Sie intern zusätzlich ein rollierendes System etablieren, so dass auch mal ein Vertriebler an einem Pair Programming teilnimmt, oder ein Studienanfänger selbständig ein Code Review durchführt, dann sind Sie auf einem sehr guten Weg. Sie müssen daran glauben, dann klappt das schon.

Es gibt eine ganze Reihe von Praktiken, die Sie sich im Zuge Ihrer Softwareentwicklung sparen können: Tests und Reviews, sämtliche Überlegungen zur Code Überdeckung, generell die Arbeit mit UML- oder SysML-Modellen, oder einen aufwendigen Architekturentwurf – die Liste lässt sich beliebig verlängern. Wenn Sie Ihre Auftraggeber nicht mit Prototypen oder kurzen Feedbackzyklen belasten, wird er sich mit großer Wahrscheinlichkeit darüber freuen, wenn die Software bei ihm vor Ort reift. Das Bananenprinzip ist schließlich nicht nur bei Bananen sinnvoll. Natürlich erfordert die hyperagile Softwareentwicklung ein gewisses Maß an Kommunikation, aber eventuelle Unzufriedenheiten können Sie wieder durch die wechselnden Ansprechpartner ausgleichen. Gerade junge Mitarbeiterinnen und Mitarbeiter bieten sich hier an, und da diese in solchen Situationen besonders viel lernen können, wird es automatisch zu einem Win-Win.

Und last but not least: machen Sie sich nicht zu viele Gedanken über Zusagen. Niemand erwartet von einem Toolhersteller ein Release zu einem vorab angekündigten Termin. Wer solche Termine hält, hat meist die Menge der neuen Features reduziert und Kunden registrieren dies. Ähnlich verhält es sich mit den durch Kunden vorgegebenen Deadlines, denn oftmals sind das nur Wünsche, die auch noch um den einen oder anderen Mannmonat verschoben werden könne, insbesondere wenn der Kunde bereits schon sehr lange auf ein zugesagtes Feature wartet. Sicherheitshalber sollten Sie ein sehr umfassendes Changelog erstellen, in dem jede Option einer Funktion im Detail – am besten jeweils mit Screenshot – abgebildet ist.

Best Practices sind besser als Good Practices

Wie lange ist Ihre Firma bereits am Markt? Ein Jahr, fünf Jahre, 20 Jahre? Natürlich ist eine lange Existenz kein Beweis dafür, wie gut Ihre Firma in Zukunft arbeiten wird. Es ist aber auf jeden Fall ein sicherer Indikator, dass in der Vergangenheit vieles richtig war. Wenn Sie sich zehn Minuten Zeit nehmen und die Erfolgsfaktoren Ihrer Firma reflektieren, dann werden Sie vielleicht auch erkennen, dass es Best Practices gibt, die einerseits natürlich besser sind als nur Good Practices – ein Narr der etwas anderes behauptet – und, die sich wie eine Blaupause für viele Kunden und Projekte eignen. Vielleicht hilft es, wenn Sie anstatt einer kompakten Nutzenargumentation auf Ihrer Website als erstes die interne Arbeitsstruktur mit der Aufteilung der Bereiche – bspw. Business Intelligence, Business Analyse, Projektmanagement, Requirements Engineering, Web-Development sowie Frontend- und Backend-Entwicklung – darstellen. Es ist für Kunden wichtig zu verstehen, wie Sie arbeiten, vermutlich sogar wichtiger als der Nutzen, den Sie ihm bieten können.

Ein letzer Gedanke: haben Sie schon Erfahrung mit einem eigenen Manifest gesammelt? Die Veröffentlichung eines Manifests auf Ihrer Website wirkt auf die meisten Kunden sehr professionell. Verwenden Sie in der Kombination mit dem Titel Versionsnummern, erkennt Ihr Kunde auf einen Blick, dass Sie sich als Organisation weiterentwickeln. Machen wir einfach einen Schnelltest: Wie wirkt „Softwareentwicklung leicht gemacht 2.0“ auf Sie?  

 

Hinweis:

Dies war eine Persiflage. Nichts davon möchte ich real für Ihre Softwareentwicklung empfehlen. Wenn Sie sich für ernsthafte und detaillierte Hintergründe bspw. zum Stakeholdermanagement, zum Umgang mit Anforderungen und der Priorisierung mit der MoSCoW-Methode, zur Arbeit mit User Storys, Use Cases und Use Case 2.0, zu den Konsequenzen bei Overengineering und Gold Plating, bei der Erstellung von Lastenheften, bei der Entwicklung von Prototypen oder Pretotypen, oder das Arbeiten mit Best bzw. Good Practices etc. interessieren, werfen Sie bitte einen Blick in unsere Rubrik Wissen kompakt.

Werbung:

Softwareentwicklung aus Berlin von t2informatik
Michael Schenkel

Michael Schenkel

t2informatik GmbH

Michael Schenkel leitet das Marketing bei t2informatik. Gerne bloggt er über Projektmanagement und Requirements Engineering. Und er freut sich ganz sicher, wenn Sie sich mit ihm auf eine Tasse Kaffee und ein Stück Kuchen treffen.

Share This