Wie agil sind Funktionspunkte?

Viele Unternehmen haben gelernt, dass sie ihre Softwareprojekte besser in den Griff bekommen können, indem sie sie mit Funktionspunkten schätzen. Gleichzeitig, Wir sehen, dass immer mehr Organisationen eine agile Arbeitsweise haben, normalerweise durch Anwendung von Scrum. Die große Frage ist, ob Function Points stehen bleiben. Wirft Scrum sie über Bord?? Oder haben Function Points in einer agilen Welt noch einen Wert?? In diesem Blog zeigen Jolijn Onvlee und Rini van Solingen, welche Reibungen und Gemeinsamkeiten es gibt.

Agil/Scrum

Agil (mit Scrum als am häufigsten verwendeten Ansatz) wird von einer wachsenden Zahl von Organisationen als Lösung für das Scheitern großer IT-Projekte angenommen. Indem Sie beginnen, Software direkt zu liefern, alle zwei Wochen erhält ein Kunde direkten Einblick in den Fortschritt und Mehrwert. Benutzer müssen nicht mehr auf die Funktionalität mit dem höchsten Geschäftswert warten. Und dazu, Der kontinuierliche Fluss von Feedback führt zu wertvollen Systemen, die funktionieren, viel schneller. Tatsächlich, mit dem Einsatz von Scrum, ein großes IT-Projekt zerfällt in viele kleine Projekte. Das erleichtert das Reagieren auf neue Erkenntnisse und reduziert die Komplexität des gesamten Projekts enorm.

Scrum handhabt Systemspezifikationen auf drastische Weise. Das Produkt wird nur allgemein beschrieben (genannt die Produktrückstand).Dann, zunächst werden nur die Teile im Detail ausgearbeitet, die den höchsten Geschäftswert haben und die Abschlussarbeiten werden schnell geliefert. Nach dieser Lieferung wird erneut der höchste Geschäftswert ermittelt, entwickelt und ausgeliefert, und so weiter. Ständige Anpassung ist so möglich. Dies ersetzt die ursprüngliche Idee eines Projekts, das ein vordefiniertes Ergebnis liefert. Die Schätzung des gesamten Lieferumfangs macht keinen Sinn mehr, einfach weil der gesamte umfang nicht mehr im detail ausgearbeitet ist. Der Fleck am Horizont kann sich jederzeit verschieben.

Reibung

Scrum handhabt Schätzungen und Budgetierung anders als ein herkömmlicher und systematischer Ansatz. Der traditionelle Ansatz verwendet oft die Funktionspunktanalyse (FPA) zur Quantifizierung. FPA wird verwendet, um abzuschätzen, wie viel die Herstellung der Software kosten wird und wie lange es dauert, diese zu liefern. Ein Funktionspunkt wird als Metrik verwendet, um die Größe des Systems zu bestimmen. Diese Dimensionierung erfolgt auf Basis des Pflichtenheftes. Für FPA ist ein gewisser Detaillierungsgrad von dem, was Sie erstellen werden, erforderlich.

Funktionspunkte und Scrum scheinen also nicht zusammenzupassen. Letztendlich, der erste möchte vorab eine vollständige Spezifikation und der andere möchte die Spezifikation jederzeit hinterfragen und aktualisieren und geht nicht zu weit ins Detail. Die Sprints innerhalb des Scrum-Ansatzes sind zu kurz und zu abwechslungsreich, um sie anhand von Funktionspunkten abzuschätzen. Gleichzeitig, auch innerhalb der agilen Organisationen, die Kosten müssen kontrolliert werden. „Wir werden am Ende sehen, wie viel es gekostet hat“ ist für die meisten Organisationen inakzeptabel. Das würde bedeuten, dass Agile Anarchie bei den IT-Ausgaben schafft, was Unsinn ist. Auch bei Scrum hat ein Kunde ein Kontrollbedürfnis. Der Product Owner möchte den Überblick über die Ergebnisse all dieser Bemühungen behalten (Ziel) und wie viel Zeit und Geld es am Ende gekostet hat (Budget). Und genau hier bietet die traditionelle FPA eine Lösung.

Ähnlichkeiten

Wenn man sich die Kombination von FPA und Scrum genauer anschaut, Sie sehen, dass sie sich eher verstärken als schwächen. Letztendlich, FPA hilft bei der Festlegung des Gesamtumfangs (der Fleck am Horizont) und das entsprechende Budget. Scrum hilft dabei, innerhalb dieses Budgets zuerst die Funktionen mit dem höchsten Geschäftswert zu realisieren. Feedback fließt so schnell wie möglich in den Lieferprozess ein. Feedback an zwei Fronten: Erste, ob der Gesamtumfang stimmt und, zweitens, ob das gesamte Problem im Rahmen des Budgets gelöst werden kann.

In der Praxis bedeutet dies, dass der Rückstand für das Projekt auf globaler Ebene ermittelt wird. Innerhalb von Scrum ist es gängige Praxis, dass der Teil des Produkts mit dem höchsten Geschäftswert bereits eine erhebliche Menge an Details aufweist. Dieser Detaillierungsgrad (vorzugsweise für mehrere Sprints) ist in der Regel ausreichend, um eine Funktionspunktanalyse durchzuführen. Sie können dann diese Analyse verwenden, um die Gesamtzahl der Funktionspunkte für den gesamten Rückstand durch Extrapolation zu bestimmen. Innerhalb der FPA-Methode, das wird erlaubt sein.

