Anforderungsmanagement - Best Practise

Anforderungen an ihr Projekt müssen zentral an einer gesammelt werden. Denn nur so erkennt sie sich gegenseitig widersprechende Anforderungen. Und die kommen oft genug vor.

Eigentlich ist aus der agilen Sicht allein schon das Wort "Anforderung" ein Anti-Pattern. Viel besser ist es ein Ziel und einen Mehrwert zu formulieren. Was möchten sie mit dieser Anforderung erreichen?  Nicht: "Ich will Nutzer in einer Datenbank speichern können." Sondern "Als Benutzer möchte ich einmal eingegebene Nutzerdaten wieder abrufen können, so dass ich sie nicht jedes Mal wieder neu eingeben muss." Das klingt bei so einem einfachen Beispiel banal, diese Formulierung "Als Nutzer möchte ich ... damit ... "  hilft aber sehr um sich auf ein Ziel zu konzentrieren und festzulegen.

Anforderungen müssen natürlich die S.M.A.R.T Kriterien erfüllen - mindestens meß- und testbar sein.

Klassische Projekt Mathematik

Gegeben seien

• Feste Resourcen (Leute die im Projekt arbeiten)
• Eine Aufgabe, die auf Tasks heruntergebrochen wurde
• Ein Starttermin für das Projekt

Gesucht ist die Dauer des Projekts, und somit also der Termin, wann das Projekt fertig werden wird.

Unter der Annahme, dass die Arbeit für alle Tasks vollständig und korrekt im Voraus geschätzt werden können, (Diese Annahme ist natürlich für Agile Projekte, und für IT/Software Projekte im speziellen völlig falsch, wie wir alle wissen. Aber spielen wir mal weiter....)  folgt dann für jeden Task

Resource x Einheit x Arbeit = Dauer

zum Beispiel

Franz arbeitet 40 h / Woche.  70% davon ist er für unser Projekt verfügbar. Und der Task hat einen geschätzen Aufand von 140 Stunden.

40h / Woche x 70% x 56h   =  2 Wochen

=> Ein Task mit (nur!) 56h wird von einer Person in frühestens zwei Wochen fertig! Unter Beachtung der Abhängigkeiten zwischen Tasks ergibt sich entlang des kritschen Pfades dann die Gesamtdauer des Projekts.

Und nein, mit doppelt so vielen Leuten wirds nicht doppelt so schnell!

Die Geschichte vom Schätzen

Eine der grundlegen Thesen der agilen Entwicklung ist:

Menschen sind ziemlich schlecht im Schätzen, jedoch relativ gut im Vergleichen.

Dies lässt sich sehr schön mit einer kleine Geschichte illustrieren.

Stellen Sie sich einen kleinen bis mittelgroßer Berg Kies vor. Davor steht eine Schubkarre und eine Schaufel. Wie lange würden sie brauchen um den Berg Kies von dort zehn Meter weiter nach da drüben zu bewegen?

Natürlich fragen sie jetzt: Wie groß genau ist denn der Berg?  Aber selbst das (=der Gesamtaufwand eines Projekts) ist ja schon meistens nicht bekannt. Und selbst wenn, dann ist die Einheit unklar: Meter Höhe? Kubikmeter? Grundfläche?  Und selbst wenn wir das noch genau wüssten, dann wüssten sie immer noch nicht wie viele Kubikmeter pro Stunde sie schaffen würden. Sicherlich, wenn man komplett alle Parameter wüsste (incl. Wie viele Kubikmeter passen in den Schubkarren, wie lange dauert das rein schaufeln? Wie weit ist die Fahrstrecke? usw.) dann könnte man die Gesamtdauer leicht ausrechnen. Aber man weis diese Parameter in der Realen Welt vorher eben nicht.

Außer es ist jemand dabei, der schon viel Kies geschaufelt hat. Der weis aus Erfahrung wie lange es dauert eine Schubkarre dort rüber zu schippen. Und der kann auch mit ziemlicher Genauigkeit schätzen, wie lange es dauert zwei, drei vier oder fünf Schubkarren dort rüber zu schaffen.

