Agile Entwicklung mit verteilten Teams

Transkript

1 Datum: 8. März 2010 Themendossier für die User Group»Agile Methoden in der Softwareentwicklung«Agile Entwicklung mit verteilten Teams Seite 1

2 Einführung in das Thema In vielen Softwareprojekten haben sich in den letzten Jahren zwei Trends etabliert. Zum einen betreiben viele nordamerikanische und europäische Unternehmen Outsourcing und Offshoring um Lohnkosten zu sparen, Zugriff auf einen größeren und qualifizierten Mitarbeiterpool zu haben und globale Märkte zu erschließen. Zum anderen wird Software zunehmend nach agilen Ansätzen entwickelt. Da beide Trends die Wirtschaftlichkeit von IT-Projekten effizient steigern können, stellt sich die Frage, auf welche Art und Weise man diese Beiden miteinander kombinieren kann. Nach kurzer Betrachtung offenbaren sich die ersten Stolpersteine. Agile Vorgehen und Methoden setzen auf face-to-face Kommunikation, z. B. an Flipcharts oder kurze Meetings in kleinen Runden. Durch die Selbstorganisation der Teams und das ständige Interagieren wird Fachwissen über das Projekt verbreitet und für jeden Teilnehmer ist ein grober Überblick darüber vorhanden, wer an welchen Teilschritten arbeitet. Durch diese hohe Transparenz des Entwicklungsprozesses baut sich zwischen den Beteiligten schnell eine vertraute Arbeitsatmosphäre auf. Wichtige Informationen, wie z. B. der Projektfortschritt und Anforderungen, sind durch Burndown Charts an zentraler Stelle für alle ersichtlich. Agile Methoden wie Pair Programming und tägliches Deployment oder auch kontinuierliche Integration sichern die Qualität des Produktes. Im Gegensatz dazu gibt es innerhalb des Entwicklungsteams bei global verteilten Projekten eine hohe räumliche Distanz und die Kommunikation findet meist über Telefonkonferenzen, Dokumente und Chats statt. Aber nicht nur die Standorte liegen weit voneinander entfernt, sondern es existieren auch sprachliche, kulturelle und zeitliche Unterschiede, die den gesamten Prozess verzögern können. Verschiedene Verhaltensweisen können zu Unsicherheiten und Missverständnissen führen und erschweren so den Aufbau von Vertrauen und Teamgeist. Viele Teams müssen verteilt entwickeln, da es aus Kostengründen nicht anders möglich ist und es stell sich die zentrale Frage: Wie kann man trotzdem die Vorteile agiler Entwicklung mitnehmen? Betrachtet man unvoreingenommen die Fakten, so kann man erkennen, dass viele Eigenheiten der beiden Trends widersprüchlich sind bzw. sich nicht miteinander vereinen lassen. Unter welchen Umständen man dennoch mit verteilten Teams agil arbeiten kann, möchten wir Ihnen in diesem Themendossier vorstellen. Die ersten beiden Kapitel stellen basierend auf Erfahrungsberichten und Blogs bewährte agile Methoden in verteilten Umgebungen vor. Agilität zeichnet sich unter anderem durch ein tägliches Build und kontinuierliche Integration aus. Dies kann gerade in global verteilten Teams, bei denen versetzte Arbeitszeiten existieren, von großem Vorteil sein und längere Ausfallzeiten können so vermieden werden. Mit Hilfe von Ticketsystemen können Fehler, Verbesserungsvorschläge und neue Features an zentraler Stelle vermittelt werden und den Wissensfluss im Projektteam entscheidend fördern. Wikis unterstützen diesen Prozess und geben eine Möglichkeit das herzustellende System zu dokumentieren. Die folgenden beiden Kapitel des Themendossiers setzten sich speziell mit Scrum und verteilter Entwicklung auseinander. Normalerweise besitzt ein Scrum-Team eine Größe von fünf bis neun Personen. Bei größeren Projekten, die mehr Arbeitskraft benötigen, muss eine Neustrukturierung stattfinden. Implementiert ist dies durch Scrum of Scrums, bei dem sich für ein einzelnes Scrum-Team als Einheit nicht viel Seite 2

