Wie melde ich die Leistung eines Softwareentwicklungsprojekts?

Ich mag Agile besonders aus diesem Grund – die Nachverfolgung und Berichterstattung über die Leistung ist intuitiv, detailliert und basiert auch auf tatsächlichen Teamergebnissen.

Etwas Hintergrund:

Bei Agilität zerlegen Sie ein Projekt in „Storys“, kleine Arbeitsstücke, die, wenn sie unabhängig implementiert werden, für einen Kunden sinnvoll wären. Für die PM.SE-Site könnten Sie beispielsweise sagen: „Das Posten einer Frage (Titel und Inhalt)“ ist eine Geschichte; in der Lage zu sein, (vom ursprünglichen Autor) zu bearbeiten, ist eine Geschichte; Das Hinzufügen von Tags ist eine Geschichte; usw.

Geschichten werden in einer vagen Größeneinheit (Story Points) geschätzt, die relativ sind . Eine Geschichte mit zwei Punkten ist ungefähr die Hälfte der Arbeit einer Geschichte mit vier Punkten. Wenn Sie ein ikonisches, standardisiertes Beispiel für eine Ein- oder Zwei-Punkte-Geschichte haben, können Sie alles relativ leicht einschätzen.

In einem typischen Agile/Scrum verfolgen Sie Ihre „Geschwindigkeit“ (Anzahl der Story Points pro Tag). Ihr „Produkt-Backlog“ ist die Liste aller Geschichten über die Lebensdauer des Produkts; Sie können jederzeit sagen: „Wir haben für dieses Projekt X Punkte an Geschichten zu erledigen, von denen wir Y Punkte abgeschlossen haben.“ Das ist deine Leistung.

Über die standardmäßigen agilen Praktiken hinaus können Sie lustige Dinge tun, wie zum Beispiel:

• Budgetierung (z. B. machen wir nur bis zu 20-30 Punkte pro zweiwöchiger Iteration)
• Statistik (in den letzten zehn Sprints ist unsere Geschwindigkeit konstant von 30 auf 40 Punkte pro Sprint gestiegen)
• Earned Value: Dieser Teil gefällt mir persönlich sehr gut. Verfolgen Sie den Wert „erwartete heute erledigte Punkte“ im Vergleich zu „heute tatsächlich erledigte Punkte“. Es sagt dir, ob du vorne oder hinten liegst.
• Produktplanung: Sie sind zwei Wochen in einem achtwöchigen Projekt. Sie haben bisher 20 Punkte erreicht (10 Punkte pro Woche); Das gesamte Projekt ist in 160 Story Points aufgeteilt . Du wirst es auf keinen Fall schaffen.

Auf der anderen Seite halten einige Leute die Punkte für unzureichend und verlangen von den Entwicklern, dass sie Geschichten weiter in Aufgaben unterteilen und Aufgaben von Aufgabe zu Aufgabe nachverfolgen und diese in Stunden schätzen. Was auch immer Ihnen die Sichtbarkeit gibt, die Sie brauchen.

Die beste Metrik, um den Fortschritt eines Softwareentwicklungsprojekts anzuzeigen, ist funktionierende Software . Angenommen, Sie melden den Status wöchentlich oder monatlich an Ihre Kunden oder Projektsponsoren / Stakeholder. Sie können melden, dass 22 % der angegebenen Funktionen abgeschlossen wurden (oder wahrscheinlicher sind 13 % der Funktionen abgeschlossen, weitere 4 % wurden begonnen und weitere 5 % sind zu 50 bis 90 % abgeschlossen). Aber was bedeuten diese Zahlen wirklich? In Wirklichkeit bedeuten diese Zahlen für einen Kunden fast nichts. Selbst für ein Feature, das Sie für „fertig“ halten, hat der Kunde möglicherweise eine andere Erwartung, und dann ist Ihr „fertig“ etwas anderes als „fertig“.

Wenn Sie andererseits an einem festgelegten Tag und zu einer festgelegten Uhrzeit eine Demo der funktionierenden Software haben, kann der Kunde/Stakeholder genau sehen, was getan oder nicht getan wurde, und inwieweit das, was getan wurde, seinen Erwartungen entspricht. Dies ist das Herzstück der agilen Softwareentwicklungsphilosophie. Aber auch wenn Sie nicht „agil arbeiten“, können Sie auf diese Weise „Fortschritte melden“.

