TFS 2013 Prozess Templates im Vergleich – CMMI vs. Agile

MSF for CMMI Process Improvement 2013 vs. MSF for Agile Development 2013

Im ersten Teil der Reihe TFS 2013 Prozess Templates im Vergleich habe ich die beiden agilen Prozess Templates, Visual Studio Scrum 2013 und MSF for Agile Developement 2013, miteinander verglichen. Die Unterschiede zwischen den beiden Templates fallen eher gering und sind hauptsächlich in den Workflows der jeweiligen Work Item Typen zu finden. Im zweiten Vergleich werde ich das Prozess Template für agile Entwicklungsprozesse dem Template für formale Entwicklungsprozesse gegenüberstellen. Mal sehen, ob es hier eine eindeutigere Antwort auf die Frage „Welches Prozess Template ist das Richtige“ gibt? Den ersten Teil des Vergleichs gibt es hier zum Nachlesen.

Der Vergleich basiert auf den Templates „MSF for Agile Developement 2013“ und „MSF for CMMI Process Improvement 2013“, die mit dem Team Foundation Server 2013 (Stand Nov. 2013) ausgeliefert werden.

MSF for CMMI Process Improvement 2013

Dieses Template ist zur Unterstützung und Verwendung in einem formalen Change Management Prozess gedacht. Wenn Ihr mindestens eines der folgenden Kriterien in Eurem Entwicklungsprozess berücksichtigen müsst, dann solltet Ihr über die Verwendung dieses Templates nachdenken:

  • Projekte haben einen sehr langen Lebenszyklus
  • Revisionssicherheit
  • Tracing von Entscheidungen
  • Sehr auf Softwarequalität bedacht
  • Explizite Prozessvorgaben bevorzugt

Hinweis: Ich werde in diesem Post nicht im Detail darauf eingehen, wie ein CMMI Projekt geplant und organisiert wird. In den Seiten des MSDN gibt es eine gute Beschreibung dazu.

MSF for Agile Development 2013

Dieses Template wurde entworfen, um alle Teams zu unterstützen, die sich nicht dem reinen Scrum verschrieben haben, aber dennoch einen agilen Entwicklungsprozess verfolgen. So steht es zumindest sinngemäß in der MSDN.

Müsst Ihr mindestens eines der folgenden Kriterien in Eurem Entwicklungsprozess unterstützen, solltet Ihr Euch mit diesem Templates näher befassen:

  • Entwicklung in kurzen Entwicklungszyklen
  • Flexibler Umgang mit Änderungen
  • Reviews sind Teil der DoD und damit Teil einer User Story

Vergleich

Work Item Typen des CMMI Templates und Agile Templates

Die beiden Prozess Template unterscheiden sich in erster Linie durch den Bereich „Change & Risk Management“, der im CMMI Template zusätzlich zwei Work Items (Change Request und Risk) zur Verfügung stellt. Ansonsten befinden sich in den beiden Templates elf weitere Work Item Typen, wovon fünf für die Planung und Entwicklung benötigt werden (Feature, Requirement bzw. User Story, Task, Bug und Issue), zwei für das Test Management (Test Case und Shared Steps), zwei für die Feedback-Funktionalität (Feedback Request und Feedback Response) und zwei für die Code-Review-Funktionen (Code Review Request und Code Review Response).

Planungsrelevante Work Items des CMMI Prozess Template

Abbildung 1: Planungsrelevante Work Items des CMMI Prozess Template

Planungsrelevante Work Items des Agile Prozess Template

Abbildung 2: Planungsrelevante Work Items des Agile Prozess Template

Eine rein oberflächliche Betrachtung wäre aber auch hier nicht ausreichend. Der Teufel liegt oft im Detail!

Feature

Das Feature Work Item wird in beiden Templates gleichbedeutend eingesetzt. Es soll die Planung von Anforderungen über mehrere Entwicklungszyklen hinweg ermöglichen, d.h. es bündelt User Stories oder Requirements aus verschiedensten Zyklen und hebt dadurch den Planungslevel auf eine abstraktere Ebene.

Wenn man das Work Item aus beiden Prozess Templates miteinander vergleicht, fällt zum einen der unterschiedliche Workflow auf. Dort findet man Differenzen sowohl in der Namensgebung der Zustände, als auch in deren Anzahl.