3 verändert. Jedes Team bestimmt einen Repräsentanten, der an einem Scrum of Scrums Meeting teilnimmt. Dieses dient der Abstimmung der Teams untereinander und hilft dabei mögliche Überschneidungen zu identifizieren um weitere Vorgehen einzuleiten. Diese Strukturierung lässt sich nach oben hin beliebig oft erweitern z. B. auf Scrum of Scrum of Scrums. Das dritte Kapitel fasst Erfahrungen zum Führen von Scrum of Scrums Meetings zusammen. Neben einer Auflistung von Problemen und Stolpersteinen, die sich bei der Umsetzung von Scrum mit mehreren Teams zeigten, werden auch Lösungsansätze vorgestellt. Das vierte Kapitel bietet eine Sammlung von Diskussionen und Blogs rund um das Thema Scrum of Scrums. Hauptschwerpunkt sind Fragen im Zusammenhang mit den richtigen Teamzusammensetzungen. Wer kommt in welches Team? Ist es besser direkt mit allen Teams in ein Projekt zu starten oder sollte man von Zeit zu Zeit weitere Teams hinzufügen? Diese und viele andere Fragen werden in diesem Themendossier beantwortet. Wir wünschen Ihnen eine interessante Lektüre! Bei Fragen kommen Sie gern auf uns zu. Ihr Team der Softwareforen Leipzig Seite 3

4 Inhaltsverzeichnis Erfahrungsberichte zu verteilter agiler Entwicklung Distributed Agile Distributed Agile Development at Microsoft patterns & practices Agile Softwareentwicklung mit verteilten Teams Using an Agile Software Process with Offshore Development Distributed Agile: Issues & Challenges, Patterns and Anti-Patterns Agile Prozesse in der Offshore-Softwareentwicklung Blogs zur verteilten agilen Entwicklung Scaling Agility: Distributed Agile Development 6 keys to succeeding with distributed agile development Making agile software development work for distributed teams Distributed Agile Development Scrum in verteilten Teams Advice on Conducting the Scrum of Scrums Meeting Scaling Scrum Without the Scrum of Scrums Scrum of Scrums Issues and Value Parallele Multi-Team-Produktentwicklung mit Scrum: ein Erfahrungsbericht Scrum of Scrums: Blogs und Diskussionen Gemeinsame Einheit für Schätzungen in Scrum of Scrums? Confessions of a scrum master scrum of scrums dilemas Scrum of Scrums: Making it visual Seite 4

5 Distributed Agile Quelle: IBM Global Services, Application Management Services Autor: Dr. Christoph Steindl Datum: Die Folien stellen zunächst Agilität und das agile Manifest im Allgemeinen vor und gehen auf Begriffe wie Extreme Programming oder Agile Modellierung näher ein. Der zweite Teil trägt die Schwierigkeiten, die die verteilte Entwicklung mit sich bringt, zusammen. Anschließend wird eine Methode vorgestellt, bei der agile Methoden auf verteilte Softwareentwicklung übertragen werden. Danach werden Verfahren aufgezählt, mit denen man Standortnachteilen entgegen wirkt und es werden Tools vorgestellt, welche die Zusammenarbeit unterstützen. Den Abschluss bilden die Meinungen von Beteiligten eines agilen und verteilten Projektes, die insgesamt ein sehr positives Feedback zu dieser Kombination äußern. Distributed Agile Development at Microsoft patterns & practices 9cf24822c6cc/distributed_agile_development_at_microsoft_patterns_and_practices.pdf Quelle: Microsoft patterns & practices Autor: Ade Miller Datum: In diesem Artikel beschreibt der Autor einen agilen und verteilten Entwicklungsansatz, der bei der Microsoft patterns & practices group in den letzten fünf Jahre verfolgt wurde. In einer kurzen Einführung werden die Vorteile der Arbeit von nah beieinander liegenden Teams, den Vor- und Nachteilen der globalen Softwareentwicklung gegenüber gestellt. Der nächste Abschnitt stellt Möglichkeiten vor, wie man die Hürden der eingeschränkten Kommunikation in verteilten Teams besser handhaben kann. Webcams, Videokonferenzen sollen räumlich weit getrennte Personen zusammenführen. Dabei wird auch auf die Zeitverschiebung eingegangen, welche die vorher genannten Möglichkeiten ausschließt. Der letzte Teil beschäftigt sich mit der Teambildung und den Einsatz von Coaches, welche dabei helfen sollen den ganzen Entwicklungsprozess effektiver zu gestalten. Den Abschluss des Artikels bildet eine Liste mit Erfahrungen, Praktiken und Methoden, welche sich in Microsoft patterns & practices Teams durchgesetzt bzw. nicht etabliert haben. Seite 5

