Aufwandsschätzungen in der agilen Softwareentwicklung E-Book

Stefan Luckhaus

• Herausgeber: tredition
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2016

Seitenzahl: 46

Beschreibung

Softwareentwicklung unterliegt Risiken, sobald sie an feste, vertraglich vereinbarte Rahmenbedingungen gebunden ist; Rahmenbedingungen wie die Lieferung eines festen Funktionsumfangs zu einem festen Preis und an einem vereinbarten Liefertermin. Viele dieser Risiken können durch die Prinzipien agiler Softwareentwicklung gemindert werden. Die Planung und Steuerung, um Entwicklungsprojekte innerhalb dieser Parameter navigieren zu können, erfordert außerdem Methoden zur Aufwandsschätzung. Damit diese die Vorteile agiler Entwicklung nicht mindern, müssen sie schnell anwendbar, im Idealfall automatisierbar sein und sich nach jedem Sprint selbst kalibrieren. Dieses Buch beschreibt, wie Umfangsmetriken in der Praxis einer an agilen Werten orientierten Softwareentwicklung gewinnbringend eingesetzt werden können, welche Unterschiede und Einschränkungen es gibt, wie die Genauigkeit der Aufwandsschätzungen mit jedem Sprint erhöht werden kann und wie automatisierte Messungen möglich sind.

Leseprobe

www.tredition.de

Stefan Luckhaus

Aufwandsschätzungen in der agilen Softwareentwicklung

Einsatz von Methoden zur Messung des funktionalen Umfangs

© 2016 Stefan Luckhaus

Verlag: tredition GmbH, Hamburg

ISBN

Paperback

978-3-7323-6593-7

Hardcover

978-3-7323-6594-4

e-Book

978-3-7323-6595-1

Das Werk, einschließlich seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung ist ohne Zustimmung des Verlages und des Autors unzulässig. Dies gilt insbesondere für die elektronische oder sonstige Vervielfältigung, Übersetzung, Verbreitung und öffentliche Zugänglichmachung.

Inhaltsverzeichnis

Merkmale und Bedeutung agiler Softwareentwicklung

Entstehungsgeschichte

Status quo

Zuverlässigkeit

Methoden zur direkten und indirekten Aufwandsschätzung

Prinzip der inkrementellen Entwicklung

Expertenschätzungen

Indirekte Schätzungen mit Story Points

Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Zusammenfassung

Methoden zur Bestimmung des Entwicklungsumfangs

Function Point-Analyse

COSMIC-Methode

Data Interaction Point-Methode

Erweiterung der Methoden zur Bestimmung des Weiterentwicklungsumfangs

Einfluss der Komplexität

Komplexität einer Implementierung

Interaktionskomplexität

Algorithmische Komplexität

Methodenvergleich

Weitere Methoden

Messung des Referenzwerts für eine indirekte Aufwandsschätzung

Nachträgliche Messung der Produktivität

Prozessabgrenzung

Betrachtung von Teilprozessen

Einhaltung festgelegter Qualitätskriterien

Automatisierte Messungen

Abbildung zu zählender Objekte auf konstruktive Merkmale

Mögliche Einschränkungen

Iterative Präzisierung der gemessenen Produktivität

Berücksichtigung nicht-funktionaler Anforderungen

Regelmäßige Messungen

Zusammenhang von Produktivität und Qualität

Fazit

Glossar

Literaturverzeichnis

Über den Autor

Einleitung

Indirekte Aufwandsschätzungen, bei denen ein methodisch nach festen Regeln ermittelter Wert für den geplanten Entwicklungsumfang mit einem präzise gemessenen Erfahrungswert für die eigene Produktivität ins Verhältnis gesetzt wird, sind eine bewährte Methode zur verlässlichen Planung von Softwareentwicklungsprojekten. Ihre Anwendung erfordert jedoch einen minimalen Spezifikationsgrad, das heißt aus einem Satz formulierte User Stories müssen durch Anwendungsfälle und Elementarprozesse präzisiert werden. Danach ist ihre „Vermessung“ möglich – und sie erfordert bei entsprechenden Methodenkenntnissen keinen großen Aufwand.

