Dem Crash vorbeugen - durch "Duzen"

Ich glaube, man kann aus den Erfahrungen der Fliegerei (hier bei SPON) so einiges lernen... Flache Hierarchien heißt aber nicht, dass jeder alles darf und muss, oder?

Buch-Tipp: Change als Fabel

Wie zitierte ein Kollege noch von einer (Entwickler-)Konferenz neulich: "Engineering is simple - people are hard"

Das ist wahr - der Wandel fängt im Kopf an. Auch wenn jemand das Gerät zur Aufhebung der Schwerkraft erfinden würde: die meisten Unternehmen würden es nicht einsetzen, wenn es nicht die meisten anderen schon tun. 

Da das Lesen von Fachbüchern langwierig und -weilig ist, heute mal eine Fabel als Empfehlung: das Pinguin-Prinzip. Sehr nett ausgedacht. Und als Fabel bleibt es auch wirklich hängen! Wir sind halt doch Steinzeitmenschen. Gut, die kannten keine Pinguine.  

Aus der Fabel-Konstruktion kann man auch etwas anderes mitnehmen: komplizierte Sachverhalte erzählt man am besten als Geschichte, auf Neudeutsch mit so genannten "Personas". Geschichten liegen uns näher als abstrakte Herleitungen und Beweise.

Teile - und herrsche!

Schimpfen Sie auch häufig über die Monolithen in Ihrer Anwendungslandschaft – weil Sie nie auch nur ein kleines Stück Software mal einzeln aktualisieren können? Gerade in großen Unternehmen mit unternehmenskritischen IT-Prozessen findet man sehr große Blöcke von Monolithen, oft in Cobol oder auch Java. Andererseits hatte der uralte Host auch seine Vorteile: oft bestand die Anwendung aus Einzelprogrammen, die man nacheinander aufgerufen wurden. Vorteil: einfach mal ein Programm austauschen können.


Schnell erinnert man sich an den ollen Cäsar und die Grundlagen-Vorlesungen der Informatik: Divide et impera! Teile und herrsche! Das hat die IT auch beherzigt: von Objektorientierung über CORBA bis zu SOA.


Erinnern Sie sich noch an SOA – Service-orientierte Architekturen? In der IT-Zeitrechnung ist das schon ewig her. Wie war das noch? Komponenten oder Teilsysteme, die Services bereitstellen! Kapselung in verschiedene Teile! Eigentlich eine ganz simple Idee. Klar, durch die Marketing-Maschinen der Berater, Fachzeitschriften und Messen wurde SOA DAS Thema. Mit jeder Menge an Sub-Themen wie Service-Orchestrierung, Service-Interferenzen, Business Modellen für die Unternehmens-SOA und wahrscheinlich auch Bach-Blüten-Therapie für Alt-Systeme...


Damals setzte man noch auf WebService-Technologie – mit ich glaube mehr als 200 Standards heute etabliert – aber natürlich in Gänze extrem aufwändig. WebServices basierten auf dem nahe liegenden Ansatz, Services technologiefrei durch das neutrale XML zu realisieren. Endlich keine zeitraubenden Konvertierungen und Fehlersuchen mehr – dachten wir. Gut, wir haben gelernt: Standards lassen sich nur mit passendem Tooling wirklich anwenden. Und: XML-Konvertierungen kosten Laufzeit – also nichts für den Hochlast- und Massendatenbereich, falls sie noch keinen Quantencomputer oder das Budget der NSA haben. Für die Integration externer Systeme macht XML Sinn: man will nicht wissen, was die da betreiben. Lieber stabil und ein paar Kisten mehr kaufen.

Interne Services sowie modernere Internet-basierte Services setzen zunehmend auf REST. Grundidee war mal, per http-Aufruf Objekt-Aktionen wie Anlegen, Löschen etc. durchzuführen mit minimalem Overhead in der Darstellung. Der Vorteil eines einfachen http-Services gegenüber eines echten WebServices liegt auf der Hand: kein XML-Parsen, JSON geht da deutlich schneller. Und zwar so schnell, dass man den Monolithen endlich aufbrechen kann:

• Geschäftsprozesse wie Angebot, Kauf, …
  
• Partner: Kunden, Beteiligte wie Versicherungsnehmer, …
  
• Produkte: Katalog, Artikel, Varianten
  
• Aufträge / Verträge: die wirklich fakturierbaren Einheiten
  
• …
  

Wenn Sie das geschafft haben – dann können Sie auch das Partner-System austauschen, ohne die anderen Systeme massiv zu beeinflussen!


Falls Ihnen das Schema oben bekannt vorkommt: viele Unternehmen setzen seit Jahren separate Systeme für die Partnerverwaltung ein. Standardsoftware-Hersteller bieten Module an. Neu ist das alles nicht – aber mit REST-Services deutlich ressourcenschonender und auch für kleinere Unternehmen machbar.


Sie können das noch weiter treiben: setzen Sie als schnellen Zwischenspeicher eine NOSQL-DB wie die MongoDB ein – aus der nur gelesen wird. Sie werden sich wundern, was dabei an Performance trotz Kommunikationsoverhead möglich ist!


Derartige Hybrid-Techniken, also traditionelle Datenbank-Speicherung in Kombination mit schnellem Lese-Speicher, werden gerade durch die Teilung in Komponenten und Services vereinfacht. Gehen Sie es also endlich an und fräsen Sie Blöcke aus dem Monolithen heraus!

Warum wir scheitern

Interessanter Beitrag auf Spiegel.de: Typische Denkfallen, etwas zugespitzt. Erinnert stark an das Buch von Dobelli. Auch wieder dabei - Klassiker: "Risiko-Management? Brauchen wir nicht".

Buch-Anregung: konkrete Methodik

Der Alltag des Projektretters ist hart und voller Entbehrungen - Zeit für Weiterbildung ist bei den 26h-Tagen natürlich kaum. Trotzdem versuche ich z.B. regelmäßig Meetings des Cologne Chapters des PMI zu besuchen. Das kostet in der Regel nichts (ich bin natürlich Mitglied), es gibt einen Imbiss und Vorträge mit unterschiedlichsten Inhalten und Ausrichtungen. Praktischerweise erstreckt sich das Kölner Gebiet in etwa von Dortmund bis Aachen und Bonn, und regelmäßig trifft man sich in der Provinz, so zum Beispiel in dieser Woche in Recklinghausen.

Den zweiten Vortrag vom Donnerstag möchte ich hier empfehlen, da Hr. Schwarz das bietet, was Standards und Methoden-Büchern fast immer fehlt: ein konkretes Vorgehen. Dabei verwendet der Autor aus seiner Erfahrung eher unbewusst die im PMBook aufgeführten Process Groups und Knowledge Areas für sofort einsetzbare Vorgehensweisen.

