Software-Messung – ein Überblick für CIOs

Softwaremessungen sind wichtig, da es schwierig ist, zu verwalten, was nicht gemessen wird. Softwarearbeit ist Wissensarbeit. Es ist eines der kostspieligsten Unterfangen der Menschheit, da mehr als 50 Millionen Menschen auf der ganzen Welt in hochbezahlten Software-Positionen arbeiten und für die meisten von ihnen sind ihre Anstrengungen unermesslich. Vielen Menschen ist nicht bewusst, dass die Softwaregröße gemessen werden kann. Die meisten anderen Formen menschlicher Arbeit verfügen über standardisierte Maße für Größe und Produktivität. Bei der Arbeit mit Software gibt es zwar geeignete Messgrößen, diese werden jedoch selten verwendet. Branchenführer, Pädagogen, Führungskräfte und sogar Regierungen stehen diesem Phänomen bisher gelassen gegenüber, aber mit der zunehmenden Bedeutung von Software für das Überleben von Unternehmen sind mehr Transparenz und eine angemessene Softwaremessung erforderlich. Die Einführung von Softwaremessungen mit COSMIC-Dimensionierung wird CIOs dabei helfen, effektiver zu verwalten.

Software-Messung hilft bei der Beantwortung wichtiger Fragen

Beim Versuch, die Fragen zu beantworten wie viel Aufwand wird benötigt, um ein Softwareprojekt abzuliefern bzw wann wird es fertig sein, verlassen sich die meisten Organisationen auf die Meinungen von Experten. Diese Softwareschätzungen sind in der Regel unwissenschaftlich und anfällig für Manipulationen. Was sie brauchen, ist ein konsistentes Mittel zur Softwaremessung. Sie sind eine unsichere Grundlage für verlässliche Managemententscheidungen und können oft zu kontraproduktivem Verhalten führen. Mit standardisierten, gültigen Softwareschätzungen und Softwaremetriken, die auf einer standardisierten funktionalen Dimensionierung in COSMIC Function Points (CFPs) basieren, können CIOs jedoch die Sichtbarkeit, Verwaltbarkeit, Produktivität und das Preis-Leistungs-Verhältnis der Softwarearbeit in ihrer Organisation erheblich verbessern. CFP-basierte Softwaremetriken und entsprechende Projektmetriken eignen sich auch für die Berichterstattung auf Vorstandsebene. Diese 15-minütige Lektüre wird ausreichen, um Ihnen den Einstieg in höhere Ebenen des Softwaremanagements zu erleichtern.

Software-Messung von Größenangelegenheiten.

Betrachten wir einige allgemeine Merkmale, die speziell für die Arbeit mit Software gelten:

• Softwarearbeit wird fast ausschließlich durch menschliche Anstrengung vorangetrieben.
• Es gibt viele Faktoren, die den Aufwand bestimmen, der für die Entwicklung einer Software erforderlich ist. Der wichtigste Faktor ist funktionale Größe.
• Funktionelle Größe kann geschätzt und in manchen Fällen sogar gemessen werden, bevor mit der Codierung begonnen wird.
• Es gibt Dutzende anderer Faktoren, die den Aufwand für die Entwicklung von Software beeinflussen, darunter Teamkompetenz, Komplexität und Unterstützung durch die Geschäftsleitung, aber die Größe ist der wichtigste Faktor.
• Es gibt große Produktivitätsunterschiede zwischen den Entwicklern. 10x oder mehr zwischen der geringsten und der höchsten Produktivität – und das Gleiche gilt für Teams.
• Softwarearbeit lässt sich nicht skalieren. Es gibt Größennachteile, die hauptsächlich auf den hohen Zeitanteil zurückzuführen sind, der für die Kommunikation zwischen Teammitgliedern aufgewendet wird. Eine gemeinsame Sprache und Kenntnisse über die Größe eines Projekts können helfen, dieses Problem einzudämmen.

Seitdem Software zu einer Branche geworden ist, ist die Softwaredimensionierung ein Thema endloser Debatten unter Entwicklern und Managern. Angesichts der Vielzahl an Menschen, die in der Softwarebranche tätig sind, ist es überraschend, dass Führungskräfte und Vorstände dies zugelassen haben.