Doch selbst jemand mit der Erfahrung wie lange es für eine Schubkarre dauert, kann kaum schätzen wie lange es für einen riesig großen Berg dauern würde. Wären es 100 oder 500 Schubkarren?

=> Man kann immer nur einigermaßen ähnliche Aufwände vergleichen und mit einer genügenden Genauigkeit schätzen.

Die konkrete Umsetzung dieses Gedankens ist das Schätzpoker ("Planning Poker").

Meeeting Kultur

Es bedarf einer neuen Meeting Kultur. Alte Gewohnheiten müssen über Bord geworfen werden und gesellschaftliche Ängste durch Effektivität ersetzt werden.



Zu Beginn eines jeden Meetings

• Kein Meeting ohne Agenda
• Als allererster Punkt 0 eines jeden Meetings wird die Agenda kurz durchgesprochen: "Fehlt noch etwas?"
• Als nächster Puntk werden die Anwesende kontrolliert. Wer ist hier fehl am Platz? Es muss für jeden Anwesenden jetzt völlig ok sein an dieser Stelle aufzustehen und zu gehen.
• Ein/e Protokollant/in wird bestimmt. (Tip: Protokoll direkt am Beamer tippen, wer flink genug tippt.)

Während des Meetings

• Das Meeting in der Reihenfolge der Agenda durchgehen. Möglichst nicht springen. 
• Auf die Zeit achten
• Diskussionen moderieren
• Nur einer redet. (Notfalls einen Hut rumgeben und aufsetzten.)

Am Ende des Meetings

•  ActionItems sammeln und festhalten: Wer macht was bis wann?

Nach dem Meeting

• Protokoll und alle gezeigten Präsentationen/Dokumente an alle Teilnehmer verschicken

Kommunikationsmittel

Da computergestützte Kommunikation einen großen Teil meiner Diplomarbeit ausmachte, liegt mir dieses Thema besonders am Herzen. Wissenschaftlich ist dieses Feld bereits umfassend erforscht und ich verweise hier nur auf bestehende Quellen: In der Kommunikationspsychologie gibt es das Sender-Empfänger-Model (Watzlawick) und das Vier-Seiten-Modell (1981) von Friedemann Schulz von Thun.

Bezogen auf IT Projekte spielt die Kommunikation im Team eine besonders große Rolle. Und die Erfahrung lehrt, dass es hier besonders viele Reibungsverluste und Missverständnisse gibt. Wie kann man das verbessern?

Wähle zu einem Kommunikationszweck das passende Kommunikationsmittel.

	ortsgebunden	non- verbal	synchron	push	bidirektional	hohe Datenr.
persönliches Gespräch	ja	ja	ja	ja	ja
Videokonferenz		ja	ja	ja	ja
Telefon / Voice-Chat		ja(2)	ja	ja	ja
Text-Chat			ja	ja	ja
E-Mail				ja		ja
Information hinterlassen(1)						ja

Grundregeln des IT ProjektManagements

Ein paar grundlegende Leitsätze. Ich weis schon, wenn man das liest, denkt man sich: Hey das ist doch selbstverständlich. Aber im tatsächlichen Tagesgeschäft wird erstaunlich wenig davon eingehalten.

Stand Up Meeting

Zu beginn eines Tages sollte es it dem Team ein kurzes Stand Up Meeting geben. Das bedeutet, das Team steht im Kreis. Stehen, damit das Meeting nicht zu lange dauert. Jeder beantwortet reihum folgende drei Fragen.

1. Was hast du gestern getan?
2. Was planst du heute zu tun
3. Was behindert dich momentan gerade in deiner Arbeit

Projekt Definiton

Projekte werden durch einen Business Plan definiert (eine DIN A4 Seite reicht)

Dauer und Aufwand

Ein einfaches, aber doch oft nicht verstandenes Prinzipt: Der Unterschied zwischen Brutto-Dauer und Netto-Aufwand.