6 Agile Softwareentwicklung mit verteilten Teams Quelle: 1.Auflage, dpunkt.verlag, ISBN Autor: Jutta Eckstein Datum: 2009 Das Buch richtet sich an Personen, die Agile Softwareentwicklung in verteilten Teams einsetzen oder vorhaben dies zu tun. Dabei fokussiert es sich darauf, den Erfolgsfaktor der Agilität auf Softwareprojekte zu übertragen, die rund um den Globus verteilt sind. Wichtige Themen sind Teambildung, Kommunikation und Vertrauen, Standorte in Verbindung halten, darunter unter anderem Werkzeuge und Botschafter. Weitere Kapitel befassen sich mit Entwickeln und Ausliefern, Feedback, Praktiken und damit, wie man Agilität in ein verteiltes Projekt einführen kann. Besonders interessant ist das Kapitel Der Geschäftswert ist das Ziel, in dem auf wichtige Faktoren, wie zum Beispiel die Planung von Releases und Iterationen mit unbekannten Größen, wie die Teamgeschwindigkeit, eingegangen wird. Using an Agile Software Process with Offshore Development Quelle: Martinfowler.com Autor: Martin Fowler Datum: Auf dieser Website stellt Martin Fowler, einer der Mitbegründer von Extreme Programming, seine Erfahrungen mit agiler Entwicklung und verteilten Teams in Indien und Australien vor. Als Lessons Learned fasst er diese zusammen und geht unter anderem auf Continuous Integration ein. Desweiteren werden verschiedene Möglichkeiten zum Aufbau des Vertrauens im Team und zur Überwindung der kulturellen Unterschiede aufgezeigt. Neben dem Einsatz von Kommunikationshilfen, wie Wikis, wird aber auch das Thema der Dokumentation behandelt. Diese gewinnt gerade im Offshorebereich zunehmend an Bedeutung. Seite 6

7 Distributed Agile: Issues & Challenges, Patterns and Anti-Patterns Quelle: blogs.agilefaqs.com Autor: Naresh Jain Datum: Die Folien geben einen Einblick in agile Softwareentwicklung unter verteilten Bedingungen. In der ersten Hälfte des Foliensatzes werden die typischen Probleme von Offshore-Entwicklungen angesprochen, wie z. B. fehlendes Vertrauen und kulturelle Unterschiede oder schlechte Kommunikation. Im zweiten Teil werden Fallstudien betrachtet, in denen verschiedene Probleme auftraten. Diese hatten die unterschiedlichsten Auswirkungen auf die in der Quelle angegebenen Projekte, so konnte z.b. nicht automatisiert getestet werden. Im folgenden Teil werden Lösungsansätze angeboten, wie man mit solchen Problemen umgeht. Agile Prozesse in der Offshore-Softwareentwicklung Quelle: Microsoft Developer Network Libary, msdn.microsoft.com Autor: Andrew Filev Datum: Der Webauftritt betrachtet aktuelle Trends wie agiles Softwareengineering und Outsourcing. Der Schwerpunkt des Artikels untersucht den Einsatz der richtigen Methoden und Tools sowie die Kommunikation innerhalb der Teams, bei denen es in einer verteilten Umgebung oft zu Problemen kommen kann. Seite 7

