Leistungsanalyse Agilo for Trac

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Düsseldorf
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Agile Softwareentwicklung
Autor(en): Georg Alexander Bock, Markus Poerschke, Peter Horczyk, Behnaz Aliasgar
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis

1 Einleitung

Agile Methoden der Software-Entwicklung gewinnen zunehmend an Bedeutung. Scrum ist hierbei eine der populärsten und am häufigsten eingesetzten Methoden[1]. Der Name Scrum ist der Sportart Rugby entlehnt, wo er für das anfängliche Gedränge zu Beginn eines Spielzuges steht. Zur Durchführung von Scrum sind zunächst keine elektronischen Tools erforderlich. Meist werden diese insbesondere von der Führungsebene gefordert, um eine gewünschte Transparenz bzw. Kontrollmöglichkeit zu schaffen[2] oder die Zusammenarbeit von räumlich getrennten Teams zu ermöglichen.

Gegenstand der folgenden Arbeit ist die Leistungsanalyse des webbasierten Tools Agilo for Trac (im Folgenden kurz "Agilo" genannt), welches laut Angaben des Herstellers agile42 GmbH viele Funktionen beinhaltet, um Scrum Projekte optimal zu unterstützen. Hierbei soll untersucht werden, inwiefern die Software Agilo in der Lage ist, die für die Scrum Vorgehensweise erforderlichen Kern-Prozesse zu fördern, im Vergleich zu einer Vorgehensweise ohne Unterstützung einer Scrum-spezifischer Software. Hierfür werden zunächst die allgemeinen Grundlagen für agile Softwareentwicklung mit dem Fokus auf Scrum beschrieben. Anhand eines fiktiven Softwareprojektes soll dann die Leistungsfähigkeit von Agilo for Trac analysiert werden. Um hier ein Benchmark zu haben wird das gleiche Projekt parallel mit den Möglichkeiten durchgeführt, die das Office-Paket (Microsoft-Office oder Open Office) zur Verfügung stellen. Hierbei werden insbesondere die Artefakte von Scrum verglichen.

2 Grundlagen

2.1 Agile Software Entwicklung

Die Agile Softwareentwicklung wird häufig mit einem Rugby Spiel verglichen. Es gibt eine begrenzte Anzahl von Spielern (Teammitgliedern) und fest definierte Regeln, als Bestandteile des Spiels. Trotz des engen Regelwerkes bestreiten die Teams selbständig das Spiel und wirken eigenverantwortlich an der Umsetzung der Ziele. Dies fördert in extremen Maßen die Motivation. "Agil" bedeutet Flexibilität in allen Bereichen der Planung, Kontrolle und Umsetzung, ähnlich wie bei einem Rugby-Spiel entscheiden diese maßgeblich über den Erfolg oder Misserfolg eines Projektes.[3]

2.2 Geschichte

Gegen Ende der 60er Jahre des vergangenen Jahrhunderts wurde Softwareentwicklung erst möglich. Computer wurden nun nicht mehr für ihre Aufgaben konstruiert, sondern wurden nachträglich programmiert. Schon damals waren Fehlplanungen und fehlerhafte Durchführungen ein großes Problem für den Erfolg eines Projektes. Es mussten neue Methoden zur Softwareentwicklung geschaffen werden, um den damals neuen und größten Teils unerprobten Anforderungen gerecht zu werden.[4]

Der Begriff Software Engineering wurde erstmals 1968 auf einer Konferenz zur „Software Krise“ in Garmisch-Partenkirchen geprägt. Damals wurde versucht Planungsmethoden von Ingenieure auf die Softwareentwicklung zu übertragen.[5]

Zunächst wurden statische Vorgehensweisen, wie das Wasserfall-Modell, dass auch noch heute Verwendung findet, genutzt. Jedoch sind in den Jahren auch die Anforderungen weiter gestiegen. Es wurde nötig durch sich plötzlich ändernde Anforderungen eine Flexibilität im Projektablauf zu erreichen.

1990 veröffentlichte Kent Beck seine Arbeit über „eXtreme Programming“ (XP). Dies war ein erster großer Fortschritt in der Agilen Softwareentwicklung. XP basierte erstmals nicht auf einem linearen Projektablauf, sondern orientierte sich an Zyklen.

Im Februar 2001 wurde unter Mitwirkung von Kent Beck das „Agile Manifest“ aufgestellt. Es besteht aus zwölf Prinzipien. Eine Kernaussage stellt dabei das zweite Prinzip dar[6]:

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."[7]

Die Veränderung und Änderung von Anforderungen wird so von den Unterzeichnern des Manifests begrüßt. Dieser Ansatz findet sich auch in den meisten Agilen Softwaremethoden wieder. Änderungen der Anforderungen sollen hier vor allem zur Förderung des Projekts beitragen.

2.3 Methoden

Das agile Manifest bildet die Grundlage für eine Reihe von agilen Entwicklungsmethoden welche die Nachteile der "klassischen" Vorgehensmodelle beheben und ein höheres Maß an Flexibilität und Kundennähe bei einem Mindestmaß an Dokumentation ermöglichen.

eXtrem Programming, Feature-Driven-Development, Agile Modeling und Scrum sind bekannte Vertreter der agilen Methoden. In den letzten Jahren ist die Popularität von Scrum stark angestiegen.[8]

Das Hauptziel agiler Methoden ist rasch eine funktionsfähige Software auszuliefern, um die Kundenwünsche bestmöglich zu erfüllen. Hierbei spielt die enge Zusammenarbeit mit dem Kunden eine zentrale Rolle. Unmittelbare Feedbacks durch den Kunden in Bezug auf die gelieferten Softwarekomponenten ermöglichen einen flexiblen Umgang mit den Anforderungen. Aber auch die Selbstbestimmung der Teams und ein eigenverantwortliches Handeln spielen bei den agilen Methoden eine wichtige Rolle.[3]

2.4 Scrum

Scrum wurde von Jeff Sutherland und Ken Schwaber gemeinschaftlich entwickelt. Sie griffen dabei auf Ideen zurück, welche Ikujiro Nonaka und Hirotaka Takeuchi in ihrem 1995 erschienenen Buch "The Knowledge Creating Company" erstmalig veröffentlicht hatten. Dort wird auch der Begriff Scrum zum ersten Mal erwähnt. 1996 wurde Scrum zum ersten Mal anlässlich der OOPSLA (The Eleventh Annual ACM Conference on Object-Oriented Programming Systems, Languages and Applications )[9] vorgestellt und später in dem 2001 veröffentlichten Buch "Agile Software Development with Scrum" umfassend beschrieben.

Auf der Website Scrum-kompakt.de wird Scrum als "ein Gesamtsystem aus Meetings, Artefakten, Rollen und Werten" beschrieben, "das aufbauend auf den Rahmengrundsätzen der agilen Softwareentwicklung ein Prozessmodell für die Entwicklung von Produkten darstellt."[10]

Scrum basiert auf den Grundsätzen der Agilen Softwareentwicklung, so ist es auch nicht verwunderlich, dass alle drei Begründer ebenfalls das Agile Manifest für Softwareentwicklung unterzeichnet haben.[11]

Im Vergleich zu dem Rugby-Spiel lassen sich folgende Aussagen über Scrum zusammenfassen:

  • Die Teammitglieder in Scrum spielen eine wichtige Rolle (Rollen)
  • Scrum ist „Runden-basiert“ (Scrum Meetings)
  • In Scrum sind Teilergebnisse wichtig und werden festgehalten. (Artefakte)

Im Folgenden werden die Rollen, die Artefakte, sowie der Ablauf von Scrum näher beschrieben.

2.4.1 Rollen

Als Folge der maßgeblichen Relevanz der Individuen in der Agilen Softwareentwicklung haben die Rollen in Scrum ebenfalls eine wichtige Bedeutung. Im Vergleich zu den klassischen Methoden weißt Scrum eine neue Vielfalt von Akteuren auf. Z.B. gibt es keinen Projektmanager mehr, oder andere Instanzen, die das Projekt allein bestimmen. In Scrum nimmt jeder Teilnehmer an dem Produkt Einfluss und ist zu jeder Zeit in das Projekt eingebunden.

2.4.1.1 Product Owner

Die Rolle des Product Owner ist sehr komplex, es ist eine Schlüsselrolle des Projektes. Als wichtigste Aufgabe kommt die Umsetzung der Produkt Vision auf ihn zu. Die gute Vermittlung der Vision an das Team soll sicherstellen, dass das Team hinter der Vision und somit auch hinter ihrem Produkt steht. Er soll also das Team motivieren. Das Erstellen des Product Backlogs mit der Beschreibung und Priorisierung der Aufgaben, Qualitätssicherung des Produktes, enge Kommunikation mit dem Kunden, dem Vertrieb, dem Marketing, der Geschäftsführung und mit dem Team sind noch einige seiner Aufgaben. Wie der Name schon sagt, ist er der Besitzer des Projekts während seiner Laufzeit und somit auch für den Return Of Investment verantwortlich. Diese Tatsache verpflichtet ihn auch dazu das Ergebnis eines Sprints zu wertschätzen und zu bewerten, damit das Team einen Feedback bekommt.[12] Unter Betrachtung der vielen Facetten dieser Rolle und ihrer entscheidenden Stellung im Scrum Prozess, sollte diese mit einer Person besetzt werden, die gut geschult ist oder besser, viel Erfahrung auf diesem Gebiet mitbringt. Exzellente Kommunikationsfähigkeit, Flexibilität und die Fähigkeit der Umsetzung der Anforderungen in Aufgaben ist an dieser Stelle essenziell.

