Neue Technologien

Softwareentwicklung: Back to the Future!

In vielen Organisationen und Projekten arbeiten zahlreiche Mitarbeitende für die Softwareentwicklung und Maschinen erledigen Aufgaben getrennt voneinander. Aus dieser Vorgehensweise resultieren Probleme. Wie die Rückbesinnung auf die ursprüngliche Art der Softwareentwicklung und der Aufbau einer organischen digitalen Fabrik helfen können.

8 Minuten Lesezeit
Mit Insights von

Softwareentwicklung heute

In der Softwareentwicklung werden heute viele manuelle Schritte durchgeführt und jede Menge Ressourcen verbraucht. Die Prozessphasen laufen nacheinander und komplett getrennt voneinander ab. Nach Abschluss einer Phase (ob erfolgreich oder nicht) werden die Arbeitsergebnisse über die sogenannte „Wall of Confusion“ geworfen. Frei nach dem Motto, nach mir die Sintflut. Aus dieser Vorgehensweise resultieren folgende Hauptprobleme, welche in gleicherweise in den unterschiedlichsten Organisationen anzutreffen sind:

  • Viele manuelle Schritte, welche den Prozess gesamthaft langsam und fehleranfällig machen
  • Qualitätssicherung (Quality Assurance) und Testing als separate Phasen am Ende des Gesamtprozesses
  • Sicherheitsanforderungen und weitere nicht-funktionale Ansprüche, wie Last & Performance oder Wartbarkeit, werden erst kurz vor der finalen Auslieferung besprochen und geprüft
  • Mangelnde Zusammenarbeit aufgrund der getrennten Arbeitsbereiche bzw. -phasen
graphic that shows, how software development looks today

Erschwerend hinzu kommen Transformationsvorhaben, welche nicht die Organisation als Ganzes berücksichtigen, sondern unter dem Strich lediglich neue Bezeichnungen auf bestehende Strukturen übertragen. Oftmals treffen wir auf Abteilungen, welche neu Dev-[hier könnte ihre Abteilung stehen]-Ops heißen, hinter der neuen agilen Fassade jedoch exakt gleich arbeiten und funktionieren wie eh und je. Der einzige Unterschied ist, dass alles schneller und agiler erledigt werden muss. Das wiederum setzt Mitarbeitenden und die gesamte Organisation unter enormen Druck. Das Risiko ist hoch, wertvolle Ressourcen zu verschwenden und Mitarbeitende zu überfordern. In Zeiten in denen Nachhaltigkeit und der „War for Talents“ immer wichtiger werden, können Organisationen es nicht mehr riskieren, ihre besten Köpfe zu verlieren und die Umwelt achtlos zu belasten.

Wir sehen großes Potenzial in der Rückbesinnung auf die ursprüngliche Art der Softwareentwicklung, welche wie selbstverständlich interdisziplinäre Teams und enge Zusammenarbeit beinhaltet. Angereichert mit modernen Ansätzen, wie DevOps, integrative Quality Assurance und agile Arbeitsformen kann die klassische Softwareentwicklung oben genannte Probleme effizient und nachhaltig lösen. Doch was genau verbirgt sich hinter diesen Begriffen?

DevOps

DevOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken. Es sorgt für Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Personen, die für die Planung, Entwicklung, Prüfung, Bereitstellung, Freigabe und Wartung eines Produkts erforderlich sind.

the devops cycle

Dabei sind sowohl ein kultureller Wandel als auch eine Veränderung des Mindsets von zentraler Bedeutung. Es geht nicht mehr um "sie", sondern um "uns". Teamarbeit ist die Grundlage von DevOps. Gegenseitiges Vertrauen, Empowerment, Verantwortung,kontinuierliche Verbesserung, datengestützte Entscheidungsfindung sowie Kundenempathie sind zentrale DevOps-Werte.

Ziel von DevOps ist es, die Markteinführung zu beschleunigen, Experimente zu ermöglichen, Software in kürzeren Abständen zu veröffentlichen, die Vorlaufzeit für Fehlerbehebungen zu verkürzen und die mittlere Wiederherstellungszeit zu verbessern.

