Vorgehen überprüfen und anpassen Der letzte Prozessbaustein nutzt die entstandene Transparenz aus der Umsetzung und Bewertung des Inkrements. Mit deren Hilfe können wir Einsicht in mögliche Verbesserungen des Vorgehens gewinnen. Das Team reflektiert regelmäßig im Rahmen der Retrospektive, wie gut mit Anforderungen umgegangen wird. Es führt regelmäßig Verbesserungsmaßnahmen durch. Wir haben zu diesem Zweck als…
Das APP-Framework – Vorstellung Die Agile Produktplanung (APP) basiert wie Scrum auf der empirischen Prozesssteuerung. Sie ist wie Scrum ein Framework, das bewusst unvollständig ist und Raum für situatives Lernen lässt. Es bietet die Essenz, die für ein einheitliches Verständnis von Anforderungen in komplexen Umfeldern notwendig ist. Wir beschreiten also mit APP einen Weg kontinuierlichen…
Im ersten Teil dieser Blogreihe haben wir gesehen, dass bereits die Frage nach plan- und dokumentenbasiertem Requirements Engineering oder agilem RE falsch gestellt sein kann. In diesem Teil widme ich mich nun den Missverständnissen rund um den RE-Prozess, Produkt-Backlog und User Stories. Es gibt nicht den einen RE-Prozess Requirements Engineering ist grundsätzlich eine prozessunabhängige Disziplin.…
Mit der Agilen Produktplanung (APP) stelle ich Ihnen heute und in den nächsten 3 Teilen dieser Blogreihe, das Framework vor, das Ihnen hilft, Requirements Engineering in Ihr agiles Vorgehen zu integrieren.Möchten Sie mehr zur Agilen Produktplanung erfahren und sind daran interessiert es umzusetzen, dann empfehle ich das mehrtägige Curriculum zu APP für Sie, oder auch…
Software beginnt als Idee, als eine Vision. Wenn der Visionär selbst Softwareentwickler ist, reicht das vielleicht schon, um ein großartiges Produkt zu entwickeln. Wenn dieser Visionär aber kein Entwickler ist, muss er das, was in seinem Hirn ist, in die Hirne anderer übertragen, die mit ihm die Software entwickeln. Und das geht nicht ohne Kommunikation.
Wir leben in einer Leistungsgesellschaft. Etwas leisten bedeutet, etwas zu machen. Wir werden danach beurteilt, was wir machen. Wenn etwas nicht funktioniert, müssen wir etwas dagegen machen. Wir denken praktisch immer additiv. Wenn etwas nicht funktioniert, mach mehr, und zwar typischerweise mehr vom Gleichen, also von dem, was eh schon nicht funktioniert hat.
Phillip G. Armour beschreibt in seinem Buch „The Laws of Software Process“ fünf Arten von Nichtwissen (5 Orders of Ignorance).
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.
Wie gehen wir mit der Qualitätssicherung von Anforderungen im agilen Umfeld um? In vielen Projekten benutzen wir User Stories und versuchen, die INVEST-Kriterien zu erfüllen. Aber was ist mit den Qualitätskriterien für Anforderungen, wie sie beispielsweise das IREB (International Requirements Engineering Board) vorschlägt? Brauchen wir die noch? Wenn ja, wann und wie kommen sie zum…
Diese oder ähnliche Aussagen („das geht bei uns gar nicht“) höre ich oft als Reaktion auf Änderungsvorhaben im agilen Umfeld. Dahinter steckt nicht nur normales Unbehagen im Angesicht von etwas Neuem und Unbekanntem. Es ist oft das intuitive Verstehen, dass dieses Neue nicht in den eigenen Kontext, in die gelebte Kultur passt.