Andreas Schwarz nennt seinen Ansatz Phalinza - das ist das lateinische Wort für "Pfalz" im Sinne der Kaiserpfalz. Gibt es als eBook oder als Print. Ich habe das Buch noch nicht gelesen, nach meinem Eindruck ist das konkrete Herunterbrechen der abstrakten Prozesse für jeden sehr wertvoll, der nicht nur schicke Folien abliefern muss - sondern erfolgreiche Projekte.

Komplexe Anforderungen – endlose Diskussionen?

Sind Sie bei der Beschreibung Ihrer Projekt-Anforderungen in Word gerade auf der neunten Überschriften-Ebene angekommen – und fragen sich, wie das der Fachbereich jemals verstehen soll?

Hatten Sie eigentlich mal vor, dicht und möglichst agil mit den Kollegen aus der Fachabteilung zusammenzuarbeiten, um die elendigen Papierwüsten von Fachfeinspezifikationen hinter sich zu lassen?

Aber dann ist es passiert! Irgendwie wurde es immer komplexer: die Fachabteilung steigt so richtig thematisch ein und zieht immer weitere Bedingungen und Abhängigkeiten aus dem Hut. Sie schreiben und schreiben: Use Cases und Objektmodell, Geschäftsregeln und nicht-funktionale Anforderungen. Liest das eigentlich noch jemand? Irgendwie haben Sie nicht das Gefühl und müssen sich zurückhalten, auf Seite 49 mal reinzusetzen: „Wer das hier liest, bekommt vom Autor einen riesen Schoko-Eisbecher spendiert!“

Aber was hilft’s? Anforderungen müssen dokumentiert und überprüft werden – sonst versenken Sie schnell mal 100 Tage Aufwand. Dummerweise nimmt das Projekt Fahrt auf, die Hektik zu und die verfügbare Zeit ab.

Versuchen Sie es mal mit Visualisierung und Grafiken! Nicht komplexe, „feature-complete“ UML-Modelle, sondern auf einfache, greifbare Zeichnungen: Masken. Viele Benutzer können sich ganz gut vorstellen, wie Masken funktionieren – sie kennen das aus dem alten System, aus ihrem Alltag. Für sie sind Masken „greifbar“, und sie können sich einbringen: man kommt dabei von „Höcksken auf Stöcksken“ wie man in Westfalen sagt. 

Fangen Sie mit der Struktur an – entwickeln Sie schrittweise die Navigationsstruktur – von welcher Maske komme ich zu welcher Maske – und dann die Inhalte der spannendsten Masken. Wenn Sie PowerPoint-Künstler sind, können Sie sogar die Kästchen in der Struktur mit den Maskenansichten verlinken...

Bekommen Sie damit die Komplexität in den Griff? Ja – wenn Sie nicht nur die Abläufe schrittweise entwickeln, sondern sich auch zunächst auf bestimmte Aspekte beschränken. Wenn die Suchmaske Variationen für verschiedene Berechtigungen haben muss – fangen Sie erst mal mit dem einfachsten Fall an und skizzieren sie einen Durchlauf von vorne bis hinten. Wenn der passt, dann können Sie auch Variationen und Verästelungen einbauen!

Und schon haben Sie übrigens ein agiles Vorgehen, wenn Sie die ersten Ergebnisse gleich mal bauen lassen. Muss nicht perfekt sein, aber Sie glauben nicht, was Sie mit echten Masken noch mal über die Randbedingungen Ihres Systems lernen werden...

Ein Wort noch zu den Werkzeugen: es geht mit PowerPoint. Ja. Tools wie Balsamiq oder WireFrameSketcher können das viel schneller und einfacher. Aber manchmal hat man halt nur Office.

Übrigens sollte man auch stets aufpassen, dass die Masken-„Skribbles“ nicht zu perfekt sind – Benutzer erwarten dann gerne, dass die Maske genau so aussieht. Aber das bringen Sie Ihrem Fachbereich in vielen, intensiven Sprints nach und nach bei...

It’s the software, stupid!

Software? Heute kann jedes Kind und jede Oma auf einem iPad eine App installieren!

Vor vielen Jahren jedoch war es nicht selbstverständlich, dass Software überhaupt ohne Computer verkauft wurde! Zur Zeiten der Großrechner galt Software als notwendiger Zusatz, immer speziell auf den Großrechner zugeschnitten. Das änderte sich erst in den 60er Jahren, dokumentiert z.B. in der Dissertation von T. Leimbach oder im Computermuseum in Paderborn: Software wurde für mehrere, sogar verschiedene Rechnertypen geschrieben! Eine Revolution damals, eine Selbstverständlichkeit mit unglaublichem Marktvolumen heute. 

Ich gebe zu, es war ein langer und mühsamer Weg von Lochkarten zum App-Store – und „write once, run anywhere“ ist gerade durch Apple auch wieder aus der Mode gekommen: auf iOS darf nur Objective-C laufen.

Einen ähnlichen Wandel erlebte in den letzten Jahren die Automobil-Industrie: wenn ich mit meinem Skoda wegen eines Problems zur Werkstatt fahre, dann liest der Techniker mit einem Bluetooth-Gerät am Wagen den Fehlerspeicher aus, bevor er sich auf die Suche begibt. Selbst im SPIEGEL gab es schon Artikel zur Arbeitswelt von Informatikern im Automobil-Bereich, ein klarer Indikator für einen weit fortgeschrittenen Wandel...

Selbst preisgünstige Autos ohne sichtbaren Bordcomputer regeln alles mittlerweile über Steuerelektronik, die wiederum durch Software kontrolliert wird. Software-Updates im Auto? Vor Jahren noch undenkbar. Ich bin gespannt, wann ich mir beim nächsten 7er-BMW Apps für mein Fahrzeug herunterladen kann (gespannt bin ich auch, wann ich mal 7er-BMW fahren darf...).

Auch im Flugzeugbau geht ohne Software nichts mehr – ich entsinne mich der vielen Diskussionen in Fachzeitschriften, ob denn die Piloten Bildschirme anstelle von Messgeräten akzeptieren würden. Heutzutage fokussiert sich die Diskussion wohl eher darauf, warum der Pilot sein iPad nicht integriert im Cockpit nutzen kann. Dass nur noch der Computer fliegt und der Pilot zusieht, ist übrigens eine Legende, selbst bei Billig-Fluglinien.

