Phillip G. Armour beschreibt in seinem Buch „The Laws of Software Process“ fünf Arten von Nichtwissen (5 Orders of Ignorance).
Anforderungsdokumentation ist nicht generell sinnvoll!
Vor etwa zwei Jahren habe ich mit einem Kunden die Fragestellung erörtert, inwieweit sich User Stories in einer Entwicklung im regulierten Umfeld einsetzen lassen. Es herrschte die Meinung, User Stories seien gänzlich ungeeignet um im regulierten Umfeld eingesetzt zu werden, da sie nicht detailliert genug seien, um als geforderte Anforderungsdokumentation zu dienen.
Wie cool ist Requirements Engineering denn?
…wahrscheinlich nicht sooooo cool, zumindest bei meiner Tochter, denn die verbindet „Anforderungen“ eher mit Aussagen wie „Räum den Tisch ab!“ und „Räum dein Zimmer auf!“.
Doch welchen Stellenwert hat Requirements Engineering und der Umgang mit Anforderungen heutzutage im Umfeld der Software-, Produkt- und Dienstleistungsentwicklung?
Seit vielen Jahren geben wir Kurse für Requirements Engineering und Management. Vor einigen Jahren kamen dort interessierte Systemingenieure zu uns, die merkten, dass die Spezifikation „ihres“ Systems immer komplexer wird. Sie wollten wissen,
Wenn der Termin drückt, werden Strukturen aufgebrochen
Kennen Sie das auch?: Der Endtermin für ein Projekt rückt immer näher, aber die Arbeit ist noch nicht erledigt. Das Projektziel ist nicht klar, oder wird immer wieder angepasst. Es gibt ständig neue Änderungen an den Anforderungen. Der ursprüngliche Zeitplan passt vorne und hinten nicht mehr. Einzig der Termin für die Markteinführung des Produkts steht fest und muss erfüllt werden!
Haben Sie zu viel Geld?
Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?
Konfliktlösungsfähigkeit – Eine Eigenschaft eines Requirements Engineers?
Welche sind die notwendigen Eigenschaften eine Requirements Engineers? Wer IREB CPRE zertifiziert ist, das Buch [1] gelesen oder an einem HOOD Training zur Vorbereitung auf die CPRE Zertifizierung teilgenommen hat, kann diese Frage mit Leichtigkeit beantworten.
Heute möchte ich mit diesem Beitrag anhand der Eigenschaft „Konfliktlösungsfähigkeit“ demonstrieren, wie praxisrelevant diese geforderten Eigenschaften an einen Requirements Engineer sind.
Faszination überwindet Ängste
Glory of Icarus by ReyeD33
Warum sollen wir uns auf eine Änderung einlassen, wenn sowohl Weg als auch Ziel unklar sind und das Risiko entweder nicht abgeschätzt werden kann, oder sogar außergewöhnlich hoch ist?
Die glaubwürdige Beantwortung genau dieser Frage entscheidet über den Erfolg oder Misserfolg eines
Agil und Traditionell sind keine Gegensätze
Das Cynefin-Modell von Dave Snowden zeigt sehr schön, dass es nicht ausreicht, als einziges Werkzeug einen Hammer zu haben und damit jedes Problem zu einem Nagel zu machen. Er nennt neben einfachen und komplizierten auch komplexe und chaotische Probleme. Und je nach Kontext brauchen wir unterschiedliche Methoden, Technologien und Praktiken, um ein Problem zu lösen.
Zeig doch mal die Metrik!
Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.
„Deep Work“ als agile Praktik
„Früher haben wir jeden Tag zwei bis drei Stunden in Meetings verquatscht, das war verschwendete Zeit“, sagte ein Entwickler kurz nach dem Beginn meines Engagements in seinem Scrum-Team zu mir. Aber dann: „Und jetzt quatschen wir den ganzen Tag im Team-Raum. Mit dem PO, mit UX- und Security-Experten oder weiteren Stakeholdern, um ‚schnell und direkt‘ Nachfragen zu Stories zu klären. Mit den anderen Entwicklern aus unserem Team, um Architekturen und Lösungskonzepte zu diskutieren. Mit den Kollegen aus anderen Teams, um Schnittstellen abzustimmen. Und jetzt mit dir, unserem Scrum-Master, weil ich davon genervt bin, dass ich nicht zum Coden komme. Vielleicht sollten wir das in der nächsten Retrospektive thematisieren; also schon wieder reden, reden, reden, anstatt zu arbeiten. Und oben drauf kommt noch die Zeit für die Selbstorganisation der Abteilung und die Beteiligung der Mitarbeiter an der Weiterentwicklung der Firmenziele.“