2.4.1.2 Der Scrum Master

Der Scrum Master ist nicht der Chef sondern wie beim Rugby Spiel der Trainer (Coach). Er/Sie beobachtet, vermittelt, leitet, optimiert, unterstützt und passt auf, dass die Regeln von den Teammitgliedern eingehalten werden. Er hilft bei der Kommunikation und Abstimmung innerhalb des Teams und sorgt für den Informationsfluss zwischen Team und Product Owner. Er ist bei den 15 Minuten-Meetings der Moderator und ist verantwortlich für die Aktualität der Scrum-Artefakte (Sprint Backlog, Burndown Charts).

Die Hauptaufgabe ist das Team vor äußeren Störfaktoren zu schützen um das Fortschreiten des Projektes nicht zu gefährden.

2.4.1.3 Teams

Die Teams (kleine Gruppen) bilden sich aus 4 bis 9 Personen. Hierfür plant der Scrum Master, wer in solch einem Team mitarbeiten soll. Er wählt die Mitglieder danach aus, welche Kenntnisse für eine schnellstmögliche Projekterledigung erforderlich und vorhanden sind. Die Projekte sind sehr umfangreich, daher ist die Selbstorganisation im Team und das gemeinsame Arbeiten das A und O. Firmen die Erfahrungen mit Scrum haben, ermutigen ihre Mitarbeiter dazu sich selbst für Projekte zu bewerben, mit dem Ziel die Teams aus Personen bilden zu können die sich kennen und somit besser zueinander passen. Solche Teams sind erfolgreicher und produktiver als Teams mit willkürlich ausgewählten Mitgliedern.

Trotz der Freiheit, sich selbst zu organisieren, gibt es einen festen Rahmen und Vorschriften, an die sich die Teammitglieder halten müssen.

2.4.2 Artefakte

Die Informationen und Pläne zur Steuerung des Scrum Projektes beschränken sich auf eine kleine Anzahl von Artefakten, hierbei zeigt sich einer der schlanken Aspekte von Scrum. Im Folgenden werden die Artefakte kurz einzeln vorgestellt.

2.4.2.1 Product Backlog

Der Product Backlog ist der Anfang eines Entwicklungsprozesses in Scrum. Hier werden die Anforderungen vom Product Owner mit dem Kunden nach dessen Wünschen grob zusammengestellt. Priorisiert nach wirtschaftlichem Nutzen werden die einzelnen Einträge mit dem geschätzten Aufwand festgehalten. Die Einträge müssen alle Anforderungen widerspiegeln, damit am Ende ein funktionstüchtiges Produkt entstehen kann. Anforderungen sollen mit möglichst wenigen Worten, unmissverständlich, die gewünschte Funktionalität beschreiben um das Team nicht unnötig einzuschränken. Die am höchsten Priorisierten Einträge sollten nach Möglichkeit als erste abgearbeitet werden um schnell ein vorzeigbares bzw. auslieferbares Produkt zu haben.
Während eines Projektes wird das Backlog permanent bearbeitet, angepasst und um weitere Posten erweitert. Aus diesem Grund sind elektronische Hilfsmittel zu empfehlen, [13] aber nicht zwingend vorgeschrieben. Ein Produkt Backlog kann auch mit Klebezetteln an einer Tafel geführt werden.

2.4.2.2 Sprint Backlog

Der von dem Team und dem Product Owner, für den einzelnen Sprint, ausgewählte Teil des Product Backlogs bildet das Sprint Backlog. Die als User Stories bezeichneten, einzelnen Anforderungen an das Produkt werden hier bei Bedarf in kleinere Arbeitsschritte unterteilt und den einzelnen Teammitgliedern zugeordnet, wobei die Zuordnung nicht Statisch ist und während eines Sprints vom Team geändert werden kann. Die wichtigsten Informationen, die aktuelle Aufgabenverteilung und die Einschätzung des Restaufwands, werden regelmäßig angepasst. Am Ende eines Sprints sollten alle Anforderungen eines Sprint Backlogs erfüllt sein.

2.4.2.3 Burndown Chart

Beispiel Scrum Burndownchart
[Abbildung: 1]
Beispiel Scrum Burndownchart

Grundsätzlich gibt es bei Scrum zwei verschiedene Burndown Charts. Diese Grafiken dienen dem Ziel der schnellen Information aller Beteiligten und werden regelmäßig aktualisiert. Der Unterschied besteht aus den Quellen, aus denen die Charts gebildet werden. Der Release Burndown Chart wird aus den Werten des Product Backlog gebildet, wobei hier die einzelnen Sprints als Markierungen gesetzt werden. Verbunden zu einer Trendlinie stellt diese den Fortschritt des gesamten Projektes dar. Der Sprint Burndown Chart hat den Sprint Backlog als Quelle. An diesem Chart lässt sich schnell ablesen wie weit fortgeschritten der aktuelle Sprint ist und abschätzen ob alle angenommenen Aufgaben erledigt sein werden. (Das Beispielbild zeigt einen vierzehntägigen Sprint am zwölften Tag). Zusätzlich zu dem aktuellen Fortschritt kann noch eine Soll-Kennlinie eintragen werden, um Abweichungen auf Anhieb erkennen zu können. Diese Vergleichsmethodik ist wenig aussagekräftig, da beide Backlogs jederzeit geändert werden können und im Sprint Backlog eher unbeliebt, weil sich viele Entwickler kontrolliert fühlen.[14] Ein zweiter nützlicher Aspekt eines Sprint Backlog Charts ist die Tatsache das die zukünftigen Sprints besser geplant werden können. Mehrere Charts zeigen die Leistung des Teams und ihre Fähigkeit sich selber einzuschätzen. Sind in mehreren Charts die Anforderungen nicht erfüllt worden, arbeitet das Team nicht so effektiv wie es bei den Sprint Planning Meetings plant. Bei den Scrummeetings lässt sich aus den Charts sehr gut ablesen, wo es zu Problemen oder Hindernissen kam, so können schnell von den Beteiligten Gegenmaßnamen eingeleitet werden.

2.4.3 Scrum Meetings

Die Scrum Meetings spielen eine sehr Wichtige (Hauptrolle) Rolle für das Projekt. Hier werden Informationen ausgetauscht, Planungen erstellt, Prozesse entwickelt und zusammengefasst, und klare Verhältnisse geschaffen. Die fortlaufenden Schritte werden geklärt, bevor sich Missverständnisse ergeben. Beim Scrum Meeting wird Zeit, Geld und Aufwand gespart.

Im Folgenden werden die mitunter wichtigsten Meetings näher erläutert.

2.4.3.1 Sprint Planning

Für jeden Sprint findet eine Sprint Planung statt. Bei der Sprint Planung werden von dem Product Owner, dem Scrum Master und dem Team die am höchsten priorisierten Anforderungen aus dem Product Backlog ausgewählt, die während des nächsten Sprints abgearbeitet werden sollen. Diese Anforderungen bilden den Sprint Backlog.

2.4.3.2 Daily Scrum

Das Daily Scrum ist für den tägliche Status Abgleich und die Einsatzplanung für den Tag. Es findet an jeden Werktag und dieselbe Zeit statt und die Dauer beträgt Maximal 15 Minuten. Jedes Mitglied beantwortet folgende Fragen:

  • Was habe ich seit dem letzten Daily Scrum geschafft?
  • Welche Probleme sind aufgetreten?
  • Was werde ich bis zum nächsten Daily Scrum erledigen?

Der Daily Scrum ist nur zum reinen Informationsaustausch vorgesehen. Es ist die Aufgabe des Scrum Master die vom Team erwähnten Probleme dann aus der Welt zu schaffen.

2.4.3.3 Sprint Review

Das Sprint Review ist der Abschluss eines Sprints. Das Team stellt hier die Ergebnisse ihrer Arbeit bei einer öffentlichen Demonstration vor. Der Product Owner vergleicht hier die Differenz zwischen dem was aus dem Sprint Backlog geschafft wurde und dem was ursprünglich geplant war. Bei diesem Treffen wird von ihm gegebenenfalls das Product Backlog angepasst. Er kann diesen um weitere Anforderungen erweitern, existierende ändern oder streichen und falls nötig die Priorisierung ändern [15].
Bei diesem treffen sind alle Interessenvertreter anwesend, hier haben sie die Möglichkeit das Ergebnis zu bewerten und zu kommentieren.

2.4.3.4 Sprint Retroperspective

In dem Meeting, welches meistens im Anschluss an das Sprint Review stattfindet, wird der Sprint an sich untersucht. In vergleichen mit vorherigen Sprints soll festgestellt werden, ob das Team besser oder schlechter geworden ist, und warum. Mit den vorhandenen Charts kann das vergleichsweise einfach verdeutlicht werden. Der Trend dient als ein Anhaltspunkt für die Planung zukünftiger Sprints.

Da Scrum ein ständiger Lernprozess ist, wird über die Erfahrungen, die jedes Teammitglied gesammelt hat, diskutiert. Die Guten sollen nach Möglichkeit wiederholt werden und bei den schlechten wird versucht die Ursachen zu finden, um diese abzustellen.[16]

2.4.4 Workflow

Bevor mit der Arbeit an dem Softwareprodukt begonnen wird, plant der Scrum Master:

Der Scrum Prozess
[Abbildung: 2]
Der Scrum Prozess
  • Was muss gemacht werden?
  • In welchem Zeitraum?
  • Aus welchen Mitgliedern soll sich das Team zusammen setzen?

Anschließend beginnt er mit der Planung einzelner Sprints. Ein Sprint beinhaltet eine Aufgabe, die erledigt werden muss. In einem Sprint Backlog werden mehrere Sprints zusammen gefasst.

