oose sucht wieder neue Mitarbeiter als Berater und Trainer.
Wir würden uns sehr über interessante Leute freuen, die bei oose als
tätig werden wollen.
Vielleicht bis Bald 
Herzliche Grüße, Björn Schneider
Marcus Winteroll wird am 28.6. auf der SEACON in Hamburg einen Vortrag über Agiles Requirements Engineering halten.
In agilen Vorgehensweisen wie Scrum werden Anforderungen mit Hilfe von User-Stories beschrieben. Sie rücken die Kundensicht in den Vordergrund und sind einfach zu handhaben, stoßen aber bei komplexen Anforderungen schnell an Grenzen. Dies wird teils durch die agile Vorgehensweise wettgemacht: In der iterativen inkrementellen Entwicklung wird das zu entwickelnde System selbst zum Vehikel der Anforderungsanalyse, denn die Begutachtung der Inkremente durch den Kunden trägt zur Klärung der Anforderungen bei. Das heißt aber nicht, dass dieses Instrument immer das effektivste ist. Zuweilen gibt es ökonomischere Möglichkeiten, die Vorstellungen des Kunden zu schärfen, als ein reales System zu entwickeln. In dem Vortrag werden Werkzeuge vorgestellt, die helfen, Anforderungen zu verstehen – sowohl neuere Entwicklungen aus dem agilen Umfeld, wie Story-Maps, als auch klassische Instrumente, wie Anwendungsfälle. Was stellt eine sinnvolle Ergänzung agiler Vorgehensweise dar, um Anforderungen effektiver zu erheben und noch agiler zu werden? Um diese Fragen zu beantworten, wird eine agile Requirements-Engineering-Methode skizziert.
Zielpublikum: Anforderungsingenieure, Analytiker, Product Owner, Projektleiter
Voraussetzungen: Erfahrungen in agilen Projekten oder mit klassischem Requirements Engineering
Schwierigkeitsgrad: Mittel
Mehr über ARE erfahren Sie auf unserer Themenseite zum Agilen Requirements Engineering.
Als Video: 
In meinem letzten Beitrag habe ich aufgezeigt, warum wir damit beginnen sollten, das in agilen Ansätzen destillierte Wissen und Gedankengut auf BPM-Projekte zu übertragen, um sie damit erfolgreicher zu machen.
Und jetzt wollen Sie sicher wissen: Wie adaptiert man nun die agile Welt auf die BPM-Welt?
Lassen Sie uns hierfür zunächst schauen, was genau wohin genau adaptiert wird.
Der erste Schritt zu agilem BPM lautet: Welche Arten von BPM-Projekten sollten wir unterscheiden, damit klar wird, worauf wir die Abbildung von Agilität abzielen?
Sie sehen schon: bei BPM-Projekten gibt es zwei relevante Unterscheidungsmerkmale
Beide Merkmale stehen orthogonal zueinander und spannen auf diese Weise vier Kategorien von BPM-Projekten auf:
Vereinfachend unterscheiden wir demnach
Diese Unterscheidung auf der Seite der BPM-Welt ist deswegen hilfreich, weil sich (wie Sie gleich sehen werden) je nach Projektkategorie andere Fragen stellen.
Auf der anderen Seite ist spannend „was genau aus der agilen Welt wollen wir eigentlich nutzbar machen?“
Sie sehen: eine Frage wie „Kann man SCRUM für BPM einsetzen?“ ist zu billig. Die Antwort kann nur lauten: „…kommt drauf an!“
So stellt sich für reinrassige IT-Projekte mit geringem Veränderungsausmaß, z. B. bei der viel zitierten Automatisierung der Rechnungsstellung (=B4), gar nicht die Frage, ob man dort eine bestimmtes agiles Vorgehen nutzen will, sondern allenfalls welches Vorgehen (=A2) und wie.
Wenn es aber am Ende gar darum geht, eine gesamte Organisation an stetige Veränderung zu gewöhnen (=B1), dann denken wir in Richtung Lean und Beteiligung von Mitarbeitern (=A4).
Jetzt haben wir geklärt, was genau wir worauf abbilden können. Und daraus lassen sich jetzt konkrete, spannende Fragen ableiten. Zum Beispiel:
Welche Frage ist es für Sie?
Die Botschaft lautet also: Klären Sie für sich bzw. ihr Vorhaben genau, welche Fragen Sie konkret beantwortet haben wollen.
Auf diese und einige andere Fragen möchte ich in folgenden Beiträgen eingehen.
Christian Weiss
In der Xing-Gruppe ARE, die von Marcus Winteroll und mir moderiert wird, findet derzeit eine spannende Diskussion zum Thema “Was ist agiles Requirements Engineering?” statt. Marcus hat den aktuellen Diskussionsstand zusammengefasst:
Sind diese Punkte vielleicht konsensfähig?
In jedem Fall bleibt die spannende Frage, wieviel Dokumentation ist notwendig? Vertreter leichtgewichtiger agiler Verfahren wie Scrum oder XP werden hier sicher versuchen, die Anzahl der Dokumente radikal zu reduzieren und möglichst viel über direkte Kommunikation abwickeln. Ist das ein gangbarer Weg oder gibt es hier Grenzen?
Vielleicht muss man die Sache ja auch andersherum betrachten: Was sind die Aufgaben eines Requirements-Engineers und welche Dokumente untersützen ihn hier wirkungsvoll und welche Dokumente brauchen seine Kunden (auch die internen)? Gibt es vielleicht kostengünstigere Alternativen zur Erstellung von Dokumenten? Welche?
Heute haben Andrea und ich den 4. open oose-Tag gestaltet. Thema: BPMN.
Neben den Notationselementen der BPMN 2.0 (Ereignisse, Aktivitäten, Gateways, Datenflüsse, Choreographie u.v.m.) standen viele praktische Übungen im Fokus unserer Veranstaltung.
Highlight war ein reales Experiment: Die TeilnehmerInnen durften einen tatsächlich existierenden oose-Workflow aufnehmen und dabei echte Fachbereichsmitarbeiterinnen und reale IT-Mitarbeitern interviewen, um anschließend den Workflow zu modellieren und zu diskutieren. Das war auch für uns ein Stück weit experimentell, ist aber hervorragend gelungen.
Die TeilnehmerInnen hatten nicht nur viel Spaß dabei, sondern konnten auch gleich die Interviewtechniken einsetzen, die sie von Christel Sohnemann am ersten open oose-Tag trainiert hatten. Auch ein paar OCEB-Zertifizierungsfragen konnten die TeilnehmerInnen anschließend erfolgreich beantworten.
Rückmeldungen der Teilnehmer waren:
Wir freuen uns über den gelungenen Tag.
Christian Weiss & Andrea Grass
Der erste Tag unserer open-oose-Woche war ein sehr erfolgreicher Start. Unsere Teilnahmer sagen:
Es gab auch negative Kommentare: “Der Tag war zu kurz“.
Ach ja, und was hat unsere Teilnehmer begeistert: Es war der Anforderungsdschungel durch den sie von unserer Trainerin Christel Sohnemann geführt wurden und den wir so angekündigt hatten:
Wie ermitteln Sie die Anforderungen an Ihre Systeme? Wählen Sie Diskussionen, Besprechungen, Interviews oder die Methode “einfach über den Zaun werfen”? Haben Sie Lust, sich durch andere wirkungsvolle Techniken inspirieren zu lassen?
An diesem Tag geben wir Ihnen einen Überblick über Methodiken, mit dem Ziel Anforderungen für ein System so zu erheben, dass die tatsächlichen Bedürfnisse des Stakeholders berücksichtigt werden. Neben unterschiedlichen Techniken erfahren Sie viel über Randbedingungen und Auswahlkriterien für eine nachhaltige Anforderungserhebung. Im Vordergrund steht an diesem Tag “das Machen”: Sie werden in zahlreichen Übungen ganz praktisch erleben, wie geeignet welche Methodik für Ihren Berufsalltag ist.
Unsere BPM-Expertin Andrea Grass hat auf der REConf einen Vortrag zum Thema BPMN und UML gehalten.
Beim abendlichen Vortrag “Dinner for two” fanden sich zur später Stunde etwa 35 Teilnehmer ein, die auch alle bis zum Nachtisch blieben. In lockerer Atmosphäre kamen Rückfragen zum Thema BPMN versus Aktivitätsdiagramm oder wie viel ist eine Prise textuelle Beschreibung in einer Anforderungsspezifikation. Als sehr positiv wurde von den Teilnehmern vor allem die praxiserpobte Kombination aus BPMN und UML gesehen.
Das Rezept:
Man nehme die neue gute BPMN 2, ein paar Diagrammtypen der UML 2 und erschaffe hieraus ein konsistentes Modell. Die Klassen mit Zuständen versehen und vorsichtig unterheben. Wer eine Vorliebe für Service besitzt, kann noch eine Prise SoaML hinzufügen. Verfeinert wird das Ganze mit einem Hauch textueller Beschreibung. Fertig ist die Anforderungsspezifikation.
Die Teilnehmer des Vortrags konnten sich Ihr Rezept sowie erprobte Tipps abholen und wurden zum Gourmet für Anforderungsspezifikationen. Wenn Sie das auch wollen, dann fragen Sie unsere Köchin andrea.grass(at)oose.de.
In meinem Abendvortrag “Wer kümmert sich denn jetzt? – Rollen und Verantwortung konsensbasiert verteilen” habe ich ein Verfahren vorgestellt, wie selbstorganisierte Teams Aufgaben und Verantwortlichkeiten im Konsens verteilen können – ein Verfahren, das für mich immer wieder zu erstaunlichen Effekten führt: Menschen übernehmen Aufgaben voller Begeisterung, zu denen sie vorher keine Lust hatten. Dafür gibt es keine Garantie, aber zumindest wird sichtbar, welche Bereitschaft für die Erfüllung einer Aufgabe da ist.
Statt viel darüber zu reden, haben wir es in einer Gruppe von 5 Personen vor den restlichen Teilnehmern gleich ausprobiert. Die Aufgabe war von mir vorgegeben: Aufgabe war es, einen Blog-Eintrag über den Abendvortrag zu schreiben und den Artikel innerhalb von 2 Wochen zu veröffentlichen.
Sabine Leretz-Richter hat im Konsens aller Beteiligten in der Gruppe diese Aufgabe übernommen. Nach nur einer Woche hatte sie nicht nur den Artikel geschrieben, sondern ihn auch in ihrem neu aufgesetzten Blog veröffentlicht.
Vielen Dank Sabine und vielen Dank an alle Teilnehmerinnen und Teilnehmer für die spannenden Diskussionen.
Markus Wittwer
P.S. Wer den Vortrag diesmal verpasst hat, kann auch gerne zur SET in die Schweiz kommen.
Agilität ist das Stichwort der letzten Jahre, agiles Projektmanagement, agiles Requirements Engineering, agile Softwareentwicklung – aber was passiert mit der Überprüfung der Qualität der so entstandenen Produkte und Projekte?
Ein Ansatz hierbei kann sein, viel zu testen, also möglichst viele der vorhandenen Testfälle schnell und häufig auszuführen, um sicherzustellen, dass keinerlei zuvor vorhandene Funktionalität im Laufe der Iterationen zu verlieren. Insofern sind automatisierte Tests eine Grundlage zum agilen Testen.
Wichtig ist aber auch, dass gerade bei agil arbeitenden Projektteams schon die Änderungen bei der Entwicklung auf etwaige Auswirkungen und Seiteneffekte zu überprüfen. Dies kann durch den Einsatz von testgetriebener Entwicklung erreicht werden, da die funktionalen Anforderungen zu erst in Form von Prüfungen festgehalten werden und somit die Spezifikation ausführbar wird. Erst im Anschluss entsteht dann das Programm, dessen Übereinstimmung auch sofort geprüft werden kann.
Insofern ist testgetriebene Entwicklung auch agiles Testen. Zumal durch den Einsatz von Unit-Tests zusammen mit FIT o.ä. auch komplexere Funktionalitäten und auch nicht funktionale Anforderungen automatisiert durch die Entwicklung und die QS geprüft werden können.
Stefan Bremer
Als Video: 
Seit einigen Jahren bereichern agile Ansätze und Prinzipien die Welt der Softwareentwicklung, im Moment sind es SCRUM, APM, Lean und Kanban. Für mich Grund genug einmal zu schauen, ob agile Ansätze auch für BPM-Projekte nützlich sind und worum es bei agilem BPM überhaupt geht.
Mal ehrlich: wie laufen typische BPM-Projekte ab?
1. erstmal alle Ist-Prozesse aufnehmen und modellieren (Prozessmodellierung)
2. dann die aufgenommenen Prozesse durchdringen und Optimierungsideen aufspüren (Prozessanalyse)
3. anschließend ausgestalten, wie es besser gehen müsste (Prozessdesign).
Dann die so entstandene Soll-Prozessdokumentation über den Zaun werfen und
4. nun auf schnelle, fehlerlose, wunschgemäße Umsetzung hoffen (Prozessumsetzung und –einführung)
und am Ende wundern, warum das Projekt gescheitert ist…
So ein Wasserfall wäre ja gar nicht so schlecht, wenn er die Dynamik des Niagara-Wasserfalls entfalten würde. Leider mutet er in der Praxis aber an, wie ein tröpfelnder Wasserhahn. Und dass solche rein sequenziellen Ansätze selten erfolgreich sind, ist lange bekannt und nachgewiesen. Ich stelle das hier bewusst plakativ dar (und es trifft auf gar keinem Fall für Ihr BPM-Projekt zu), aber so erleben wir es draußen in der Realität.
Stattdessen wissen wir unlängst, wie es besser geht. Agile Ansätze sind dafür konzipiert,
Und das sind doch größtenteils dieselben Ziele wie wir sie mit BPM-Projekten erreichen wollen. Es macht also Sinn, sich zu fragen, ob man Elemente der agilen Softwareentwicklung irgendwie nutzen kann.
Der Gedanke, agile Ansätze für BPM-Projekte zu nutzen wirft allerdings noch etliche Fragen auf. Zum Beispiel:
Das sind alles richtig spannende Fragen!
Agiles BPM beantwortet diese und viele andere wichtige Fragen und zeigt auf, wie man erfolgreiche Praktiken, Vorgehen, Prinzipien und anderes wertvolles Gedankengut auf den Kontext der BPM-Welt abbildet. Lassen Sie uns also damit beginnen, den in agilen Ansätzen destillierten Erfahrungsschatz nutzbar zu machen!
Im nächsten Blog-Eintrag dieser Serie geht es darum, ob Agilität und BPM überhaupt zusammen passen.
Schönen Start in die Woche wünscht
Christian Weiss
