VSTS im Einsatz: Team gewinnt

(…)
im Sinne einer Wertsteigerung, also MSF
for Agile Software Development
und MSF
for CMMI Process Improvement
, von der
Stange direkt zum Einsatz kommen [5];
MSF ist hochgradig skalier- und erweiterbar,
sodass die genannten agilen bzw. formalen
Prozessmodelle an unternehmensspezifische
Anforderungen anpassbar sind.
Passt das immer noch nicht, sind eigene
Prozessmodelle oder die von Drittherstellern
denkbar [6], in die das enorme Wissen
der elegant mit Heuristiken, Metriken und
Best Practices jonglierenden Mitarbeiter
einfließen kann. Implizites Wissen kann
damit sogar explizit gemacht werden. Damit
werden die „recht langweiligen“ und
Peter-Prinzip-verdächtigen Prozesse automatisiert
und stehen auch nicht mehr
neben Software-Entwicklungs-projekten,
sondern sind immer und zu jeder Zeit ein
essentieller Teil von ihnen. Darum ist MSF
die Grundlage und weil es Bestandteil der
Software-Familie VSTS ist, tut es als „Formula
X“ das Wunderwerk – die Integration
im Team.

Gehe direkt ins Gefängnis, gehe nicht über Los?

Klingt das alles vielleicht ein wenig zu abstrakt?
Wie wäre es denn mit einem Gefängnis
von Projektleitern für Software-
Entwickler? Ein Schelm ist, wer jetzt an etwas
mit Gitterstäben statt Getränke- bzw.
Kaffeeautomaten in den Fluren von Abteilungen
denkt. Vielmehr könnten über
automatisierte Testläufe bzw. Reporting/
Monitoring sichergestellt werden, dass
Software-Entwickler nicht allzu vielen Programmierfehlern
eine Korrektur schuldig
bleiben. Sind zu viele Programmierfehler
nicht behoben worden, wird der Software-
Entwickler ins „Programmierfehler-Gefängnis“
gesteckt und darf keinen produktiven
Quellcode mehr schreiben. Erst wenn
der betroffene Software-Entwickler seine
verursachten Programmierfehler auf ein
bestimmtes Maß oder gar auf Null reduziert
hat, darf er wieder produktiv wirken. Vorstellbar
wäre auch eine ganz andere Situation:
Ist ein Software-Entwickler in einem
Projekt oder Unternehmen neu hinzugekommen
und produziert häufig trotz exzellenter
Fähigkeiten eine Reihe von groben
Programmierfehlern, weil es immer
Zeit benötigt, bis die Dinge so laufen wie
sie sollen, könnte der Software-Entwickler
ebenfalls in das „Programmierfehler-
Gefängnis“ gesteckt werden: Er schreibt
infolgedessen keinen produktiven Quellcode
mehr und muss vielleicht im Sinne
von „Pair Programming“ erst eine Zeit
lang anderen über die Tastatur und auf den
Monitor schauen. Ob das sehr sinnvoll und
bereichernd ist oder nicht, kann hinterfragt
werden. Umsetzbar ist es über das MSF,
mit dem so auch eine Unternehmenskultur
einbezogen werden kann. Im Übrigen ist
so eine Einschränkung der Zugriffsrechte
natürlich auch für andere Rollen denkbar,
sodass zum Beispiel Projektleiter den
Status einer Aufgabe (Work Item) ändern
können, aber dafür nichts am Quellcode.

Die Rolle Tests & Reports im Ökosystem

Das MSF-Teammodell definiert ein Team
aus gleichberechtigten Partnern, die rollenbasiert
untereinander abhängig sind
und miteinander kooperieren. So gibt es
Programm-Management, Entwicklung,
Test, Logistikmanagement, Benutzerausbildung

und Produktmanagement. Aufgrund
dieses MSF-Teammodells gibt es
die rollenbasierten Produkte von VSTS.
VSTS ist also eine mögliche Implementierung
von MSF. Es ist aber nicht der Grund,
warum auf Folien von Microsoft zu VSTS
häufig ein Projektleiter, ein Architekt, ein
Entwickler, ein Tester und ein Wirtschaftsanalytiker
zu sehen sind. Ein Projekt kann
bei MSF for Agile oder MSF for CMMI oder
auch innerhalb eines eigenen unternehmensinternen
Prozess auch nur drei oder
aber auch neun Rollen besitzen. Abbildung
2 stellt dar, welches Mitglied aus der Software-
Familie VSTS, dabei welche Disziplinen
unterstützt.

Abb. 2: Unterstützte Disziplinen

Eine vorstellbare Rolle bei der Software-
Entwicklung, um die Prozesskontrolle
zu erhöhen und die von jedem seriösen
Anbieter von Anwendungen durchgeführt
wird, ist das Testen von Software.
Dass dabei der Begriff „Testen“ häufig und
nicht nur bei der Domäne der Software-
Entwicklung, dreimal genannt wird, soll
bestimmt eine Test-Resistenz aufbrechen.
Kosten-/Zeitdruck, Unwissenheit über die
Testverfahren oder schlichtweg Dilettantismus
wie in Form von „Testen? Ich mache
gute Arbeit – brauch ich nicht“ können
das Auffinden von Fehlern in den frühen
Phasen von Software-Entwicklungsprojekten
verhindern, die dann aber umso größere
Probleme und nicht nur einen kleine verschmerzbare
Fehler in den späteren Phasen
bedeuten können. Bei Visual Studio Team
System hat sich daran grundsätzlich nichts
geändert. Auch hier gilt: Testen, Testen,
Testen und übrigens Testen. Die Bedeutung
dessen könnte aber leicht mit einer
etwas anderen Interpretation erklärt werden:
Jetzt gibt es gegenüber Visual Studio
2003 endlich nicht nur die Möglichkeit,
überhaupt Testarten wie zum Beispiel einen
Unit Test ablaufen zu lassen, sondern
auch die Möglichkeit, die Tests wieder zu
verwenden. Ein Webtest, der die Interaktion
von einem Endanwender mit einer
Webanwendung simuliert, könnte so beispielsweise
für einen Lasttest verwendet
werden, bei dem Hunderte oder gar Hunderttausende
von virtuellen Endanwendern
simuliert werden.

Bei exzellenten Tests werden, bedingt
durch die hohe Variabilität bei Software,
häufig mehr Quellcode-Zeilen für Tests,
als für die eigentlichen zu testenden Quellcode-
Zeilen geschrieben. Hier ist eine solche
Wiederverwendung die Möglichkeit
schlechthin, noch mehr Testläufe „abzufeuern“,
um Schwachstellen zu identifizieren. (…)

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.