Workflow des Feature Work Items im CMMI Template

Abbildung 3: Workflow des Feature Work Items im CMMI Template

Workflow des Feature Work Items im MSF for Agile Template

Abbildung 4: Workflow des Feature Work Items im MSF for Agile Template

Zwei weitere Unterschiede findet man in der Definition der Work Item Felder. Das Feld Triage und Risk existiert nur im Work Item Type aus dem Template für formale Prozesse.

In Tabelle 1 ist eine Gegenüberstellung der wichtigsten Felder und zeigt auch deren Unterschiede:

ComparePT2_FeatureFields

Requirement vs. User Story

Das Requirement und das User Story Work Item werden verwendet, um die zu erstellenden Komponenten und Funktionen zu spezifizieren.

Zur Klassifizierung der Work Items stehen dem Nutzer im CMMI Template die Felder Size und Business Value zur Verfügung, mit deren Hilfe der Product Owner eine Priorisierung vornehmen kann. Der Business Value schätzt den Kundennutzen ab und Size den Aufwand für die Entwicklung. Hier wird auch gleich ein Unterschied zwischen den Work Items deutlich. Das User Story Item arbeitet mit Feld Story Points und stellt ausserdem kein Feld für die Bewertung des Business Values bereit. Dafür gibt es das Feld Risk, welches die Bewertung des Risikos einer Anforderung bezogen auf das Gesamtsystem zulässt.

Hinweis: Der Business Value kann im MSF Agile Template über das Feature Work Item definiert werden, dem eine gewisse Anzahl von User Stories untergeordnet sind.

Tabelle 2 zeigt eine Auflistung der wichtigsten Felder beider Work Items:

ComparePT2_RequirementUserStoryFields

Das Feld Triage wird dazu verwendet, um einen Entscheidungsprozess zu dokumentieren. Das Feld kommt auch noch in weiteren Work Items (Bug, Task, Change Reuquest und Issue) zum Einsatz und hat folgende Zustände:

  • Pending – es wird auf eine Entscheidung gewartet (z.B. wird die Anforderung umgesetzt)
  • More Info – es wird auf weitere Infos gewartet, um die Entscheidung treffen zu können
  • Info Received – es wird auf eine Entscheidung auf Basis der neuen Infos gewartet
  • Triaged – es wurde eine Entscheidung getroffen

Neben den abweichenden Feld Definitionen gibt es auch Unterschiede im Workflow beider Work Items. Wie im Feature Work Item heißen die Zustände anders, z.B. Proposed statt New und der Zustandsübergang von Closed zurück auf den Ursprungszustand (Proposed / New) gibt es ebenfalls nicht mehr.

Workflow des Requirement Work Items aus CMMI Prozess

Abbildung 5: Workflow des Requirement Work Items aus CMMI Prozess

Workflow des User Story Work Items aus Agile Prozess

Abbildung 6: Workflow des User Story Work Items aus Agile Prozess

Task

Eine Aufgabe wird in beiden Prozess Templates durch ein Task Work Item abgebildet. Der Task unterscheidet sich in den Templates sowohl im Workflow als auch in den Feld-Definitionen.

Während im CMMI Template die bekannten Zustände Proposed, Active, Resolved und Closed zu finden sind, existieren im MSF Agile Template zwar genauso viele Zustände (New, Active, Closed und Removed), aber deren Übergänge sind anders definiert.

Workflow des Task Work Item des CMMI Template

Abbildung 7: Workflow des Task Work Item aus CMMI Template

Workflow des Task Work Item des Agile Template

Abbildung 8: Workflow des Task Work Item des Agile Template

Zur Vollständigkeit sind in der nachfolgenden Tabelle die wichtigsten Felder des Task Work Items beider Templates aufgelistet:

ComparePT2_TaskFields

Bug

Über das Bug Work Item werden Fehler in der Anwendung verwaltet. Die Work Items beider Templates unterscheiden sich nur wenig. Es gibt leichte Differenzen im Workflow, sowohl in der Anzahl der Status als auch in der Benennung.

Bug Workflow aus CMMI Template

Abbildung 9: Bug Workflow aus CMMI Template

Bug Workflow aus Agile Template

