Da ich in der Vergangenheit auch zu den Leidtragenden gehörte, die aufgrund von ungenauen Vorgaben Termine nicht einhalten konnte, ist es sicherlich auch hier einmal Zeit einen Beitrag zum Thema Anforderungsmanagement zu widmen.Aber zuerst eine Definition:

Anforderungsmanagement (engl. Requirements Management) ist eine Managementaufgabe für die effiziente und fehlerarme Entwicklung komplexer Systeme. Es umfasst die Anforderungserhebung  Requirements-Engineering) sowie Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risikomanagement, Änderungsmanagement und Umsetzungsmanagement.

Quelle: Wikipedia

Bei meiner Suche zum Thema agiles Anforderungsmanagement, bin ich auf einen Vortrag von Detlef Buder und Alexander Fischbach gestoßen, in dem sie die Fragen beantworten:

• Benötigen agile Entwicklungsmethoden überhaupt ein Anforderungsmanagement im klassischen Sinne?
• Wie viel ist “soviel Dokumentation wie nötig” in Bezug auf die Anforderungsanalyse?
• Wie viel muss ich über ein zu erstellendes System wissen, damit ich mit der iterativ / inkrementellen Entwicklung starten kann?

Ich sehe das Anforderungsmanagement als eines der Kernthemen im Projektmanagement, bleibt zu klären, in wie weit es sich in agile Vorgehensmodell integrieren läßt.

Dieser Artikel hat mich mal wieder bestätigt. Es geht darum, dass wir häufig auf das hören, das wir bezahlt haben. Grundlage ist ein Artikel von Francesca Ginoa (”Do we listen to advice just because we paid for it?”) in dem die Autorin in einem kontrollieren Experiment genau das nachweist.

In kaum einem anderen Bereich wird dies so deutlich, wie im IT-Consulting. Ich erlebe es immer wieder in Projekten, in denen blind auf die Beratungleistung der Consultants vertraut wird, ist der Prophet im eigenen Lande nichts wert. Allerdings erhält mein Wort deutlich mehr Gewicht, wenn ich als externer Berater in einem Unternehmen meine Meinung äußere, als bei meinem eigenen Arbeitgeber. Schlimm wird es erst, wenn man aus Projekten aufgrund einer “kritischen” Meinung herausgehalten wird. Das erinnert mich an die Fabel von James Thurber: “The Owl Who Was God”. Hier ergeht es einem wie dem Fuchs in der Fabel, der von der Gemeinschaft der Tiere verstoßen wird.

In diesem Sinne - schönes Wochenende.

Die Vorteile von agilen Vorgehensweisen in IT-Projekten sind hinlänglich bekannt (oder hier nachzulesen).  Kritiker meinen, dass bei diesen Methoden häufig der Gesamtüberblick verloren geht. Dadurch dass das Big Design Up Front (oder Bug Desgin Up Front) fehlt, und die Systeme iterativ entworfen werden, kann man schnell das ingenieurmäßige Vorgehen vermissen.

Agile Projekte stehen aber nicht im Konflikt mit den Ingenieurswissenschaften. Ganz im Gegenteil, dort werden sie seit den 80 erfolgreich eingesetzt. Ziel agiler Projekte ist vielmehr der Blick auf das Wesentliche zu beschränken. Dennoch fehlt häufig das „Big Picture“ für den Gesamtüberblick.

Genau dort kommt das Fundamental Modeling Concept (FMC) zum Einsatz. Mit Hilfe des FMC kann man Fach- und IT-Landkarten erstellen,  die allen Projektbeteiligten helfen einen schnellen Überblick zu bekommen.  Ich habe mir das Landkartenkonzept einmal näher angesehen und bin davon überzeugt. Im Vergleich zu Unified Modeling Language (UML), kann man FMC –Blockdiagramme ohne großen Lernaufwand auf Anhieb verstehen.  Das genügt um nach meinem Grundsatz zu handeln:

“So einfach wie möglich - aber nicht einfacher”

Probieren Sie es mal aus: http://www.fmc-modeling.org/

Es ist schon verwunderlich, dass viele Menschen das Magische Dreieck des Projektmanagements kennen, aber bei technischen Systemen ein ähnliches Spannungsfeld nicht akzeptieren. Dabei ist es doch so einfach, die Eigenschaften eines Software- oder Hardwaresystems auf grundlegende Werte zu reduzieren und diese anschließend zu vergleichen.

Diese Eigenschaften stehen in einem Spannungsfeld nur kommt die Erkenntnis erst später im Projektverlauf.  In den Weiten des Internets habe ich einen Artikel dazu gefunden, der die Eigenschaften solcher Systeme vergleicht und eine andere Bezeichnung findet:

• gut + schnell = teuer
• gut + günstig = langsam
• schnell + günstig = minderwertig

Leider ist es so, dass niemand solch sprechenden Bezeichnungen für ein System verwendet. Das würde dem Kunden sofort die Augen öffnen. Aber grundsätzlich wissen Sie nun, wenn Sie ein schnelles, günstiges System erworben haben, ist es von minderer Qualität. In diesem Sinne.

Es ist mal wieder soweit.  Heute ist der System Administrator Appreciation Day. An diesem Tag wird den Systemadministratoren für ihre Arbeit hinter den Kulissen gedankt. Ich selbst weiß wie es ist, Sysadmin zu sein. Wenn die Benutzer merken, dass man da ist, handelt es sich vermutlich um einen Serverausfall, oder eine sonstige Störung. Wenn wir unsere Arbeit nieder legen, um zu streiken, merkt es keiner, wenn wir sie vorher gut erledigt haben. Ebenso wird grundsätzlich nur gemeckert, wenn die Benutzer Spam-Mails empfangen – von den zigtausend, die täglich abgewehrt werden. Tja, als Sysadmin hat man es eben nicht leicht..