Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Agile Development Best Practices

Mittwoch, 24. November 2010

In Ihrem Vortrag berichteten Aaron Bjork – Program Manager für Team Foundation Server (TFS) und Peter Provost – Senior Program Manager für Visual Studio Ultimate über das neue Scrum Template für TFS und wie man es einsetzt. Die Aufzeichnung der Session finden Sie hier.
Neben den Einblicken in die Handhabung von Product Backlog Items, Bugs und Tasks in Produkt- und Sprintplanung, wurden die Erfahrungen aus den Projekten vom Publikum besonders geschätzt. Diese wurden von den Präsentatoren in Form von 12 Take-Aways formuliert sind im folgenden noch einmal zusammengefasst und mit unseren Erfahrungen ergänzt worden.

1. Define Done

Akzeptanzkriterien sind wichtig für die Definiton von Backlog Items. Jeder, der mitwirkt diese herunterzubrechen, muss sie gelesen und wie die Story-Beschreibung selbst auch verstanden haben. Aaron nannte als Beispiel die Entwicklung der Burndown-Charts in seinem Team. Gegen Ende des Sprints stellte er fest, dass die Entwickler nur die blanken Burndowns lieferten – ohne die wichtigen Metadaten um den Chart herum. Wie er feststellen musste, war die Erwartungshaltung in Form der Akzeptanzkriterien nicht klar definiert.

2. Fail fast

Scrum eignet sich besonders in Projekten, die nicht zur Gänze überblickt werden können – sei es technologisch oder durch unklare Marktanforderungen her bedingt. Die kurzen Sprint dienen der Risikoreduzierung, etwas langfristig zu planen, viel zu investieren, nur um danach festzustellen, dass man am Markt vorbeigeplant hat. Frühes Scheitern ermöglicht eine schnellere Reaktion auf neue Erkenntnisse.

3. Understand your teams velocity

Der Umfang der tatsächlich geleisteten Arbeit im Vergleich zur Abschätzung soll in vielen Unternehmen die Qualität der initialen Schätzungen erhöhen. Peter ist in 20 Jahren nicht ein Projekt untergekommen, bei dem dies funktioniert hat. Hingegen sei es wichtig, die Geschwindigkeit des Teams zu ermitteln. Diese wird sich mit der Zeit auf einem bestimmten Wert einpendeln (wenn das Team stabil bleibt) und gibt Auskunft darüber, wie viel sich das Team für den nächsten Sprint vornehmen kann. Aaron betonte, dass die Velocity auf Dauer nur zur Transparenz und Vorhersagbarkeit beitragen kann, wenn die Rahmenbedingungen gleich bleiben. Dazu zählen die Sprint-Länge, die Unveränderbarkeit der commiteten Backlog-Items usw.

4. Write unit tests – always

Peter machte deutlich, dass Unit-Test allein Sache der Entwickler seien. Ein professioneller Entwickler schreibt nach dem TDD Ansatz erst die wie er sie lieber nennt „Entwicklertests“ und dann den Code, der diese erfüllt. Er nannte den Ansatz „Red, Green, Refactor“. Peter zeigte eindrucksvoll mit Hilfe des X.Net Unit-Testing-Frameworks, welches Unit Tests immer gleich im Build ausführt, sowie dem ReSharper für das schnellere Coden und Refaktorieren, wie es sich mit den richtigen Tools und Visual Studio agil programmieren lässt.

5. Bugs are real work

Im Scrum Template werden Bugs wie Product Backlog Items behandelt. Fehler in bereits geleisteter Arbeit zu beheben ist wichtiger als neue Funktionen zu bauen, schließlich war die fehlerhafte Funktion ja höher priorisiert als die anstehende Funktion. Daher sollten diese einen entsprechend hohen Rang im Backlog einnehmen und schnell aus der Welt geschafft werden.

6. Code with confidence

Peter betonte ein häufig auftretendes Phänomen bei der Abschätzung des Aufwandes. Oft kommen Aussagen wie: „Das wird könnte durchaus ca. 2-3 Wochen dauern.“ Das ist in Peters Augen keine Abschätzung, sondern ein Hinweis darauf, dass große Unsicherheit herrscht. Er empfiehlt noch einmal die Problemstellung zu überdenken, den Code und die Architektur zu verstehen und durch das Schreiben von Tests vorab an Sicherheit zu gewinnen, damit man mit Confidence an die Aufgabenstellung herangehen kann – bei Abschätzung und Umsetzung.

7. Always deliver value

Ein wesentlicher Aspekt der täglichen Arbeit ist es, immer den zu liefernden Nutzen im Auge zu haben. Vor allem Entwickler treffen mehrmals häufig undokumentierte Entscheidungen zum Verhalten einer Anwendung. Verliert man dabei den Nutzen einer Funktion aus dem Fokus, dominieren schnell technische Gegebenheiten die Anwendung.

8. Finish what you start

Ein Problem, welches in vielen Fällen dafür sorgt, dass nichts fertig wird ist es, zu viele Dinge auf einmal anzufangen. Stellen Sie sicher, dass Sie nur die Dinge anfangen, die Sie abschließen können und die zum Zeitpunkt des Beginns auch als wichtig eingestuft sind.

9. Autonomy, mastery, purpose

Das Team muss in gewisser Hinsicht autonom agieren können. In der Software-Entwicklung müssen regelmäßig Entscheidungen getroffen werden, die einen mal mehr mal weniger großen Einfluss auf das Produkt haben. Das Team sollte bis zu einem definierten Grad derartige Entscheidungen unkompliziert selbst treffen können – sollte diese aber inkl. einer Begründung für die Wahl aus möglichen Optionen dokumentieren (z.B. in Design-Dokumenten oder im Code). Die Mitglieder benötigen zusätzlich die Möglichkeit wirkliche Exzellenz in einem Bereich Ihrer Arbeit zu erlangen und zu wissen und zu spüren, dass diese Expertise auch im Team benötigt wird, d.h. Sie einen Zweck hat.

10. Do the right thing … At the right time

Viele Dinge erscheinen dringend, entpuppen sich aber bei genauerer Betrachtung als unwichtig. Konzentrieren Sie sich bei der Auswahl der nächsten Tätigkeiten auf das Wesentliche. Das hilft Ihnen Dinge zum richtigen Zeitpunkt zu liefern und das Richtige zum richtigen Zeitpunkt abschließen zu können.

11. Plan until you need to learn

Eines der Hauptanliegen der Präsentatoren war es zu verdeutlichen, dass Planung zu jedem Projekt dazu gehört. Auch zu agilen Projekten. Doch muss der Plan regelmäßig an die aktuellen Erkenntnisse angepasst werden. Daher ist Planung bis zum nächsten zu erwartenden Erkenntnisgewinn richtig und wichtig. Langfristige Detailplanungen hingegen verursachen lediglich Mehrarbeit bei der späteren Anpassung der Planung. Auch bei der Planung sind Nutzen und Wert wesentliche Kriterien für einen Projektplan.

12. Quality is not a variable

Peter betonte abschließend noch die Wichtigkeit von Qualität. Passen Sie in Ihren Projekten alle möglichen Stellgrößen den Gegebenheiten nach an. Lassen Sie die Qualität dabei aber unberührt auf hohem Niveau.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , ,

Hinterlasse eine Antwort