8 Scaling Agility: Distributed Agile Development Quelle Bradapp.blogspot.com Autor: Brad Appleton Datum: In seinem Blog zählt der Autor Brad Appleton Quellen auf, die sich mit dem Thema der verteilten und agilen Entwicklung befassen. Darunter sind z. B. Quellen aus der September/Oktober Ausgabe von IEEE Software aus dem Jahre 2006, aber auch von Communications of the ACM erfaßt. Neben diesen ist zusätzlich eine lange Liste mit Literaturquellen rund um das Themengebiet enthalten. 6 keys to succeeding with distributed agile development 6 keys to succeeding with distributed agile development Quelle: Blog.assembla.com Autor: Andy Singleton Datum: In diesem Blog beschreibt der Autor sechs Erfolgsrezepte, die sich in seinem verteilten und agilen Team über die Projekte hinweg herauskristallisiert haben. Schwerpunkt des Beitrags ist die Wissensverbreitung innerhalb des Teams, die durch Ticketsysteme, Berichte und Chats unterstützt wird. Making agile software development work for distributed teams Making agile software development work for distributed teams Quelle: Searchsoftwarequality.com Autor: Colleen Frye Datum: Seite 8

9 In diesem Beitrag schildert die Autorin, wie sich die Ansichten bezüglich agiler und verteilter Entwicklung bei dem Veranstaltungsorganisators acteva.com geändert haben. Acteva war zu Beginn der Überzeugung, dass sich Agilität und globale Entwicklung nicht miteinander vereinen ließen. Aus Zeitgründen musste die Organisation jedoch einen Versuch starten, die verteilte Entwicklung agil anzu gehen. Dabei benutzen sie die Velocity Platform von GlobalLogic, die eine Menge Tools und Frameworks zur Organisation und Durchführung solcher Projekte bereitstellt und sehr positiv von allen Beteiligten aufgenommen wurde. Distributed Agile Development Quelle: Jacoozi.com Autor: Levent Gurses Datum: In seinem Blog beschreibt der Autor unterschiedliche Teamstrukturen, die in einem Onshore- Offshore Projekt angewandt werden können. Zum Vergleich beschreibt er zuerst ein agiles Onshore-Team mit den unterschiedlichen Gruppen, wie z.b. Tester, Entwickler und Support. Danach werden anhand dieser Gruppen drei verschiedene Offshore-Modelle vorgestellt, in denen Gruppen ausgelagert werden. Advice on Conducting the Scrum of Scrums Meeting Quelle: Autor: Mike Cohn Datum: In diesem Beitrag werden Hinweise für das Führen eines Scrum of Scrums Meetings gegeben. Ausgehend vom Daily Scrum erfordert eine verteilte Entwicklung, aber auch die Entwicklung mit mehreren Scrum-Teams, die gute Kommunikation zwischen den einzelnen Teams, damit sie ihre Seite 9

10 Aufgaben ineinander integrieren können, aber auch, damit sie abschätzen können, ob sie sich in bestimmten Teilen eines Projektes in die Quere kommen. Wichtige Punkte die in dieser Quelle betrachtet werden, sind die Organisation und Frequenz solcher Meetings. Scaling Scrum Without the Scrum of Scrums Quelle: Autor: Chris Sims Datum: Der Autor beschreibt in diesem Artikel eine andere Art der Organisation von Scrum mit mehreren Teams. Er ist der Meinung, wenn zwei oder mehrere Teams häufig im selben Code arbeiten, dann sollten diese Teams zusammen ihre Stand-up-Meetings betreiben. Dies soll gegenüber der hierarchischen Ordnung von Scrum of Scrums den Vorteil bringen, dass an den kritischen Stellen die Entwickler mehr miteinander kommunizieren und an anderen weniger als benötigt. Scrum of Scrums Issues and Value Quelle: Autor: Mark Levison Datum: Die Webseite fasst Erfahrungsberichte, die sich mit der Skalierung von Scrum auf große Projekte beschäftigen, zusammen. Dabei werden teilweise ganz unterschiedliche Probleme und deren Lösungsstrategien genannt. Ein Ansatz beschreibt die Probleme auf drei Ebenen, dem technischen Level, dem Level zwischen den Teams und dem strukturellem Teamlevel. Ein anderer beschäftigt sich mit der Zerlegung von Stories, damit ein und dieselbe Thematik nicht von mehreren Teams umgesetzt wird. Seite 10