Die Sprints werden sehr kurz und überschaubar gehalten, damit die Produktivität sich steigert. In Schritt 2 bündelt das Team die in Backlogs zusammengefassten Sprints zu sogenannten Backlog Tasks. Es gibt jeden Tag eine kurze Teambesprechung von 15 Minuten. Was haben wir erreicht? Welche Probleme gab es und was muss bis morgen erreicht werden?

Ein Sprint darf höchstens 30 Tage lang sein. Es gibt aber kein Minimum.

2.4.5 Verteilte Teams

In einem Team werden die Aufgaben schneller und besser bewältigt als eine einzelne Person dies könnte.
Aus diesem Grund werden viele Teams gebildet um verschiedene Projekte oder Aufgaben im Unternehmen zu übernehmen und zu betreuen.

Es gibt kleine und große Teams. Beide Teams haben ihre Vorteile und Nachteile. Es gibt keine perfekte Zahl für die Teamgröße. Die Zeit und der Aufwand sind hier zu beachten. In einem kleinen Team ist die Kommunikation und die gemeinsame Arbeit viel intensiver, produktiver und der Erfahrungsaustausch schneller. Jeder kann sich auf sein Gebiet spezialisieren und sich weiterbilden. Der Ausfall eines Teammitgliedes kann aufgrund des hohen Spezialisierungsgrades zu einem Nachteil (Projektverzögerung) führen.
In einem größeren Team zu arbeiten hat den Vorteil, dass Menschen mit verschiedener Herkunft und anderer Berufserfahrung zusammen arbeiten. Bei komplizierten Projekten kann die Arbeit in Teilbereiche aufgeteilt werden. Das hat den Vorteil, dass kleinere Gruppen sich bemühen, die Aufgaben zu lösen.
Nachteile gibt es in größeren Gruppen, so ziehen sich einige Mitglieder unter Umständen zurück und nehmen weniger an Gruppenaktivitäten oder Diskussionen teil. Weniger Informationen werden austauscht was zu Missverständnissen führen kann.[17]

2.4.6 Große Projekte

Große Projekte, auch Meta Scrum genannt, entstehen sobald sich die Anzahl der Teammitglieder vergrößert und mehrere Teams gebildet werden. Damit die Kommunikation und der Informationsaustausch zwischen den verschiedenen Teams gut funktioniert, treffen sich bei regelmäßigen Meetings, hier Scrum-of-Scrums genannt, je ein Vertreter (dies kann ein beliebiges Mitglied sein) der Teams und berichten wie es um die Teilprojekte steht und vergleichen ihre Ergebnisse. Des weiteren werden übergeordnete Themen besprochen. Zusätzlich findet weiterhin ein Daily Scrum Meeting in den einzelnen Teams statt. Hier berichtet der Vertreter über die Erkenntnisse aus dem Meeting mit den anderen Teams.

Vor allem bei großen Projekten kann der Einsatz von Scrum sinnvoll sein, bringt aber Probleme mit sich. Bei Projekten, wo Teams in der ganzen Welt verstreut arbeiten, treten Probleme durch Zeitliche und räumliche Unterschiede auf. Da die Anwesenheit bei dem Daily Scrum bzw. Scrum-of-Scrums Pflicht ist, muss die Teilnahme durch elektronische Hilfsmittel, wie z.B. Telefon oder Videokonferenzsysteme, erfolgen. Auch können Vertreter benannt werden, die am Ort arbeiten wo das Scrum-of-Scrums Meeting stattfindet. Diese nehmen wiederum, per Videokonferenz, beim Daily Scrum ihrer Teams teil. Sie sind so bestens über die Vorgänge im Team informiert und können es in allen Belangen vertreten.[18] Durch diese Vorgehensweise können auch Probleme mit Zeitunterschieden gelöst werden, der Vertreter nimmt morgens am Daily Scrum und abends am Scrum-of-Scrums teil.

In der Praxis wurden so Projekte mit mehreren hundert Teammitgliedern umgesetzt. Das zeigt wie gut sich Scrum als Prozess erweitern lässt und wie gut er funktioniert.

2.4.7 Elektronische Scrum-Tools

Für die Umsetzung von Scrum werden verschiedene Softwaretools angeboten. An dieser Stelle wird eine kleine Auswahl gelistet.

Eine Entscheidung über den bestmöglichen Anbieter für elektronische Scrum-tools muss jeder Anwender für sich anhand eigener Kriterien treffen. Die oben angeführten Softwareanbieter geben die Möglichkeit, die vorgestellten Tools als Test- oder Teamversion herunterzuladen. Hier greifen unterschiedliche Testzeiträume von einem Monat bis zu einem Jahr. Die nach Test gewünschte Version kann dann als lizenzierte Vollversion erworben und eingesetzt werden. Hierdurch wird auch der in Testversionen grundsätzlich nicht gewährte Support durch den Softwarehersteller sichergestellt.

3 Agilo for Trac

Logo Agilo for Trac
[Abbildung: 3]
Logo Agilo for Trac

Agilo for Trac ist ein webbasiertes Tool, welches Teams bei der Vorgehensweise nach Scrum behilflich sein soll. Hierbei werden die Rollen, Zeremonien und Artefakte von Scrum durch Agilo unterstützt, sowie die Zusammenarbeit und Interaktion der Teammitglieder gefördert. Agilo unterstützt die Verwaltung der in Scrum üblichen Backlogs, das Product-Backlog, sowie das Sprint-Backlog und bietet zusätzlich die Möglichkeit für Teams, eigene Backlogs anzulegen. Neben diesen Funktionen stehen weitere Features wie ein Wiki, diverse Charts, ein Whiteboard und die direkte Anbindung an ein Versionskontrollsystem (SVN) zur Verfügung.

Agilo for Trac basiert auf der bekannten Bugtracking-Software Trac und wurde ebenfalls in Python geschrieben.

3.1 Hersteller

Agilo for Trac wurde von der Firma Agile42 GmbH entwickelt. Das Unternehmen, mit dem Hauptsitz in Berlin und Niederlassungen in den Niederlanden, Italien und Kanada, bietet seinen Kunden praxisorientierte Prozessberatung, Trainings und Software an. Der Hauptfokus liegt dabei auf "schlanken" und agilen Vorgehensweisen.

Als Erfolgsrezept sieht Agile42 die verwendete Kombination von Einbindung aller Projektbeteiligten, Wissensvermittlung, individuelles Team Coaching und die Nutzung einer unterstützenden Software. [19]

3.2 Vertriebsmodell / Versionen

Agilo for Trac wird ausschließlich über das Internet angeboten. Als freie Version - ohne die erweiterten Pro Features - wird Agilo unter einer Apache 2.0 Lizenz vertrieben. Die Pro Version wird als Download-Version angeboten mit optionaler Installationsmöglichkeit durch Agile42 oder als gehostete Lösung auf den Servern von Agile42. Zusätzlich ist eine Appliance-Lösung als Download verfügbar.

Es stehen zwei kostenpflichtige Preismodelle zu Verfügung:

  • Lizenz mit gleichzeitigem Hosting durch Agile42 (Hosting)
  • Reine Lizenzgebühren (Pro-Version)
Tabelle 1: Preisliste Hosting / Pro-Version
Hosting Pro-Version Month User
€ 1.071,00 € 910,35 1 100
€ 1.220,94 € 1.028,16 6 20
€ 1.256,64 € 996,03 12 10
€ 1.576,75 € 1.335,18 3 50
€ 2.387,14 € 1.927,80 12 20
€ 2.988,09 € 2.578,73 3 100
€ 3.052,35 € 2.513,28 6 50
€ 5.969,04 € 4.712,40 12 50
€ 6.040,44 € 4.855,20 6 100
€ 11.309,76 € 9.103,50 12 100
€ 17,85 € 10,71 1 1
€ 49,98 € 27,37 3 1
€ 71,40 € 51,17 1 5
€ 96,39 € 57,12 6 1
€ 119,00 € 99,96 1 10
€ 188,02 € 107,10 12 1
€ 198,73 € 143,99 3 5
€ 226,10 € 192,78 1 20
€ 332,01 € 282,03 3 10
€ 385,56 € 271,32 6 5
€ 565,25 € 471,24 1 50
€ 630,70 € 546,21 3 20
€ 642,60 € 530,74 6 10
€ 754,46 € 508,13 12 5
[Tabelle: 1]
Preisliste Agile42 Hostingkosten - Vgl. Agile42, Preisliste [20][21]

3.3 Installation

Sowohl die freie, als auch die kostenpflichtige Version von Agilo können von der Website des Herstellers geladen werden. Nach der Installation kann mittels eines Web-Browsers auf die Oberfläche von Agilo zugegriffen werden. Die Installation eines Clients ist somit nicht nötig. Bei der Hosted-Version übernimmt der Anbieter die Installation, sowie Wartung der Agilo Installation. Weiterhin werden aktuelle Software-Updates vom Anbieter eingespielt.

Die Installation der kostenlosen und der Pro-Version erfolgt durch den Kunden, wird aber auch als Service angeboten. Agile42 stellt für beide Versionen einen Windows Installer, eine Virtuelle Maschine, sowie eine Phython Egg zur Verfügung. Mit Phyton wird eine im Web nicht verbreitete Programmiersprache verwendet. Die Installation wird dadurch erschwert, dass kein einfacher Webspace ausreicht, um Agilo betreiben zu können. Es wird ein Windows-Server oder ein Server mit Unterstützung für Phyton benötigt, die meist ein hohes Maß an Fachkenntnis voraussetzen.