Obwohl es viele Faktoren gibt, die die Kosten und Dauer eines Softwareprojekts beeinflussen, ist die Größe der wichtigste Faktor. Wenn Sie die Anforderungen analysiert und die Funktionsgröße von CFPs ermittelt haben, können Sie mit einiger Sicherheit vorhersagen, wie lange es dauern und wie viel es kosten dürfte. Dies sind wichtige Fragen, die verantwortungsbewusste Manager beantworten müssen, um effektiv planen zu können. Das Wissen über die funktionale Größe zu Beginn des Projektlebenszyklus kann dazu beitragen, die Qualität der von Managern getroffenen Entscheidungen zu verbessern und somit das Risiko, die Kosten und die Dauer des Projekts zu reduzieren. Es stehen Branchen-Benchmarks zur Verfügung, oder Organisationen können ihre eigenen Benchmarks für die Produktivität in CFP festlegen, um die Frage „Wann sind wir fertig?“ zu beantworten. Frage.

Softwaremessung und Softwareentwicklung

Alle anderen Formen des Ingenieurwesens verwenden standardisierte (ISO) Größenmaße. Software Engineering ist die einzige technische „Disziplin“, die dies nicht geschafft hat. Die Softwareentwicklung sollte eine standardisierte Größenmessung umfassen.

Standardisierte Softwaredimensionierung

Viele Leute denken, dass die Messung der Softwaregröße erst durchgeführt werden kann, nachdem die Arbeit abgeschlossen ist. Das ist nicht so. Software kann bereits vor Beginn der Codierung vermessen werden.

Den meisten in der Branche Tätigen ist nicht bewusst, dass die Messung der Softwaregröße möglich und einfach durchzuführen ist, noch bevor mit der Codierungsarbeit begonnen wird. Die funktionale Größe kann allein durch die Untersuchung der Benutzeranforderungen bestimmt werden.  

Sie können Codezeilen zählen, nachdem die Software geschrieben wurde, aber die Anzahl der Codezeilen (Line of Code Count, LOC) ist von geringem Wert, es sei denn, Sie berücksichtigen den Aufwand für die Aufrechterhaltung dessen, was bereits geschrieben wurde. Stellen Sie sich außerdem vor, dass zwei Entwickler einige Funktionen schreiben. Entwickler A kann sie in nur vier Codezeilen schreiben, während Entwickler B 40 Zeilen benötigt, um die gleiche Funktionalität zu erreichen. Welches ist größer? Was ist produktiver? Was ist fehleranfälliger? Dies zeigt uns, dass wir LOC nicht zuverlässig als Prädiktor für Größe, Aufwand oder Zeitschätzung verwenden können.

Software-Messung der funktionalen Größe führt zu datengesteuerten Entscheidungen über Software

Als Gesellschaft bewegen wir uns schnell in Richtung datengesteuerter Entscheidungsfindung. Auch bei Entscheidungen zu Hause schauen wir uns vor der Kaufentscheidung Bewertungen und technische Daten an. Damit dieser Ansatz effektiv ist, müssen wir gültige, konsistente und vertrauenswürdige Daten verwenden. Nachdem wir viele Jahre lang zentrale Messgrößen im Softwarebereich untersucht haben, sind wir zu dem Schluss gekommen, dass auf der Größe von COSMIC basierende Messgrößen am zuverlässigsten sind.

• Größe oder Umfang (CFP),
• Produktivitätskennzahlen (CFP/Zeit),
• Software-Qualitätsmetriken (Defekte/CFP) und
• Ressourcen (Ressource/CFP).

Wechseln Sie zu einer bewährten Softwaredimensionierung