Abbildung 10: Bug Workflow aus dem Agile Template

Ausserdem gibt es ein paar Unterschiede bei den Feld Definitionen der Work Items, diese sind in folgender Tabelle zusammengefasst:

ComparePT2_BugFields

Das Feld Root Cause gibt Aussage darüber, was der Ursprung des Fehlers ist und lässt folgende Unterscheidungen zu:

  • Coding Error
  • Design Error
  • Specification Error
  • Communication Error

Issue

Ein Issue Work Item wird benutzt, um Probleme nachzuverfolgen, die zu einer Blockade des Entwicklungsprozesses führen könnten. Wie in den nachfolgenden Grafiken deutlich zu erkennen ist, haben die Work Items in den beiden Prozessen eine unterschiedliche Gewichtung. Während der Workflow im CMMI den anderen Work Items (Task, Bug, Requirement und Feature) sehr stark ähnelt und ebenfalls vier Zustände besitzt (Proposed, Active, Resolved und Closed), hat das Issue Work Item im agilen Template nur zwei Stunde (Active und Closed).

Workflow des Issue Work Items aus CMMI Prozess

Abbildung 11: Workflow des Issue Work Items aus CMMI Prozess

Workflow des Issue Work Items aus Agile Prozess

Abbildung 12: Workflow des Issue Work Items aus Agile Prozess

Auch in der Anzahl der Work Item Felder gibt es Unterschiede. So hat das Issue Work Item aus dem CMMI Template wesentlich mehr Felder, die zur Problembeschreibung und -beseitigung dienen als das agile Template:

ComparePT2_IssueFields

Change Request, Risk und Review

Die drei Work Item Typen Change Request, Risk und Review werden für das Änderungs- und Risikomanagement benötigt. Ein Change Request wird für jede Änderung erstellt, die unter die Kontrolle des Änderungsmanagements fällt. Risk Work Items werden für jede Art von Risiko angelegt, sei es ein Ereignis oder eine Situation, welches den Gesamtprozess blockieren könnte und Review Work Items dienen zur Dokumentation von Design- oder Code-Reviews.

Da es im MSF for Agile Prozess Template kein Pendant dazu gibt, verzichte ich auf eine Auflistung der Status und Work Item Felder und verweise auf die MSDN. Dort wird die Verwendung dieser Work Items ausführlich beschrieben.

Zusammenfassung

In der Gegenüberstellung der beiden Templates fällt auf, dass eigentlich nichts so richtig Auffallend ist. Gravierende Differenzen kann ich in der reinen Betrachtung der Artefakte nicht erkennen, außer dass das CMMI for Process Improvement Template drei Work Items mehr besitzt.

Sicherlich sind das auch die entscheidenden Work Items, wenn ich einen formalen Prozess verfolge, der sehr stark auf die Nachverfolgung von Änderungen und Risiken ausgelegt ist. Aber irgendwie hatte ich mir mehr Abgrenzung erwartet. Für mich sieht es fast ein wenig so aus, als wäre das MSF for Agile Development Template ein abgeleitetes CMMI Template, mit etwas entschlackten Feld Definitionen und agileren Work Item Namen. Wer ein etwas flexibleres und schlankeres Template sucht, der sollte sich auf jeden Fall das Microsoft Visual Studio Scrum Template ansehen. Das ist ja auch zugegebenermaßen mein Favorit.

Abschließend lässt sich wie immer feststellen, die Auswahl des am besten geeigneten Prozess Templates hängt sehr stark vom gelebten Prozess ab. Eventuell kann ein Template den Prozess auch nur zum Teil abbilden und es muss erst noch erweitert und angepasst werden.

Deswegen mein Tipp! Bevor ihr euch final auf ein Prozess Template festlegt, erstellt erstmal ein Spiel-Projekt mit Eurem favorisierten Template und überprüft, in wie weit das Template Eure Anforderungen erfüllt und Euren Prozess unterstützt.

[1] MSDN: http://msdn.microsoft.com/en-us/library/dd997574.aspx

[2] MSDN: http://msdn.microsoft.com/en-us/library/ee332488.aspx

[3] MSDN: http://msdn.microsoft.com/en-us/library/dd380647.aspx

[4] MSDN: http://msdn.microsoft.com/en-us/library/ee461565.aspx