Die nächste Revolution läuft gerade an – im Maschinen- undAnlagenbau: auch hier wird durch immer günstigere und leistungsfähigere Hardware die Steuerung in Software verlagert. Auch bei diesen Steuerungen gilt: die Erwartung an Features und Komfort steigt mindestens so stark wie die Leistungsfähigkeit der Hardware. 

Gerade die Integration von Maschinen in betriebliche Prozesse ermöglicht z.B. sehr genaue Fertigungs- und Lagerhaltungsplanungen, natürlich mit Anbindung an die entsprechenden Systeme. Und natürlich wollen die Controller dann auch wissen, wie Rüstzeiten und Prozessschritte denn so ausfallen. Hinzu kommt die Vorerfahrung aus dem täglichen Leben: stellen Sie mal einen kleinen Bildschirm irgendwo hin und lassen Sie Kollegen die neue Anwendung bedienen – viele gehen ganz selbstverständlich von einem Touch-Screen aus...

So wird auch im industriellen Bereich die Wertschöpfung im Bereich Software-Entwicklung drastisch zunehmen. Insbesondere wird man die mühsam und teuer erstellten Anwendungen nicht nur für eine Maschine erstellen, sondern gleich für mehrere Grundtypen verwenden wollen, inklusive Konfiguration und Customizing. 

Warum sollte man eine SPS-Konfiguration für jede Maschine neu einstellen? Und voilá, da sind Sie dann mitten im Software-Engineering gelandet! Schließlich wird die Leistungsfähigkeit und Vielfalt der Software als Verkaufsargument dienen – vgl. VC20 und C64: technisch damals nicht mehr ganz aktuell, aber wegen der hohen Anzahl an Programmen klarer Marktführer.

„When in Rome, do as the Romans do“

Soweit die Erkenntnis – aber was heißt dies für Ihr Projekt? Der Software-Anteil am Gesamtvolumen wird steigen! In der Regel wird der Software-Anteil das Budget im Vergleich zu früher geradezu aufblähen: schließlich müssen die neuen Interaktionen über Touch-Displays und Schnittstellen zu anderen Systemen auch programmiert werden. 

Werden Sie in einer solchen Situation die Maschine mit klassischer, funktionaler Dekomposition entwerfen lassen? Am besten von Ingenieuren, die jahrelang solche Maschinen gebaut haben? Oder riskieren Sie dabei Schiffbruch?

Erinnern Sie sich noch an die fast unbedienbaren, aber feature-vollständigen Videorecorder der 90er? Ich glaube nicht, dass ich schon jedes Feature meines Fernsehers verstanden habe oder gar nutzen werde – würde mich aber freuen, wenn die Grundfunktionen an der ein oder anderen Stellen einfacher zu bedienen wären!

Verstehen Sie mich nicht falsch: auf keinen Fall sollten Sie auf das Wissen der Ingenieure verzichten! Vielmehr müssen Sie, bevor die Ingenieure loslegen können, ganz andere, bisher nicht betrachtete Bereiche diskutieren: Da sind wir wieder bei Anforderungen, Use Cases / Anwendungsfällen usw.

Ihre Ingenieure kommen dann spätestens im Design zum Zuge, wenn es um die Umsetzungsmöglichkeiten geht! Natürlich auch schon vorher für Machbarkeitsanalysen und neue Techniken. Vermeiden Sie aber, dass ein Experte für 80er-Jahre Masken die Oberflächen Ihres Systems entwirft! Das geht selten gut!

Die drei wichtigsten Tipps, bevor Ihr Notebook-Akku leer ist:

• Planen Sie Software-intensive Systeme mit Mitteln des Software-Engineering, um Ihr Budget nicht zu riskieren.
• Gehen Sie möglichst iterativ in kleinen Schritten vor, sowohl bei neuen Technologien als auch bei neuen Design-Konzepten.
• Prüfen Sie kritisch, ob Ihr Team (und Sie selbst) genug von modernem Software-Engineering verstehen! Sonst holen Sie sich RECHTZEITIG Hilfe!

Zur Andacht

"Scrum ersetzt die Inkompetenz des Projektmanagers durch die Unfähigkeit des Teams!"

Neulich gehört - hat was, oder?

Hilfe – meine Programmierer bauen Frameworks!

Bei der Planung Ihres Projektes haben Entwickler und Architekten mitgearbeitet. Der Termin ist zwar eng, aber erreichbar. Sie dürfen nur keine Zeit verlieren! Nach dem Setup der Arbeitsumgebungen und des Build-Prozesses läuft die Entwicklung langsam an, Ihr Blutdruck sinkt und Sie atmen mal durch.

Das wichtigste erste Feature ist, die Daten persistent zu speichern, klar: in der Datenbank. Das Datenmodell haben Ihre Leute schon erstellt, hat viel Zeit gekostet, bis die zufrieden waren. Jetzt geht’s los! Die Entwickler hauen in die Tasten und malen Kästchen-Diagramme an die Whiteboards. So weit, so beeindruckend.

Irgendwie sehen Sie zwar viel Arbeit, aber wenig konkrete Ergebnisse? Und immer, wenn Sie nachfragen, heißt es: „Läuft! Muss halt sein: der Code ist die Basis, damit wir später schnell implementieren können.“

Keine Sorge – Sie sind nicht allein! Was Ihnen gerade passiert, haben viele Projektleiter schon durchgemacht: Ihre Entwickler bauen nämlich gerade ein Framework! Sicherlich gibt es ganz in Ihrer Nähe eine Selbsthilfegruppe von Software-Projektleitern, die Sie freundlich aufnimmt... Im Ernst: Warum tun die das? Und bringt das Ihr Projekt voran oder in Bedrängnis?

Ihre Entwickler haben natürlich in der ein oder anderen Form einen Informatik-Hintergrund, häufig durch Ausbildung, viele sogar durch ein Studium. Irgendwann einmal hat sich die Informatik von ihren Stiefeltern, der Mathematik und der Elektrotechnik, losgesagt und verfolgt seit dem eigene Ansichten, Traditionen und Mythen.

Eine grundlegende Tradition ist die Abstraktion eines Algorithmus oder eines Fachobjektes durch eine generische Sicht: wenn der Sortieralgorithmus mit Adressdaten funktioniert, warum nicht auch mit Kontodaten? Ist nicht jeder Beteiligte in einem Geschäftsprozess ein Partner, der zumindest eine postalische Adresse hat?

Gerade die Abstraktion bietet aus kaufmännischer Sicht durchaus Vorteile: Sie wollen ja nicht jedes Mal wieder für die Erfindung des Rades bezahlen – schließlich ermöglicht insbesondere die Objektorientierung eine generische Herangehensweise und eine schnelle Wiederverwendung bei niedrigen Kosten.