3.4 Basis Funktionen

Schon die freie Version von Agilo besitzt einen reichhaltigen Funktionsumfang.

Funktion freie Version
Vollständige Rückverfolgbarkeit von Anforderungen durch Stories und Tasks
x
Subversion Integration: Task, Bugs etc. können direkt über Subversion geschlossen werden
x
Enge Verknüpfung mit dem entwickelten Quellcode: Code Anzeige, Versionsunterschiede aufzeigen, Unterstützung von verschiedenen Versionskontrollsystemen (Subversion, Mercurial, Git, Bazaar and Perforce)
x
Direkter Export nach Excel (CSV) mit Masseneditier und -löschfunktion
x
Priorisierte Product Backlogs und Unterstützung für die Zuordnung von Stories zu Sprints
x
Multi-Projekt- und Multi-Team-Support
x
Vielfältige backlogs: bug backlog, impediment Backlog
x
Verteilt arbeitende Teams (in verschiedenen Zeitzonen) werden von den Burndown charts unterstützt
x
Unterstützung von Kontingenten, um unvorhersehbare Aufgaben wie Support-Anfragen oder Bug-Fixes zu einem Zeitpunkt zu begrenzen
x
Frei Konfigurierbar: eigene Rollen, vorhandene Rollen erweitern, eigene Workflows definieren
x
User stories können mit mehreren Anforderungen verknüpft werden, um die Nachverfolgung zu verbessern
x
Integriertes Wiki
x
Erweiterbar mit (freien) Plugins
x
Integrierte Team-Verwaltung: Eingabe der Teamverfügbarkeit, automatische Berechnung
x
Editieren von wichtigen Story-/Task-Eigenschaften direkt in der Backlog-Ansicht
x
Drag&drop berücksichtigt Hierarchien
x
Intelligentes Drag & Drop: Priorisierung der Backlogs per Drag & Drop
x
[Tabelle: 2]
Funktionsumfang der Agilo Basisversion, inkl. Gewichtung, Vgl. Agile42, Featurelist [22]

3.5 Zusatzfunktionen (Pro Version)

Die Tabelle der Zusatzfunktionen erweitert die der Basisfunktionen. Alle Basisfunktionen sind auch in der Pro-Version enthalten.

Funktion Pro-Version
Professioneller Support inklusive Service Level Agreement (SLA)
x
Integriertes Whiteboard
x
Erstellung von neuen Tickets direkt aus der Backlog-Ansicht
x
Editieren der Story- und Task-Eigenschaften aus dem Backlog ohne Neuladen der Seite
x
Einstellungen für die Ansicht werden pro User gespeichert
x
Kanaban Unterstützung durch konfigurierbare Whiteboard-Spalten
x
Als gehostete Lösung verfügbar
x
[Tabelle: 3]
Funktionsumfang der Agilo Pro-Version, inkl. Gewichtung, Vgl. Agile42, Featurelist [22]

3.6 Erweiterte Funktionen von Agilo

Agilo for Trac bietet neben der Umsetzung von Scrum zusätzliche Funktionen. Ein Wiki, sowie eine SVN Unterstützung werden vom Trac System zu Verfügung gestellt.

Durch Plugins für Trac kann Agilo zudem erweitert werden. Jedoch wird dies zwar weitestgehend ermöglicht, aber nicht offiziell unterstützt. Probleme mit Plugins fallen somit nicht unter die SLA von Agile42.[22]

4 Leistungsanalyse Agilo for Trac

4.1 Vorgehensweise

Ziel dieser Arbeit ist die Leistungsanalyse von Agilo for Trac. Hierbei sollen nicht nur allgemeine Kriterien wie Performance, Sicherheit und Usability betrachtet werden, sondern vor allem die Leistungsfähigkeit im Sinne von Scrum. Die Frage, wie gut unterstützt Agilo die Team-Mitglieder, den Scrum-Master und den Product-Owner bei ihrer täglichen Arbeit mit Scrum, soll geklärt werden.

Zu diesem Zweck werden Kriterien festgelegt, die eine spätere Gesamtbeurteilung der Software ermöglichen. Das Ergebnis wird in einer Bewertungsmatrix festgehalten und bewertet.

4.2 Test-Szenario

Es wird eine fiktive Software-Unternehmung betrachtet. Da die Möglichkeiten von Scrum ausgeschöpft werden sollten, wird von zwei Teams ausgegangen, die aus ca. fünf bis neun Personen bestehen. Der Projektzeitraum soll sechs Monate betragen. Als Versionen werden die Pro-, sowie die Hosted-Version als auch die kostenlose Version von Agilo for Trac getestet. Als Vergleich wird eine grobe Analyse einer Vorgehensweise ohne Unterstützung durch eine dedizierte Software durchgeführt.

4.3 Kriterien

Die Leistung von Agilo for Trac wird durch das Vermögen der Software bestimmt, den Scrum-Prozess abzubilden. Ob ein Scrum-Projekt an sich erfolgreich ist, kann hier nicht bewertet werden, da dies von softwareunabhängigen Faktoren abhängt. Die folgenden Kriterien legen fest, worauf bei der später erfolgenden Leistungsanalyse geachtet werden soll. Sie definieren sozusagen eine Erwartungshaltung in Bezug auf die Features und das Verhalten von Agilo for Trac.

4.3.1 Abbildung des Scrum-Prozesses

4.3.1.1 Scrum Rollen

Scrum beschreibt drei Rollen, die unterschiedliche Aufgaben wahrnehmen. Diese Rollen müssen in Agilo abgebildet sein. Die Rechte- bzw. Rollenverteilung der Software sollte dem User nur für die Rolle relevante Menüpunkte und Informationen bereitstellen. Für den Vergleich ist zu prüfen, wo der Vorteil der Rollendefinition in Agilo gegenüber dem Office-Paket liegt.

4.3.1.2 Scrum Artefakte

Die unter 5.2.2 vorgestellten Artefakte (Product-Backlog, Sprint-Backlog und Burndown-Chart) müssen in Agilo abgebildet sein. Hier sollte Agilo seine Stärken ausspielen können, das es durch serverseitige Skripte und Datenbankzugriff die Artefakte vernetzen kann und detaillierte Auswertungen ermöglichen sollte.

4.3.1.3 Scrum Meetings

Die Meetings/Zeremonien finden in großer Regelmäßigkeit statt und sind vom Ablauf her standardisiert. Hier wäre zu erwarten, dass Teammitglieder, Scrum-Master und Product-Owner quasi auf Knopfdruck Unterlagen für die Meetings bereitstellen können.

4.3.2 Bedienbarkeit und Usability

Agilo for Trac basiert auf dem Ticket-System Trac. Das bedeutet, es enthält viele Funktionen, die ursprünglich für einen anderen Zweck geschrieben wurden. Ist es den Entwicklern von Scrum gelungen, die Oberflächen übersichtlich zu halten, dem User wiederholt manuelle Aufgaben abzunehmen und sich an den Erwartungshaltungen der User zu orientieren?

4.3.3 Schulungsaufwand und Einarbeitungszeit

Scrum an sich ist ein überschaubares Framework, welches oberflächlich betrachtet einfach aussieht, aber im Detail eine intensive Beschäftigung mit den einzelnen Bestandteilen voraussetzt. Agilo sollte bestenfalls den Scrum-Prozess unterstützen und in Form von Wizards und Hilfe-Dateien durch den gesamten Prozess führen. Benutzer, die mit Scrum vertraut sind sollten nach kurzer Einarbeitung mit Agilo vertraut sein.

4.3.4 Team-Kommunikation und Wissensmanagement

Agilo for Trac ist webbasiert. Eine Architektur die von je her für den Austausch von Daten und Wissenstransfer gedacht war. Hier sollte Agilo in der Lage sein, seine Vorteile gegenüber der Standard-Software auszuspielen.

4.3.5 Reportingfunktionen

Ein äußerst wichtiger Bestandteil von Scrum ist Transparenz. Transparenz in der Kommunikation, in den Sprints und der Leistung der Teammitglieder. Agilo sollte durch entsprechende Reportingfunktionen diese Transparenz ermöglichen.

4.3.6 Sicherheit und Verfügbarkeit

Ausgehend von einem softwareproduzierenden Unternehmen welches Agilo for Trac einsetzt, kann das Softwareprojekt einen immensen Kapitalwert für das Unternehmen darstellen. Dieses muss durch entsprechende Maßnahmen gegen den Zugriff von Außen abgesichert sein. Gerade wenn Agilo auf öffentlich verfügbaren Servern im Internet gehostet wird. In der Bewertung sollte die Sicherheit somit mit einem nicht unwesentlichen Gewichtungsfaktor einfließen.

4.3.7 Installation / Hardwareanforderungen / Maintenance

Agilo wird für verschiedene Plattformen angeboten. Die Installation erfordert entsprechende Fachkenntnisse. Inwiefern werden von Agilo bestimmte Hardwareanforderungen vorausgesetzt? Wie sieht es mit der Zukunftssicherheit von Agilo for Trac aus. Wird die Software weiterentwickelt oder ist eine Roadmap vorhanden?

4.3.8 Kosten

Neben den Anforderungen an das Produkt sind auch Kosten bei der Leistungsanalyse zu berücksichtigen, da diese oft ein Grund für eine Umstellung auf eine Software sind.

4.3.9 Gewichtete Bewertungsmatrix