Dabei geht es nicht nur darum, dass Dev (Entwicklung) und Ops (Betrieb) zusammenarbeiten. Es geht darum, dass alle Personen, welche an der Erstellung des Produkts beteiligt sind, zusammenarbeiten.

the roles needed for a devops team

Wie in der Illustration gezeigt, sind dies Entwicklung, Security, Business, Architektur, Compliance, Quality Assurance und Operation. Wir sind uns aber sicher, wir haben noch ein paar Personengruppen vergessen.

Sie haben sicher schon von folgenden neuen Begriffen gehört

  • DevSecOps: Dev = Entwicklung, Sec = Security, Ops = Betrieb
  • BizDevOps: Biz = Business, Dev = Entwicklung, Ops = Betrieb

Diese neuen Begriffe versuchen den Begriff DevOps um weitere Personengruppen zu vervollständigen. Leider sind diese neuen Begriffe ebenfalls unvollständig. Denn es bräuchte einen Begriff wie DevSecBizArchCompQAOps oder Dev*Ops oder DevXOps um dem, was wir mit DevOps erreichen wollen, gerecht zu werden.

Deshalb bleiben wir doch einfach bei DevOps, auch wenn der Begriff nicht optimal ist. Bei DevOps geht es darum alle Personen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu schaffen. Das ist DevOps.

Quality Assurance

Quality Assurance (Qualitätssicherung) wird oftmals gleichbedeutet mit Testing verwendet. Da dies nicht nur inkorrekt, sondern auch viel Verwirrung im täglichen Arbeitsumfeld stiftet, erläutern wir nachfolgend die wesentlichen Merkmale und Unterschiede beider Begriffe.

Quality Assurance ist klar prozessorientiert, während Testing sich vorwiegend auf das Produkt fokussiert. Testing ist Teil von Quality Assurance. Quality Assurance ist wiederum Teil eines grösseren Quality Control Systems.

The relation between quality assurance and testing

Bei Qualitätssicherung geht es in erster Linie darum Fehler zu vermeiden. Dies indem sichergestellt wird, dass die Prozesse zur Verwaltung und Erstellung der Ergebnisse funktionieren. Ob dem so ist, wird auch mittels bewährter (agiler) Zeremonien wie dem Review oder der Retrospektive überprüft.

Bei Quality Assurance geht es ebenso um technische Prozesse, welche sicherstellen, dass die Qualität auf effektive und effiziente Weise erreicht wird (Built-in Quality). An dieser Stelle herrscht grosses Synergiepotenzial mit DevOps.

Testing ist ein essenzieller Teil von Qualitätssicherung. Der Schwerpunkt liegt hierbei auf der Erkennung, dem Finden von Fehlern. Testing umfasst Aufgaben zur Planung und Kontrolle, Analyse und Design, Implementierung und Ausführung, Bewertung der Abbruchkriterien und Berichterstattung sowie Testabschlussaktivitäten. Testing beinhaltet ebenso fachliche oder technische Reviews wie auch Code-Inspections.

Testing in der agilen Entwicklung erfordert einen hohen Grad an Automatisierung. Hier gilt jedoch stets: Qualität vor Quantität! Dass Tests automatisiert werden können, sagt nichts über deren Sinnhaftigkeit aus. Jeder Test, ob manuell oder automatisiert, bedeutet Aufwand. Daher ist der Fokus klar auf wertbringende Tests zu legen.

Der Mythos, dass Testautomatisierung manuelles Testing ersetzten soll, hält sich leider hartnäckig. Unsere Erfahrung zeigt jedoch eindeutig: Testautomatisierung ersetzt keine explorativen (manuellen) Tests oder  die Spezialistinnen und Spezialisten mit ihrem umfangreichen Knowhow. Diese Rolle befindet sich jedoch klar im Wandel.

Tools zur Automatisierung von Tests und weiteren Abläufen in der Entwicklung helfen dem gesamten Team schneller und effizienter zu werden. Dies ermöglicht den einzelnen Teammitgliedern sich anderen Aufgaben, bei welchen das menschliche Gehirn gefordert ist, zuzuwenden.