Gerade die stets angeführten Kostenvorteile bei Wiederverwendung halte ich übrigens für einen hartnäckigen Mythos: Wie viele EU-Forschungsprojekte, experimentelle Programmiersprachen und wissenschaftliche Arbeiten hat es hierzu schon gegeben? Und wie viel Code wird in der Praxis wirklich wiederverwendet? Oft stellt man fest, dass ein cleverer Algorithmus doch noch ziemlich ausgebaut werden muss, damit er auch tatsächlich wiederverwendbar ist – etwa als Framework. Denn die Situationen, in denen Code erneut eingesetzt werden soll, können extrem unterschiedlich sein: vielleicht ist die generische Sortierung gar nicht so vorteilhaft, wenn zu viele Sätze in eine Maske geladen werden müssen? Will sagen: Trau, schau, wem!

Falls Sie Entwickler-Magazine wie die c’t, Java-Magazin, Entwickler-Magazin, Objekt-Spektrum u.a. lesen: wundern Sie sich auch immer, wie viele Frameworks aus dem Open Source Bereich dort vorgestellt werden? Natürlich gibt es auch viele, viele kommerzielle Frameworks, die in diesen Zeitschriften beworben werden. Es wäre mal interessant nachzuhalten, welche der vorgestellten Frameworks wieder in der Versenkung verschwinden! Die wesentliche Erkenntnis ist aber meist: 

"There is a framework for that!“

Wenn Sie ein Framework bauen wollen oder müssen – weil es wirklich kein passendes und verfügbares gibt – wie tun Sie das dann?

Treiben Sie die Entwicklung von Framework und Anwendung, Modul oder was immer auf dem Framework basiert, parallel voran:

• Die Entwickler bauen ein Feature des Frameworks, z.B. „lese Daten aus Tabelle und packe sie in ein Objekt“.
• Dann bauen sie z.B. die Geschäftslogik, den Service zum Aufbereiten der Daten sowie eine Maske, in der die Daten angezeigt werden.
• Dabei lernen Ihre Entwickler ziemlich viel über die tatsächlichen Anforderungen der nutzenden Module an das Framework – und können schnell das Framework noch anpassen. Das Ganze können Sie natürlich auch halb parallel machen: die einen bauen das Framework, die anderen die Maske.
• Danach kommt das nächste Feature dran, z.B. Speichern von Objekten in der Datenbank.
• (und so weiter)

Selbst wenn sich zwischendurch die Richtung des Projektes ändert, und auch wenn Sie am Ende wirklich ein komplettes Framework haben:

• Sie bauen nur das, was wirklich benötigt wird – Code für „später“ oder meist „viel später“ oder sogar „viel, viel später“ wird nicht für teures Geld erstellt.
• Die Vorausplanungen für das Framework werden schnell validiert – nichts ist so erkenntnisbringend wie nutzende Module! Wir alle neigen nämlich bei Planungen zu  Irrtümern – sonst wären wir ja schon alle Millionäre oder Nobelpreisträger...
• Wenn Sie dies mit relativ kurzen Zyklen umsetzen, verstärken Sie diese Effekte noch.

So gut das alles klingt: Sie werden Ihre Entwickler schon überzeugen müssen. Als Projektleiter haben Sie noch andere Mittel, in Scrum-Projekten müssen Sie den Product Owner dafür gewinnen. Machen Sie den Entwicklern klar, dass es um harte Dollars geht!

Übrigens ist das Beispiel mit der Persistierung natürlich nur ein Beispiel... Sie haben dafür natürlich eine große Auswahl an Frameworks (im Java-Bereich) unter Hibernate, Eclipselink, iBatis und anderen. Natürlich haben die alle ihre Schwächen – dafür könnte man ein perfektes, neuartiges Framework bauen...

Beobachtung des Tages: PMBoK und oder Wasserfall?

Gestern Abend traf sich wieder das PMI Cologne Chapter zu Vortrag und News aus dem Chapter. In der Diskussion in der traditionellen Brötchenpause fiel uns im Gespräch folgendes auf:
Man hört häufig, dass das PMBoK ja einen traditionellen Ansatz vertritt und sehr Wasserfall-artig sei. Das verwundert immer die zertifizierten PMPs und alle, die es sich angetan haben und das PMBoK wirklich gelesen haben - es steht da nämlich so nicht drin. Im Gegenteil: iteratives und inkrementelles Vorgehen ist durchaus vertreten!

Woher kommt diese Vorstellung?

Ich meine, dass wir vor allem in der IT häufig eher kleine Projekte haben. Naheliegenderweise sind große Projekte mit mehreren tausend Projekttagen auch seltener. Gerade beim Einsatz von Scrum verdrängt man gerne mal, dass in größeren Landschaften auch jemand das Ganze irgendwie zusammenführen muss - und das steht nicht im Scrum-Guide!

Nun muss man nur die Product Owner (in Scrum) dazu bekommen, sich die PMBoK-Inhalte anzusehen: sie machen ja in Scrum einen wesentlichen Teil der "traditionellen" PM-Aufgaben...

Tipp für PMP-Aspiranten

Die PMP®-Zertifizierung des Project Management Institute erfreut sich nach wie vor großer Beliebtheit. Ich vermute, es liegt auch daran, dass man sein (theoretisches) Wissen in einer organisatorisch einfachen Form beweisen kann, nämlich durch den vierstündigen Multiple-Choice-Test - Interviewer oder tiefe Überprüfung von Ausarbeitungen usw. werden dabei natürlich nicht eingesetzt. Das ginge schon kostenmäßig nicht.

Wer gerade auf dem Weg zum PMP ist: das PMBoK (Project Management Body of Knowledge) ist anscheinend gerade erschienen. Erfahrungsgemäß dauert es dann ein wenig, bis neue Fragen einsickern in den Fragenpool. 

Tipp: Nutzen Sie eins der zur Zeit häufig angebotenen, kostenlosen Webinare, um sich einen Überblick über die Neuigkeiten zu verschaffen! Auf Xing und Linkedin sollten Sie da schnell fündig werden...

Update: ab August werden die Prüfungen auf Basis des neuen PMBoK® durchgeführt - die 5. Auflage ist bereits erschienen. PMI Mitglieder können sie herunterladen beim pmi.org.

Projekt-Scoping

Ihr Chef hat Ihnen das Projekt übergeben mit den Worten: „Das schaffen Sie schon!“. Nach dem Durchsehen der Unterlagen haben Sie sogar Zeit gehabt, mit dem Projektteam zu sprechen – nur... irgendwie taucht aus dem Nebel keine strahlende Erkenntnis auf?