Bewertungskriterien Bewertungsskala (nach Schulnoten) Gewichtungsfaktor Ergebnis
1
2
3
4
5
6
Scrum Rollen
0,15
Scrum Artefakte
0,15
Scrum Meetings
0,15
Bedienbarkeit und Usability
0,10
Schulungsaufwand und Einarbeitungszeit
0,05
Team-Kommunikation und Wissensmanagement
0,10
Reportingfunktionen
0,10
Sicherheit und Verfügbarkeit
0,10
Installation / Hardwareanforderungen / Maintenance
0,05
Kosten
0,05
Summe
1
[Tabelle: 4]
Gewichtete Bewertungsmatrix

4.4 Bewertung

4.4.1 Scrum Rollen

Die drei Hauptrollen von Scrum, der Scrum-Master, der Product-Owner und das Team-Member sind als vordefinierte Rollen in Agilo vorhanden.

Bei der Neuanlage eines Agilo-Projektes werden zunächst die Benutzer angelegt. Danach werden jedem Benutzer die gewünschten Rechte zugewiesen. Die Gruppe "authenticated" sorgt dafür, dass jeder eingeloggte Benutzer bereits beim Start alle notwendigen Basisrechte bekommt. Diese können später erweitert werden. Agilo stellt hierzu eine sehr detailliert einstellbare Rechtestruktur zur Verfügung, welche auch die Verwaltung von Gruppen zulässt. Dadurch erhält im späteren Projekt jeder Mitarbeiter nur Zugriff auf die Bereiche, die den Rechten seiner bzw. ihrer Rolle entsprechen. Für die Rechtezuweisung gibt es einen gesonderten Navigationspunkt. Hierbei fällt auf, dass die bereits eingegebenen Namen der Teammitglieder nicht aus einer Dropdown-Liste ausgewählt werden können, sondern per Freitext quasi neu eingegeben werden müssen. Dies ist anfällig für Schreibfehler und es kann vorkommen, dass User unbeabsichtigt neu angelegt werden. Auch konnten Rechte für nicht vorhandene User angelegt werden.

Positiv zu bewerten ist an dieser Stelle, dass den Teammitgliedern gleichzeitig die Arbeitsstunden pro Woche zugewiesen werden. Diese werden später zur Zuweisung der freien Ressourcen verwendet.

User-Administration in Agilo for Trac
[Abbildung: 4]
User-Administration in Agilo for Trac
User-Administration in Excel
[Abbildung: 5]
User-Administration in Excel

Im Vergleich dazu ist die Excelliste zur schriftlichen Fixierung der Rollenverteilung im Scrum-Projekt sehr einfach aufgebaut. Ihr Vorteil ist die Flexibilität durch die beliebige und schnelle Erweiterbarkeit. Bei Agilo werden in der fein strukturierten Rechteverwaltung auch die späteren Authentifizierungen für das System definiert. Der Administrator legt fest, wer auf welchen Bereich Zugriff haben wird. So ist es auch möglich, eventuellen Stakeholdern des Projektes, lesenden Zugriff auf definierte Bereiche und Reportings zu geben.


Die Rollenverteilung und feinstufige Rechtevergabe machen Agilo sehr flexibel. Auch Projekte mit mehreren parallel und verteilt arbeitenden Teams können so gehandelt werden. Hier wird eine zwei vergeben. Eine Note ist abzuziehen, da die Rechteverwaltung aufgrund fehlender Dropdownlisten umständlich war und das System Falscheingaben durch den User zugelassen hat. So konnte zum Beispiel einem nicht existierenden User ein Recht zugewiesen werden.

Bewertung Teilbereich
1
2
3
4
5
6
Scrum Rollen
X

4.4.2 Scrum Artefakte

4.4.2.1 Product Backlog

Product Backlog in Agilo for Trac
[Abbildung: 6]
Product Backlog in Agilo for Trac
Product Backlog in Excel
[Abbildung: 7]
Product Backlog in Excel

Die in Scrum benötigten Artefakte können komplett über Agilo abgedeckt werden. Die Neuanlage eines Backlogs erweist sich als relativ einfach. Die einzelnen Items von Agilo sind im technischen Sinne "Trac-Tickets". Aus den Standardeinstellungen heraus können Anforderungen, User-Stories, Bugs und Aufgaben dem Product-Backlog hinzugefügt werden. Im Vergleich zu einem in Excel geführten Backlog kann Agilo die Items untereinander verlinken. Die Elemente des Backlogs lassen sich per Drag and Drop verschieben und direkt aus dem Backlog heraus über ein Popup-Fenster bearbeiten.

Das Zuweisen der Backlog-Items zu Sprints funktioniert schnell und zuverlässig, aber nicht intuitiv. Die Möglichkeiten der Vernetzung in Agilo übersteigen deutlich die eines in Excel geführten Backlogs.

Durch die Rechte-Verteilung können neue Anforderungen nur vom Produkt-Owner angelegt und mit entsprechenden Geschäftswerten (Business Values) versehen werden. Das gleiche gilt für die User-Story. Agilo unterstützt hierbei das Kano-Modell mit den Prioritäten Mandatory, Linear und Exciter. [23]. Interessant an dieser Stelle ist, dass User Stories zugewiesen werden können, was durch Scrum nicht erlaubt ist.

4.4.2.2 Sprint Backlog

Sprint-Backlog (Whiteboard-Ansicht) in Agilo for Trac
[Abbildung: 8]
Sprint-Backlog (Whiteboard-Ansicht) in Agilo for Trac
Sprint-Backlog in Excel
[Abbildung: 9]
Sprint-Backlog in Excel

Hier zeigt Agilo die stärken der webbasierten Software. Es stehen verschiedene Ansichten zur Verfügung, zwischen denen per Mausklick gewechselt werden kann. Dies erhöht vor allem die Übersichtlichkeit. Auch bauen die einzelnen Prozess-Schritte in Agilo aufeinander auf, was den Scrum-Neulingen die mit Agilo arbeiten eine Hilfe ist. Das oben dargestellte Whiteboard ist eine Ausnahmeerscheinung in Agilo. Die Bedienung ist wesentlich einfacher als die der anderen Elemente. Es kommt einem echten Whiteboard sehr nahe und unterstützt die Planung innerhalb der Sprints sehr gut. Allerdings steht das Whiteboard nur Usern mit einer Agilo Pro-Lizenz zur Verfügung.

Im Laufe der Sprints werden die einzelnen Aufgaben von den Team-Mitgliedern übernommen. Durch verschiedene Filter und Ansichten ermöglicht Agilo hier eine hohe Transparenz und punktet gegenüber dem alternativ gepflegtem Sprint-Backlog. Teammitglieder können während der Sprints auch neue Aufgaben anlegen, ohne diese User-Stories zuordnen zu können. Für Letzteres wird die Hilfe des Scrum-Master benötigt. Dieser Teilbereich geht klar an Agilo, da die Verlinkbarkeit unter den Items und die rechtegesteuerten Zugriffsmöglichkeiten so in Excel nicht abzubilden sind.

4.4.2.3 Burndown Chart

Burndown Chart in Agilo for Trac
[Abbildung: 10]
Burndown Chart in Agilo for Trac
Burndown Chart in Excel
[Abbildung: 11]
Burndown Chart in Excel

Das Burndown-Chart lässt sich von verschiedene Stellen in Agilo aus aufrufen. Es ermöglicht eine schnelle Kontrolle der Restaufwände pro begonnenem Task und prognostiziert den weiteren Verlauf. Im Vergleich mit Excel sind hier wenige Unterschiede festzustellen. Es bleibt zu erwähnen, dass der Nachbau dieser Funktionalität in Excel erweiterte Fachkenntnisse voraussetzt.

Im Gesamtbild sind die Artefakte von Scrum vollständig und gut in Agilo for Trac abgebildet. Die Funktionen des Whiteboards kommen der klassischen Scrum Arbeitsweise sehr nahe und ermöglichen eine gute Übersicht in den laufenden Sprints. Aus diesen Gründen wird auch dieser Punkt mit einer zwei bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Scrum Rollen
X

4.4.3 Scrum Meetings

4.4.3.1 Sprint Planning

"Whiteboard" von Agilo for Trac
[Abbildung: 12]
"Whiteboard" von Agilo for Trac

Im Verlaufe des Sprint Planning können die Sprint Backlog Items direkt aus dem Product Backlog in Agilo übertragen werden. Sobald ein Sprint erstellt wurde können Tickets wie z.B. eine User Story zu einem Sprint hinzugefügt werden. Dieses wird dann automatisch im Sprint Backlog angezeigt. Dort können Aufgaben ergänzt werden und zu den jeweiligen Resourcen respektive Teammitgliedern zugeordnet werden. Eine erweiterte Übersicht über den Sprint bietet das "Whiteboard". Dort werden alle Aufgaben angezeigt und nach User Story und Status sortiert. Diese Funktion ist nur in der Pro- und Hosted-Version verfügbar.

Eine weitere Möglichkeit den Fortschritt des Sprints zu verfolgen bietet die so genannte „Roadmap“. Hier können auch neue Sprints angelegt werden. Eine Besonderheit an dieser Ansicht ist, dass die Sprints hingegen der Scrum-Theorie in Meilensteine aufgeteilt sind. Der Fortschritt wird mit einem Prozent-Balken dargestellt.

4.4.3.2 Daily Scrum

Agilo bietet keine dedizierte Funktion, um ein Daily Scrum umzusetzen. Der Scrum Master wird bei dem Meeting lediglich von Agilo unterstützt indem Informationen über Aktualisierungen der Aufgaben, sowie Sprint Backlog und Burndown Chart zu Verfügung gestellt werden.

4.4.3.3 Sprint Review

Für die Sprint Review Meetings bietet Agilo keine Unterstützung an. Das war allerdings auch nicht zu erwarten.