Agile und interdisziplinäre Zusammenarbeit

Agile Arbeitsmodelle verändern die Art unserer Zusammenarbeit. Ob positiv oder negativ hängt stark von der Organisation, deren Kultur und ihren Menschen ab. Um Agilität effizient zu leben und umzusetzen braucht es Diversität im Team. Ein Fußballteam voller Stürmer oder Verteidigerinnen wäre nur mäßig erfolgreich. Es ist der Mix aus verschiedenen Spezialitäten, der den Unterschied macht und Schlüssel zum Erfolg ist. Auf Produktentwicklung bezogen bedeutet das: Weg von den Silos hin zu interdisziplinären Teams, welche alle für das Produkt relevante Disziplinen und Rollen unter einem gemeinsamen Team-Dach vereinen. Jede Disziplin ist gleichwertig, jedes Teammitglied ist wichtig, jede Rolle schafft Mehrwert.

So einfach es klingt, so herausfordernd kann die praktische Umsetzung sein. Ein ausgezeichneter Ausgangspunkt für interdisziplinäre Teams ist die Definition von gemeinsamen Qualitäts-Prinzipien. Essenziell wichtig hierbei ist, dass die Prinzipien vom gesamten Team gemeinsam definiert, verstanden und von jedem Teammitglied aktiv gelebt und eingefordert werden. Diese gemeinsamen Qualitäts-Prinzipien sind nicht gleichzusetzen mit der aus Scrum bekannten „Definition of Done“ oder „Definition of Ready“. Die Prinzipien stehen vielmehr über den „Definitions“ und bilden die gemeinsamen Werte des Teams ab. Gute Starthilfe und Unterstützung bei der täglichen interdisziplinären Zusammenarbeit können folgende bewährte Ansätze liefern:

  • Die 3 Amigos
  • Whole Team Testing

Die 3 Amigos

Gute Anforderungen erfordern verschiedene Perspektiven. Darum arbeiten Fach (Business), Entwicklung (Development) und Testing/QA während des gesamten Produktentwicklungszyklus eng zusammen. Von der Anforderungserhebung über das kooperative Definieren konkreter Anforderungen (z.B. User Stories), bis hin zur Entwicklung und der finalen Abnahme sind alle drei Disziplinen zu jeder Zeit involviert. Dies schafft gemeinsames Verständnis und reduziert die Wahrscheinlichkeit von Missverständnissen und Fehlern auf ein Minimum.

Achtung vor häufigen Stolperfallen:

  • Begrenzung der 3 Amigo-Diskussionen auf nur drei Personen.Wenn es weitere Beteiligte gibt, die für einen bestimmten Arbeitsschritt relevant sind, sollten diese unbedingt in die Diskussion einbezogen werden.
  • Ausdehnung der 3 Amigo-Diskussion auf das gesamte Team.
    Das Ziel dieser Praxis ist es, jede notwendige Perspektive in einer möglichst kleinen Gruppe einzubeziehen.
  • 3 Amigo-Diskussionen werden zu regelmäßigen Treffen und als weitere Team-Zeremonie behandelt, anstatt als praktischer Leitfaden dafür, welche Perspektiven in eine Diskussion über ein bestimmtes Arbeitsinkrement einbezogen werden sollten.
Zur neuen Kundenplattform dank agilem DevOps-Ansatz

Whole Team Testing

Die Essenz von Whole Team Testing ist die gemeinsame Teamverantwortung für Qualitätssicherung und Testing. Das bedeutet Testing ist nicht mehr exklusiv die Aufgabe und im Fokus von professionellen Testerinnen und Testern, sondern von jeder einzelnen Person im Team. Die Test-Rolle verändert sich hin zu einer auf Unterstützung und Coaching ausgerichteten. Das Team hat somit einen sogenannte Quality-Coach welcher professionelles Testing- und QA-Knowhow ins Team bringt. Selbstverständlich kann diese Person aktiv im Testing unterstützen, der Hauptfokus liegt jedoch nicht mehr darauf.