Das Messen und Schätzen von Software ist seit den Anfängen der Softwareindustrie eine Herausforderung. Wir überspringen die Geschichtsstunde und kommen direkt zum aktuellen Stand der Dinge. Die meisten agilen Softwareteams schätzen den Aufwand anhand unwissenschaftlicher, inkonsistenter „aufwandsäquivalenter“ Indikatoren Story-Punkte oder T-Shirt-Größen.  Story-Punkte Und T-Shirt-Größen sind unzuverlässige, nichtlineare und äußerst spielbare Proxy-Schätzungen dafür, wie lange es dauern wird, einen Teil der Arbeit zu erledigen. Die Anzahl der Story-Punkte Die von einem Schätzer oder einem Team zugeteilte Menge wird von den Beweggründen desjenigen beeinflusst, der die Größe angibt. „Story Points“ sind oft der einzige Indikator, der Managern zur Unterstützung bei der Planung und Verwaltung der Arbeit angeboten wird. Daher werden diese Indikatoren überbeansprucht und als eine Art verlässliche Messgröße missbraucht, wenn sie weit davon entfernt sind. In einigen Fällen wird die Anzahl der Geschichten als Indikator für Fortschritt und Umfang verwendet. Unsere Studien mit über 250.000 User Stories haben eine Abweichung in der Story-Größe von 2–120 CFP gezeigt, was beweist, dass die Story-Größe inkonsistent ist und die Story-Anzahl daher unzuverlässig ist.

Die Lösung für dieses Problem gibt es schon seit einigen Jahren: die ISO-Standardmessung der Software-Funktionsgröße, bekannt als COSMIC Function Point (CFP). Die COSMIC-Größenbestimmung ist eine kostenlose Methode, die einen stabilen, internationalen Standard darstellt und von einer gemeinnützigen Organisation verwaltet wird  https://www.cosmic-sizing.org/. Der COSMIC-Standard ist eine Adaption des ursprünglichen Konzepts der funktionalen Größenbestimmung, das 1974 vom IBM-Mitarbeiter Alan Albrecht erfunden wurde.

Der COSMIC Function Point (CFP) ist eine Maßeinheit für die Funktionsgröße, die auf JEDES Softwareprojekt, jede DevOps-Arbeit, Softwarewartung oder Paketimplementierung angewendet werden kann. Es handelt sich um eine konsistente und universelle Größenmessung, die unabhängig von den verwendeten Codierungsmethoden oder Sprachen verwendet werden kann. Es wird nach und nach als führender Standard für die Größenbestimmung anerkannt und in immer mehr Informatikkursen auf der ganzen Welt gelehrt.

Mit der COSMIC-Dimensionierung können Sie die funktionale Größe (die Anzahl der CFPs) innerhalb eines Softwareblocks schätzen oder messen. Es stellt eine Größenansicht aus Benutzersicht dar, nicht aus technischer Sicht. (Beachten Sie, dass ein „Benutzer“ ein anderer Systemakteur sein kann, sodass diese Methodik auch für eingebettete Systeme verwendet werden kann.) Es ist unabhängig von der Technologie oder Architektur, die zur Bereitstellung der Software verwendet wird, und kann daher für das gesamte Software- und Wartungsportfolio verwendet werden.  Als CIO können Sie jedes Ihrer Softwareprojekte und Softwarewartungsaktivitäten messen. Sie profitieren von validen, konsistenten Software-Metriken, auf deren Grundlage Sie fundierte Entscheidungen treffen können.  Sie können sogar vergangene Projekte messen, um Benchmarks für die Produktivität bereitzustellen.

Wir wollen wissen, wann es fertig sein wird

Dies ist eine häufige Herausforderung für CIOs. Und es ist normalerweise sehr schwer zu beantworten. Wenn Sie jedoch CFPs als Standardgrößenmetrik verwenden und die Leistung der Entwicklungsteams in CFP pro Monat oder CFP pro Sprint verfolgen, wird das Enddatum vorhersehbar. Die Messung der Softwaregröße ist der Grundstein für gültige Softwaremetriken und die Beantwortung der entscheidenden Frage, wie lange es dauern wird.

CFP-Größe und ihre Beziehung zum Aufwand

Die CFP-Größe ist ein hervorragender Indikator für den Aufwand und damit auch für die Kosten. Unabhängige Studien haben gezeigt, dass CFP ein konsistenterer Kostenindikator ist als die eigene Schätzung eines Teams in Form von Story Points (siehe Diagramme unten). Die Produktivitätsraten variieren von Team zu Team, aber jedes Team wird bei sonst gleichen Bedingungen wahrscheinlich eine konstante Anzahl an CFP pro Sprint oder Monat liefern. So können Sie schnell die Kosten pro CFP ermitteln.