Vielleicht befolgen Sie sogar den Rat aus einem der letzten Blog-Posts und orientieren sich an den neun Bereichen: dabei fällt Ihnen dann auf, dass insbesondere der Umfang (Scope) und die Kosten nicht klar sind. Was nun?

Kennen Sie den alten Witz mit dem Bildhauer, der von einem begeisterten Kunstfreund gefragt wird, wie er denn so wundervolle Madonnen aus dem Stein herausarbeitet? „Ach, ich meißel’ halt alles weg, was nicht nach Madonna aussieht!“. So einfach ist es zwar nicht – der Ansatz ist aber ähnlich: ich empfehle Ihnen, ein „Scoping“ durchzuführen, also die wesentlichen Inhalte, Kosten und Dauer aus dem Nebel ans Licht zu zerren. 

Für Software-Projekte erstellen Sie iterativ folgende Artefakte:

Business Case

Lohnt sich das Endprodukt? Zumindest sollte jemand identifizieren können, was der Nutzen ist, wenn auch nicht immer in EUR.

Welche Annahmen liegen dem Szenario zu Grunde? Wenn Sie dies wissen, können Sie viel effektivere Entscheidungen treffen!

Beispiel: Sie erstellen eine Verwaltungssoftware, die nicht am Markt als Standardsoftware verfügbar ist. Mitten im Projekt stellen Sie fest, dass ein Softwarehaus mit drei Buchstaben kurz vor der Fertigstellung einer Standardsoftware steht. Was nun? Ist Ihre Lösung noch viel billiger als die neue? Welche Vorteile hat Ihre Lösung, die im Standard nicht zu finden sind? Müssen Sie sich vielleicht noch stärker auf die individuellen Features fokussieren?

Übersicht Geschäftsprozesse

In vielen großen Unternehmen werden von Organisations- oder Optimierungs- oder Prozess-Abteilungen Geschäftsprozesse erfasst, verwaltet und auf fachlicher Ebene analysiert. Dabei reicht die Bandbreite von „Bilder malen“ bis hin zu ausgewachsener BPMN-Modellierung mit direkter Verwendung in Workflow-Engines. Mein Eindruck: es wird häufiger gemalt als modelliert. Das liegt wohl auch daran, dass Fachabteilungen in fachlichen Zusammenhängen denken – nicht in Algorithmen. Sonst würden die Mitarbeiter ja auch schnell in der IT-Abteilung landen...

Gut nutzen kann man Prozess-Landkarten, Bebauungspläne usw. Gibt es bei Ihnen nicht? 

• Tragen Sie horizontal die groben wertschöpfenden Prozessbereiche auf, z.B. Marketing, Akquise / Vertrieb, Abschluss, Leistung / Bestandsverwaltung / Pflege, Austritt / Storno / Beendigung (je nach Branche halt unterschiedlich). 
• Platz für sekundäre Prozessbereiche wie Buchhaltung, Personalwesen etc. ist dann schon meist nicht mehr – die passen auch zur Not auf ein weiteres Blatt. 
• Unter jeden Prozessbereich können Sie die Systeme packen, die daran beteiligt sind.  Oder, um auf die Geschäftsprozesse zu kommen, die feineren Schritte wie „Angebot erstellen“, „Vertrag abschließen“, „Leistungsanspruch prüfen“. Das Blatt füllt sich in der Regel schnell...
• Hilfreich ist oft, die wesentlichen Prozessbeteiligten (als Rollen) in der Senkrechten zu notieren, in der ersten Spalte: dann können Sie die Prozesse schnell den Beteiligten zuordnen.

Tipp: elektronisch (PowerPoint, Visio, Zeichentools) geht das letztlich schneller als auf Papier.

Auf dieser Ebene müssen Sie vor allem herausfinden, an welchen Prozessen Ihr neues System beteiligt sein wird!

Use Case Übersicht

Die konkrete Beteiligung des Systems an den Prozessen betrachten wir dann als „Use Cases“ oder „Anwendungsfälle“. Die Grundidee ist sehr einfach: wer macht was mit dem System? Zunächst mal trägt man alle Akteure und Top-Level Use Cases in einem Diagramm zusammen. Auch wesentliche, fremde Systeme wie die Buchhaltung oder das Dokumentenarchiv sollten hier als Akteure auftauchen.

Diese Top-Level Use Cases bilden die oberste Ebene Ihrer funktionalen Gliederung. Verfeinern Sie diese Ebene durch Use Cases, für die Sie grob erfassen, was gemeint ist: „Einloggen: Benutzer kann sich einloggen mit Möglichkeit zum Password Reset“.

Meist kann man die Verfeinerungen in die Übersicht einbauen: mit einem UML-Tool können Sie z.B. farbige Bereiche einrichten, um das Lesen zu erleichtern. 

Geplante Komponenten

Was müssen Sie eigentlich programmieren, so im Groben? Anfangs fällt dies vielen Beteiligten schwer, weil sie geistig von „Anforderung“ auf „Lösung“ umschalten müssen.

Tipp: Beginnen Sie „außen“: wo sind die „Schnittstellen“ des Systems? Arbeiten Sie sich dann nach „innen“ vor:

• GUI und menschliche Interaktion: Hier finden Sie schnell GUI-Komponenten und meist auch gleich die darunter liegenden Logik-Komponenten.
• Schnittstellen von und zu anderen Systemen: Wie funktionieren die? Zum Einlesen von Dateien brauchen Sie beispielsweise mindestens eine Importkomponente – welche Komponente jedoch führt die fachliche Logik aus?

Aus diesen Überlegungen bestimmen Sie ziemlich schnell Aussagen zu Abhängigkeiten, Umfang und Kosten:

• Erstellen Sie eine Matrix aus Use Cases und Komponenten: im Kreuzungspunkt eine „1“, falls die Komponente im Use Case verwendet wird, sonst eine „0“.
• Denken Sie sehr intensiv nach über Komponenten, die keine oder wenige Einsen haben...
• Lassen Sie erfahrene Architekten oder Entwickler die Komponenten schätzen – in Projekttagen.
• Parallel dazu können Sie durch Komplexitätsfaktoren versuchen, den Aufwand für die Use Cases zu schätzen und mit Aufwandsklassen zu multiplizieren:

Einfach: 2 PT
Mittel: 5 PT
Komplex: 10 PT

• Der Trick: die Trennung von Klassifikation und Zahlen führt zu besseren Schätzungen!
• Zu guter Letzt vergleichen Sie die Schätzungen für Use Cases und Komponenten – und finden Sie heraus, warum es an welcher Stelle Unterschiede gibt.