11 Parallele Multi-Team-Produktentwicklung mit Scrum: ein Erfahrungsbericht Parallele Mult-Team-Produktentwicklung mit Scrum: ein Erfahrungsbericht Quelle: Objekt Spektrum 06/2008 Autor: Dr. Stefan Klein, Christian Oberleitner Datum: 11/2008 In diesem Bericht tragen die beiden Autoren ihre Erfahrungen aus zwei Jahren Entwicklung mit Teamgrößen von Personen zusammen. Dabei wurde von einem traditionellen Prozess auf Scrum umgestellt. Neben ein paar Grundlagen zu Scrum wird besonders auf Aspekte der Arbeit mit mehreren Teams eingegangen. Neben dem Scrum of Scrums Meeting wird auch die Organisation der Daily Scrums vorgestellt, die so organisiert sind, dass auch andere Interessenten aus anderen Teams daran teilnehmen können, um eine höchstmögliche Wissensverbreitung zu erreichen. Gemeinsame Einheit für Schätzungen in Scrum of Scrums? Gemeinsame Einheit für Schätzungen in Scrum of Scrums? Quelle: Autor: M. Bohlen, K. Ramünke, A. Kriegisch Datum: In diesem Forumsbeitrag diskutieren die drei Autoren über eine Möglichkeit, Schätzungen teamübergreifend zu realisieren. Dabei berechnet ein Autor seine Schätzung über den Focus Factor, der Storypoints pro Personentag darstellt. Ein anderer empfiehlt die Visualisierung der Teams in einen Burndown Chart. Der Dritte plädiert auf eine gemeinsame Aufwandsschätzung mit jeweils Vertretern der Teams, um eine Relation der geschätzten Storypoints zwischen den Teams erstellen zu können. Seite 11

12 Confessions of a scrum master scrum of scrums dilemas Confessions of a scrum master scrum of scrums dilemas Quelle: Abrachan.wordpress.com Autor: Abrachan Pudusserry Datum: In diesem Blog beschäftigt sich der Autor mit den Hauptproblemen bei der Zusammenstellung der Teams innerhalb von Scrum of Scrums. Dabei geht es unter anderem darum, ob man lieber erst die Teams bilden sollte und danach das Scrum of Scrums bzw. umgekehrt oder ob man direkt mit allen Teams in ein Projekt hinein startet oder die Anzahl von Zeit zu Zeit erhöht. Scrum of Scrums: Making it visual Scrum of Scrums: Making it visual Quelle: Autor: Xavier Quesada Allue Datum: In diesem Blog wird die Organisation der Arbeit aus einem Projekt, in dem Scrum of Scrums angewandt wurde, betrachtet. Dabei werden die Teams in Farben geteilt. Ein schwarzes Team wird mit Personen gebildet, die sich nicht eindeutig in andere Teams einordnen lassen. Die anderen farbigen Teams sind die üblichen Scrumteams. Die Quelle sticht durch ihre visuelle Darstellung der Teams und deren Arbeit mit Pinboards hervor. Seite 12

13 Impressum Autor Johannes Perlet Tel.: +49 (0) Feedback Uns interessiert Ihre Meinung! Haben Sie Fragen, Anregungen oder Anlass zur Kritik? Bitte senden Sie Ihre Kommentare an: Sven Seiffert Telefon: +49 (0) Abmeldung Sie wollen dieses Dokument in Zukunft nicht mehr empfangen? Senden Sie uns einfach eine mit einer kurzen Nachricht an: Zugangsdaten für Sehr gern richten wir für Sie Zugangsdaten für unseren passwortgeschützten Bereich "Wissen" ein (für unsere Partnerunternehmen; für andere Unternehmen sind Probezugänge möglich). Senden Sie uns einfach eine mit einer kurzen Nachricht an Seite 13

14 Seite 14 Softwareforen Leipzig GmbH Querstraße Leipzig T +49 (0)341 / F +49 (0)341 / E info@softwareforen.de I