4.4.3.4 Retroperspective

Für die Leistungsanalyse der Teams können die oben beschriebenen Reportingfunktionen verwendet werden. Verbesserungsvorschläge werden als neue Einträge in das Impediment-Backlog eingetragen. Dieses ist im Standard von Agilo nicht vorhanden. Da aber die Möglichkeit besteht, eigene Tickets zu definieren, kann über diesen Weg ein eigenes Impediment-Backlog angelegt werden. Auch hier ist die Unterstützung durch Agilo eher gering.


Bewertung Teilbereich
Die Scrum Zeremonien werden nur bedingt von Agilo unterstützt. Dies liegt aber in der Natur des Scrum Prozesses selbst. Hier zählt die Arbeit der Entwickler-Teams und deren Motivation. Auch zwischenmenschliche Faktoren fallen dabei ins Gewicht. Agilo liefert die notwendigen Features, um die Leistung aller Teammitglieder und der Sprints zu beurteilen. Hindernisse können ebenfalls in Agilo eingetragen und nachverfolgt bzw. abgearbeitet werden. Aufgrund der schlechten Unterstützung bei den Meetings, welche wie bereits erwähnt nicht durch eine Software zu leisten ist, wird dieser Punkt mit drei bewertet.


Bewertung Teilbereich
1
2
3
4
5
6
Scrum Meetings
X

4.4.4 Bedienbarkeit und Usability

Die Benutzeroberfläche von Agilo for Trac basiert, wie das ganze System, auf Trac. In Agilo wurden jedoch das Layout und auch das Design geändert. Die Oberfläche erinnert an vielen Punkten an das Mac OS X Betriebssystem von Apple. Ein wichtiger Punkt ist jedoch das geänderte Layout, das für die Benutzerführung von wichtiger Bedeutung ist.

Ticketübersicht in Agilo for Trac
[Abbildung: 13]
Ticketübersicht in Agilo for Trac
Ticketübersicht in Agilo for Trac
[Abbildung: 14]
Ticketübersicht in Agilo for Trac

Agilo wurde durch eine Sidebar ergänzt, damit kann einen schnellen Zugang zu wichtigen Bereichen erhalten. Über die Sidebar kann auf die Backlogs oder auf die Tickets zugreifen und neue Tickets erstellen. Bei Bedarf kann diese auch eingeklappt werden. Die Sidebar ist statisch und passt sich den Bereichen der Software nicht an. Dies führt in der Administration dazu, dass dort zwei vertikale Navigationen vorhanden sind, was irritierend für den Benutzer sein kann. Der User hätte hier eine Subnavigation anstelle einer Sidebar erwartet.
 Weiterhin wird sie Stets neu geladen, was zu einem Flimmern beim Wechsel zu einer anderen Ansicht führt.

Die Navigationspunkte und Schaltflächen werden meist als Text dargestellt. Auch auf bekannte Symbole, wie für "Bearbeiten", "Löschen" oder "RSS abonnieren" wurde komplett verzichtet. Lediglich die Top-Navigation wird durch Grafiken unterstützt. Dadurch wirkt die Oberfläche teilweise überladen. Funktionen werden jedoch meist durch eine Button-Optik kenntlich.

Lediglich in einigen Tabellenansichten werden Grafiken verwendet. Im Product Backlog werden Symbole eingesetzt, die das Filtern der Ergebnisse ermöglicht. Jedoch sind diese nicht intuitiv und müssen erst vom Nutzer erlernt werden.

Weiterhin ist die Benutzerführung von Agilo nicht komplett logisch durchdacht. Angenommen, der Administrator möchte den Namen, oder die E-Mail Adresse eines Users ändern. Hierzu würde er zunächst auf "Admin" klicken und dann unter dem Punkt "Accounts" "Users" auswählen wollen. Dort erscheint zwar eine Übersicht der Benutzer jedoch besteht dort nur die Möglichkeit einen Benutzer zu löschen. Um einen Nutzer bearbeiten muss der Administrator zunächst zu "Agilo" -> "Teams" navigieren und dort zunächst das Team wählen, in dem sich der Benutzer befindet. In der folgenden Ansicht, in der fälschlicherweise der Accountname statt des Namens angezeigt wird, besteht die Möglichkeit den Benutzer anzuklicken und anschließend zu bearbeiten.

Ein weiterer Mangel in der Benutzerführung sind die Formulare. Diese wirken oft durcheinander und erschweren das Wechseln zwischen den Feldern, denn die Nutzung der TAB-Taste funktioniert nicht immer.

Diese Beispiele zeigen, dass mit Agilo for Trac scheinbar kein Schwerpunkt auf die Benutzeroberfläche gelegt wurde. Diese ist jedoch für die Software von vitaler Bedeutung, weil vor allem eine intuitive Benutzerführung den Wechsel in hohem Maße erleichtert.

Bewertung Teilbereich
Die Bedienbarkeit und Usability wird mit 4 bewertet. Die Benutzerführung weißt einige Mängel auf. Agilo ist zwar bedienbar, jedoch erfordert dies ein hohes Maß an Kenntnis, da die Benutzung wenig intuitiv ist.

Bewertung Teilbereich
1
2
3
4
5
6
Bedienbarkeit und Usability
X

4.4.5 Schulungsaufwand und Einarbeitungszeit

Die Einarbeitungszeit für den Benutzer sind von selbigen abhängig. Personen, die eine Affinität zu EDV und Software haben oder schon mit Trac gearbeitet haben werden sich in Agilo for Trac schneller einarbeiten können als andere.

Agilo richtet sich an Unternehmungen zur Software-Entwicklung, daher sind die Anwender in der Regel schon mit Ticket-Systemen vertraut. Die Einarbeitungszeit wird so minimal ausfallen.

Anders verhält es sich hier mit dem Scrum Master und dem Product Owner. Ihnen stehen mehr Funktionen zu Verfügung. Einige von Ihnen sind dabei in Agilo anders umgesetzt, als in Scrum vorgesehen. Hier ist eine intensive Einarbeitung nötig.

Agile42 bietet dazu verschiedene Trainings an. Darunter auch ein Online-Training, das auch bei der Installation und Einrichtung von Agilo for Trac helfen soll, sowie Trainings für die verschiedenen Rollen. Angeboten werden Trainings für das Team, den Scrum Master, den Product Owner, sowie ein Training, dass einen Überblick über Scrum verschaffen soll. Agile42 bietet zudem eine Zertifizierung. [24]

Bewertung Teilbereich
Der Aufwand für die Einarbeitung und Schulung fällt gering aus. Jedoch ist eine Nutzung von Agilo for Trac ohne Schulung oder Einarbeitungszeit nicht möglich. Daher wird dieser Teilbereich mit drei bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Schulungsaufwand und Einarbeitungszeit
X

4.4.6 Team-Kommunikation und Wissensmanagement

Agilo for Trac bietet keine Möglichkeit für die Teammitglieder untereinander direkt zu kommunizieren. Die Kommunikation beschränkt sich auf das Erstellen und Zuweisen von Tickets. Diese können von jedem Teammitglied über Agilo eingesehen werden, so dass sich jedes Teammitglied jederzeit über die Aufgaben der anderen Teammitglieder informieren kann.

Anders sieht es beim Wissensmanagement aus. Hier stehen den Teammitgliedern, sowie allen weiteren Personen ein integriertes Wiki zu Verfügung. Tickets können direkt mit Wiki-Einträgen verlinkt werden. Dies bietet den Teammitgliedern die Möglichkeit z.B. User Stories oder Anforderungen im Detail zu beschreiben. Klassisch für ein Wiki können hier auch früher gemachte Änderungen eingesehen werden, was den gesamten Vorgang sehr transparent macht. Dadurch das Agilo webbasiert ist hat es Vorteile gegenüber lokal liegenden Dateien. Diese Vorteile werden vor allem für verteilt arbeitende Teams interessant.


Bewertung Teilbereich
Das Wiki ist zur Ansammlung von projektspezifischen Wissen praktisch und der Zugriff unterliegt gleichzeitig der Rechte- und Rollenverteilung von Agilo. Die sonstigen Funktionen zur Unterstützung der Team-Kommunikation und des Wissensmanagement sind in Agilo rudimentär erfüllt. Fairer Weise sollte gesagt werden, dass dies nicht die Aufgaben eines Scrum-Tools ist. Für den Austausch und die Kommunikation sind unter anderem die täglichen Meetings im Scrum-Prozess gedacht. Auch hier steigt der Bedarf, die Team-Kommunikation durch Tools zu unterstützen mit der Entfernung der Teams voneinander. Dieser Bereich wird mit der Note drei bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Team-Kommunikation und Wissensmanagement
X

4.4.7 Reportingfunktionen

Als Reportingfunktion stehen in Agilo mehrere Möglichkeiten zur Verfügung. Das Dashboard liefert einen Cockpit-ähnlichen Überblick über den aktuellen Sprint. Es enthält das Burndown-Chart sowie weitere Anzeigen zur Analyse des Sprints und der Leistung der einzelnen Teammitglieder. So werden zum Beispiel die augenblicklich zugewiesenen und nicht abgeschlossenen Tasks abgebildet. Alle drei Anzeigen zusammen ausgewertet zeigen den genauen Status Quo an und lassen Rückschlüsse auf eventuelle Probleme zu. Direkte Links zum Produkt- und Sprint-Backlog ermöglichen eine tiefergehende Analyse eventueller Probleme.