Der Plan

Wenn Sie die ersten Hürden überwunden haben, müssen Sie natürlich eine Vorstellung über den Ablauf gewinnen – welche Komponenten / Use Cases etc. bauen Sie zuerst?

Wenn Sie agil planen, brauchen Sie nicht alles herunter zu brechen und zu verfeinern! Nur die wichtigen Teile – wenn Sie herausgefunden haben, welche das sind...

Why you should be careful when assigning rewards

You might want to consider the following very interesting talk - would that explain some observations in your project team?

Plötzlich Projektleiter

Kennen Sie den Film „Plötzlich Prinzessin“? Ein amerikanisches Mädchen wird durch absurden Zufall Prinzessin eines europäischen Staates – über Nacht. Eigentlich geht es im Film um die Herausforderungen des Erwachsenwerdens, und eigentlich ist dies eine Teenie-Highschool-Komödie.

Uneigentlich fühlt sich der ein oder andere Informatiker oder Ingenieur aber ziemlich genau so: das Projekt ist wichtig für die Firma (nicht das imaginäre europäische Land, aber immerhin), böse Kräfte (Termine und zugesagte Eigenschaften) bedrohen die Harmonie, plötzlich muss man gesellschaftliche Ereignisse wahrnehmen wie Geschäftsessen in italienischen Restaurants, wo es nicht einmal Pizza gibt.

Meist passiert dies in den „goldenen Zeiten“: viele Projekte, viel Umsatz, kaum verfügbare Leute mit Erfahrung – alle anderen Optionen scheiden für den Chef aus. Denn wer ein guter Software-Entwickler, Architekt oder Tester ist: der ist ja auch ein guter Projektleiter! Dies nennt man in der PM-Literatur übrigens den „Halo-Effekt“ und meint den „Heiligenschein“-Effekt: wenn jemand viel geleistet hat, trauen wildfremde Menschen ihm plötzlich alles zu. 

Wie überlebt man die an sich ja erfreuliche Beförderung? Da hilft ein Tipp aus einem anderen Film, Highlander: „Verlier’ nicht Deinen Kopf, Highlander!“ Im Film ist der Tipp mehrdeutig – Highlander sind unsterblich, es sei denn, ihr Kopf ist weg. Wenn Sie frisch gebackener Projektleiter sind, heißt dies: verlieren Sie vor allem nicht die Übersicht! 

Wo fängt man an? Wie fängt man an? Das ist natürlich in jeder Situation unterschiedlich... Aber: Einarbeiten ist notwendig – haben Sie als Entwickler auch gemacht, als Sie das erste Mal für einen JBoss Application Server entwickelt haben! Nehmen Sie sich die Zeit und verlangen Sie diese auch! Niemand kann von jetzt auf gleich produktiv sein, bei Politikern gesteht man in neuen Ämtern nach Wahlen sogar 100 Tage zu!

Um das Ruder übernehmen zu können, müssen Sie den Standort bestimmen: welche Themen sind relevant? Welchen Zustand hat das Projekt gerade? Wo müssen Sie mehr Aufwand reinstecken und was kann warten? Ich habe Projektleiter erlebt, die sich mit den Risiken des Projektes nicht beschäftigen wollten, weil man Risikomanagement ja sowieso implizit dauernd macht  – logisch! Dafür wurden unrealistische Termine als unveränderbar verkauft...

Hier ein einfacher Vorschlag für eine Übersicht: die neun Bereiche stammen aus dem ANSI-Standard für Projektmanagement, dem so genannten PMBoK (Project Management Body of Knowledge®, Marke und Copyright des Project Management Institute):

Scope: Was?

Was bauen Sie da überhaupt? Und wo ist die Grenze, welche goldenen Wasserhähne können Sie vermeiden?

Tipp: Scope mit den Stakeholdern klären... möglichst früh... auch wenn’s manchmal schwierig ist. Wenn gar nichts klar ist - weder Umfang noch Kosten - führen Sie ein Projekt-Scoping durch (dazu später mal mehr).

Time: Wann?

Wann ist die Software fertig – und wann wird sie gebraucht? Gibt es da womöglich eine Differenz?

Gibt es offensichtliche Engpässe (critical chain) in Ihrem Plan? Kann man etwas parallelisieren – verschränken – beschleunigen? Gibt es überhaupt einen Zeitplan?

Welche Zeitpuffer sind im Plan enthalten und reichen sie aus?

Cost: Was darf’s denn kosten?

Hat eigentlich schon jemand daran gedacht, dass nach Inbetriebnahme womöglich noch Pflegeaufwand benötigt wird für die ersten dramatischen Fehler?

Beinhaltet das Budget wenigstens Puffer?

Wenn Sie noch sehr früh dran sind mit dem Projekt – beinhaltet das Budget dann auch die Vorbereitungen?

Human Resources (HR): Wer?

Sie haben ein Projekt und sogar ein Team vorgefunden – aber wer sind die Leute, auf die Sie sich verlassen müssen? Welche Fähigkeiten haben die und welche fehlen ihnen?

Haben Sie Mitarbeiter – oder haben Sei ein Team?

Tipp: in größeren Organisationen unbedingt mit den Linien-Vorgesetzten absprechen – sonst müssen die Leute plötzlich im Tagesgeschäft „dringendste“ Aufgaben erledigen.

Risk: Wird es klappen?

„Ich weiß schon, was ich tue!“ – „Die Risiken habe ich auch so im Blick.“ – „Wir sind hier ja nicht im Selbstfindungsseminar?“

Was soll man da noch zu sagen? Wer seine Risiken – und Chancen – nicht rational behandelt... Oder, wie man vielleicht den Kapitän der Titanic hätte sagen hören können: „Eisberg? Welcher Eisberg?“.

Tipp: Ihr Budget muss Puffer für bekannte Risiken enthalten, das ist noch relativ naheliegend. Puffer für „unknown unknowns“ brauchen Sie auch! Oft wird dies auch als „management reserve“ gesehen, weil nur das Management das Budget dafür im Ernstfall freigeben kann.

Quality

„Gratluation! Se haben erworben BAnduhr für Arm von highste Qualitaet!“ – warum nur ähneln alle Qualitätsparolen in Projekten diesem erfundenen, aber nicht unüblichen Versprechen? Vielleicht, weil man sich meist keine Gedanken zur Messung von Qualität machen möchte?

Tipp: setzen Sie auf Automation, wo Sie nur können:

• Statische Code-Analysatoren wie Checkstyle, PMD, FindBugs, Sonar, ...
• Unit-Tests für separierte Module (ja, im Prinzip macht die immer jeder und vollständig...)
• Unit-Tests als Integrationstests für interagierende Module, also quasi direkt unter der GUI
• GUI-Tests: ok, das ist manchmal sehr aufwändig und nervig, vor allem bei Rich Clients. In Projekten habe ich schon Java-basierte Scripting Sprachen gesehen, die effektiver als teure Tools den Entwicklern eine Automatisierung erlaubten.

Communication: Mit wem reden Sie eigentlich?

Sie wissen sicher schon, dass Kommunikation mal locker 80% der Zeit des Projektmanagers beanspruchen kann. Damit Sie überhaupt noch zu irgendwas kommen, müssen Sie herausfinden: mit wem kommunizieren Sie wie über was? Also, gefragt sind mal wieder die Stakeholder:

Das PMO will jede Woche einen Bericht per e-Mail, basierend auf dem Excel-Template. Die „friendly user“ möchten einmal im Monat einen Status präsentiert bekommen.

Das Management möchte einmal im Monat von Ihnen am Kaffeeautomaten hören, dass es gut läuft...

Tipp: Identifizieren Sie die Stakeholder – gründlich und vollständig. Nicht alle erkennt man gleich!

Procurement: Wer liefert?

In Ihrem Team haben Sie einen Freelancer – wie lange ist der eigentlich noch da? Reicht das Budget für die Zeit?

Arbeitsintensiv ist auch die Steuerung von Zulieferern wie z.B. Design- und Web-Agenturen! Wann sollen die noch mal was liefern – und in welcher Qualität?

Integration: Und jetzt?

Alle Einzelteile müssen zusammenwirken: wenn Sie die absurden Kosten- und Zeit-Schätzungen Ihrer Vorgänger korrigieren (mit dem Team) und das Projekt dann länger läuft: ist dann eigentlich noch der Freelancer dabei? In welche Risiken können Sie laufen?

Tipp: gehen Sie die Integration iterativ an – dann können Sie korrigieren und optimieren!

Demnächst hier: wie Sie anhand der Bereiche sich auch „on the flight“ überprüfen können. 

Fehlschläge - Link-Tipp

Fehlschläge bei IT- und Software-Projekten sollen schon vorgekommen sein - auch ohne teuren Flughafen drumherum... Nun lernt man z. B. bei Scrum aus eigenen Fehlern immer am Besten, jedoch lernt man aus den Fehlern anderer deutlich billiger: P. Mertens von der Universität Erlangen-Nürnberg untersucht in dem Artikel "Fehlschläge bei IT-Großprojekten der Öffentlichen Verwaltung – ein Beitrag zur Misserfolgsforschung in der Wirtschaftsinformatik" Fehlschläge und resultierende Erfahrungen bei öffentlichen Projekten (der Artikel ist - glaube ich - in ähnlicher Form im "Informatik Spektrum" der Gesellschaft für Informatik erschienen).
Beim Lesen besser nicht drüber nachdenken, was das an Steuergeldern gekostet hat!

Anforderungen formulieren - Best practices

Eigentlich ist es nicht schwierig, die grundlegenden syntaktischen und grammatikalischen Bedingungen anzuwenden:

Formulierungen im Aktiv
Auch wenn es nicht nach superkorrektem Formaldeutsch klingt:

• Richtig: „Der Benutzer markiert die freizugebenden Einträge und bestätigt die Freigabe“ 
• Behördendeutsch: „Durch die Markierung und anschließende Bestätigung initiiert der Benutzer die Freigabe“

Ungenauigkeiten vermeiden
Vermeiden von Abschwächungen und ungenauen Quantifizierungen, zur Abschreckung:

• „Das neue System muss alles können, was das alte System auch konnte“
• „Das System verschickt die Reports in der Regel täglich“
• „Grundsätzlich zeigt das System dem Benutzer nur aussagekräftige Fehlermeldungen“

Einfache, klare Sätze

• Richtig: „Das System zeigt... Der Benutzer gibt ein...“
• Falsch: "Nachdem das System die Liste anzeigt, gibt der Benutzer einen Suchbegriff zur Verfeinerung ein" 

Hier empfiehlt sich der Translator-Test: wenn es so einfach ist, dass man es z.B. mit Google Translate vom Deutschen ins Englische übersetzen kann, ohne dass es zu peinlich wird, dann ist es einfach genug! Abgesehen davon, dass Sie vielleicht nicht jedem Übersetzungsdienst sagen möchten, womit Sie sich gerade beschäftigen...


Priorität und Verbindlichkeit

Pro Anforderung festlegen:

• Richtig: Soll, Muss, Kann
• Falsch: „Das System sollte das jeweils aktuelle Datum auf jede Seite des Reports ausgeben“ - die Klassifizierung kann sich schneller ändern, als Sie die Grammatik anpassen können!

Soweit – so einfach. Im Prinzip.

In der Praxis muss man meist Fachleuten mit tiefem Fachwissen solche einfachen Regeln immer und immer wieder nahebringen, oft verwechseln gerade ungeübte Anwender epische Romantexte mit nützlichem Informationsgehalt.
Und: interessante Nebensatzkonstruktionen sollte man Herrn Kafka und Kollegen überlassen.

Anforderungen – oder: Wie man als strahlender Held den neunköpfigen gordischen Knoten reitet...

Projekterfolg steht und fällt mit Anforderungen – das ist bekannt. Aber ist das wirklich so schwierig? Eigentlich liest man doch dauernd über Requirements Engineering, zum Beispiel

• Requirements Engineering von Klaus Pohl
• Das berühmte Volere Template
• Artikel, Paper und Vorträge von Chris Rupp von der Sophist Group 

Best Practices zur Formulierung von Anforderungen finden Sie hier.

Ein paar Anforderungen zu sammeln, ist eigentlich einfach: viele Unternehmen verwenden Excel, einige hingegen spezielle Software wie Doors oder andere. Auch Ticketsysteme wie Jira werden gerne als Anforderungsverwaltung eingesetzt.

Und die Verwaltung?

Mit welchem Tool verwalten Sie als Projektleiter die wachsende Liste? Word? Excel? Wiki-Systeme wie Confluence? Ticket-Systeme wie Jira? Viele Unternehmen nutzen Excel – ist sowieso vorhanden, mittlerweile mengentauglich und jeder kennt es. Und der ein oder andere kann sogar Makros programmieren – ganz ohne IT-Abteilung!

