30.11.2011

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)

28.11.2011

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.

22.11.2011

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.

15.11.2011

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

14.11.2011

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.