Wie lange denken sie Arbeitet ein Mitarbeiter für ihr Projekt? Wahrscheinlich würden sie im ernsten Moment sagen: Ja natürlich 40 h pro Woche. So stehts im Vertrag. Aber arbeitet denn die Resource nur für ihr Projekt? Selbst wenn dem so ist, sind 100% noch lang keine 40 Stunden. Ein Mitarbeiter hat Urlaub, Pausen, Ablenkungen und viele viele administrativen Tätigkeiten. Die Erfahrung lehrt, dass man mit einem Faktor von 0,7 gut beraten ist. Selbst eine exklusive Resource arbeitet also nur zu ca. 70% ihrer Zeit an ihrem Projekt.

Wie lange braucht jemand also für 1BT (einen Bearbeitertag) Aufwand?  "Na da ist er ja morgen fertig!"  - wohl kaum. Wenn man die Reibungsverluste für das Kontextswitching abzieht, sind das mindestesn 2 Tage in brutto real Zeitdauer.

Überlasten sie ihre Resourcen nie mehr als 70%, denn darunter leidet die Qualität. Das müssen sie später im Bugfixing nur doppelte und dreifach wieder nachholen.

MS Projekt Einstellungen

Das berühmte MS Projekt. Jeder kennt es. Jeder hasst es. Und keiner kann damit richtig umgehen. Dabei ist dieses Monster-Tool gar nicht mal so schlecht, wenn man ein paar Tricks bei der Verwendeung beachtet.   Im Vergleich zu anderen Projektmanagement Tools hat MS Projekt die Eigenschaft 'immer alles selber machen zu wollen'. Aber mit den richtigen Einstellungen kann man ihm das abgewöhnen:

MS Office -> Menü -> Extras -> Optionen
-> Reiter: "Berechnen" -> Berechnungsmodus > Manuell     und
-> Reiter: "Terminplan" -> Standardvorgangsart -> Feste Arbeit


Wenn man nun Tasks und Abhängigkeiten einfügt ist nicht gleich immer alles 'zerschossen'. "Feste Arbeit" bedeutet: Wenn sie eine Resource zu einem Task hinzufügen, wird die Dauer kürzer und umgekehrt. Wenn sie "mit gewalt", die Dauer verkürzen, wird die Auslastung der Resource(n) höher. MS Projekt nennt das "Einheiten". Der geschätze Arbeitsaufwand für einen Task bleibt jedoch immer gleich.

Auf dem Reiter "Terminplan" gibt es noch eine Checkbox: "Angefangene Vorgänge automatisch unterbrechen". Standardmäßig ist dies aktiviert. Wenn sie einen halbfertigen Vorgang in die Zukunft verschieben, so wird der Taskbalken geteilt und nur der hintere (noch nicht erledigte Teil) verschoben. Das kann man so machen. Da ja der vordere Teil bereits in der Vergangenheit erledigt wurde.

Möchte man größere Umbauten am Projektplan in einer frühen Phase des Projekts machen, dann macht man diese Einstellung lieber aus.

Noch ein weiterer Tip: Sparsam sein mit Abhängigkeiten. Am besten Tasks gruppieren und dann ausschließlich nur Abhängigkeiten auf den obersten Ebenen vergeben, also z.B. Task-Gruppe B kann erst beginnen wenn die komplette Gruppe A fertig ist (Ende-Anfang-Beziehung)

Dann bleibt das Projekt einigermaßen handhabbar.

Bit, Daten, Information und Wissen

Ein Bit ist die kleinstmögliche Informationseinheit.
Eine uninterpretierte Menge an Bits sind reine Daten.
Interpretierte Daten bilden eine Information.
Information im Kopf eines Menschen sind Bilder.
Von einem Menschen aufgenommene und verarbeitete Bilder sind Wissen.
Aus der Verknüfpfung von gelerntem Wissen kann neues Wissen entstehen.

Eine reine Menge von Daten (z.B. "000101101011101") enthält keine Information. Erst durch Interpretation (Semantik) entsteht daraus eine Information, ein Text oder eine Aussage.