Neben dem Dashboard gibt es eine Reihe vordefinierter Reoports, welche Aufgaben, Anforderungen und User Stories aus verschiedenen Sichten anzeigen. Eigene Abfragen können über die Weboberfläche zusammengestellt und abgespeichert werden. Nach dem Speichern erscheinen diese im linken Navigationsmenü. Die Zusammenstellung der Reports ist äußerst flexibel und ermöglicht nahezu jede gewünschte Abfrage auf das System.

Bewertung Teilbereich
Die Reportingfunktionen sind zwar optisch sehr technisch und nicht gerade intuitiv bedienbar angelegt, aber sie ermöglichen eine sehr flexible Abfrage auf eine Vielzahl von Daten. Diese können zudem in verschiedenen Formaten exportiert werden. Ein Vergleich zu Excel bleibt in diesem Fall fast unfair, da Excel bei vertretbarem Aufwand hier nicht mithalten kann. Als Bewertung wird eine Note abgezogen, da die Darstellung teilweise unübersichtlich und überfrachtet ist. Auch ist die Trennung zwischen Agilo und Trac spezifischen Funktionen zeitweise verwirrend.

Bewertung Teilbereich
1
2
3
4
5
6
Reportingfunktionen
X

4.4.8 Sicherheit und Verfügbarkeit

Eine Agilo Installation ist in der Regel über das Internet erreichbar. Dadurch können die Anwender global auf die Agilo-Oberfläche zugreifen, jedoch können so auch Angriffe von außen erfolgen. Zudem ist Agilo for Trac Quelloffen, was einem potentiellen Angreifern das aufspüren von Sicherheitslücken und die Durchführung des Angriffs erleichtert. Dies erhöht das Sicherheitsrisiko der Software.

Eine Absicherung kann durch eine Beschränkung auf ein Intranet erfolgen. Dies ist jedoch nicht auf die Hosted-Version anwendbar. Zudem wird dadurch die Verfügbarkeit auf das Intranet eingeschränkt.

Geschützt wird die Hosted Version von Agilo durch .htaccess. Dies bietet zwar einen serverseitigen Zugriffsschutz, jedoch bedeutet dies für die Software, dass sich ein Benutzer zwar abmelden, sich jedoch ohne Eingabe von Benutzernamen oder Passwort sofort wieder anmelden kann.

Zum Schutz der Daten vor dem Zugriff durch Dritte erfolgt die Verbindung bei der Hosted-Version über eine gesicherte Verbindung. Bei der kostenlosen, sowie der Pro-Version ist dies abhängig von den Server-Einstellung. Hier sollte darauf geachtet werden, dass der Server gesicherte Verbindungen per HTTPS unterstützt.

Kunden von Hosted Agilo for Trac und Agilo Pro erhalten im Notfall Hotfixes durch ein Service Level Agreement[22]. Zudem wird die Software der Hosted Version automatisch auf dem neusten Stand gehalten. Nutzer der freien Version müssen bis zum nächsten Release warten[25].

Die Verfügbarkeit von Agilo for Trac ist bis zu 100% gegeben. Die Informationen für das Scrum-Projekt werden zentral gespeichert. Eine Synchronisierung der Daten zwischen den verschiedenen Personen ist daher nicht nötig. Es wird somit sichergestellt, dass mit den neusten Informationen gearbeitet wird.

Bewertung Teilbereich
Agilo for Trac ist zu 100% verfügbar. Zudem sorgt der SLA für eine Verbesserung der Verfügbarkeit, sowie der Sicherheit. Die aktuelle Hosted-Version weißt jedoch eine Sicherheitslücke auf. Daher wird die Sicherheit und Verfügbarkeit mit 2 bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Sicherheit und Verfügbarkeit
X

4.4.9 Installation und Hardwareanforderungen

Die Installation und das Hosting erfolgt bei der Hosted-Version durch Agile42.[25] Bei der Pro-Version besteht die Möglichkeit Agilo ebenfalls von Agile42 installieren zu lassen.[26] Für die kostenlose, sowie die Pro-Version ist ein Server mit Python nötig. Es wird auch eine Windows Installation angeboten, so dass Agilo auch auf einem PC laufen könnte.

Bewertung Teilbereich
Python ist für alle gängigen Betriebssysteme verfügbar und die Installation ist für Fachleute einfach durchzuführen. Im Vergleich zu anderen Web-Applikationen, die z.B. mit PHP und MySQL arbeiten, ist die Installation jedoch relativ kompliziert. Daher wird die Installation und Hardwareanforderung mit 2 bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Installation und Hardwareanforderungen
X

4.4.10 Kosten

Bei den Anfallenden Kosten werden folgende Kosten berücksichtigt:

  • Lizenzkosten
  • Serverkosten
  • Einrichtungskosten

Kosten, die durch die Verwendung der Software als Zeit anfallen werden nicht berücksichtigt, da diese auch in einer Vorgehensweise mit anderen Hilfsmitteln benötigt wird. Weiterhin werden Kosten für ggf. anfallende Schulungen nicht berücksichtigt.

Bei der Installation von Agilo wird von einem Stundensatz von 70€ ausgegangen und 3 Stunden angesetzt.

Für die Servermiete wird ein kleiner Server für 20€/monatlich angenommen. Dieser ist ausreichend für 20 Benutzer für einen Zeitraum von 6 Monaten.

Tabelle 3: Kosten
Kostenpunkt Free-Version Pro-Version Hosted-Version
Software-Lizenz 0,00 € 1.028,16 € 1.220,94 €
Server 240,00 € 240,00 € 0,00 €
Installation 210,00 € 210,00 € 0,00 €
Wartung 140,00 € 140,00 € 0,00 €
Summe 690,00 € 1.618,16 €  1.220,94 €
[Tabelle: 5]
Kosten

Bei Abzug der Gesamtkosten für die Free-Version von den Kosten der Hosted-Version ergibt sich der Aufschlag, den die Hosted-Version mehr kostet im Vergleich zu der kostenlosen Version. Umgerechnet auf einen Benutzer sind dies 4,43 € monatlich.

Dieser Betrag sollte in die Überlegung, welche Version verwendet wird, aufgenommen werden. Das Whiteboard, sowie die Vorteile der SLA sollten diese Kosten amortisieren.

Weiterhin ist zu erkennen, dass sich die Pro-Version gegenüber der Hosted-Version nicht rechnet, es sei denn sie soll auf einen Server im Intranet betrieben werden (dann ändern sich jedoch die Kosten für den Server) oder die Unternehmung hat spezielle Anforderungen an die Sicherheit.

Bewertung Teilbereich
Insgesamt betrachtet sind die Kosten für die Software und Hardware für Agilo for Trac nicht als hoch zu bewerten. Es sollte jedoch berücksichtigt werden, dass die Software selten alleine eingeführt wird sondern im Zusammenhang mit der Implementierung von Scrum im Unternehmen zu sehen ist. Hierbei sollten die Kosten für Consulting und eventuelle - wenn auch kurzfristige - Produktivitätsschwankungen der Software- oder Projekt-Teams berücksichtigt werden. Dieser Bereich wird mit der Note zwei bewertet.

Bewertung Teilbereich
1
2
3
4
5
6
Kosten
X

4.5 Gesamtergebnis

Bewertungskriterien Bewertungsskala (nach Schulnoten) Gewichtungsfaktor Ergebnis
1
2
3
4
5
6
Scrum Rollen
X
0,15
0,30
Scrum Artefakte
X
0,15
0,30
Scrum Meetings
X
0,15
0,45
Bedienbarkeit und Usability
X
0,10
0,40
Schulungsaufwand und Einarbeitungszeit
X
0,05
0,15
Team-Kommunikation und Wissensmanagement
X
0,10
0,30
Reportingfunktionen
X
0,10
0,20
Sicherheit und Verfügbarkeit
X
0,10
0,20
Installation / Hardwareanforderungen / Maintennance
X
0,05
0,10
Kosten
X
0,05
0,10
Summe / Durchschnitt
1
2,50
[Tabelle: 6]
Gewichtete Bewertungsmatrix

5 Fazit

Agilo for Trac ist ein übersichtliches Scrum Tool, welches alle durch die Scrum Vorgehensweise geforderten Rollen und Artefakte unterstützt. Die Umsetzung des Whiteboards ist hierbei besonders gelungen, da dies einer "echten" Tafel denkbar nahe kommt und so die Kernidee von Scrum in den digitalen Raum Transportiert. Die Bedienoberflächen könnten übersichtlicher und moderner gestaltet sein.

Im Vergleich zu klassischen Office-Tools konnte Agilo dennoch durchweg überzeugen. Die Verlinkung der einzelnen Elemente untereinander und die mitgelieferten Funktionen ließen sich so nicht in den Vergleichs-Tools abbilden.

Die Fülle der Funktionen in Agilo, die nicht direkt Scrum spezifisch sind und aus der Ticketsystemherkunft von Agilo for Trac resultieren, verwirren teilweise und lenken von den eigentlichen Scrum-Prozessen ab. Es entsteht hier der Eindruck, dass Agilo durch die Möglichkeiten von Trac begrenzt wird.

Dies hat offensichtlich auch der Hersteller Agile42 erkannt und entwickelt zur Zeit eine nicht mehr auf Trac basierende Version unter dem Namen Agilo for Scrum.

6 Ausblick

Am 31. Mai 2011 kündigte Agile42 ein neues Tool für den Scrum Prozess an. Infolge dessen wurde das Tool Agilo for Scrum in Agilo for Trac umbenannt und das neue Tool führt nun den Namen „Agilo for Scrum“.

Mit Agilo for Scrum will Agile42 eine neue Generation von Scrum Tools entwickeln. Es soll nun in einer „komplett neuen und außergewöhnlichen Art und Weise“ den Scrum Prozess unterstützen[27].