Geeignet für Verträge

Da es sich bei CFP um ein konsistentes und unabhängiges Maß handelt, kann es auch in Softwareverträgen eingesetzt werden. Anstatt zu einem „Zeit- und Material“-Vertrag mit einem Entwicklungsanbieter gezwungen zu werden, können CIOs auf CFP-basierte Verträge auf Kostenbasis verlangen. Dadurch kann eine größere Kostensicherheit erreicht werden, auch wenn Sie noch nicht alle Anforderungen kennen. Ausgelagerte Softwareverträge, die auf Story Points basieren, kosten Sie wahrscheinlich 101 TP3T mehr und dauern etwa 101 TP3T länger als solche, die auf einem festen Festpreis pro CFP basieren. In solche Verträge sollten auch Ziele für Produktivität (z. B. CFP/Monat) und Qualität (Grenzwerte für Mängel/CFP bei Abnahmetests, nach Kritikalität) aufgenommen werden.

Lernen, Größe zu messen

Die Technik zur Dimensionierung der Softwarefunktionalität in CFP dauert etwa einen Tag, um die Grundlagen zu erlernen, und etwa drei Wochen, um kompetent und zertifiziert zu werden. Mit der nötigen Erfahrung können Sie in weniger als einem Tag die äquivalente Größe eines Mitarbeiterjahres an Entwicklungsarbeit ermitteln. Wenn Sie sich für die Verwendung unseres automatisierten Dimensionierungstools ScopeMaster entscheiden, kann die CFP-Dimensionierung noch schneller und mit geringem Aufwand durchgeführt werden.

Standardisierte Softwaredimensionierung in Ihrem Unternehmen

Wie bei allen Dingen führt die Verwendung standardisierter Gewichte und Maße zu einem gerechteren und transparenteren Markt. Eine standardisierte Softwaredimensionierung wird dasselbe für den Softwaredienstleistungsmarkt bewirken – es ist nur eine Frage der Zeit. Bis dahin gibt es Gewinner und Verlierer. Allein die USA geben jährlich $500 Milliarden für Unternehmenssoftware aus. Wir schätzen, dass über 301 TP3T davon durch die Einführung einer standardisierten Software zur Größenmessung eingespart werden könnten.

Wenn Sie wissen möchten, warum Menschen tun, was sie tun, lohnt es sich immer, der Spur des Geldes zu folgen. Es gibt milliardenschwere Institutionen, die von „Zeit- und Materialverträgen“ profitieren und deren kommerzielle Interessen durch die Einführung standardisierter Größen gefährdet werden. Heutzutage werden die meisten Softwarearbeiten auf Zeit- und Materialbasis in Auftrag gegeben, wobei das kommerzielle Risiko für den Lieferanten gering ist. Sobald Einkaufsorganisationen beginnen, auf der Bezahlung zu bestehen Ausgabe anstatt Bemühung Bei Softwarearbeiten verschiebt sich das Gleichgewicht des kommerziellen Risikos leicht vom Anbieter zum Käufer.

Außerdem profitieren viele Berater, agile Coaches, Framework-Anbieter und sogar Entwickler von der mangelnden Transparenz, die dadurch entsteht, dass Software nicht formal dimensioniert wird.

Durch die Nutzung der CFP-Dimensionierung können Käufer Softwaredienste, darunter Entwickler, Tester, Agile Coaches, Architekten und sogar Berater, zu einem Preis pro CFP erwerben. Zu gegebener Zeit ist eine breite Einführung der CFP-Dimensionierung unvermeidlich, da diejenigen, die die Softwaredienstleistungen kaufen, feststellen werden, dass sie nicht nur transparenter und messbarer sind, sondern dass Sie mit der richtigen Dimensionierung auch mehr Software schneller liefern können. Letztendlich wird dies zur Kommerzialisierung der Softwarearbeit führen.