Schnell geht mit der wachsenden Anforderungsflut die Übersicht verloren, aber halt, in Excel nutzen Sie doch einfach Auto-Filter, Pivot-Tabellen und Gruppierungen! Jetzt müssen Sie noch kurz das Feedback der Stakeholder einholen, also Datei versenden und hoffen, dass die alle nur ins vorgesehene Feld schreiben.

Dummerweise geht das mehrfach so, weil eine Antwort mitunter weitere Fragen hervorruft. Und Stakeholder gibt es mehr, als Sie dachten. Die fangen an, Antworten und Kommentare mit individuellen Farben zu markieren, weil man so einfacher auf einen Blick den Zusammenhang sieht. Oft trifft man zudem auf die Kombination aus Excel zum Filtern und Sortieren und Word zur textuellen Beschreibung.

Haben Sie das schon mal erlebt? Nach meiner Beobachtung erstellen vor allem Techniker und Ingenieure mit Vorliebe Funktionslisten: Benutzerregistrierung, Anmeldevorgang, Suchfunktion, Neuanlage von Geschäftsobjekten Typ A, Neuanlage von Geschäftsobjekten Typ B, ...

Hilft das den Stakeholdern, wenn sie die Anforderungen prüfen und freigeben sollen? Ich erinnere mich an ein Projekt, in dem die Stakeholder sich nach einigen Runden außer Stande sahen, die Beschreibungen jeweils zu prüfen und freizugeben. Wie beherrschen Sie die Komplexität? Noch mehr Makros und Filter?

Hier hilft Ihnen nur Struktur: vom Groben zum Detail, auf jeder Ebene Übersicht schaffen!
Welche Strukturierung passt zu Ihrer Anwendungsdomäne? Eine generelle Antwort ist schwierig: "Embedded Software" im Anlagenbau unterscheidet sich deutlich von Online Transactional Processing (OLTP), also Verwaltungssoftware, in Unternehmen.
Meine Domäne sind OLTP-Systeme, bei denen immer – und wirklich immer – folgende Struktur schnell Nutzen schafft:

Strukturen

Geschäftsprozesse

Womit erwirtschaftet das Unternehmen Gewinn? Oft sind durch Betriebsorganisation oder ähnliche Stakeholder Prozesse schon dokumentiert. Zudem kann man schnell in wertschöpfende Kernprozesse und unterstützende Prozesse unterscheiden. Meist erhält man eine Folge von Prozessbereichen, die auch zeitlich darstellbar sind. Beispiele:

• Produktentwicklung in einem Versicherungsunternehmen: stellt oft den ersten Schritt im Lebenszyklus eines Produktes dar, inklusive Ideenfindung, Berechnungen, Dokumentation, etc.
• Marketing des entwickelten Produktes ist der nächste Schritt: das Unternehmen bewirbt das Produkt 
• Vertrieb fokussiert sich auf die Ansprache einzelner Kunden: denen muss man natürlich den Produktpreis individuell benennen können
• Abschluss folgt dem Vertrieb, in der Versicherungsdomäne ein sehr wichtiger Prozessbereich mit vielen einzelnen Prozessen

Use Cases – Anwendungsfälle

Wer macht was mit dem System? Hier beschreiben Sie die Prozessanteile, die mit dem zu entwickelnden System umgesetzt werden. Dabei führen „Akteure“ die Schritte des Use Cases aus. Ein Use Case stellt einen abgeschlossenen Bearbeitungsschritt dar – und kann auch von einem externen Systeme als Akteur ausgeführt werden (Beispiel unten).

User Stories: hier wird’s agil... 

Man kann einen Use Case meist gut zerlegen in kleinere Teile (Login, Suchen, Ergebnisse sortieren). Das hilft bei agilen, kurzen Sprints: das Team kann die Story auch wirklich in der Zeit umsetzen, der gesamte Use Case kann in mehreren Sprints entstehen (Beispiel unten).

Nichtfunktionale Anforderungen

Gerne vergessen und immer ein Kostenfaktor: wie schnell soll eigentlich das System jeweils reagieren? Und wie viele Datensätze verarbeiten Sie denn so? Es macht ja doch einen Unterschied, ob man das System für 10.000 oder 10 Millionen Datensätze pro Stunde entwirft.

Beispiele 

Use Cases – ganz grob

• Akteur Sachbearbeiter
• Antrag erfassen: Unbearbeiteten Antrag wählen, gescannten Papierantrag anzeigen,  automatisch erfasste Daten sichtprüfen, fehlende und falsche Daten nachtragen, Antrag prüfen und freigeben.
• Akteur Zeitsteuerung
• Antragsprüfung einmal pro Tag starten: freigegebene Anträge für die Prüfung finden, jeden Antrag maschinell prüfen, Ablehnung oder Bestätigung veranlassen.
• Akteur externes System, hier Data Warehouse (DWH)
• Daten neuer Anträge exportieren an das DWH: pro Sparte Daten selektieren und verdichten, Ergebnisse exportieren, erfolgreichen Lauf vermerken.

User Stories (Beispiel Antrag erfassen)

• Als Sachbearbeiter wähle ich einen gescannten und automatisch erkannten, aber noch nicht bearbeiteten Antrag aus, um ihn zu bearbeiten und dadurch einen Vertragsabschluss vorzubereiten.
• Als Sachbearbeiter lasse ich mir den gescannten Papiereintrag anzeigen, um die automatisch erkannten Einträge zu prüfen und gegebenenfalls zu korrigieren.
• Als Sachbearbeiter vergleiche ich automatisch erkannte Feldinhalte mit dem Scan-Bild und korrigiere Fehler.
• Als Sachbearbeiter starte ich die automatische Prüfung und gebe den Antrag frei, wenn keine Probleme erkannt wurden, um den Vertragsabschluss zu ermöglichen.
• Als Sachbearbeiter starte ich die automatische Prüfung und setze den Antrag auf Wiedervorlage bei Problemen. Hiermit werden fehlerhafte Anträge nachbearbeitet.

Das wirkt auf den Leser nüchtern und langweilig? Mag sein, die Einfachheit der User Stories erlaubt aber eine Bearbeitung z.B. in einem Sprint und vermeidet Mehrdeutigkeiten. Denken Sie daran: was Sie nicht reinschreiben, wird spätestens dann vom Entwickler interpretiert.

Die oben gezeigte Struktur hilft bei der Verwaltung von Anforderungen, sowohl in traditionellen als auch in agilen Projekten! Probieren Sie es aus – und finden Sie Ihre eigene, perfekte Struktur!

Viele große Projekte versuchen zudem, sehr feine Anforderungen zu verwalten, um Nachvollziehbarkeit zu erreichen. Dies ist jedoch eine ganz andere, längliche Geschichte...