Adrian Zwingli, Verwaltungspräsident
Das Richtige schnell und richtig liefern
Die Balance in Projekten für Software oder für softwareintensive Produkte ist aus den Fugen geraten. Es wird das Falsche und Unnötige in mangelhafter Qualität geliefert, und das obendrein teurer und später als vereinbart. Die bekannten Lösungsansätze haben versagt. Es wird Zeit, die Dinge anders zu sehen. Diese kurze Abhandlung zeigt auf, wie Ihnen SwissQ mit neuen Ansätzen in den Bereichen Requirements, Testing und Agilität hilft, das Richtige schnell und richtig zu liefern.
Niemand von uns kennt das exakte „Wie“, um schnell grossartige Software zu schreiben, geschweige denn in genügender Qualität. Auch den letzten Organisationen wird es nun langsam bewusst, dass die altmodische Art, Software zu entwickeln, tot ist. Wasserfall-Modelle haben sich bereits im letzten Jahrzehnt verabschiedet, der V-Modell Ansatz wurde gar nie richtig verstanden. Die Organisationen versuchen nun, die Art und Weise der Software-Entwicklung zu ändern und sehen Agilität als eine Möglichkeit. Aber sind agile Verbesserungen wirklich gut für die Softwareprojekte? Ja, sind sie. Aber sind sie auch gut genug? Nein, Agilität löst nicht alle Probleme. Die neuen Vorgehen (Agile, Scrum, DAD und Co.) versagen bei der Lösung fundamentaler Probleme auch. Es wird zwar öfter „released“, aber der Nutzen und die Qualität der Software steigt nicht wirklich.
Abbildung 1: Do the right thing fast and right
Es wird Zeit, die Dinge anders anzugehen. Die Software Industrie muss lernen, die richtige Software in der richtigen Qualität zur richtigen Zeit zu liefern. Leider etwas, was die meisten IT-Spezialisten nicht im ganzen Ausmass verstehen.
Das Ziel
Um als Produkt oder als IT-Projekt erfolgreich zu sein, ist es essentiell, zwischen den drei Einflussfaktoren die richtige Balance zu finden: Sowohl das Richtige zu tun, als es auch richtig zu tun und es oben drein schnell zu tun. Das rote Zentrum, die Überlappung der drei Einflussfaktoren, muss möglichst gross sein. Jede Abweichung (oder ein zu starker Fokus auf eines der Gebiete) führt zu erheblichen Problemen, welche nachfolgend detaillierter beschrieben werden.
Das Richtige tun (do the right thing)
Der grundsätzliche Zweck einer Software ist es, ein spezifisches Problem zu lösen und dies gut zu lösen. Leider gibt es nur wenige Beispiele für Software, welche dies wirklich gut kann. Oft geht es „irgendwie“, nur mit Einschränkungen, Umständen und Einbussen. Jeder von uns könnte dazu wohl unzählige Beispiele nennen.
In der heutigen schnelllebigen Zeit müssen wir wieder lernen, dass die Software von Anfang an das spezifische Problem lösen soll und umgehend ihren Zweck erfüllt. Der Benutzer muss von Anfang an zufrieden sein. Das bedeutet nicht, dass die Software bereits alles können muss. Aber der Benutzer (respektive alle Stakeholder) muss umgehend sehen (und erfahren können), dass das Vorhaben gut kommt und das Richtige schnell und richtig geliefert wird.
Abbildung 2: Happiness at first release
Leider verfallen viele Projekte in das Gegenteil; die Software soll alle Probleme der Welt erschlagen können und das Projekt verliert sich in unnötigem Umfang. Zum Beispiel überprüfen weniger als 50% aller Projekte, ob Anforderungen und Funktionen überhaupt einen Mehrwert liefern (Swiss Requirements Trends & Benchmarks 2012). Das Projekt startet schon überladen und viele Ressourcen werden auf unnötige Aktivitäten verschwendet. Die Effizienz sinkt. So wichtig das Erkennen der bedeutsamen Anforderungen sein mag, genau so wichtig ist es zu erkennen, was unwichtig oder unnötig ist.
Fazit: Wir müssen uns die Frage stellen, welche Prioritäten bestehen und wann welche Funktionalität erfüllt sein muss. Damit das Richtige und Wichtige umgesetzt wird.
Es richtig tun (do things right)
Das Richtige zu tun, ist nur die Hälfte der Miete. Wenn wir das Richtige tun wollen, es aber falsch umsetzen, werden wir unsere Ziele nicht erreichen. Die Software kann zwar die Aufgabenstellung lösen, aber nur mit Abstürzen, Fehlern und anderen Beeinträchtigungen. Schlecht geschriebene Software, wenig durchdachte Architektur, Legacy Systeme mit vielen Änderungen und Ergänzungen führen zu verminderter Qualität, hohem Testaufwand und dadurch weniger zufriedenen Kunden.
Auf der anderen Seite stehen unsere IT Engineers mit einem starken Willen zu Perfektionismus. Die Arbeit, also die Software, wird vergoldet. Oft geraten dabei die Bedürfnisse der Benutzer zu Gunsten der technischen Anforderungen in den Hintergrund . Ein (technisches) Premium-Produkt muss zur rechten Zeit (Time to Market) das Richtige können (do the right thing). Das Vergolden der Produkte durch unsere Ingenieure führt oft zu massiver Überteuerung, unnötiger Funktionalität und verspäteter Lieferung.
Fazit: Wir müssen lernen gute, zweckmässige und stabile Software zu entwickeln und diese effizient zu testen. Dabei müssen wir Techniken verwenden, welche das Vergolden verhindern und die Information liefern, wann die Software gut genug ist.
Geschwindigkeit (Speed)
Mit der immer grösser werdenden Komplexität der heutigen Software verliert die Softwareentwicklung an Geschwindigkeit. Doch Geschwindigkeit ist ein Schlüsselfaktor, um den Bedürfnissen der Benutzer gerecht zu werden. Sind wir sehr schnell, bietet sich sogar die Möglichkeit, aktiv Benutzer-Feedback einfliessen zu lassen. Hat sich die Umwelt, der Kontext des Projektes, verändert, können wir reagieren.
Leider ist bei den meisten Vorhaben genau das Gegenteil der Fall. Überladener Auftrag, unnötige Zusatzwünsche, Eigenwünsche der Entwickler, etc. führen zu unnötiger Komplexität und dadurch zu der genannten Verlangsamung. Zeitpläne sind bei Erstellung bereits Makulatur, am freien Markt würde es den direkten Bankrott bedeuten. Agile Softwareentwicklung hat in diesem Bereich schon einiges bewirkt. So viel, dass viele Teams nur noch schnell sind, es aber verpassen, die richtige Funktionalität im richtigen Qualitätslevel zu liefern.
Fazit: Wir müssen lernen, Geschwindigkeit als Schlüsselfaktor ernst zu nehmen. Single- und Double-Learning haben für Reduktion von „Waste“ und schnellem Feedback zu sorgen.
Die Probleme im Detail
Quick Star / Shit Quality (schneller Star, schlechte Qualität)
Gut gemeint, oft ungenügend umgesetzt: Wichtige Funktionalität wird zeitgerecht umgesetzt, wobei die Qualität ungenügend ist und dadurch oft grosse Probleme für die Zukunft entstehen. Kann hie und da eine Option sein, um Time-to-Market einzuhalten. Re-work sollte dann umgehend angegangen werden. Der generierte Technical Debt (technische Schulden) kann in Zukunft sehr hohe Kosten verursachen.
Missed Market Opportunities (verpasste Marktchancen)
Beautiful Software. Löst die richtigen Probleme, sieht gut aus und ist auch technisch top umgesetzt. Leider kommt die Lösung zu spät und kostet oft mehr. Kann hie und da gut ausgehen, wenn keine Konkurrenz da ist (zum Beispiel bei internen Projekten). Bei den meisten Produkten der Grund für den Misserfolg. Für Unternehmen bedeutet es oft der Niedergang.
Quick Shit / High Quality (schnell und gut, verpasste Funktionalität)
Gute Software zur rechten Zeit, welche jedoch niemand braucht; toll erstellte Software, welche oft mit Hilfe agiler Methoden sehr schnell entwickelt wurde. Leider löst sie das Problem oder den Auftrag des Benutzers nicht oder nur ungenügend. Niemand möchte diese einsetzen. Viele verkaufen es trotzdem als Erfolg und überlassen das ungenügende Produkt den Nutzern, welche damit ihre Arbeit mehr schlecht als recht erledigen können. Nur wenige haben den Mut, denn Misserfolg auch offen zuzugeben. Moderne Unternehmen nutzen die Erkenntnisse aus dem Fehlschlag für positive Anpassungen in einer nächsten Iteration.
Das kann SwissQ für Sie tun
SwissQ bringt die 3 Dimensionen in Einklang und unterstützt so Organisationen, das Richtige schnell und richtig zu liefern: Durch das Bereitstellen von Expertise, Ressourcen, Assessments, Methoden und Trainings.
Requirements Engineering = Do the right thing
Von der Idee zur Anforderung. Das Richtige umsetzen und nicht das Unwichtige! Erkennen, was wirklich benötigt wird. Wir verhandeln als Dolmetscher zwischen Fach und IT, moderieren, visualisieren und modellieren. Anforderungen werden erhoben, priorisiert, spezifiziert und verifiziert. Dies mit neuen Methoden, welche es erlauben, den Geschäftswert (Business Value) in das Zentrum aller Anforderungen zu stellen. Damit das Richtige und Wichtige umgesetzt wird.
Software Testing = Do it right
Damit es richtig und zweckmässig gemacht wird. Gut genug, statt vergoldet. Einfach richtig. Wir konzipieren, planen, steuern, definieren, automatisieren die Tests. Und vor allem: Wir finden die Bugs! Mit Agile- und Embedded-Testing so früh und günstig wie möglich. Speziell schlanke Methoden reduzieren den Aufwand erheblich, so zum Beispiel für Mobile Testing. Damit das Projekt erfolgreich eingeführt wird.
Agile = Do it fast
Einfach und schnell. Ohne Kompromisse in Qualität, Verantwortung und Geschwindigkeit. Wir helfen agilen Teams, schnell und in der benötigten Qualität das Richtige zu liefern. Dabei denken wir nicht nur an das einzelne Team (z.B. Scrum und co), sondern wir wissen auch, wie die Requirements- und Testspezialisten in agile Teams und Projekte integriert werden können. SwissQ selbst lebt Agilität bis auf die Stufe der Geschäftsleitung, wir haben es in unserer DNA. Entsprechend begleiten wir ganze Organisationen in ihrer Transformation, um das Richtige schnell und richtig zu liefern.
Anmerkung: Dieser Artikel und die Grafiken basieren auf der Arbeit von Michael Dubakov, Gründer und CEO von TargetProcess, welches Agile Project Management Software für Scrum oder Kanban anbietet. Verwendung mit freundlicher Genehmigung.
[:de]
[:] 
Schreibe einen Kommentar