Dieses Buch beschreibt in kurzen Ausführungen und basierend auf eigenen praktischen Erfahrungen des Autors die Grundlagen methodischer Aufwandsschätzungen. Es zeigt, dass diese Vorgehensweise nicht nur gut mit agiler Softwareentwicklung vereinbar ist, sondern gerade Grundprinzipien wie beispielsweise

die flexible Berücksichtigung geänderter Anforderungen oder

regelmäßige Verbesserungen als Folge von Nachbetrachtungen

unterstützt.

Merkmale und Bedeutung agiler Softwareentwicklung

Entstehungsgeschichte

Anfang der 90er Jahre gerieten viele Großprojekte aufgrund ihrer langen Prozesslaufzeiten und den währenddessen häufig wechselnden Anforderungen, starren Rollenverteilungen und anderen Problemen in Schieflage. Häufig genannt wird in diesem Zusammenhang das nach dem Wasserfallmodell begonnene Großprojekt C3 des Chrysler-Konzerns (Chrysler Comprehensive Compensation). In dieser Zeit experimentierte man in den USA mit leichtgewichtigen Entwicklungsprozessen und fand heraus, dass beispielsweise durch kürzere Laufzeiten, mehr Eigenverantwortung und Zusammenarbeit in den Projektteams oder einen unkomplizierten Umgang mit Änderungsanforderungen viele Risiken besser bewältigt und die Projekte häufiger zum Erfolg geführt werden konnten - Erfolg im Sinne einer frühzeitigen Verwertbarkeit der Ergebnisse durch den Auftraggeber. Es entstanden Vorgehensmodelle wie Scrum oder Crystal. Das Chrysler-C3-Projekt wurde durch die Einführung verschiedener Methoden aus dem Kontext leichtgewichtiger Vorgehensmodelle vor dem Scheitern bewahrt, die anschließend unter der Bezeichnung Extreme Programming populär wurden [Wells 2009].

Auf einem Treffen im Februar 2001 in Utah (USA) tauschten Experten ihre Erfahrungen mit Softwareentwicklungsprozessen aus und formulierten ein Wertesystem, das das Fundament für die künftig als agil bezeichnete Art der Softwareentwicklung bildete – das Agile Manifest [Agiles Manifest 2001]:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen

mehr als Prozesse und Werkzeuge

Funktionierende Software

mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden

mehr als Vertragsverhandlung

Reagieren auf Veränderung

mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Das Agile Manifest wird oft falsch interpretiert. Beispielsweise dahingehend, dass man auf Dokumentation verzichten kann. Insbesondere der letzte Absatz macht jedoch deutlich, dass es dabei nur um Prioritäten geht, eine Tätigkeit wie Dokumentation aber durchaus für wichtig befunden wird.

Präzisiert wurde dieses Wertesystem durch zwölf Prinzipien agiler Softwareentwicklung [Agiles Manifest Prinzipien 2001]:

1.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

2.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

3.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

4.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

5.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

6.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

7.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

8.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutsolltenein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

9.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

10.

Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.

11.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

12.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Der Erfolg agiler Methoden sprach sich herum. Nach einer Ende 2005 von Forrester Research durchgeführten Untersuchung entwickelten bereits 14% der Unternehmen in Europa und Nordamerika ihre Software unter Zuhilfenahme von agilen Prozessen, während weitere 19% über die Nutzung nachdachten [Forrester 2005].

Status quo

Der auf agile Methoden spezialisierte Technologieanbieter VersionOne stellte in seiner siebten jährlichen Umfrage zu agilen Methoden fest, dass 2013 bereits 84% aller Unternehmen agile Entwicklung betreiben [VersionOne 2013]. Inzwischen hat die Zahl vermutlich weiter zugenommen. Jedoch auch wenn keine agilen Vorgehensmodelle wie Scrum eingesetzt werden sondern hybride Modelle, beispielsweise die Kombination agiler Methoden mit Projektmanagementstandards, so findet man in erfolgreichen Projekten immer wieder die folgenden drei typischen Merkmale agiler Entwicklung:

Inkrementell