Durch zwischenmenschliche Kommunikation können nur Daten übertragen werden. Was man aber eigentlich erreichen möchte ist es, ein Bild aus dem eigenen Kopf in den Kopf des Empfängers zu übertragen. Dazu muss dieses Bild im eigenen Kopf erst einmal in Datenform (z.B. Worte) verschlüsselt werden und dann - evtl. unter dem Einfluss von Störungen (Lärm) - zum Empfänger übertragen werden. Dort müssen diese Daten wieder entschlüsselt (gehört), verarbeitet, interpretiert, aufgenommen und verstanden werden. Auf jedem dieser Schritte können Fehler passiert, d.h. dass das Bild am Ende beim Empfänger nicht so ankommt, wie das vom Sender gedacht war.

So entstehen Missverständnisse: Man hat ein Bild im Kopf. Beschreibt es nur mit Worten. Und der Gegenüber versteht aufgrund von Mehrdeutigkeiten etwas ganz anderes. Man geht jedoch blind davon aus, dass der Empfänger dann genau das Selbe Bild wie man selbst im Kopf hat. Eine Technik um das zu verhinden ist das Paraphrasieren: Der Empfänger wiederholt was er verstanden hat und der Sender kann somit kontrollieren, ob sein Bild ankam.

Zwei Menschen können nur miteinander kommunizieren, wenn sie einen gemeinsamen Erfahrungsschatz an Bildern besitzten. Sie müssen mindestens die gleiche Sprache gelernt haben. Wenn jemand z.B. das mentale Bild eines Baumes beschreibt, dann kann der Gegenüber das nur vollständig verstehen, wenn er auch schon mal einen Baum gesehen und angefasst hat. Man kann jemandem etwas beschreiben, dass er vorher noch nie gesehen hatte. Oder ihm etwas lernen, dass er vorher noch nicht konnte. Dies bedarf sehr aufwändiger Kommunikation.

Mensch Maschine Schnittstelle

Heute stehn wir mit Computern dort, wo wir mit Autos vor 50 Jahren waren. Damals war es noch ganz normal, dass ein Auto alle paar Kilometer mal stehen blieb und nur von Experten bedient werden konnte. Heute könnte jedes Kind Auto fahren. Waum ist das so? Weil wir es beim Auto geschafft haben ein einfaches Interface zu schaffen. Es reicht zu wissen, wie man lenkt, schaltet und Gas gibt um ein Auto benutzen zu können. Der Fahrer muss nicht wissen, wie ein Motor im Detail funktioniert. Erst wenn etwas kaputt geht, dann geht man in die Werkstatt wo der Fehler von Experten repariert wird.

Bei Computern stecken wir immer noch auf dem Level fest, dass es ganz normal ist, dass ein Computer alle paar Tage mal abstürzt und nur von absoluten Experten bedient werden kann. Es fehlt ein besseres Interface.

Enwicklung von Computern und Autos

Wie war das damals in den 1950er Jahren, also so ca 50 Jahre nachdem das erste Auto erfunden wurde? Damals sahen Autos noch mehr aus wie Pferdekutschen ohne Pferde. Es war völlig normal, dass ein Auto alle paar Kilometer liegen blieb und irgend etwas repariert werden musste. Um ein Auto fahren zu können musste man ein tiefgehendes Verständnis von Pneumatik, Verbrennungsmotoren und technischen Konstruktionen haben. Autos konnten nur von Experten bedient werden.

Und wie fährt man heute ein Auto?

Die Zukunft der Anwendungsentwicklung

Ich glaube, dass sich die Art wie Computeranwendungen entwickelt werden, in der nahen Zukunft sehr verändern wird. Vor langer Zeit einmal gab es monolitische Anwendungen - vielleicht sogar noch in Assembler geschrieben. Der gesamte Code in einer Datei. Moderne größere Anwendungen sind in voneinander möglichst unabhängige Module unterteilt. Üblich ist eine drei Schichtenarchitektur in der Art:

• Frontend, GUI
• Business Layer, Logik
• Backend, Datenbank

Für die Erstellung eines Frontends und die Verdrahtung von Backend und Business Layer gibt es ausgereifte standard Libraries. Das Frontend folgt dem Model-View-Controller Design Pattern. Und die Datenbank wird über einen Entity-Relationship-Mapper auf Datenobjekte im Business Layer abgebildet. Diese beiden Patterns sind erprobt, ausgereift und funktionieren recht gut. Nur die eigentliche Logik in der Mittelschicht wird nach wie vor noch in "Spagetthi Code" gezwängt. Hier gibt es noch keine allgemein übliche Vorgehensweise.
Meiner Meinung nach sind Rule Engines genau der richtige Lösungsansatz hierfür. Hier betrachtet man die Business Logik nicht mehr als Code, sondern als reine Konfigurations Daten in strukturierter WENN-DANN-Form, z.B. "Wenn der Mietwagen Fahrer älter als 25 ist, dann bekommt er einen Rabatt von 15%." Diese Regeln können sogar toolgestützt von einer Fachabteilung (in Textfiles) verwaltet werden. Diese Textfiles werden dann von einer RuleEngine eingelesen, validiert und können dann auf gegebene Facts (=einen gegebenen Mietwagenfahrer) angwendet werden.

Zur Laufzeit einer Anwendung können diese Regeln dann einfach verändert und neu eingelesen werden, ohne dass die RuleEngine dabei selbst angefasst werden muss. Die Business Logik wird einfach als reine Konfigurationsdaten betrachtet.

Siehe: JBoss Drools Rule Engine

Die Mutter aller Fehler

Versuchen sie sich einmal zu erinnern, als sie das letzte Mal einen Fehler in ihrem Berufsleben gemacht haben. Mal ehrlich: Woran lags? Wollen wir mal Fehler aus Faulheit und Leichtsinnsfehler ausschließen. Ich spreche von Situationen, in denen man es wirklich versucht hat. Man wollt es ernsthaft richtig machen. Und trotzdem ging es schief.

Ich bin der Überzeugung, dass sich so ein Fehler fast immer darauf zurückführen lässt, dass man irgendwo vorher in der Kette eine falsche Annahme getroffen hat. Man ging von einer Voraussetzung als selbstverständlich aus, die man nicht überprüft hat.

Wenn sie also mal einen Fehler suchen, dann prüfen sie ihre Annahmen.

Anforderungsmanagement

Kennen sie das? Aus der Fachabteilung kommt die Anfrage: Ich brauche das Passwort für den Server. Völlig erstaunt Fragt man vorsichtig zurück: "Wozu denn?" Und schon geht der Streit los: "Bei euch in der IT Abteilung bekommt man nie was man will. Ständig muss man sich rechtfertigen!" Und schon sind alle Vorurteile mal wieder erfüllt. ("self fullfilling prophecy" nennt sich das in der Psychologie)

Dabei wollte der Arme Mitarbeiter doch einfach nur ein bestimmtes Dokument vom Server lesen. Dass er dazu kein Server Root Passwort braucht ist ihm natürlich nicht bewusst. Ein einfacher Nur-Lese Zugriff z.B. auf das Fileshare wäre eigentlich das was er gebraucht hätte.

Wo liegt nun der Fehler in dieser traurigen Geschichte? Wirklich beim armen Mitarbeiter aus der Fachabteilung? Nein, ganz so einfach ist es nicht. Den von dieser Rolle kann man ja nicht verlangen, dass er weis was ein Samba-Share ist. Der Fehler liegt in der Anforderung. Der Mitarbeiter forderte ein Passwort, weil er denkt das löst sein Problem. Er möchte das Dokument sehen. Doch eigentlich hätte er nicht mit der seiner Meinung nach richtigen Lösung auf die IT-Abteilung zukommen sollen, sondern mit seinem Problem: "Ich möchte dieses Dokument lesen können." Es ist dann aufgabe der IT-Abteilung ihn dafür die passende Technologie zur Verfügung zu stellen.