Spätestens seit dem Erscheinen des Agilen Manifests (einer Art Leitbild für agile Software-Entwicklung) ist es zu einer gewissen Inflation an Manifesten gekommen. Und da haben wir auf nichts dringlicher gewartet als auf ein neues agiles Manifest von Kent Beck (ausgegraben von PJMB), der bereits zu den Vätern des ursprünglichen Manifests gehört. Etwas sarkastisch könnte man so ein Manifest als eine ideologische Verkürzung der Welt zu einem Patentrezept bezeichnen. Und so ein Anspruch geht mir zu weit, so gut und so richtig die einzelnen Aussagen für sich auch sein mögen.

Das Projektmagazin berichtet, dass die Bundesstelle für Informationstechnik (BIT) den neuen Standard V-Modell XT Bund veröffentlicht hat. Details und Download gibt es bei der BIT.

Und noch einmal Pawel Brodzinski, der sich mit einem Beitrag von Jennifer Bedell auf PMStudent zum Thema Testmanagement auseinander setzt: Testen kann auch ausufern, wenn der Scope des Projekts aus dem Auge verloren wird und weit über die ursprünglichen Projektauftrag hinaus getestet wird. Zurecht weist Pawel darafhin, dass die Erfüllung von Spezifikationen mitunter noch wenig über die tatsächliche Qualität des Ergebnisses aussagt. Auch wenn alle Anforderungen erfüllt sind, kann der Patient bereits tot sein. Der Test der Spec stelllt quasi den minimalen Testumfang dar,  aber um die Qualität sicherzustellen braucht es „mündige Tester“, die auch nach rechts und links schauen, aber mit Augenmaß, um nicht einfach den Projektauftrag beliebig zu erweitern und die Kosten aus dem Ruder laufen zu lassen.

Pawel Brodzinski bringt es auf den Punkt: Bei aller Methoden-Diskussion – letztlich zählt nur das Ergebnis und dessen Qualität, da sollte es keine Rolle spielen ob das mit agilen oder klassischen Methoden erreicht wurde. Auch die beste Methode ist bei fehlendem Qualitätsbewußtsein unzulänglich. Pfusch bleibt Pfusch!

In unserem Powerpoint-verseuchten Alltag vergessen wir allzuleicht, dass es auch noch andere Visualisierungsmöglichkeiten gibt, z.B. Poster. Hier ein paar Beispiele:

• Andreas Heilwagen hat bei Serview zwei Prince2-Poster ausgegraben: Zum Einen eine Prozessübersicht, zum Anderen ein Ablaufdiagramm.
• Von der InterFace AG gibt es ein Scrum-Plakat.
• In Sachen Prozessmanagement gibt es von der Berliner BPM-Offensive einen Überblick über Business Process Model und Notation.

Die Beispiele sind alle sehr Methoden-lastig, aber Sie vielleicht schon mal daran gedacht Ihr Projekt in Poster-Form darzustellen: Auftrag & Inhalt, Stakeholder, Vorgehensweise, Beteiligte,…

Sebastian Preuss/ Seibert Media weist in einem lesenswerten Beitrag auf die Bedeutung des Debriefings im Testmanagement hin. Die Tester im User-Test sichern nicht nur die Qualität, wir sollten ihren Einfluss auf das Changemanagement auch nicht vergessen! Ihre Eindrücke und ihr Feedback landen früher oder später bei den Anwendern. Selbst wenn der Test schief lief, können sie bei den Anwendern für Verständnsi und Akzeptanz beitragen.

Mit dem Thema Testmanagement haben wir uns hier auch schon wiederholt auseinander gesetzt:

#195 Testmanagement in IT-Projekten
#187 Umgang mit Testfehlern
#156 Excel Toolset
#153 Your Unit Tests lies to you
#148 Testmanagement in IT-Projekten: Organisation und Ablauf
#145 „Effektives“ Testmanagement
#86 Gute Tester, schlechte Tester

Neuerdings häufen sich untern den Anhängern von agilen Methoden Posts über Kanban. So widmen sich z.B. Pawel Brodzinski und Henrik Kniberg dem Thema.

Kanban kommt eigentlich aus der Produktionssteuerung und beruht im Wesentlichen auf dem Pull-Prinzip. Statt einer zentralen Steuerung (also übertragen einer zentralen Planvorgabe), wird dezentral ja nach aktuellem Bedarf (also situationspezifisch je Sprint) Material (also Input/Requirements/Zulieferungen) abgerufen.

Auch über Lean Management findet man gelegentlich ähnliche Übertragungen auf das Projektmanagement.

Die guten alten Management-Methoden finden also im Projektmanagement und der Softwareentwicklung ein erfolgreiches Recycling.

Craig Brown von Better Projects hat eine Taxonomie für Requirements von Don Firesmith ausgegraben. Zugegeben, solche Übersichten sind immer etwas abstrakt und theoretisch, haben aber durchaus ihre Berechtigung, z.B. um einen Anforderungskatalog auf Vollständigkeit und Qualität hin zu überprüfen.

Je besser der Anforderungskatalog, umso überschaubarer werden die erforderlichen Änderungen (jedenfalls im Normalfall).

Natürlich wird es immer Änderungen geben, denn die Welt dreht sich immer weiter und wir wissen heute (hoffentlich) auch mehr als gestern. Paul Ritchie von Crossderry Blog weist darauf hin, dass bei Change Requests häufig eine der wichtigsten Fragen nicht gestellt wird, nämlich welche anderen Anforderungen/Changes möglicherweise auf der Strecke bleiben wenn ein bestimmter Change Request verabschiedet und realisiert wird. Sozusagen die Opportunitätskosten eines CRs.

Craig Brown schlägt Storyboards als „requirement tool“ vor. Leider beschränken sich seine Ausführungen auf die Überschrift und ein Youtube-Video über Storyboards im Film. Storyboards sind natürlich auch wieder eine Visualisierungstechnik, insofern ist der Ansatz interessant. Die Frage liegt darin, wie Storyboards auch auf abstraktere, weniger visuelle Themen als Film oder beispielsweise die Präsentationserstellung angewendet werden können.

Über SCRUM war hier schon öfters die Rede. Bei Henrik Kniberg finden sich aktuell zwei interessante Beiträge zu SCRUM (alle in Englisch). Zum Einen die Präsentation zu seiner SCRUM-Einführung auf der Agile 2009 in Chicago, zum Anderen seine SCRUM Checklist 2.0, „a simple tool to help you get started with Scrum, or assess your current implementation of Scrum“.