Diese Arbeit konnte zeigen, dass Agilo for Trac Aufgrund der Basis Trac zwar eine große Funktionsvielfalt aufweist, jedoch nicht einfach zu bedienen ist. Im folgenden Abschnitt wird das neue Tool Agilo for Scrum kurz vorgestellt und dessen Unterschiede zu Agilo for Trac ebenfalls kurz dargestellt.

6.1 Agilo for Scrum

Zunächst ist festzustellen, dass Agilo for Scrum im Gegensatz zu Agilo for Trac auf keinem System aufsetzt. Dies bietet den Vorteil, dass die neue Software auf keine Funktionen, die eigentlich für andere Aufgaben konzipiert wurden, zurückgreifen muss, um den Scrum-Prozess abbilden zu können. Diese Auffassung wird nach wenigen Klicks bestätigt. Begriffe wie „Ticket“ oder andere Bezeichnungen, die nicht Scrum entstammen befinden sich in Agilo for Scrum nur noch wenige.

Ein wichtiger Unterschied zu Agilo for Trac ist zudem, dass der Benutzer durch den Scrum Prozess geführt wird. Die Navigation orientiert sich nun nach dem Ablauf von Scrum und nicht nach Funktionen.

Navigation von Agilo for Scrum
[Abbildung: 15]
Navigation von Agilo for Scrum
Navigation von Agilo for Trac
[Abbildung: 16]
Navigation von Agilo for Trac

Dies ist bereits an der neuen Navigation erkennbar (siehe Abbildung). Die Software wirkt nun eher wie ein Wizard, der ein durch den Prozess führt. Es wird nun klar, in welcher Reihenfolge User Stories, Backlogs und Aufgaben erstellt werden müssen. Auch der Zusammenhang zwischen den verschiedenen Elementen von Scrum wird in der neuen Software deutlicher.

Die Anpassung an die Bedürfnisse von Scrum hat jedoch zur Folge, dass einige Funktionen, wie das Wiki oder eine SVN Anbindung fehlen. Jedoch ist zurzeit noch nicht geklärt, ob diese Funktionalitäten noch folgen, da sich Agilo for Scrum noch in der Beta-Phase befindet.

Im Vergleich zu Agilo for Trac begibt sich Agile42 mit dem neuen Produkt auf eine neue Ebene. Es bleibt jedoch abzuwarten, wie sich das neue Projekt entwickelt.

7 Fußnoten

  1. ↑ Quelle: [ Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009 ]
  2. ↑ Vgl. S. 304 [ Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln, Carl Hanser Verlag, München 2009 ]
  3. ↑ 3,0 3,1 Vgl. S. 62 [ A. Schatten, S. Biffl, M. Demolsky, E. Gostischa-Franta, Th. Östereicher, D. Winkler: Best Practice Software-Engeneering - Eine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen, Spektrum Akademischer Verlag, Heidelberg 2010 ]
  4. ↑ Vgl. Carsten Dogs, Timo Klimmer
  5. ↑ Vgl. Tessen Freund
  6. ↑ Vgl. http://agilemanifesto.org/history.html (14.06.2011 21:31)
  7. ↑ http://agilemanifesto.org/iso/en/principles.html (14.06.2011 21:33)
  8. ↑ Quelle: [ Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009 ]
  9. ↑ Vgl. Schwaber (1996)
  10. ↑ http://www.scrum-kompakt.de/einfuehrung-in-scrum/ (14.06.2011 22:19)
  11. ↑ Vgl. http://agilemanifesto.org/iso/de/ (14.06.2011 22:33)
  12. ↑ Vgl. S. 95 [ Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln, Carl Hanser Verlag, München 2009 ]
  13. ↑ Vgl. S. 7 [ Holger Staudacher/Tobias Langenbacher: Agiles Projektmanagement mit Scrum, 2008 GRIN Verlag ]
  14. ↑ Vgl. S. 142 [ Mike Cohn: User Stories: Für die agile Software-Entwicklung mit Scrum, XP u.a. , mitp 2010 ]
  15. ↑ Vgl. S. 34 [ Roman Pichler: Agiles Projektmanagement: Eine Einführung, OBJEKTspektrum 01/2005 ]
  16. ↑ Vgl. http://inside-scrum.blogspot.com/2008/02/sprint-retrospective.html (15.06.2011 15:36)
  17. ↑ Vgl. S. 207 bis 216 [ Mike Cohn: Agile Softwareentwicklung, 2010 Verlag Addison-Wesley]
  18. ↑ Vgl. S.98 [ Peter Killisperger:Anwendung von agilen Methoden im industriellen Umfeld, 2006 GRIN Verlag ]
  19. ↑ Vgl. Agile42 GmbH - http://www.agile42.com/about-us/
  20. ↑ Agile42 GmbH - http://agilo.enstore.com/item/hosted
  21. ↑ Agile42 GmbH - http://agilo.enstore.com/item/licenses-agilo1lic
  22. ↑ 22,0 22,1 22,2 22,3 Agile42 GmbH: http://www.agile42.com/agilo/features/ (11.06.2011 21:30)
  23. ↑ Vgl. S. 134 [ Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln, Carl Hanser Verlag, München 2009 ]
  24. ↑ Agile42 GmbH: http://agile42.com/de/training/ (11.06.2011 21:52)
  25. ↑ 25,0 25,1 Agile42 GmbH: http://agile42.com/de/agilo/hosted-agilo-Trac/ (11.06.2011 21:33)
  26. ↑ Agile42 GmbH: http://agile42.com/de/agilo/support-and-services-agilo-scrum/ (11.06.2011 22:48)
  27. ↑ Vgl. Agile42 GmbH: http://agile42.com/de/blog/2011/05/31/agilo-for-scrum-and-agilo-for-Trac/ (13.06.2011 17:28)

8 Abkürzungsverzeichnis

AbkürzungBedeutung
AgiloAgilo for trac
CSVComma separted value
EDVElektronische Datenverarbeitung
htaccesshypertext access
HTTPSHypertext Transfer Protocol Secure
PHPHypertext Preprocessor
RSSReally Simple Syndication
SLAService Level Agreement
SVNApache Subversion
TABTabulator
WikiWikipedia
XPeXtreme Programming

9 Abbildungsverzeichnis

  1. ↑ Beispiel Scrum Burndownchart
  2. ↑ Der Scrum Prozess
  3. ↑ Logo Agilo for Trac
  4. ↑ User-Administration in Agilo for Trac
  5. ↑ User-Administration in Excel
  6. ↑ Product Backlog in Agilo for Trac
  7. ↑ Product Backlog in Excel
  8. ↑ Sprint-Backlog (Whiteboard-Ansicht) in Agilo for Trac
  9. ↑ Sprint-Backlog in Excel
  10. ↑ Burndown Chart in Agilo for Trac
  11. ↑ Burndown Chart in Excel
  12. ↑ "Whiteboard" von Agilo for Trac
  13. ↑ Ticketübersicht in Agilo for Trac
  14. ↑ Ticketübersicht in Agilo for Trac
  15. ↑ Navigation von Agilo for Scrum
  16. ↑ Navigation von Agilo for Trac

10 Tabellenverzeichnis

  1. ↑ Preisliste Agile42 Hostingkosten
  2. ↑ Funktionsumfang der Agilo Basisversion, inkl. Gewichtung
  3. ↑ Funktionsumfang der Agilo Pro-Version, inkl. Gewichtung
  4. ↑ Gewichtete Bewertungsmatrix
  5. ↑ Kosten
  6. ↑ Gewichtete Bewertungsmatrix


11 Literatur- und Quellenverzeichnis

Autor Quelle / Literatur
Mike Cohn Agile Softwareentwicklung: Mit Scrum zum Erfolg, VerlagAddison-Wesley Verlag, München 2010
Mike Cohn User Stories: Für die agile Software-Entwicklung mit Scrum, XP u.a. , mitp 2010
Boris Gloger Scrum-Produkte zuverlässig und schnell entwickeln, Carl Hanser Verlag, München 2009
Oliver Hoß Agile Softwareentwicklung, Books on Demand GmbH, Norderstedt 2008
Peter Killisperger Anwendung von agilen Methoden im industriellen Umfeld, 2006 GRIN Verlag
Holger Staudacher/Tobias Langenbacher Agiles Projektmanagement mit Scrum, 2008 GRIN Verlag
Agile42 GmbH Hersteller der Software Agilo for Trac, Homepage: http://agile42.com/ , 2011
Ralf Wirdemann Scrum mit User Stories, Hanser Verlag, München 2009
Roman Pichler Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.Verlag GmbH, Heidelberg 2008
Roman Pichler Agiles Projektmanagement: Eine Einführung, OBJEKTspektrum 01/2005
Carsten Dogs, Timo Klimmer Agile Software-Entwicklung kompakt, mitp, 2005
Tessen Freund Software Engineering durch Modellierung wissensintensiver Entwicklungsprozesse, GITO mbH Verlag, 2006
Manifest für Agile Softwareentwicklung, Homepage: http://agilemanifesto.org/iso/de/ , 2010
Ingo Vogt Agile Softwareentwicklung, Homepage: http://www.ordix.de/ORDIXNews/3_2007/Projektmanagement/agile_softwareentwicklung.html
A. Schatten, S. Biffl, M. Demolsky, E. Gostischa-Franta, Th. Östereicher, D. Winkler Best Practice Software-Engeneering - Eine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen, Spektrum Akademischer Verlag, Heidelberg 2010
Von „http://winfwiki.wi-fom.de/index.php/Leistungsanalyse_Agilo_for_Trac“
Persönliche Werkzeuge