Distributed Scrums - Analyse des Softwaretools Agilo
Aus Winfwiki
|
Fallstudienarbeit | |
| Hochschule: | Hochschule für Oekonomie & Management |
| Standort: | Hamburg |
| Studiengang: | Bachelor Wirtschaftsinformatik |
| Veranstaltung: | Fallstudie / Wissenschaftliches Arbeiten |
| Betreuer: | Prof._Dr._Uwe_Kern |
| Typ: | Fallstudienarbeit |
| Themengebiet: | Kollaboratives Projektmanagement |
| Autor(en): | Mathias Behrendt, Felix Reher, Hennig Rohde |
| Studienzeitmodell: | Tagesstudium |
| Semesterbezeichnung: | |
| Studiensemester: | 4 |
| Bearbeitungsstatus: | begutachtet |
| Prüfungstermin: | |
| Abgabetermin: | |
1 Einleitung
1.1 Problemstellung
Telearbeit wird von vielerlei Seiten für die durch sie gewonnene Flexibilität hoch gelobt - seien es die direkten Beteiligten, Arbeitgeber und Arbeitnehmer, seien es diverse öffentliche Stellen bzw. Ministerien.
Wenn es dann aber an die konkrete Einführung von Telearbeitsplätzen geht, wird dieser oftmals Vorbehalte und Widerstände entgegengehalten - angefangen bei Ängsten vor Kontroll-Verlust und Isolation von den Kollegen bis hin zu erhöhtem Betreuungsaufwand und erschwertem Monitoring durch Vorgesetzte.
Demgegenüber steht das agile Projekt-Vorgehensmodell Scrum mit dem Versuch, die Software-Entwicklung durch direkte und damit intensivere Kommunikation und durch einen ständigen Informationsaustausch im Entwickler-Team in einer höheren Qualität zu ermöglichen.
Doch wie führt man ein Team, das mangels einer gemeinsamen Arbeitsumgebung eigentlich gar kein Team ist?
Wie arbeitet man effektiv im Team zusammen, wenn man mit den anderen nur über Telemedien kommunizieren kann?
Unterstützung bei diesen Problemen verspricht die Anwendung der Software Agilo for Scrum von der agile42 GmbH.
1.2 Zielsetzung / Abgrenzung
Es wird untersucht, inwieweit die Software "Agilo for Scrum" die effiziente Integration von Telearbeitern in ein nach dem Vorgehensmodell Scrum arbeitendes Team von Software-Entwicklern ermöglicht.
Außen vor bleiben Szenarien und Umstände, bei denen die räumliche Trennung durch sprachliche und soziale Kulturdifferenzen bzw. durch das Leben in unterschiedlichen Zeitzonen verschärft wird.
1.3 Vorgehensweise
Nach der Einführung in das agile Projekt-Vorgehensmodell Scrum und der Erläuterung von Besonderheiten verteilter Teams wird die Software "Agilo for Scrum" in ihrer kostenlosen und der sogenannten Pro-Version vorgestellt.
Auf die genannten Grundlagen aufbauend werden drei Blickwinkel definiert, unter denen "Agilo for Scrum" untersucht wird, um eine Einschätzung treffen zu können, ob und wie gut es hierbei Unterstützung leisten kann.
2 Grundlagen
2.1 Vorstellung Scrum
Scrum wurde ursprünglich als Methode zur Produkt-Entwicklung von Ikujiro Nonaka und Hirotaka Takeuchi entwickelt [1]. Sie veröffentlichen 1995 ein Buch mit dem Titel "The Knowledge Creating Company", in welchem auch der Begriff Scrum geprägt wurde. Diese Grundlagen wurden im späteren Verlauf durch Jeff Sutherland (VMARK Software) und Ken Schwaber (Advanced Development Methods) durch die Hinzunahme wissenschaftlicher Vorgehensweisen weiter ausgebaut und vorangetrieben.
2001 erschien das erste Buch über Scrum, geschrieben von den Entwicklern Ken Schwaber und Mike Beedle. Sie gründeten ebenfalls die "Agile Alliance", welche Interessengruppen an Scrum vereint und Zertifizierungsprüfungen abnimmt. Ken Schwaber allerdings verliess 2009 die Vereinigung.
Eine Grundannahme bei Scrum ist, dass Fertigungs- oder Entwicklungsprozesse zu komplex sind, um sich im Vorwege in definierbar abgeschlossene Phasen, Meilensteine oder einzelne Arbeitsschitte mit einer Granularität von Tagen beziehungsweise Stunden pro Ressource planen lassen. Die Produktivität sei bei selbstorganisierten Teams deutlich höher gegenüber Teams mit klassischem, festen Entwicklungsrahmen.
Scrum selbst erfüllt als Methode die, 2001 im Agilen Manifest fixierten, Bedingungen der agilen Software-Entwicklung.
Über eine zentralisierte Anforderungsliste der Projektes, das Product Backlog, werden alle Anforderungen laufend verwaltet und priorisiert. Teile des Project Backlogs werden zu Beginn eines jeden Sprints in ein Sprint Backlog überführt und abgearbeitet. Hierbei wird grundsätzlich innerhalb der Dauer des Sprints ein lauffähiges, getestetes und - wenn auch rudimentär - dokumentiertes Produktinkrement erstellt. Eine Änderung des Umfangs, des Inhalts oder Eigenschaften der in das Sprint Backlog übertragenen Aufgaben ist gemäß Scrum untersagt.
Nach Ende des Sprints findet ein Sprint Review Meeting statt, welches zur Überprüfung und Genehmigung der Arbeitsergebnisse dient durch den Auftraggeber bzw. Product Owner dient.
Im Anschluss an das Sprint Meeting findet die Sprint-Retrospektive findet statt, eine Möglichkeit um die Zusammenarbeit des Teams zu reflektieren und gegebenenfalls Verbesserungsmaßnahmen für zukünftige Sprints abzuleiten.
2.1.1 Offizielle Rollen
In der folgenden Übersicht werden die offiziellen Rollen eines Scrum-Teams gemäß Rahmenwerk kurz erläutert und hierbei in die Einzelrollen des Scrum Masters (SM) sowie des Product Owners (PO) und in die Gruppenrolle Team (bzw. Entwicklungsteam) differenziert.
2.1.1.1 Scrum Master
Der Scrum Master steht als natürliche Person in Form eines Unterstützers zwischen Team und Unternehmen, übernimmt hierbei allerdings keine klassischen Aufgaben eines Projekt-Managers. Seine Rolle dient vielmehr der Etablierung von Scrum im Projektzyklus und die Einhaltung der darin niedergelegten Vorgehensweisen sowie Artefakte.
"Der Scrum Master fungiert als Servant-Leader: als Führungsfigur deren Aufgabe es ist, dem Team zu dienen." [2]
Seine Primäraufgabe ist somit die Unterstützung der Teamrollen.
Um dieser Aufgabe gerecht zu werden, hat der Scrum Master die Aufgabe das Team zu steuern, die Zusammenarbeit von Product Owner sowie Team sicherzustellen und die Beseitigung jeglicher auftretender Hindernisse oder externer Einflussnahme. Der Scrum Master ist für die Durchführung der Sprints beziehungsweise der Moderation der einzelnen Scrum Meetings und die Formulierung und Priorisierung der Anforderungen in dem Product Backlog behilflich.
"Als Scrum Master verfügen Sie zwar über Einfluss, aber über keine Autorität bezüglich der Arbeitsorganisation im Team." [2], dennoch triff der Scrum Master unter anderem "[..] die Entscheidungen, welche das Team nicht selbst treffen will, sofort in den Meetings. Dies ist wichtig, da so das Team in der Lage ist, weiterzuarbeiten." [3]
Fachliche Kompetenz ist kein zwingendes Merkmal des Scrum Masters, wohl aber ausgeprägte Soft-Skills wie Moderationserfahrung, Kenntnisse in Konfliktmanagement und sanfte Mitarbeiter- beziehungsweise Menschenführung.
- Seit 2003 ist es möglich, sich bei der Scrum Alliance [4] zum zertifizierten Scrum Master prüfen zu lassen.
2.1.1.2 Product Owner
Der Product Owner stellt die einzige fachlich verantwortliche natürliche Person gegenüber dem Auftraggeber für den Erfolg eines Scrum-Projektes dar und erfüllt diese Aufgabe unter anderem durch die Definition und Formulierung der Kundenanforderung im Product Backlog. Hierdurch wird maßgeblich Einfluss auf die mögliche Arbeitsleistung des Teams genommen. Somit werden alle Anforderungen an das Projekt zentral verwaltet.
Die Auswahl und Besetzung des Product Owners ist abhängig vom Umfang und Größe des durchzuführenden Projekts. In der Regel wird die Rolle durch Projekt- oder Produkt-Manager erfüllt. Essenziell für die Erfüllung der Tätigkeit ist hierbei die Zusammenführung von Kompetenz und Vollmachten, um notwendige Entscheidungen aus eigenen Befugnissen treffen zu können.
Zu den Primäraufgaben des Product Owners zählt somit die kontinuierliche Definition von Zielen in Form von User Stories, welche im Product Backlog gelistet und priorisiert werden.
Hierbei wird von Seiten des Product Owners möglichst eng mit dem Team zusammengearbeitet.
"Er hilft dem Team, die Kundenbedürfnisse und Anforderungen zu verstehen und diese in Produktinkremente umzusetzen, indem er es mit detaillierten Anforderungen versorgt und die entstandenen Arbeitsergebnisse überprüft. Der Product Owner schlägt also die Brücke zwischen den Endkunden und der Softwareentwicklung." [5]
- Unter anderem die Scrum Alliance [6] ermöglicht es, sich zum zertifizierten Project Owner prüfen zu lassen.
2.1.1.3 Team
"Ein Scrum Team umfasst mindestens fünf und allerhöchstens acht Personen." [7] Diese Anzahl ist wichtig, um das Maximum der Produktivität zu gewährleisten. Werden mehr Mitglieder in das Team involviert, besteht generell die Tendenz, dass Reibungsverluste durch erhöhten Kommunikationsaufwand entstehen und die Kontrollmechanismen aus Scrum aufgrund von Komplexität nicht greifen können. Bei zu wenigen Personen krankt das System in der Regel an zu geringem Informationsaustausch.
Seine Primäraufgabe ist die Erfüllung der Entwicklungsarbeit in einem Sprint, um an dessen Ende ein lauffähiges Softwareinkrement zu liefern.
Das Team schätzt die Aufwände der Elemente im Backlog und erklärt sich während des Sprint Planning Meeting bereit, im nächsten Sprint eine bestimmte Menge von Einzelelemente des Product Backlogs abzuarbeiten. Während eines laufenden Sprints kann das Team aufgrund der Selbstorganisation alle Entscheidungen im Rahmen von vorgegebenen Richtlinien selbst fällen. Der Scrum Master hat hierbei die Aufgabe, sämtlich auftretende Hindernisse zu beseitigen, um den Arbeitsablauf sicherzustellen.
Die Zusammensetzung des Scrum Teams sollte so gewählt sein, dass Summe alle Fähigkeiten der Mitglieder ausreicht, um die im Sprint gesetzten Ziele zu erreichen. Wie die Aufteilung der Aufgaben beziehungsweise die Erreichung der Ziele erfolgt, obliegt ganz allein dem Team.
2.1.2 Artefakte
2.1.2.1 Product Backlog
Das Product Backlog dient der Erfassung und Verwaltung von Anforderungen innerhalb des Produktes in Form einer Aufgabensammlung, welche der ständigen Bearbeitung der Anforderungen während des Projektzeitraums unterliegt. Das bedeutet, dass das Product Backlog während der Laufzeit niemals vollständig abgeschlossen ist. Man bezeichnet es auch als lebendes Dokument [8]. Erst am Ende des Projekts müssen alle umgesetzten Anforderungen in detaillierter Form im Product Backlog aufgeführt sein [8].
Einzelne Anforderungen innerhalb der Liste werden als Product Backlog Items bezeichnet und sind so zu formulieren, dass sie dem Kunden einen Nutzwert liefern. Dieses wird in der Regel durch die Formulierung von User-Stories oder Cases sichergestellt. Die hierzu zu verwendete Syntax lautet:
Als Anwender, mit [der Rolle X] benötige ich [eine Funktionalität], damit ich [den Nutzen Y] bekomme. [9]
Diese Art der Formulierung hat den Sinn, alle Anforderungen übersichtlich und einheitlich strukturiert in das Product Backlog einzutragen beziehungsweise Anforderungen einfach von der Kundenseite generieren zu lassen.
Nach Einpflegen der Anforderungen werden diese vom Product Owner und dessen Team sortiert und priorisiert nach Nutzen, Risiko und Kosten. Für identifizierte Risiken müssen im Vorfeld Gegenmaßnahmen aufgeführt und diese vorab als weiterer Einträge ins Produkt-Backlog übernommen werden.
Die Form des Product Backlogs kann grundsätzlich variieren. Gängige Varianten hierbei sind Mind Maps, Listen oder Story Cards.
2.1.2.2 Sprint Backlog
"Das Sprint Backlog weist die Arbeit oder die Aufgaben aus, die das Team aus den Product Backlog Elementen für diesen Sprint ausgewählt hat." [10] Somit dient es primär der Selektion und Differenzierung von Aufgaben und Anforderungen aus dem Product Backlog für die Dauer eines Sprints. Ebenso zeigt es die Verantwortlichkeiten der Mitglieder für einzelne Aufgaben.
Einmal gewählte Aufgaben sind hierbei ausschließlich durch das Team, niemals aber durch den Product Owner änderbar. Diese Aufgabe sollte dabei nicht länger als 16 Stunden dauern, sehr große Aufgaben sollten bevorzugt in kurze Teileinheiten granuliert werden.
2.1.2.3 Sprint Burndown Chart
Im Idealfall fällt die Kurve kontinuierlich und der Restaufwand schneidet am Sprint-Ende gegen den Nullpunkt. Durch Extrapolation des Verlaufs bzw. der linearen Verlängerung der negativen Steigung zur Laufzeit des Sprints lässt sich ablesen, ob der geschätzte Aufwand auch in der geplanten Zeitperiode umgesetzt werden kann. Das Sprint Burndown Chart ist öffentlich einsehbar und zeigt den zu erwartenden Abschlusstermin aller Arbeitspakete.
2.1.2.4 Release Burndown Chart
Das Release Burndown Chart ist eine graphische Darstellung des noch zu erbringenden Restaufwands pro Sprint und dient dem Product Owner. Es zeichnet den verbleibenden, geschätzten Aufwands des Product Backlogs über die Zeit auf. Der Aufwand in der Regel in Einheiten von einzelnen Sprints gemessen. Durch Generierung einer Trendlinie kann auf der Basis der abgeschlossenen Änderungen an der verbleibenden Arbeit bis zur Erreichung des Projektziels gezogen werden.
2.1.3 Zeremonien
2.1.3.1 Sprint Planning Meeting
Das Sprint Planning Meeting besteht aus zwei Teilbereichen. Diese sind durch die unterschiedlichen Granularitäten der Tasks sowie der Teilnehmer definiert. Im ersten Teil des Treffens findet sich das Scrum Team mit Scrum Master und Product Owner sowie - optional - interessierten Kundenvertretern zusammen. Hierbei kommuniziert der Product Owner dem Team die am höchsten priorisierten Elemente seines Product Backlog. Das Team hingegen prüft intern, welche Elemente es hiervon im kommenden Sprint erledigen kann. Gemeinsam wird von Product Owner und Team das Sprint Goal definiert. Dieses ist ein Ziel, welches festhält, was im Sprint erreicht werden soll und gegen welches am Ende des Sprints im Sprint Review Meeting geprüft wird, ob der Sprint erfolgreich war.
Im nun folgenden Teil des Treffens legt das Team mit Unterstützung des Scrum Masters fest, welche Elemente des Product Backlogs im Sprint erledigt werden sollen. Die gewählten Elemente werden in einzelne detaillierte Aufgaben einer geschätzten Aufwandsdauer von 4 bis 16 Stunden aufgeteilt und entsprechen Teilstücken zur Umwandlung des Product Backlogs zu Software. Die Gesamtsumme der Aufgaben entspricht dem Sprint Backlog, welches während des Sprints abzuarbeiten ist. Dieses wird hierbei kontinuierlich angepasst, so z.B. Änderungen an Aufwandsschätzungen korrigiert oder Aufgaben überarbeitet.
2.1.3.2 Sprint Review Meeting
Das Sprint Review Meeting, welches am Ende eines jeden Sprints durchgeführt wird, dient als sehr informell gehaltene Sitzung über maximal 90 Minuten, um das neu erstellte Softwareinkrement einer Interessensgruppe aus Management, Anwendern, Auftraggebern und Product Owner vorzustellen. Die Teilnehmerliste kann im Review Meeting um beliebige Personen erweitert werden, die ein Interesse an dem Projekt haben. Generell ist dieses Meeting öffentlich. Dieses Meeting wird vom Scrum Master moderiert und die Software durch das Team präsentiert - wobei versucht wird, alle Neuerungen beziehungsweise Verbesserungen der Architektur oder Designs des Inkrements aufzuzeigen.
Alle Resultate des Sprints werden mit den Soll-Zuständen aus dem Product Backlog gegenübergestellt. Hierbei können durch das Auditorium Fragen gestellt, Beobachtungen weitergegeben oder Vorschläge gemacht werden, welche häufig in Änderung von Elementen des Product Backlogs resultieren.
In der Regel erfolgt anschließend an das Sprint Review Meeting und den damit verbundenen Anforderungen-Modifizierungen an das Produkt ein neuer Sprint. Ausnahme hier ist lediglich der Fall, dass der Kunde jedoch mit dem entstandenen Produkt zufrieden ist oder andere Gründe eine Einstellung des Projektes erfordern.
2.1.3.3 Sprint Retrospective Meeting
Das Sprint Retrospective Meeting, welches zwischen dem Sprint Review Meeting und dem nächsten Sprint Planning Meeting stattfindet, wird durch den Scrum Master moderiert. An dem Meeting nehmen der Product Owner, der Scrum Master sowie das Team teil. Alle Beteiligten sollen hierbei offen und ehrlich erörtern, was im letzten Sprit positiv oder negativ verlaufen ist.[11] Das heißt, in diesem Meeting bietet sich dem Scrum Master durch Diskussion und Lernen die Möglichkeit, das Team "zu verbessern, um [den Scrum-Prozessrahmen] effizienter und angenehmer für den nächsten Sprint zu gestalten." [12] Die grundsätzliche Zielsetzung des gesamten Meetings ist somit eine "Steigerung der Produktivität, der Leistungsfähigkeit des Teams und der Softwarequalität." [13]
2.1.3.4 Daily Scrum Meeting
Im Daily Scrum Meeting, einem optimaler weise täglich stattfindenden Meeting, treffen sich für maximal 15 Minuten zur selben Zeit und am selben Ort aller Mitglieder des Scrum Teams. Das Meeting wird vom Scrum Master moderiert. Er hat die Aufgabe, sicherzustellen, dass die Regeln eingehalten werden und die eingeplante Dauer nicht überschritten wird. Ein Scrum Meeting ist keine Diskussionsrunde, es werden hierbei keine Problematiken oder ähnliches besprochen oder gar gelöst. Bestehen über das Treffen hinausgehende Probleme oder Unklarheiten, wird ein entsprechender Antrag auf ein zusätzliches Meeting im Verlauf des Daily Scrum gestellt.
Grundsätzlich stellt der Scrum Master während des Treffens jedem Teammitglied die folgenden drei Fragen:
- Was haben Sie in diesem Projekt seit dem letzten Daily Scrum Meeting durchgeführt?
- Was planen Sie bis zum nächsten Daily Scrum Meeting?
- Welche Hindernisse sind bei der Umsetzung für diesen Sprint und das gesamte Projekt aufgetreten? [14]
Die Beantwortung dieser Fragen fördern beziehungsweise verfolgend die Ziele:
- Die Teilnehmer des Treffens berichten dabei den Status ihrer Arbeit primär nicht dem Scrum Master oder einem Vorgesetzten, sondern den anderen Teammitgliedern. Hierdurch wird die Kommunikation innerhalb des Teams und das Wissen des Einzelnen über das Gesamtprojekt verbessert. Jeder weiß, was der andere tut bzw. womit er beschäftigt ist.
- Probleme und Hindernisse, welche zu einer sinkenden Performance führen, können aufgezeigt und analysiert werden. Hierzu zählt unter anderem auch eine projekt-externe Belastung durch das Management.
- Durch das Team gemeldete Hindernisse können durch den Scrum Master nach bester Möglichkeit schnellstmöglich beseitigt werden.
- Das Treffen ermöglicht im Notfall eine schnelle Entscheidungsfindung durch das Team.
2.2 Besonderheiten verteilter Teams
2.2.1 Einführung in die Problematik
- Definition Telearbeit
"Telearbeit ist jede auf Informations- und Kommunikationstechniken gestützte Tätigkeit, die ausschließlich oder alternierend an einem außerhalb des Betriebs liegenden Arbeitsplatz verrichtet wird" [15].
Sie wird in einer Reihe von Intensitäten bzw. Stufen umgesetzt [16]. Vorteile für den Arbeitgeber ergeben sich aus einer höheren Effizienz durch Flexibilität, einer Reduzierung der Gebäude-Kosten durch eine Verringerung der notwendigen Büro-Fläche sowie aus der Anreizwirkung für qualifizierte Fachkräfte [17].
Auf Seiten des Telearbeiters sind die Vorteile von Telearbeit hauptsächlich auf der persönlichen Ebene zu finden - angefangen bei ersparten Wege-Zeiten über die besser Vereinbarkeit von Familie und Beruf bis hin zur Freiheit, nicht in der Nähe der Firmen-Niederlassung wohnen zu müssen [18].
Nachteilig wirkt sie sich für den Einzelnen hauptsächlich auf der sozialen Ebene aus - sei es die Abgeschiedenheit vom Flurfunk, sei es die Isolation vom allgemeinen Firmen-Klima [18].
2.2.2 Eingeschränkte Kommunikation
- Weitere Nachteile in der Teamarbeit ergeben sich zum einen aus Einschränkungen in der Kommunikation sowohl zwischen den Team-Mitgliedern selbst, als auch zwischen Telearbeiter und der allgemeinen Belegschaft der Firma:
Der allgemeine Smalltalk bei "'ner Tasse Kaffee", der Pausen-Zigarette oder dem gemeinschaftlich eingenommenen Mittag-Essen entfällt. Ursache hierfür ist zum einen sicherlich das faktische Fehlen eines geeigneten Anlasses - andererseits aber auch der Umstand, dass durch den Einsatz von Telekommunikation jeder Kommunikationsakt bewusst initiiert werden muss. Dies hat insofern negative Auswirkungen, dass kleine und damit eigentlich unerhebliche Missverständnisse unter diesen Umständen nicht direkt und unkompliziert geklärt werden können und damit - sicherlich abhängig vom persönlichen Temperament der Beteiligten - eher zur Eskalation neigen.
Darüber hinaus ergeben sich aus der Verwendung von Telemedien weitere Einschränkungen in der eigentlichen Kommunikation: Abhängig vom verwendeten Medium wird der Non-verbale Anteil an der Kommunikation nur in erheblich geringerer Intensität übermittelt. Am umfassendsten wird dies sicherlich noch bei einer Video-Konferenz gelingen, schon in einem Telefongespräch gehen jedoch durch Mimik und Körperhaltung ausgedrückte Informationen verloren. Bei ausschließlich schriftlicher Kommunikation mittels Brief und E-Mail gestaltet sich die Informations-Übermittlung auf der Beziehungs-Ebene am schwierigsten - im Rahmen der Chat-Kommunikation haben sich immerhin Surrogate in Form der sog. Smileys etabliert. Schließlich ist es bei der Verwendung von Telekommunikation quasi unmöglich, die Privatheit bzw. Intimität eines vertrauensvollen "Gespräches unter 4 Augen" herzustellen.
- Negative Auswirkungen auf die Teamarbeit ergeben sich wiederum durch die höheren Wahrscheinlichkeit von Missverständnissen und den reduzierten Mitteln der De-Eskalation.
Die kommunikative Distanz zum Kommunikationspartner führt zudem möglicherweise zu einer herabgesetzten Hemmschwelle in der Eskalation eines Streitgespräches. Relevant ist dies vor allem bei der Integration von Neu-Mitgliedern, besonders während der sog. Sturm-Phase des Team-Buildings.
Auftretende Konflikte können zudem aufgrund der Distanz nicht ohne weiteres aufgelöst werden - eine unkomplizierte Aussprache zur De-Eskalation (z. B. bei einem Feierabend-Bier) ist spontan nicht möglich, sondern muss entweder geplant oder auf ein späteres Zusammentreffen verschoben werden. Die Zusammenarbeit einzelner Team-Mitglieder wird damit bei bestehenden Konflikten schwerer beeinträchtigt.
2.2.3 Einschränkungen des gemeinsamen Arbeitens
Bereits die physische Distanz führt zu Leistungs-Einschränkungen bei der Zusammenarbeit im Team.
Nicht möglich ist z.B. das Pair-Programming, eine der Kern-Techniken der agilen Software-Entwicklung. Zwei Entwickler arbeiten hierbei simultan am selben Arbeitsplatz. Derjenige, der jeweils Tastatur und Maus bedient, hat für den Moment die Kontrolle und gibt sie bei der nächsten Gelegenheit an den Partner ab. Diese Möglichkeit der Abstimmung über gemeinsam genutzte aber nicht gleichzeitig nutzbare Bedien-Instrumente fehlt bei einem Zusammenschalten über Telemedien. Die Entwickler müssen andere Mittel und Wege finden, um sich abzustimmen.
Auch sind elementare Präsentationsmittel wie z.B. Whiteboard und Flipchart gar nicht oder nur mit hohem Aufwand zugänglich (z.B. im Rahmen von Video-Konferenzen). Dies erschwert eine eingängige Darstellung von Strukturen und Übersichten - z.B beim Entwurf von Architekturen oder der Einarbeitung in unbekannte Code-Teile. Sicherlich lassen diese sich auch mithilfe einer Bildschirm-Präsentation durchführen - dies bedeutet jedoch wiederum einen erhöhten Aufwand zur Vorbereitung und damit weniger Spontaneität.
Spontane Meetings - sei es, um Prototypen vorzustellen oder sofort eine Entscheidung im Team zu treffen - sind ebenfalls nicht möglich. Jedes physische Treffen verursacht erhebliche Kosten und aufwendige Vorbereitung bzw. technischen Aufwand (z.B. für Video-Konferenzen). Als Folge ist eine Hemmschwelle für Spontan-Kommunikation zu beobachten - beispielsweise ist bereits für den simplen Blick auf den Bildschirm eines anderen Team-Mitglieds mit paralleler Diskussion schon der koordinierte Einsatz zweier Telemedien notwendig.
2.2.4 Aufwendige Infrastruktur
Auf technischer Ebene kann mit erheblichem Aufwand versucht werden, die eben benannten Produktivitätsnachteile bei der Zusammenarbeit über Telemedien zu beheben. Als zwingend notwendig wird die Verwendung eines zentralen, gemeinsam genutzten Code-Repositories angesehen, gegen das das Team gemeinsam entwickelt. Der Fernzugriff hierauf muss zwecks Geheimhaltung des Quellcodes beschränkt und geschützt werden - sofern es sich nicht um ein OpenSource-Projekt handelt. Daher ist eine umfassend gesicherte Infrastruktur notwendig - z.B. unter Verwendung von virtuellen privaten Netzen.
Während eine Audio-Kommunikation zwischen den Team-Mitgliedern mittels Telefon zuverlässig, unkompliziert und bei Verwendung von VoIP auch kostengünstig möglich ist, gestaltet sich die Verwendung von Video-Konferenzen weiterhin als technisch hoch aufwendig. Dies ergibt sich aus der synchronen Nutzung zweier Echtzeit-Datenströme sowie aus der enormen Datenmenge bei der Distribution mehrerer Video-Übertragungen. Spätestens bei der Verwendung von Kameras zur Übertragung von handschriftlichen Skizzen steigen die Anschaffungskosten pro Teilnehmer leicht auf fünfstellige Beträge.
Kostenintensiv ist hierbei nicht nur die schlichte Bereitstellung dieser Kommunikationsmedien, sondern die Sicherstellung von deren Hochverfügbarkeit. Dies kann zum einen durch die redundante Anbindung der Arbeitsplätze an das Firmen-Netz geschehen, zum anderen durch entsprechend teure Verfügbarkeits-Vereinbarungen mit den Betreibern der Verbindungsnetze. Trotz des großen Aufwandes reicht im Zweifel eine technische Störung bei einem einzelnen Teilnehmer einer Telekonferenz, um diese als Ganzes zu verhindern. Gemäß Murphy's Gesetz treten derartige Störungen an neuralgischen Punkten, wie z.B. auch dem Internet-Zugang der einzelnen Entwickler, unmittelbar vor Deadlines auf bzw. treffen mit der Entdeckung eines kritischen Bugs zusammen.
3 Vorstellung Agilo
3.1 Einleitung
Wie eben gezeigt, ist es erheblich aufwändig und vorbereitungsintensiv, Telearbeiter effizient in den Arbeitsablauf und die Projekt-Organisation zu integrieren.Während die Technik allgemein als fallspezifisch anzusehen ist, ermöglicht eine Anwendung von Vorgehensmodellen die Vergleichbarkeit der Projekt-Strukturen.
Die Software "Agilo for Scrum" unterstützt die Anwendung des Vorgehensmodells Scrum auf die Softwareentwicklung und erlaubt es als Web2.0-Anwendung, auch solche Team-Mitglieder in ein Projekt zu integrieren, die teilweise bzw. ausschließlich nur über Telemedien mit dem Rest des Teams kommunizieren können.
3.2 Funktionsumfang
Agilo for Scrum kommt mit einem großen Funktionsumfang daher. Grundsätzlich wird zwischen einer freien und einer Pro-Version unterschieden. Aus der folgenden Tabelle geht der Funktionsumfang der jeweiligen Version hervor.
| Funktion | freie Version | Pro Version |
|---|---|---|
| Voller Support für alle drei Scrum Rollen und verschiedenen Funktionen zur Unterstützung des Workflows | x
| x
|
| Hierarchische Tickets, Aufgaben können mit den User Stories verknüpft werden (optional) | x
| x
|
| Lückenlose Rückverfolgbarkeit von Anforderungen durch Stories und Tasks | x
| x
|
| Enge Integration mit Ihren Quellcode: Code durchsuchen | x
| x
|
| Datenexport in eine *.csv Datei | x
| x
|
| Priorisierte Product Backlog und Unterstützung für die Zuordnung Geschichten Sprints | x
| x
|
| Multi-Projekt-und Multi-Support-Team | x
| x
|
| Mehrere Auftragsbestände: Bug Backlog, Hinderungsgrund Backlog | x
| x
|
| Chart unterstützt verteilte Teams in verschiedenen Zeitzonen (Zeitzone Unterstützung) | x
| x
|
| Support für die Kontingente, unvorhersehbare Aufgaben wie Support-Anfragen oder Bug-Fixes | x
| x
|
| Hinzufügen von benutzerdefinierten Typen und Felder zu vorhandenen Typen, definieren von benutzerdefinierte Workflows | x
| x
|
| Verbesserung der Rückverfolgbarkeit (Stories / Anforderungen) | x
| x
|
| Integriertes Wiki | x
| x
|
| Erweiterbar mit (kostenlos) Plugins | x
| x
|
| Integriertes Team-Management bzgl. der Verfügbarkeit | x
| x
|
| Wichtige Stories / Tasks können in der Backlog View editiert werden | x
| x
|
| Professionelle Unterstützung, einschließlich der SLA | | x
|
| Integriertes whiteboard | | x
|
| Erstellen Sie neue Tickets direkt aus dem Backlog | | x
|
| Auftragsbestand per Drag & Drop priorisieren | | x
|
| Hierarchien per Drag & Drop berücksichtigen | | x
|
| Hosted Service verfügbar | | x
|
- Tabelle 1: Vergleich Funktionsumfang Agilo vs. Agilo Pro. Vgl. Agile42, Featurelist [19]
Die wesentlichen Unterscheidungsmerkmale, inbesondere die Funktionalitäten, die bei der Projektdurchführung nach Scrum essentiell sind, sollen in diesem Kapitel genannt und kurz vorgestellt werden. Zusätzlich werden die vier verschiedenen Ticket-Typen besprochen. Weitere Funktionen, wie zum Beispiel der Datenexport in eine *.csv Datei, werden nicht weiter berücksichtigt, da sie für die Umsetzung vom Scrum keine bedeutsame Relevanz haben.
3.3 Hersteller
Der Hersteller agile42 GmbH mit dem Hauptsitz in Berlin und einer Zweigstelle in den Niederlanden (Amsterdam) hat es sich zur Aufgabe gemacht, Kunden praxisorientiert bei der Realisierung von agilen Softwareprojekten zu unterstützen. Ein grundsätzlicher Bestandteil ist die Software Agilo for Scrum sowie die ständige Weiterentwicklung des Produktes. Weitere Tätigkeitsfelder sind der Support für die kostenpflichtige Pro-Edition und die Bereitstellung einer IT-Infrastruktur. Zusätzlich sind in dem Produktportfolio Schulungen und Nachhilfe vorhanden, um den generellen Umgang mit einer agilen Vorgehensweise wie Scrum zu erlernen.
Vgl. Agile42, Unternehmensbeschreibung [20]
3.4 Vertriebsweg / Preismodell
Der Vertrieb der Software Agilo for Scrum erfolgt ausschließlich über das Internet. Auf der Homepage des Herstellers kann direkt eine kostenfreie Testversion der Agilo Pro-Edition heruntergeladen und 30 Tage lang genutzt werden. Soll die Software darüber hinaus zum Einsatz kommen, so sieht das Lizenzmodell zwei Varianten vor. Die erste Variante beinhaltet, dass der Kunde die Anwendung in Eigenregie zur Verfügung stellt. In der zweiten Variante wird dies von der Agile42 GmbH übernommen. In diesem Fall sichert das Berliner Unternehmen eine Verfügbarkeit von 99,99% zu. Die folgende Tabelle listet die Preise im Detail auf.
| Zeitraum | Preis pro User u. Monat (reine Lizenz) | Rabatt |
|---|---|---|
| 3 Monate
| 8,50 Euro
| ---
|
| 6 Monate
| 8,00 Euro
| 6 % incl.
|
| 12 Monate
| 7,50 Euro
| 12 % incl.
|
| Zeitraum | Preis pro User u. Monat (hosted Agilo) | Rabatt |
| 3 Monate
| 21,00 Euro
| ---
|
| 6 Monate
| 19,00 Euro
| 10 % incl.
|
| 12 Monate
| 15,00 Euro
| 29 % incl.
|
- Tabelle 2: Übersicht Preismodell. Vgl. Agile42, Shop [21]
3.5 Begriffsdefinitionen Ticket
3.5.1 Requirement
Ein Ticket vom Typ Requirement beinhaltet die Beschreibung einer notwendigen Anforderung. Die Anforderungen sollen die Frage nach dem "Was" und dem "Warum" beantworten. Was ist notwendig, um das vorhandene Problem zu lösen? Warum handelt es sich überhaupt um ein Problem bzw. warum ist es notwendig, dieses zu lösen? Wichtig ist, das diese Anforderungen so präzise wie möglich formuliert werden. Als Hilfsmittel zur Formulierung kann die SMART-Methode (einfach, messbar, erreichbar, realistisch und nachvollziehbar) verwendet werden. Die Antworten auf die Fragen der Anforderungen können sich auf ein oder mehrere User Stories verteilen, wobei jede eine funktionale Lösung der Anforderung darstellt.
Vgl. Scrum for Agilo - Requirement [22]
3.5.2 User Story
Eine User Story ist eine vom Benutzer in Umgangssprache formulierte Anforderung an einen Teil der zu entwickelnden Software. Eine User Story ist einfach und kurz geschrieben. In der Regel handelt es sich um zwei bis vier Sätze. Der kleine Umfang sorgt dafür, dass die Komplexität überschaubar bleibt und die Anforderungen an das Design, den Code, die Dokumentation sowie die Tests in nur einem Durchlauf umgesetzt werden können.
Vgl. Scrum for Agilo - User Story [23]
3.5.3 Task
Ein Task ist die kleinste Einheit einer Tätigkeit, die von einem einzigen Mitglied bearbeitet bzw. abgearbeitet werden kann. Auch hier ist die Einfachheit im Aufbau und der Struktur von hoher Bedeutung, damit der Mitarbeiter sofort mit der Arbeit beginnen kann und das zusätzliche Einholen von Informationen entfällt. Idealerweise dauert die Abarbeitung eines Tasks zwischen 3 und 12 Stunden. Dies ist als Orientierungswert zu sehen, wobei die maximale Arbeitszeit zwei Tage nicht übersteigen sollte. In diesen Fällen ist eine Aufsplittung in mehrere Tasks erforderlich.
Vgl. Scrum for Agilo - Task [24]
3.5.4 Bug
Agilo Tickets vom Type Bug dienen dem Entwickler Team. In der Regel erstellen sie hieraus Tasks zur zielgerichteten Bearbeitung. Dies könnten zum Beispiel Aufgaben sein, wie Sourcecode korrigieren, Unit-Test erstellen, reproduzieren des Fehlers und viele mehr.
Vgl. Scrum for Agilo - Bug [25]
3.6 Basis Funktionen
3.6.1 Basis-Einrichtung
Um ein neues Projekt zu starten, müssen mangels einer einheitlichen grafischen Oberfläche für die der Agilo-Installation zugrunde liegenden Versions-Verwaltung sowie TRAC-Software eine Reihe von Kommandos direkt auf der Konsole des Agilo-Servers ausgeführt werden [26]. Hierauf sind diverse Eingaben zu tätigen, u.a. der Pfad, unter welchem das Code-Repository für das Projekt liegt. Zur Vervollständigung müssen in der Trac-Init-Datei für das neue Projekt noch weitere Ergänzungen eingetragen sowie das Projekt als solches dem TRAC bekanntgemacht werden [26].
3.6.2 Workflow Product Owner
Nun kann der Product Owner das Product Backlog sowie die ersten Anforderungen generieren [27] - hierzu ruft er das Scrum Dashboard auf und wählt den Menüpunkt "New Requirement". Nun kann er die bereits vom Kunden formulierten Anforderungen eintragen [28]. Die jeweiligen Anforderungen können hierbei direkt mit User Stories assoziiert werden.
3.6.3 Workflow Scrum Master
Nachdem die Anforderungen im Product Backlog vorhanden sind, kann der Scrum Master die erste Besprechung für den ersten Sprint (Sprint Planning Meeting) einberufen. Es sollen nun alle Teammitglieder einen Gesamtüberblick über die Anforderungen erhalten. Dazu kann ein Projektor oder ein großer Monitor verwendet werden. Über den Backlog Report kann mittels drill-down zu den einzelnen User Stories navigiert werden.
3.6.4 Workflow Team
Sobald das Team die Grundplanung abgeschlossen hat, wird mit der Aufwandsschätzung begonnen und festgelegt, wie viele User-Stories im ersten Sprint umgesetzt werden können. Dies kann direkt in der User-Story über das Edit-Fenster vermerkt werden. Alternativ können diese Informationen auch in das Product Backlog geschrieben werden. Anschließend kann der Product Owner die Sprint-Eigenschaft auf den nächsten setzen.
3.7 Funktionen Pro-Edition
3.7.1 Drag&Drop Whiteboard
3.7.2 Feature
Die Pro-Version von Agilo for Scrum bringt weitere Vorteile mit sich, die vor allem das Handling erleichtern. So ist es möglich, direkt aus dem Backlog heraus ein neues Ticket zu erstellen. Eine weitere sehr nützliche Funktion ist, dass der Auftragsbestand per Drag&Drop priorisiert werden kann und dabei Hierarchien berücksichtigt werden.
3.7.3 Support-SLA
Der SLA Support bezieht sich ausschließlich auf den von der agile42 GmbH angebotene Service, die Anwendung für den Kunden im Internet bereit zu stellen. Der Hersteller garantiert in diesen Fällen eine Verfügbarkeit von 99,99%. Der Ordnung halber muss an dieser Stelle noch einmal auf das Kapitel 3.4 Vertriebsweg / Preismodell verwiesen werden, denn hierbei handelt es sich um einen erweiterten Service der Pro-Edition, durch den zusätzliche Kosten entstehen.
4 Bewertungskriterien
4.1 Bewertungsmaßstab Scrum
Nachdem bereits die agile Managementmethode Scrum, die Schwierigkeiten der Zusammenarbeit innerhalb verteilter Teams und auch die Software agilo for Scrum beschrieben wurden, soll es in dem folgenden Kapitel um die Festlegung von Bewertungskriterien gehen. Hierbei sind die Realisierung des Rollenschemas, der Artefakte, der Zeremonien und die Umsetzung sowie die Nutzbarkeit für verteilte Teams von großer Bedeutung.
4.1.1 Abbildung des Rollenschemas
Innerhalb von Scrum gibt es drei unterschiedliche Rollen. Jede einzelne von Ihnen hat eine besondere Perspektive auf das Projekt und jede Rolle benötigt unterschiedliche Informationen. Die Erwartungshaltung an die Software wäre demnach, dass sich die einzelnen Rollen innerhalb von Benutzerrollen wiederfinden und jeder einzelnen Rolle eine differenzierte Einstiegsansicht konfiguriert werden kann. Außerdem muss die Software unterschiedliche Berechtigungsrollen zur Verfügung stellen.
4.1.2 Abbildung der Artefakte
Die Artefakte von Scrum wurden bereits in Kapitel 2.1.2 erläutert. Die Software muss also einen Product Backlog, ein Sprint Backlog, ein Sprint Burndown Chart und ein Release Burndown Chart abbilden können. Bei dem Product Backlog zum Beispiel handelt es sich um so genanntes lebendes Dokument, diese sollte folglich auch von mehreren Bearbeitern editiert werden können. In diesem Zusammenhang stellt sich die Frage, wie geht die Software mit parallelen Zugriffen um?
4.1.3 Unterstützung bei Zeremonien
Die in Scrum vorgesehenen Zeremonien sind in Kapitel 2.1.3 erläutert worden. Daraus ergibt sich die Erwartungshaltung, dass der Scrum Master und evtl. Product Owner bei Sprint Planning-, -Review- und -Retrospective Meetings sowie beim Daily Scrum Meeting in der Präsentation der Artefakte und Tickets entsprechend unterstützt werden.
Um einen effizienten Ablauf der Besprechungen, vor allem des Daily Scrum Meetings, zu ermöglichen, wäre es sinnvoll, wenn der Scrum Master auf das Product Backlog, einzelne User Stories oder auch einen Task auch parallel zur Präsentation des Backlogs zugreifen kann. Darüber hinaus sollte eine Darstellung ausschließliche der wesentlichen Details in prägnanter Form möglich sein.
4.2 Bewertungsmaßstab "Verteilte Teams"
In diesem Kapitel werden die Bewertungskriterien für die Kommunikationsmöglichkeiten, die Integrationsmöglichkeiten von zum Beispiel Freihandskizzen, der generelle Dateiaustausch der einzelnen Projektbeteiligten, sowie die Colaborations-Mittel definiert.
4.2.1 Colaborations-Mittel
Die Software muss die Möglichkeiten des Wissensmanagements bereitstellen, zum Beispiel ein integriertes Wiki. Da die Teams an unterschiedlichen Standorten arbeiten und der Kollege nicht ohne erheblichen Aufwand die Maus seines Kollegen in die Hand nehmen kann, um einen Arbeitsschritt zu übernehmen, muss die Software Remote-Desktop-Verbindung und auch das Screen-Sharing unterstützen.
4.2.2 Kommunikationsmittel
Bei verteilten Teams ist die Kommunikation von hoher Bedeutung. Inwiefern werden die Zeremonien in Form von Online-Konferenzen (Audio / Video) im Programm abgebildet wurden. Ist eventuell ein Instant-Messenger integriert, um während der gesamten Arbeitszeit einen direkten Kontakt zu den anderen Teammitgliedern zu haben?
4.2.3 Integrationsmöglichkeiten - Infrastruktur
Stellt Agilo for Scrum eine Funktionalität zur Verfügung, die es ermöglicht, externe Dokumente mit einem Ticket zu verknüpfen und diese allen zugänglich zu machen? In diesem Zusammenhang wird ebenfalls die Realisierung eines zentralen Ablageortes für allgemeine Dokumente erwartet. Des Weiteren stellt sich auch die Frage, ob und wie viel Speicherplatz der von der agile42 GmbH angebotene Hosted Service zur Verfügung stellt.
4.3 Leistungs- u. Anforderungsumfang
In dem Kapitel Leistung- und Anforderungsumfang geht es um die Definition der Bewertungskriterien in Bezug auf die Benutzbarkeit, die Kosten. Des Weiteren soll auch die Umsetzung des Datenschutzes und die Realisierung der Datensicherheit bewertet werden.
4.3.1 Usability
Die Beurteilung der Handhabung von Agilo for Scrum wird mit hoher Wahrscheinlichkeit stets sehr subjektiv sein. Dennoch soll hier versucht werden, so objektiv wie möglich zu urteilen. Da drei verschiedene Personenkreise mit dieser Software arbeiten sollen, wäre die Erwartung, dass die Oberfläche so gestaltet ist, dass sie sehr intuitiv zu bedienen ist.
4.3.2 Kosten
Die Kosten der Software wurden bereits in Kapitel 3.3 - Vertriebsweg / Preismodell vorgestellt. Da es im direkten Vergleich keine adäquate Software gibt bzw. diese nicht Bestandteil dieser Arbeit ist, muss eine alternative Messgröße zu Rate gezogen werden. Die Kosten für die Pro-Version sollten gegen die Kosten einer zentralen Arbeitsstätte gestellt werden. Allerdings wird dieser Bewertungspunkt, wie auch das Bewertungskriterium Datenschutz / Datensicherheit nur zu einem geringen Anteil in die gesamte Bewertung einfließen, da hier weitere Faktoren eine Rolle spielen.
4.3.3 Datenschutz / Datensicherheit
Das sensible Thema Datenschutz und Datensicherheit ist ein wesentlicher Bestandteil, vor allem vor dem Hintergrund, dass hoch innovative Softwareprojekte einen besonderen Schutz genießen. Dieses Schutzbedürfnis gilt aber grundsätzlich - unabhängig davon, ob sie in verteilten Teams oder lokal, mit Scrum oder einer alternativen Methode durchgeführt werden. Insofern werden die Kriterien mit einem kleinen Anteil in die Gesamtbewertung einfließen.
4.4 Gewichtung
4.4.1 Prozentuale Verteilung
| Nr. | Kriterium | Bewertungsanteil |
|---|---|---|
| 1
| Abbildung des Rollenschemas | 10%
|
| 2
| Abbildung der Artefakte | 10%
|
| 3
| Abbildung der Zeremonien | 10%
|
| 6
| Colaborations-Mittel | 15%
|
| 4
| Kommunikationsmittel | 15%
|
| 5
| Integrationsmöglichkeiten - Infrastruktur | 15%
|
| 7
| Usability | 15%
|
| 8
| Kosten | 5%
|
| 9
| Datenschutz / Datensicherheit | 5%
|
| Summe
| 100%
| |
- Tabelle 3: Übersicht prozentuale Verteilung.
4.4.2 Bewertungsskala
Durch die Wahl der Bewertungsskala mit der Spanne von eins bis zehn kann sichergestellt werden, dass eine richtungsweisende Entscheidung bei der Bewertung der einzelnen Punkte getroffen und das Endergebnis aussagekräftig wird.
4.5 Entwurf Scoringmatrix
| Kriterium | Bewertungsskala | Gewichtung | Ergebnis | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
| 10
| |||
| Abbildung des Rollenschemas | | | | | | | | | | | 10%
| xx
|
| Abbildung der Artefakte | | | | | | | | | | | 10%
| xx
|
| Abbildung der Zeremonien | | | | | | | | | | | 10%
| xx
|
| Colaborations-Mittel | | | | | | | | | | | 15%
| xx
|
| Kommunikationsmittel | | | | | | | | | | | 15%
| xx
|
| Integrationsmöglichkeiten - Infrastruktur | | | | | | | | | | | 15%
| xx
|
| Usability | | | | | | | | | | | 15%
| xx
|
| Kosten | | | | | | | | | | | 5%
| xx
|
| Datenschutz / Datensicherheit | | | | | | | | | | | 5%
| xx
|
| Summe
| 100%
| XX
| ||||||||||
- Tabelle 4: Entwurf Scoringmatrix.
5 Bewertung
5.1 Perspektive Scrum
5.1.1 Qualität & Umfang der Umsetzung des Rollenschemas
Agilo bietet wie oben dargestellt volle Unterstützung der durch Scrum definierten Rollen-Verteilung von Product Owner, Scrum Master und Team Member mit entsprechend abgestuften Zugriffsrechten auf Artefakte und Dokumente. Die Berechtigungsvergabe ist aufgrund der verwendeten alphabetischen Sortierung etwas unübersichtlich, besser wäre hier z.B. eine optische Differenzierung zwischen Rollen und Detail-Berechtigungen.
- Insofern werden hier 9 Punkte vergeben.
5.1.2 Qualität & Umfang der Umsetzung der Artefakte
Auch die vier von Scrum verwendeten Artefakte Product und Sprint Backlog sowie Sprint und Release Burndown Chart, werden vollständig abgebildet. Deren Befüllung mit den Tickets Requirement, User-Story, Task und Bug erschließt sich intuitiv und ermöglicht die einfache Anwendung des Scrum Workflows.
- Daher werden hier volle 10 Punkte vergeben.
5.1.3 Qualität & Umfang der Unterstützung bei Zeremonien
Der Grad der Unterstützung durch die Software bei der Abhaltung von Meetings wird den Erwartungen nicht vollständig gerecht. Sicherlich lässt sich eine nebenläufige Darstellung von Backlogs und Detail-Ansichten durch die Verwendung von mehreren Monitoren bzw. Beamern erreichen, dennoch wird eine speziellen Präsentations-Ansicht vermißt.
Auch wenn die Umsetzung des Whiteboards auf eine Web-2.0-Darstellung verblüffend intuitiv und eingängig bedienbar gelungen ist, bleibt die Einfachheit der Nutzung eines physischen Whiteboards unerreicht, auf welchem Karteikarten mittels Magneten angeheftet bzw. verschoben werden können.
- Daher werden hier 6 Punkte vergeben.
5.2 Perspektive "Verteilte Teams"
5.2.1 Implementierte Unterstützung der Colaboration
Durch die Verwendung von TRAC als Unterbau von Agilo ist hier dessen volle Funktionsbreite als Wiki-System inclusive der Integration weiterer TRAC-Plugins möglich.
Eine darüber hinausgehende Online-Unterstützung agiler Techniken, wie z.B. des Pair-Programming mittels Screen-Sharing oder Remote-Desktop-Verbindung, wird dagegen nicht geboten.
- Daher werden hier nur 6 Punkte erreicht.
5.2.2 Implementierte Kommunikationsmittel
Entgegen der Erwartungen bietet Agilo keine direkte Kommunikationsunterstützung bzw. Integration von externen Tools wie z.B. Instant-Messenger oder Skype, der Skype Ltd.. Der Hersteller scheint davon auszugehen, dass dies ausschließlich von Fremd-Programmen übernommen wird und diese keinerlei Integration bedürfen.
Immerhin lassen sich mittels der Kommentar-Funktion Ergänzungen zu den einzelnen Tickets hinzufügen.
- Daher werden hier nur 4 Punkte erreicht.
5.2.3 Implementierte Infrastruktur-Unterstützung
Externe Dokumente wie eingescannte handschriftliche Zeichnungen oder als Dateien abgespeicherte E-Mails können komfortabel durch Upload an die einzelnen Tickets angefügt werden. Hierdurch werden jedoch jeweils Kopien von den einzelnen Dokumenten erzeugt. Eine Anbindung an ein externes Content-Management-System ist nicht gegeben - hier werden auch von den TRAC-Entwicklern keine funktionsfähigen Plugins angeboten. Komfortabel gelöst ist immerhin die Verlinkung gegen externe Webserver mittels Wiki-ähnlichen Notation des TRAC.
- Daher werden hier 8 Punkte vergeben.
5.3 Perspektive Leistungs- u. Anforderungsumfang
5.3.1 Usability
Auf den ersten Blick wirkt die Oberfläche von Agilo gut strukturiert und übersichtlich. Die ersten Schritte sind aufgrund der Komplexität nicht ohne eine Einarbeitszeit zu gehen und bedürfen zwingend einer ein- bis dreitägigen Einarbeitungszeit. Ab dem dritten Sprint sollte die Software dann aber bis ins Detail beherscht werden können. Als negativer Punkt muss erwähnt werden, dass es bei einigen Arbeitsschritten nicht die Möglichkeit gibt, diese systemtechnisch rückgängig zu machen (Undo-Modus).
- Daher werden hierfür 8 Punkte vergeben.
5.3.2 Kosten
Da in einem Team maximal zehn Teilnehmer inklusive Product Owner und Scrum Master sind, halten sich die Kosten in Grenzen. Dies ist selbst in der kostenintensivsten Variante, eine gehostete Version in Verbindung mit der geringsten Laufzeit, der Fall.
- Daher werden hierfür volle 10 Punkte vergeben.
5.3.3 Datenschutz / Datensicherheit
Die Umsetzung von Datensicherheit und Datenschutz obliegt generell dem Betreiber des Servers. Die Vertraulichkeit der Datenübertragung kann durch eine optionale SSL-Verschlüsselung gewährleistet werden - sofern der Zugang nicht von vornherein mittels eines VPN-Zugangs realisiert wird.
- Daher werden hierfür 9 Punkte vergeben.
5.4 Scoringmatrix
| Kriterium | Bewertungsskala | Gewichtung | Ergebnis | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
| 10
| |||
| Abbildung des Rollenschemas | | | | | | | | | x
| | 10%
| 0,9
|
| Abbildung der Artefakte | | | | | | | | | | x
| 10%
| 1
|
| Abbildung der Zeremonien | | | | | | x
| | | | | 10%
| 0,6
|
| Colaborations-Mittel | | | | | | x
| | | | | 15%
| 0,9
|
| Kommunikationsmittel | | | | x
| | | | | | | 15%
| 0,6
|
| Integrationsmöglichkeiten - Infrastruktur | | | | | | | | x
| | | 15%
| 1,2
|
| Usability | | | | | | | | x
| | | 15%
| 1,2
|
| Kosten | | | | | | | | | | x
| 5%
| 0,5
|
| Datenschutz / Datensicherheit | | | | | | | | | x
| | 5%
| 0,45
|
| Summe
| | | | | | | X
| | | | 100%
| 7,35
|
- Tabelle 5: Bewertung Scoringmatrix.
5.5 Kritische Bewertung der Umsetzung
Auch wenn Agilo eine ausgesprochen gelungene Abbildung des Scrum-Workflows bietet, bleiben Defizite im Einsatz bei verteilten Teams bestehen. Diese zeigen sich primär bei der Präsentation im Rahmen der Zeremonien - im speziellen des Daily Scum Meetings, da die Visualisierung der Tickets den Basis-Ansprüchen an Struktur und Prägnanz nicht gerecht wird.
Des weiteren gibt es keine in der Anwendung integrierte Möglichkeit, räumlich getrennte Teilnehmer bidirektional in die Präsentation einzubinden. Dies kann zwar teilweise durch Einsatz von externen Anwendungen bzw. einer Telefon-Konferenz behoben werden - deren nahtlose Integration in den Workflow bzw. das Bedienkonzept von Agilo ist allerdings nicht vorgesehen.
6 SWOT-Analyse "Agilo 4 Scrum" in verteilten Szenarien
Ausgehend von der Kriterienbewertung gemäß Kapital 5 lässt sich Agilo wie folgt in einer SWOT-Analyse einordnen.
| Stärken
| Schwächen
|
|---|---|
|
|
| Chancen
| Risiken
|
|
|
- Tabelle 6: SWOT-Analyse.
7 Zusammenfassung
Die in der Einführung aufgeführten Problematiken beim Einsatz von Telearbeitsplätzen in agilen Software-Entwicklungsprozessen werden durch die vorgestellte Software-Lösung in der Pro-Version 1.2.1 unserer Ansicht nach zwar in einer durchaus verwendbaren, aber nicht optimalen Art und Weise gelöst.
Die Tatsache, dass externe Anwendungen für die direkte Kommunikation und für einen kontinuierlichen Informationsaustausch benötigt werden, ist unserer Ansicht nach in dem von uns untersuchten Anwendungsfall ein merkliches Defizit der Software. Die dadurch fehlende Integration der oben genannten Funktionalitäten bedeutet einen erhöhten Administrations-Aufwand und lässt eine Einschränkung der Entwicklungs-Produktivität des Teams befürchten.
Auf der anderen Seite werden sämtliche Prozesse der Scrum-Methodik entsprechend des Rahmenwerkes umfassend und korrekt abgebildet und ermöglichen auf diese Weise auch unerfahrenen Scrum-Anwendern gleich welcher Rolle einen effizienten Einsatz der Software.
Die Umsetzung der klassischen "Offline-Elemente", beispielsweise die Anwendung des Whiteboards, die Verwendung von Kartei-Karten und das Zeichnen des Burn-Down-Charts ist hervorragend gelungen.
Wie dargestellt, kann die Anwendung unseres Erachtens dennoch gut zum Einsatz kommen, um durch das Angebot Telearbeit die Attraktivität des Unternehmens für Spezialisten zu steigern sowie geordnete und strukturierte Projektadministration auch in verteilten Szenarien zu forcieren.
8 Ausblick
Wünschenswert für zukünftige Releases von Agilo für Scrum wäre die differenzierte Integrationsmöglichkeit in Form von Schnittstellen oder spezifischen Plugins für den Einsatz in räumlich getrennten Szenarien. Hierzu zählen wir u.a. VOIP-Anwendungen eine einfache Variante zur Verwendung von Desktop-Sharing oder die Einbindung von Echtzeit-Multiuser-Kommunikationsplattformen. Hierbei sollte auf etablierte Protokolle oder Anwendungen gesetzt werden, um eine hohe Vielfalt bieten und gleichzeitig die bestehenden Kommunikationsmittel übernehmen zu können.
Wir sehen speziell in dem - von uns präferierten - Präsentationsmodus einen Bedarf zur besseren bzw. übersichtlicheren Darstellungsmöglichkeit bei Meetings. Diese könnten für Verwendung von Multi-Screens oder anderen parallelen Visualisierungsmöglichkeiten ausgelegt werden, um möglichst einfach und komfortabel das Spektrum an Optionen anzubieten, welche bei klassischer Anwendung von Scrum als "Offline-Methodik" zur Verfügung stehen.
9 Fußnoten
- ↑ The New New Product Development Game
- ↑ 2,0 2,1 Pichler, Roman (2008) - Seite 21
- ↑ Schweitzer, Raffael (2003) - Seite 7
- ↑ http://www.scrumalliance.org/CSM
- ↑ Pichler, Roman (2008) - Seite 11
- ↑ http://www.scrumalliance.org/CSPO
- ↑ Schweitzer, Raffael (2003) - Seite 8
- ↑ 8,0 8,1 Vgl. Pichler, Roman (2008) - Seite 28
- ↑ Mike Cohn - http://blog.mountaingoatsoftware.com/
- ↑ Schwaber, Ken (2007) - Seite 13
- ↑ Vgl. Pichler, Roman (2008) - Seite 112ff
- ↑ Schwaber, Ken (2007) - Seite 123
- ↑ Pichler, Roman (2008) - Seite 111
- ↑ Schwaber, Ken (2007) - Seite 9
- ↑ Kreilkamp et al (2001) - Seite 9
- ↑ http://www.verdi-innotec.de/telearbeit/freie_seite.php3_hauptkategorietelearbeit_basisinfor~2.htm
- ↑ http://www.hk24.de/produktmarken/unternehmensfoerderung_und_start/unternehmensfuehrung/personal_ordner/telearbeit.jsp
- ↑ 18,0 18,1 http://www.verdi-innotec.de/telearbeit/freie_seite.php3_hauptkategorietelearbeit_basisinfor~4.htm
- ↑ Agile42 GmbH - http://www.agile42.de/cms/pages/features/
- ↑ Agile42 GmbH - http://agile42.de/cms/pages/about-us/
- ↑ Agile42 GmbH - http://www.agile42.com/cms/pages/shop-germany/
- ↑ Agile42 GmbH - http://demo.agiloforscrum.com/agilo-help/scrum/Requirement
- ↑ Agile42 GmbH - http://demo.agiloforscrum.com/agilo-help/scrum/UserStory
- ↑ Agile42 GmbH - http://demo.agiloforscrum.com/agilo-help/scrum/Task
- ↑ Agile42 GmbH - http://demo.agiloforscrum.com/agilo-help/user/Ticket
- ↑ 26,0 26,1 siehe http://demo.agiloforscrum.com/agilo-help/admin/CommandLine
- ↑ siehe http://demo.agiloforscrum.com/wiki/WikiStart#QuickStartGuide
- ↑ siehe http://demo.agiloforscrum.com/agilo-help/admin/BacklogAdmin
10 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| CSM | Certified Scrum Master |
| CSPO | Certified Scrum Product Owner |
| CSV | Comma-Separated Values |
| IT | Informationstechnologie |
| PO | Product Owner |
| Pro | Professional |
| SLA | Service-Level-Agreement |
| SMART | Specific, Measurable, Attainable, Realistic, Time-Bound |
| SM | Scrum Master |
| SSL | Secure Sockets Layer |
| SWOT | Strengths, Weaknesses, Opportunities, Threats |
| VOIP | Voice Over IP |
| VPN | Virtual Private Network |
11 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | Übersicht über den Scrum-Prozess |
| 2 | Beispiel Product Backlog |
| 3 | Beispiel Sprint Backlog |
| 4 | Beispiel Burndown Chart |
| 5 | Screenshot Agilo Pro, Aktive Tasks |
| 6 | Screenshot Agilo Pro, Interaktives Whiteboard |
12 Tabellenverzeichnis
| Tab.-Nr. | Tabelle |
|---|---|
| 1 | Vergleich Funktionsumfang Agilo vs. Agilo Pro |
| 2 | Übersicht Preismodell |
| 3 | Übersicht prozentuale Verteilung |
| 4 | Entwurf Scoringmatrix |
| 5 | Bewertung Scoringmatrix |
| 6 | SWOT-Analyse |
13 Literatur- und Quellenverzeichis
| Derby, Ester; Larsen, Diana (2006) | Derby, Ester; Larsen, Diana: "Agile Retrospectives", 1. Auflage, The Pragmatic Bookshelf, Dallas, Texas |
| Eckstein, Jutta (2009) | Eckstein, Jutta: "Agile Softwareentwicklung mit verteilten Teams", 1. Auflage, dpunkt.verlag, Heidelberg |
| Kreilkamp et al (2001) | Kreilkamp, Peter; Oldenburg, Stephan; Wakiel, Borna : "Telearbeit - Leitfaden für flexibles Arbeiten in der Praxis", herausgegeben von den Bundesministerien für Arbeit und Sozialordnung, für Wirtschaft und Technologie, für Bildung und Forschung in Zusammenarbeit mit Deutsche Telekom AG, Bonn, |
| Jensen, Björn (2010) | Jensen, Björn: "Be free, be agile - Agilo for Scrum: schlankes Werkzeug zur Umsetzung von Scrum", heise Developer |
| Pichler, Roman (2008) | Pichler, Roman: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. Auflage, dpunkt.verlag, Heidelberg |
| Schwaber, Ken (2007) | Schwaber, Ken: "Agiles Projektmanagement mit Scrum", 1. Auflage, Microsoft Press, Redmond, Washington 98052-6399 |
| Schweitzer, Raffael (2003) | Schweitzer, Raffael: "Seminar Software Engineering, Agile vs. klassische Methoden der Software-Entwicklung", http://www.ifi.uzh.ch/rerg/fileadmin/downloads/teaching/seminars/seminar_ws0304/07_Schweitzer_Scrum_Ausarbeitung.pdf, Zürich, zugegriffen am 02. Juni 2010 |
| Agile42 GmbH (2010) | Agile42 GmbH: "Hersteller der Software Agilo for Scrum", http://agile42.de/cms/pages/, Hamburg, zugegriffen am 13. Juni 2010 (eventuell kostenlose Registration erforderlich) |