Obwohl ich Asche überhaupt nicht widerspreche, habe ich eine etwas andere Sicht auf die wertvollsten Metriken und neige dazu, Folgendes zu berichten:

• Vorlaufzeit : Wird auch prädiktiv verwendet als „Ihre Wartezeit ab diesem Punkt beträgt ungefähr N Tage“. Dies ist die durchschnittliche Zeit in Arbeitstagen von der Anfrage des Kunden bis zur Lieferung für eine bestimmte Serviceklasse.
• Zykluszeit : Eigentlich gleich Vorlaufzeit, aber mit einem anderen Ausgangspunkt für die Messung. Dies ist die durchschnittliche Zeit in Arbeitstagen von der Annahme durch das Team bis zur Lieferung für eine bestimmte Serviceklasse. Der Unterschied zwischen Lead- und Zykluszeit ist die Zeit, die es in einem Rückstand verbringt, der ignoriert wird.
• Durchsatz : Wie viele Arbeitselemente werden durchschnittlich in einem bestimmten Zeitraum für eine bestimmte Serviceklasse geliefert. Dies ist im Wesentlichen Geschwindigkeit.

Viele Menschen mögen die Zyklus- und Durchlaufzeitmessungen genauso sehr wie den Durchsatz, weil sie Ihnen explizit sagen, wie reaktiv Ihr Team/Ihre Organisation ist. Ich neige dazu, die Geschwindigkeit von Geschichten zu vermeiden, da sie die Schätzung des Teams enthält und daher leicht von den Teams gespielt werden kann, insbesondere wenn von ihnen erwartet wird, dass sie sich fortschreitend verbessern.

Beim zweiten Teil Ihrer Frage kommt es ganz auf den Kontext des Teams an. Ich kann mir nicht vorstellen, ein verteiltes oder großes Projekt ohne irgendeine Art von elektronischer Werkzeugunterstützung durchzuführen, und hatte persönlich sowohl mit Rally als auch mit Microsofts Team Foundation-Workitem-Tracking gute Erfolge. Bei kleinen Projekten ist es weniger als 5 Minuten Aufwand, sie jeden Tag von einer Kartenwand zu erfassen, was eine einfache grafische Darstellung mit Excel oder auf großem sichtbarem Papier ermöglicht.

Ich schlage vor, dass Sie die folgenden Metriken verfolgen: - Geschwindigkeit: Anzahl der Story Points, die Ihr Team während einer Iteration liefert - Anzahl entgangener Fehler: Fehler, die Ihren QA-Bemühungen entgangen sind und nach der Freigabe durch den Kunden gefunden wurden - Zeit zur Behebung des Fehlers: durchschnittliche Zeit einen Defekt zu beheben

Wir erfassen diese Metriken mithilfe von http://www.programeter.com , das von uns selbst erstellt wurde, um die Leistung und Qualität unserer Produktentwicklungsbemühungen zu verfolgen.

Ich würde der These etwas widersprechen, dass Agilität außergewöhnlich ist, wenn es darum geht, sich auf die Verfolgung und Berichterstattung auf tatsächliche Teamergebnisse zu verlassen.

Ich könnte mir vorstellen, dass nicht agile Teams über reale Arbeitsfortschritte berichten, und ich habe gesehen, wie agile Teams Fiktion berichten (95 % der Arbeit abgeschlossen und 1 von 5 Storys während der Überprüfung abgeschlossen), es ist alles eine Frage von Regeln und persönlicher Verantwortung.

Was in diesem Bereich wirklich helfen kann, ist das agile Konzept Definition of Done – kurz gesagt eine Reihe von Bedingungen, die erfüllt sein müssen, um ein Stück Arbeit als wirklich, wirklich abgeschlossen zu behandeln, das sofort gemeldet und abgeschlossen werden kann. Ich denke, dies ist eines der wichtigsten Dinge, die definiert werden müssen, bevor eine Leistungsmessung beginnt. Nur dann besteht die Chance, dass die Messung objektiv und aussagekräftig ist.