Von Pia Wiedermayer und Romano Roth
In vielen Organisationen und Projekten sind an der Softwareentwicklung zahlreiche Mitarbeitende und Maschinen beteiligt, die ihre Aufgaben getrennt voneinander erledigen. Dieser Ansatz führt zu Problemen. So kann die Rückkehr zur ursprünglichen Art der Softwareentwicklung und der Aufbau einer organischen digitalen Fabrik helfen.
In der heutigen Softwareentwicklung werden Unmengen an Ressourcen verbraucht und manuelle Schritte ausgeführt. Die Prozessphasen laufen nacheinander ab, völlig getrennt voneinander. Nach Abschluss einer Phase (sei sie erfolgreich oder nicht) werden die Arbeitsergebnisse über die sogenannte «Wall of Confusion» geworfen. Ganz nach dem Motto «nach mir die Sintflut». Dieses Vorgehen führt zu folgenden Hauptproblemen, die in den unterschiedlichsten Organisationen in gleicher Weise anzutreffen sind:
- Viele manuelle Schritte, die den Gesamtprozess langsam und fehleranfällig machen.
- Qualitätssicherung und Testing als separate Phasen am Ende des Gesamtprozesses.
- Sicherheitsanforderungen und andere nicht-funktionale Anforderungen, wie Last und Performance oder Wartbarkeit, werden erst kurz vor der finalen Auslieferung diskutiert und überprüft.
- Mangelnde Zusammenarbeit aufgrund getrennter Arbeitsbereiche und Phasen.
Erschwerend kommt hinzu, dass es Transformationsprojekte gibt, die nicht die Organisation als Ganzes betrachten, sondern lediglich neue Bezeichnungen auf bestehende Strukturen übertragen. Wir treffen häufig auf Abteilungen, die nun Dev-[hier könnte Ihre Abteilung stehen]-Ops heissen, aber genau gleich wie immer hinter der neuen agilen Fassade arbeiten und funktionieren. Der einzige Unterschied ist, dass alles schneller und agiler erfolgen muss. Das setzt die Mitarbeitenden und die gesamte Organisation enorm unter Druck. Es besteht die ernsthafte Gefahr, wertvolle Ressourcen zu verschwenden und Mitarbeitende zu überfordern. In Zeiten, in denen Nachhaltigkeit und der «War for Talent» immer wichtiger werden, können es sich Organisationen nicht mehr leisten, ihre besten Köpfe zu verlieren und die Umwelt unbedacht zu schädigen.
Wir sehen grosses Potenzial in der Rückkehr zur ursprünglichen Art der Softwareentwicklung, die selbstverständlich interdisziplinäre Teams und enge Zusammenarbeit beinhaltet. Angereichert mit modernen Ansätzen wie DevOps, integrativer Qualitätssicherung und agilen Arbeitsweisen kann die klassische Softwareentwicklung die oben genannten Probleme effizient und nachhaltig lösen. Doch was bedeuten diese Begriffe genau?
DevOps#
DevOps ist ein Mindset, eine Kultur und eine Reihe technischer 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.
Sowohl ein Kulturwandel als auch ein Wandel des Mindsets sind dabei von zentraler Bedeutung. Es geht nicht mehr um «die anderen», sondern um «uns». DevOps basiert auf Teamwork. Gegenseitiges Vertrauen, Empowerment, Verantwortung, kontinuierliche Verbesserung, datenbasierte Entscheidungsfindung und Kundenempathie sind zentrale DevOps-Werte.
Das Ziel von DevOps ist es, die Markteinführung zu beschleunigen, Experimentieren zu ermöglichen, Software in kürzeren Abständen zu releasen, die Durchlaufzeit für Bugfixes zu reduzieren und die durchschnittliche Wiederherstellungszeit zu verbessern. Dabei geht es nicht nur um die Zusammenarbeit zwischen Dev (Entwicklung) und Ops (Betrieb), sondern um die Zusammenarbeit zwischen allen Personen, die an der Erstellung des Produkts beteiligt sind.
Wie in der Abbildung dargestellt, sind dies Entwicklung, Sicherheit, Business, Architektur, Compliance, Qualitätssicherung und Betrieb. Wir sind uns jedoch sicher, dass wir einige Personengruppen vergessen haben.
Sie haben wahrscheinlich schon von folgenden neuen Begriffen gehört:
- DevSecOps: Dev = Entwicklung, Sec = Sicherheit, Ops = Betrieb
- BizDevOps: Biz = Business, Dev = Entwicklung, Ops = Betrieb
Diese neuen Begriffe sind ein Versuch, den Begriff DevOps mit weiteren Personengruppen zu vervollständigen. Leider sind auch diese neuen Begriffe unvollständig. Denn ein Begriff wie DevSecBizArchCompQAOps oder Dev*Ops oder DevXOps wäre nötig, um dem gerecht zu werden, was wir mit DevOps erreichen wollen. Aus diesem Grund bleiben wir einfach bei DevOps, auch wenn es nicht der idealste Begriff ist. Bei DevOps geht es darum, alle Personen, Prozesse und Technologien zum Zweck der kontinuierlichen Wertschöpfung zusammenzubringen.
Qualitätssicherung#
Qualitätssicherung wird oft als Synonym für Testing verwendet. Da dies nicht nur falsch ist, sondern auch erhebliche Verwirrung in den Arbeitsalltag bringt, erläutern wir im Folgenden die wesentlichen Merkmale und Unterschiede zwischen den beiden Begriffen.
Qualitätssicherung ist klar prozessorientiert, während sich Testing hauptsächlich auf das Produkt konzentriert. Testing ist ein Teil der Qualitätssicherung. Die Qualitätssicherung wiederum ist Teil eines grösseren Qualitätsmanagementsystems und es geht primär darum, Fehler zu vermeiden.
Damit wird sichergestellt, dass die Prozesse zur Steuerung und Erstellung der Ergebnisse funktionsfähig sind. Bewährte (agile) Methoden wie Reviews oder Retrospektiven werden eingesetzt, um zu prüfen, ob dies der Fall ist. Bei der Qualitätssicherung geht es auch um technische Prozesse, die sicherstellen, dass Qualität effektiv und effizient erreicht wird (Built-in Quality). Hier besteht grosses Synergiepotenzial mit DevOps.
Testing ist ein wesentlicher Teil der Qualitätssicherung. Der Hauptfokus liegt dabei auf der Detektion, also dem Finden von Bugs. Zum Testing gehören Aufgaben zur Planung und Steuerung, Analyse und Konzeption, Realisierung und Durchführung, Bewertung der Endekriterien und Berichterstattung sowie Aktivitäten zum Testabschluss. Zum Testing gehören auch fachliche und technische Reviews sowie Code-Inspektionen.
Testing in der agilen Entwicklung erfordert einen hohen Automatisierungsgrad. Hier gilt jedoch: Qualität vor Quantität! Die Tatsache, dass Tests automatisiert werden können, sagt nichts darüber aus, ob sie sinnvoll sind. Jeder Test, ob manuell oder automatisiert, ist mit Aufwand verbunden. Der Fokus muss daher klar auf Tests liegen, die einen Mehrwert bieten.
Leider hält sich der Mythos hartnäckig, dass Testautomatisierung manuelles Testing ersetzen muss. Unsere Erfahrung hat jedoch klar gezeigt, dass Testautomatisierung kein Ersatz für exploratives (manuelles) Testing oder Spezialistinnen und Spezialisten mit umfassender Expertise ist. Allerdings befindet sich diese Rolle klar im Wandel. Testautomatisierungstools und andere Entwicklungsverfahren helfen dem gesamten Team, schneller und effizienter zu arbeiten. So können sich die einzelnen Teammitglieder den Aufgaben widmen, für die das menschliche Gehirn benötigt wird.
Agile und interdisziplinäre Zusammenarbeit#
Agile Arbeitsmodelle verändern die Art unserer Zusammenarbeit. Ob dies positiv oder negativ ist, hängt stark von der Organisation, ihrer Kultur und ihren Menschen ab. Im Team ist Vielfalt gefragt, um agile Praktiken effizient zu erleben und umzusetzen. Eine ganze Fussballmannschaft, die nur aus Stürmern oder Verteidigern besteht, wäre nur mässig erfolgreich. Es ist die Kombination unterschiedlicher Spezialitäten, die den Unterschied macht und der Schlüssel zum Erfolg ist.
In Bezug auf die Produktentwicklung bedeutet dies: weg von den Silos, hin zu interdisziplinären Teams, die alle für das Produkt relevanten Disziplinen und Rollen unter einem gemeinsamen Teamdach vereinen. Jede Disziplin ist gleichwertig, jedes Teammitglied ist wichtig und jede Rolle schafft einen Mehrwert.
So einfach es klingt, in der Praxis kann die Umsetzung herausfordernd sein. Ein hervorragender Ausgangspunkt für interdisziplinäre Teams ist die Definition gemeinsamer Qualitätsprinzipien. Hier ist es entscheidend, dass die Prinzipien des gesamten Teams gemeinsam definiert, verstanden und von jedem Teammitglied aktiv gelebt und eingefordert werden. Diese gemeinsamen Qualitätsprinzipien dürfen nicht mit der «Definition of Done» oder «Definition of Ready» gleichgesetzt werden, die wir aus Scrum kennen. Bei den Prinzipien geht es vielmehr um die «Definitions» und sie bilden die gemeinsamen Werte des Teams.
Folgende bewährte Ansätze können einen guten Einstieg bieten und im Alltag der interdisziplinären Zusammenarbeit unterstützen:
- Die 3 Amigos
- Whole-Team Testing
Die 3 Amigos#
Gute Anforderungen erfordern unterschiedliche Perspektiven. Business, Entwicklung und Testing/QA arbeiten daher während des gesamten Produktentwicklungszyklus eng zusammen. Alle drei Disziplinen müssen jederzeit eingebunden sein, von der Anforderungsanalyse über die kooperative Definition konkreter Anforderungen (z. B. User Stories) bis hin zur Entwicklung und finalen Abnahme. So entsteht ein gemeinsames Verständnis und die Wahrscheinlichkeit von Missverständnissen und Fehlern wird minimiert.
Auf potenzielle Stolpersteine ist zu achten:
- Beschränkung der 3-Amigo-Diskussionen auf nur drei Personen. Wenn weitere Personen beteiligt sind, die für einen bestimmten Arbeitsschritt relevant sind, müssen sie in die Diskussion einbezogen werden.
- Ausweitung der 3-Amigo-Diskussion auf das gesamte Team. Das Ziel dieser Praktik ist es, jede benötigte Perspektive in einer möglichst kleinen Gruppe einzubeziehen.
- 3-Amigo-Diskussionen werden zu regelmässigen Meetings und werden als zusätzliche Teamzeremonie behandelt, anstatt eine praktische Roadmap für die Perspektiven zu sein, die in eine Diskussion über ein bestimmtes Arbeitsinkrement einbezogen werden sollten.
Whole-Team Testing#
Das Wesen des Whole-Team Testing ist die geteilte Teamverantwortung für Qualitätssicherung und Testing. Das bedeutet, dass Testing nicht mehr ausschliesslich die Aufgabe und der Fokus professioneller Tester ist, sondern jeder einzelnen Person im Team. Die Testing-Rolle wandelt sich zu einer Rolle, die auf Unterstützung und Coaching ausgerichtet ist. Das Team verfügt also über einen sogenannten Quality Coach, der professionelle Test- und QA-Expertise ins Team bringt. Diese Person kann natürlich aktiv beim Testing unterstützen, dies steht jedoch nicht mehr im Mittelpunkt.
Ein weiterer wichtiger Aspekt des Whole-Team Testing ist die Vereinbarung gemeinsamer Prinzipien. Diese können beispielsweise aus dem Testing Manifesto abgeleitet oder individuell definiert werden. Gemeinsames Teamverständnis und Commitment zu den Prinzipien sind entscheidend für den Erfolg.
Unabhängig vom gewählten Ansatz, den eingesetzten Tools oder dem Automatisierungsgrad: Erfolg stellt sich ein, wenn das Mindset jedes Teammitglieds verändert und persönliche Arbeitsweisen aktiv angepasst werden. Ein Mini-Wasserfall in einem agilen Sprint ist schlimmer als jedes umständliche Projekt nach dem V-Modell. Dies erzeugt übermässigen Stress, Frustration und führt im schlimmsten Fall zu Burnout, reduzierter Produktqualität und höheren Kosten (für Bugfixes etc.). Eine Lose-Lose-Situation ist unausweichlich.
Wie sieht die Zukunft aus?
In Zukunft müssen Unternehmen die richtigen Produkte oder Features zur richtigen Zeit und in hoher Qualität liefern. Mit anderen Worten: Sie müssen aus all den guten Ideen jene mit dem höchsten wirtschaftlichen Wert für ihre Kunden identifizieren und sie mit der richtigen Qualität so schnell und kostengünstig wie möglich liefern. Das bedeutet, dass Unternehmen ihre digitale Produktentwicklung professionalisieren und in einem gewissen Mass standardisieren müssen. Die Zukunft liegt daher in der Industrialisierung der digitalen Produktentwicklung und im Aufbau einer organischen digitalen Fabrik im Unternehmen.
In der digitalen Fabrik arbeiten alle in einem Value Stream gemeinsam an einem Produkt. Dieses eine Team übernimmt dabei die vollständige End-to-End-Verantwortung (E2E) für das Produkt und trägt somit 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, also das Förderband, wird von einem zentralen Engineering-Team entwickelt und betrieben. Dieses Team coacht und unterstützt die Produktteams, damit sie die Verantwortung für das Förderband selbst übernehmen können und keine Abhängigkeit entsteht.
Die Prozesse, Tools und Methoden in einer digitalen Fabrik sind standardisiert. Alle Prozesse sind, wo immer möglich, automatisiert und Built-in Quality ist die Norm. Dies standardisiert die digitale Produktentwicklung. Qualität, Time-to-Market und Kundenzufriedenheit werden langfristig gesteigert. Bei all dieser Standardisierung sollten wir jedoch den menschlichen Faktor nicht vergessen. Wie jedes andere Konzept wird auch die digitale Fabrik ohne Menschen und Organisationen, die offen und motiviert sind, gemeinsam als ein Team das beste Produkt zu entwickeln, nicht sehr erfolgreich sein.
Unabhängig vom Grad der Automatisierung und Standardisierung: Unternehmen müssen eine unterstützende und wertschätzende Kollaborationskultur etablieren und sie aktiv über alle Hierarchieebenen hinweg pflegen. Mitarbeitende müssen sich persönlich wertgeschätzt und akzeptiert fühlen; nur so lassen sich Spitzenleistungen und nachhaltige Produktentwicklung erreichen.
Was halten Sie von unserem Konzept der digitalen Fabrik? Wir freuen uns auf Ihr Feedback und Ihre Fragen zu diesem Artikel.
Originalbeitrag: Zühlke: Back to the future of software development