Scrum und FPA sind Freunde

Zusamenfassend, Scrum und FPA können sich hervorragend helfen und stärken. Die Funktionspunkte helfen Ihnen, die Gesamtausgaben im Griff zu behalten. Durch den Einsatz von Scrum bleiben Sie auf der Grundlage von Erkenntnissen flexibel. Letztendlich liegt es an Ihnen, das Gesamtproblem zu lösen. So schnell, so gut und so günstig wie möglich. In diesem Bereich, Funktionspunkte und Scrum haben ein gemeinsames Ziel.
Scrum und FPA sind also Freunde. Kontrollverlust und Budgetüberschreitung sind die (gemeinsam) Feind!

Schnelle Gewinne

Quick Wins in der Kombination Scrum und Function Points

1. Schnellere Konkretisierung des Product Backlogs
   Das Product Backlog ist die Beschreibung aller nicht implementierten Anforderungen, die gestellt werden müssen. Ganz oben im Product Backlog stehen die Items, die für das Geschäft am wichtigsten sind und nur diese Items werden im Detail ausgearbeitet. Die Größe des Product Backlogs kann mit FPA konkretisiert werden. FPA-Shows was Funktionalität ist erforderlich. FPA bietet damit eine funktionale Zusammenfassung des Product Backlogs.
2. Messbares Ziel
   Ein detailliertes Product Backlog für die ersten sechs Sprints reicht aus, um einen geschätzten FPA zu erstellen (ISO / IEC 24570 Nesma-Methode zur Messung der funktionellen Größe). Die Anzahl der Funktionspunkte kann dann auf die Summe hochgerechnet werden. So, das ultimative Ziel (der Fleck am Horizont) kann quantifiziert werden, und das Endergebnis wird greifbar gemacht, ohne dass detaillierte Spezifikationen für das gesamte Produkt erforderlich sind.
3. Einfachere Messung des „Mehrwerts“’
   Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“ (Einfachere Messung des „Mehrwerts“, selbstverständlich). Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“, Einfachere Messung des „Mehrwerts“. jedoch, Einfachere Messung des „Mehrwerts“: Funktionspunkte!
4. Einfachere Messung des „Mehrwerts“
   Einfachere Messung des „Mehrwerts“, Einfachere Messung des „Mehrwerts“. Einfachere Messung des „Mehrwerts“ – und darin, die nächsten Sprints – lässt sich einfach messen, auch hinsichtlich der Gruppierung von Funktionalitäten. Das Gesamtbild bleibt erhalten und Schichten sind nachvollziehbar.
5. Unterstützung bei Schätzungen
   Schätzen ist die Aufgabe des Teams. Eine Schätzung ist immer (und bleibt) ein heikles Geschäft. Letztendlich, ein Team hat keine Kristallkugel und bevor du dich versiehst, Schätzungen werden wie Garantien verwendet. Scrum-Schätzungen mit Story Points, aber das sind relativ: vergleichbar mit dem Team aber nicht darüber hinaus. Funktionspunkte, jedoch, sind absolut und vergleichbar. Funktionspunkte sind zwischen Projekten vergleichbar und können nicht nur im Voraus gemessen werden, aber auch während und nach einem Projekt. So, das Team bekommt eine zusätzliche Hilfe bei der Schätzung.
6. Verbesserungen erkennen
   Da FPA ein objektives Maß bietet, kann es in der Retrospektive des Scrum-Prozesses verwendet werden, um Verbesserungen aufzuzeigen. So können Sie den Teams helfen, voneinander zu lernen und die wichtigsten Hemmfaktoren zu erkennen.
7. Bestätigung des Business Case für Scrum
   Während viele Organisationen von Scrum begeistert sind,, Gerüchte sind durch die Weinrebe zu hören, dass Scrum-Prozesse mehr Nacharbeit beinhalten (durch fortschreitende Einsichten) was sie teurer macht. Die Anzahl der Funktionspunkte der neuen und erweiterten Funktionalität kann ermittelt und damit die Produktivität sowohl der Adaption als auch des gesamten Prozesses festgestellt werden. Dann kann der Business Case objektiv bestimmt werden.

Dieser Blog wurde ursprünglich als Meinungsartikel in . veröffentlicht Automatisierungsleitfaden (In Holländisch).

 

Über die Autoren

Jolijn Onvlee (jolijn@onvlee.com) ist unabhängiger FPA-Spezialist und Berater, Auditor und Dozent im Bereich Qualität, Budget- und Produktivitätsmanagement. Jolijn hat auch viele Jahre als Vorsitzender und Vorstandsmitglied von Nesma . gearbeitet.

Rini van Solingen ist CTO bei Prowareness (rini@scrum.nl) und Professor an der Technischen Universität Delft. Rini ist die Autorin des Buches “Die Macht von Scrum”; jetzt auch auf Französisch erschienen, Deutsch und Englisch.