Die Fähigkeit, Software-Änderungsprojekte schneller und besser als die Konkurrenz durchzuführen, wird zu einem entscheidenden Faktor für das Überleben eines Unternehmens. Mithilfe valider Messungen können Sie feststellen, welche Teams, Lieferanten und Projekte tatsächlich erfolgreich sind und welche nur so tun. Wenn beispielsweise Team A in 12 Monaten 1000 CFP für $1m Dollar liefert, während Team B in 20 Monaten 700 CFP für $2m liefert, können Sie deutlich erkennen, wer einen besseren Job macht. Dies ist ohne CFP-Dimensionierung nicht möglich.

Es wird Widerstand gegen die Einführung einer transparenten Dimensionierung der Softwarearbeit geben. Transparenz und Messbarkeit können für diejenigen, die davon profitieren, eine Bedrohung darstellen. Sie sollten mit Widerstand von Ihren Entwicklungslieferanten und sogar von Ihren eigenen internen Entwicklungsteams rechnen, die derzeit über ein Maß an Freiheit verfügen, das sich daraus ergibt, dass sie nicht gemessen werden.

Sie werden Gegenreaktionen hören wie „Dafür haben wir keine Zeit“. Für eine typische verfeinerte User Story werden bis zu zwei Stunden aggregierter Gesprächsarbeit benötigt, um Story-Punkte zu formen, zu analysieren und abzuschätzen. CFP hingegen lässt sich in wenigen Minuten ermitteln.

Eine weitere Reaktion, auf die Sie stoßen werden, ist „Wir haben bereits viele Kennzahlen“. Als Reaktion darauf müssen Sie Ihre Teams hinsichtlich der Gültigkeit der „Metriken“ herausfordern, die sie derzeit bereitstellen. Hier sind einige häufig verwendete sogenannte Metriken und ihre Schwächen im Vergleich zu CFP-basierten Äquivalenten. Dies sind häufig verwendete Indikatoren. Sie können hilfreich sein, sind aber KEINE gültigen Metriken, die auf a basieren metrisches System.