Ein weiterer wichtiger Aspekt von Whole Team Testing ist die Verständigung auf gemeinsame Prinzipien. Diese können sich beispielsweise aus dem Testing Manifesto ableiten oder individuell definiert werden. Für den Erfolg ausschlaggebend ist das gemeinsame Teamverständnis und Bekenntnis zu den Prinzipien.

Unabhängig vom gewählten Ansatz, den eingesetzten Tools oder dem Automatisierungsgrad: Der Erfolg kommt mit der Veränderung der Denkweise jedes Teammitglieds und der aktiven Anpassung persönlicher Arbeitsweisen. Ein Mini-Wasserfall in einem agilen Sprint ist schlimmer als jedes schwerfällige Projekt nach V-Modell. Dies erzeugt übermässigen Stress, Frustration und führt im schlimmsten Fall zu Burn-out, bei geringerer Produktqualität und höheren Kosten (für Fehlerbehebung etc.). Eine Lose-Lose Situation ist vorprogrammiert.

Wie sieht die Zukunft aus?

Unternehmen müssen in Zukunft die richtigen Produkte oder Features zur richtigen Zeit in hoher Qualität liefern. Das heisst, sie müssen aus all den guten Ideen die Ideen mit dem höchsten ökonomischen Wert für ihre Kundschaft identifizieren, diese in der richtigen Qualität, in grösstmöglicher Geschwindigkeit und zu möglichst geringen Kosten liefern.

Das bedeutet, Unternehmen müssen ihre digitale Produktenwicklung professionalisieren und bis zu einem gewissen Grad standardisieren. Die Zukunft liegt somit in der Industrialisierung der digitalen Produktentwicklung und dem Aufbau einer organischen digitalen Fabrik im Unternehmen.

the future of software development

In der Digital Factory arbeiten alle Personen eines Wertstroms zusammen an einem Produkt. Dieses One-Team übernimmt dabei die vollständige End-to-End (E2E) Verantwortung für das Produkt. Das Team hat also die volle Verantwortung für Vision, Mission, Backlog, Budget, Qualität und Betrieb. Eine solche organische digitale Fabrik ist nicht statisch. Die Entwicklungsplattform des Produkts, sozusagen das Förderband, wird von einem zentralen Engineering-Team entwickelt und betrieben. Dieses Team coacht und unterstützt die Produkt-Teams, sodass diese selbst die Verantwortung für das Förderband übernehmen können und keine Abhängigkeit entsteht.

Die Prozesse, Tools und Methoden in einer digitalen Fabrik sind standardisiert. Möglichst alle Prozesse sind automatisiert und Built-In Quality ist die Norm. Dies vereinheitlicht die digitale Produktentwicklung. Qualität, Time-To-Market und Kundenzufriedenheit werden nachhaltig gesteigert. Doch vergessen wir bei all der Standardisierung nicht den Faktor Mensch. Ohne Menschen und Organisationen, die offen und motiviert sind als One-Team gemeinsam das beste Produkt zu entwickeln, wird die digitale Fabrik, wie jedes andere Konzept, nur wenig erfolgreich sein.

Unabhängig vom Automatisierungs- und Standardisierungsgrad: Unternehmen müssen eine unterstützende und wertschätzende Kultur der Zusammenarbeit etablieren und die über alle Hierarchiestufen hinweg aktiv pflegen. Mitarbeitende müssen sich persönlich wertgeschätzt und akzeptiert fühlen. Nur so können Bestleistungen und nachhaltige Produkteentwicklung erzielt werden.

Was halten Sie von unserem Konzept der Digital Factory? Wir freuen uns über Ihr Feedback und Fragen zu diesem Artikel.

Ansprechpartner für die Schweiz

Romano Roth

Chief of DevOps & Partner

Seine Leidenschaft ist es, Unternehmen dabei zu unterstützen, Menschen, Prozesse und Technologien zusammenzubringen, damit sie ihren Kunden einen kontinuierlichen Mehrwert bieten können. 

Kontakt
Vielen Dank für Ihre Nachricht.