• Story-Punkte – Diese sind subjektiv, spielbar, unwissenschaftlich und innerhalb und zwischen Teams inkonsistent. Story Points sind im Wesentlichen ein Indikator für eine Schätzung des Stundenaufwands. Verwenden Sie stattdessen CFP.
• T-Shirt-Größen– sind auch subjektive, spielbare, unwissenschaftliche und inkonsistente Indikatoren für Anstrengung.
• Geschichte zählt – Geschichten variieren in ihrer absoluten Größe und liegen typischerweise zwischen 2 und 120 CFP, der Median liegt bei 6 CFP. Daher ist das Zählen von Geschichten ungleicher Größe ein unzuverlässiger Indikator für den Fortschritt.
• Agile Geschwindigkeit – zitiert in Geschichten oder Story Points im Laufe der Zeit. Sehen Story-PunkteDies sollte als Indikator für die Produktivität angesehen werden. Verwenden Sie stattdessen: CFP pro Sprint oder Monat`
• Sprint-Burndown oder wöchentlicher Abbrand– basierend auf Story Points oder Story Counts. Stattdessen verwenden CFP geliefert.

Nb. Zykluszeit, Durchlaufzeit, Fehlerbehebungsrate, Codekomplexität, Fehlererkennungsrate, Und Testabdeckung Sind Beispiele für gültige Kennzahlen, die wir fördern.

Verwendung von CFP als Basismetrik für die Steuerung von Projekten

Sie können CFP nicht nur zur Dimensionierung Ihres Softwareportfolios und Ihrer Projekte verwenden, sondern auch CFP-basierte Metriken als Grundlage für die Steuerung des Projektfortschritts verwenden:

• Produktivität (CFP/Monat),
• Qualität (gefundene Mängel/CFP)*
• Personalplanung wie etwa die Arbeitszuteilung (in CFP) pro Person.
• Umfang (CFP), Scope-Änderung und Scope-Volatilität

*Dies kann weiter unterteilt werden in Mängel nach Kritikalität und Mängel nach Quelle – alles gemäß CFP.

Dies sind alles wichtige Maßnahmen zur effektiven Steuerung von Softwareprojekten. Sie werden schnell erkennen, welche Projekte gut laufen und welche Hilfe benötigen.

CFP und Qualität

Werfen wir einen Blick auf die Beziehung zwischen Softwarequalität und Sizing bzw. Größenwissen (in CFP).

Der Größenbestimmungsprozess trägt zur Qualität bei

Der Dimensionierungsprozess regt uns dazu an, gründlich über die funktionalen Anforderungen nachzudenken, die für die Bereitstellung einer wertvollen Geschäftsfähigkeit erforderlich sind. Diese Denkweise hilft, mögliche Missverständnisse frühzeitig auszuräumen. Diese Missverständnisse würden sich sonst als Mängel bemerkbar machen. Der Prozess der CFP-Größenbestimmung ist also tatsächlich der „ultimative Test bei der Linksverschiebung“.

Die Kenntnis der Größe hilft, die Qualität zu verbessern

Die Kenntnis der Größe kann uns (bei der Verwendung von Benchmarks) helfen, die Anzahl der Fehler vorherzusagen, die wir in einer Software erwarten könnten. Diese Prognose wiederum wird uns bei der Bestimmung helfen Wie viele Tests sind erforderlich?   Durch die Zusammenarbeit mit Mängel pro CFP, unser Qualitätsverständnis steigt.

Auch die automatisierte Analyse trägt zur Verbesserung der Qualität bei

Wenn Sie sich dafür entscheiden, ScopeMaster® zum Analysieren und Testen von Anforderungen zu verwenden, entdecken Sie sofort etwa 50% der latenten Anforderungsprobleme, die Sie dann schnell und frühzeitig beheben können. Dies entspricht etwa 8% aller Mängel bei einem Projekt, bei größeren Projekten sogar noch mehr.

Lieferantenqualitätsmanagement mit CFP

Wenn Sie einen Vertrag verwenden, der ein Höchstmaß an akzeptablen Mängeln pro CFP vorschreibt, können Sie Anbieter dazu ermutigen, Qualität sicherzustellen. Etwas, wozu sie bei T&M-Verträgen möglicherweise weniger motiviert sind.

Einschränkungen der funktionellen Größenmessung mit CFP

CFPs sind ein Maß für die funktionale Größe aus Benutzersicht. Sie messen Datenbewegungen eines Softwaresystems. Sie können nicht messen Rechengröße einer Softwaretransaktion, noch können sie zur Messung von „nicht funktionsfähig„Aspekte der Softwarearbeit, wie Leistung, Wartbarkeit, Benutzerfreundlichkeit (und andere Funktionen). Dies ist nicht nur ein Mangel der GFP, sondern ein Versagen der gesamten Branche. Bisher hat noch niemand gültige, konsistente Maßnahmen für diese beiden Dimensionen entwickelt (Rechengröße, Und NFRs) von Software.

Selbst mit diesen Einschränkungen ist die Korrelation zwischen CFP und dem Aufwand, der zur Erledigung der Arbeit aufgewendet wird, außergewöhnlich. Das bedeutet, dass die Kenntnis der Größe von CFP Ihnen einen sehr starken Indikator dafür gibt, wie viel Aufwand erforderlich ist und damit Kosten und Zeitpläne – die beiden Teile davon Planungswissen, das Projektleiter und Entwicklungsleiter benötigen, um fundierte Entscheidungen zu treffen.

Wann können Sie die Größe schätzen oder messen?

Die CFP-Schätzung kann jederzeit im Softwareentwicklungslebenszyklus durchgeführt werden, sogar gleich zu Beginn, sobald sich die Geschäftsanforderungen abzuzeichnen beginnen. Die ersten Schätzungen können mit zunehmendem Wissen über die Benutzerfunktionalität verfeinert und genauer werden. Wenn sich die Anforderungen weiterentwickeln, steigt die Sicherheit der Schätzungen und schließlich können die Schätzungen zu einer genauen Messung werden. Um eine genaue Messung durchzuführen, müssen Sie lediglich alle Datenbewegungen kennen, die mit jeder funktionalen Anforderung (oder funktionalen User Story) verbunden sind. Mit CFP können Sie die Größe beliebiger Anforderungen festlegen. Sie müssen nicht alle Anforderungen im Voraus kennen und auch nicht das Design kennen, um die CFP-Größe zu bestimmen. Spätestens vor der Aufnahme in einen Sprint sollten Sie die CFP-Größe einer User Story messen. Sie können sogar vergangene Projekte schätzen oder messen, um Referenzdaten für interne Produktivitätsmaßstäbe zu erstellen.

Die Nachteile der Einführung der GFP

Es gibt viele Menschen in der Welt der Software, deren Lebensunterhalt vom Fehlen einer einheitlichen Größenmessung abhängt. Zu den größten Nutznießern gehören Organisationen, die Softwareentwicklungsdienstleistungen auf Zeit- und Materialbasis verkaufen. Dazu gehören einige sehr große und einflussreiche Organisationen. Außerdem profitieren viele Berater, agile Coaches, Framework-Anbieter und sogar Entwickler von der mangelnden Transparenz, die dadurch entsteht, dass Software nicht formal dimensioniert wird. Fehler können versteckt werden, die Produktivität ist schwer einzuschätzen und das mag ihren Interessen entgegenkommen. Andererseits hat die Messung mit CFP für jeden, der für den Kauf oder die Verwaltung von Software verantwortlich ist, wirklich keine Nachteile. Der Aufwand für die Messung ist gering. Sowohl die Kenntnis der Größe als auch die Durchführung der CFP-Dimensionierung können dazu beitragen, Umfangsprobleme zu reduzieren, die Qualität zu verbessern und die Produktivität jedes Softwareprojekts zu steigern.

CFP ist perfekt für Agile und Scaled Agile

Die vollständigen Anforderungen eines Softwareprojekts sind zu Beginn des Projekts selten bekannt. Der agile Workflow ermöglicht es Ihnen, mit dieser frühen Unsicherheit umzugehen. Agile Projekte zeichnen sich durch ein sich entwickelndes Bewusstsein für Anforderungen aus. Zum Glück CFP dürfen präzise gemessen werden, noch bevor alle Anforderungen an ein System bekannt sind. Sie messen einfach genau das, was Sie wissen. Möglicherweise können Sie auch abschätzen, was noch nicht sicher bekannt ist. Mit Erfahrung können Sie sogar frühzeitig abschätzen, wenn nur die allgemeinen Fähigkeiten oder Epics bekannt sind. Im Verlauf eines Projekts werden Epics in funktionale User Stories zerlegt, und diese ersten Schätzungen werden zu präziseren CFP-Maßen mit abnehmender Fehlerquote. Stellen Sie sich Anforderungssicherheit als ein Spektrum vor, das von „wir wissen alles“ bis „wir wissen sehr wenig“ reicht. Obwohl es einfacher ist, die Größe eines Projekts zu bestimmen, wenn man alle Anforderungen kennt, ist es überraschend, wie viel bereits frühzeitig bekannt ist. Im Allgemeinen arbeiten wir am Anfang einfach nicht hart genug, um das Erkennbare aufzudecken.

In Organisationen mit mehreren Softwareteams müssen leitende Manager die Produktivität verschiedener Teams kennen, um leistungsschwache Teams zu verbessern und von hochproduktiven Teams zu lernen. CFP löst das Problem mangelnder einheitlicher Größenverteilung zwischen den Teams. Durch die Einführung von CFP in allen Teams können Produktivitätsraten verglichen werden. Produktivitätsraten können auch zwischen internen und externen Teams verglichen werden. Dadurch erhalten Software-Führungskräfte die Daten, die sie benötigen, um bessere Entscheidungen zu treffen. Man sollte niemals Teams mit Story Points vergleichen.

Es ist an der Zeit, die Softwaregröße in den Griff zu bekommen

Nach 70 Jahren des Rätselratens und unwissenschaftlicher Ansätze ist es für verantwortungsbewusste CIOs und Software-Führungskräfte an der Zeit, auf der Einführung geeigneter technischer Maßstäbe für die Größe zu bestehen. Durch die Einführung und Durchsetzung der CFP-Einführung profitieren Sie von einer besseren Sichtbarkeit und Vorhersehbarkeit Ihrer Softwareaktivitäten. In Ihrem Unternehmen und unter den Lieferanten wird es Kritiker geben, daher müssen Sie bereit sein, diese dazu zu ermutigen, die Vorzüge einer gültigen Größenmessung zu erkennen. Die Messung der Softwaregröße ist eine gute Praxis. Dies führt zu einer besseren Messbarkeit und letztendlich zu einem effektiveren Management. Zu gegebener Zeit können Sie Kennzahlen zu geliefertem und gepflegtem CFP als Teil Ihrer Kennzahlen auf Vorstandsebene teilen. Vorausschauende CIOs, die ihre Leistung durch Messung verbessern möchten, werden von der Einführung von CFP erheblich profitieren.

Automatisierung ist hier, um zu helfen

Unsere bahnbrechende Arbeit bei ScopeMaster ermöglicht mühelos eine automatisierte, konsistente und gültige Dimensionierung funktionaler User Stories oder schriftlicher funktionaler Benutzeranforderungen. ScopeMaster schätzt die Anzahl der CFP in einer User Story, indem es die Sprache der Story analysiert. Die meisten agilen Projekte enthalten weniger als 500 User Stories. Diese können mit ScopeMaster innerhalb einer Stunde automatisch dimensioniert werden. Die User Stories können dann verfeinert (in der Qualität verbessert) werden und die Schätzung wird zu einer Messung. Dies dauert mit ScopeMaster® typischerweise ein Zehntel der Zeit als ohne.

Nächste Schritte.

Wenn Sie mehr darüber erfahren möchten, wie Sie Ihr Software-Portfolio messen, mehr über gültige Software-Metriken erfahren und Ihre Entwicklungsproduktivität messen möchten, um mehr Sicherheit in Ihre Software-Projekte zu bringen, finden Sie hier einige empfohlene nächste Schritte:

1. Ermutigen Sie Ihr Managementteam, die COSMIC-Größen in CFP zu entdecken. Wir empfehlen die Leitfaden zur Softwaremessung
2. Ermutigen Sie Ihr PMO, die CFP-Größe als Kennzahl im Portfoliomanagement einzuführen
3. Bitten Sie Ihre Lieferanten, über die pro Sprint oder Monat gelieferte CFP zu berichten
4. Bitten Sie Ihre Qualitätsmanager, die Berichterstattung über festgestellte Mängel gemäß CFP zu prüfen.
5. Bitten Sie Ihr Vertragsteam, Festpreisverträge pro CFP zu prüfen, und bitten Sie Ihre Lieferanten, Kosten pro CFP anzugeben.
6. Rechnen Sie mit Widerständen innerhalb Ihres Unternehmens und seitens der Lieferanten. Seien Sie darauf vorbereitet, ihm mit Ihrem eigenen Bedarf an Verbesserungen bei der Transparenz von Größe, Produktivität, Preis-Leistungs-Verhältnis und Qualitätsmessung entgegenzuwirken.

Kontaktieren Sie uns bei ScopeMaster, um unser automatisiertes Dimensionierungstool und Anleitungen zur Einführung von CFP in Ihrem Unternehmen kennenzulernen.

Über Colin Hammond

Colin Hammond ist Experte für Software-Dimensionierung, Projektsicherung und automatisierte Software-Anforderungsanalyse. Er hält regelmäßig Vorträge auf Konferenzen zu den Themen Projektmanagement, Softwaretests, Geschäftsanalyse und Kostenanalyse. Colin ist der Gründer und CEO von ScopeMaster, das das preisgekrönte automatisierte Tool zur funktionalen Größenbestimmung anbietet ScopeMaster und professionelle Dienstleistungen zur Einführung und Verwendung funktionaler Größen.

Dank an

Ich bin sehr dankbar Kirk Bryde (Agile Coach) und Lonnie Franks (Software Project Assurance Expert) für ihren wertvollen redaktionellen Beitrag zu diesem Artikel.

Verweise

McConnell, Steve. „Softwareschätzung, Entnebelung der schwarzen Kunst“

Boehm, Barry et al. 2000. „Softwarekostenschätzung mit COCOMO II“

Garmus, David und Herron, David. „Funktionspunktanalyse: Messpraktiken für erfolgreiche Softwareprojekte.“

Jones, Kapern. „Angewandte Softwaremessung: Produktivität und Qualität sichern“

Symons, Charles „Ein Leitfaden zur Messung der Softwaregröße”