Ich habe hauptsächlich an Projekten gearbeitet, die dem Wasserfallmodell folgten, und wir hatten während des SDLC viele Checklisten und Audits, die sicherstellten, dass wir die Qualitätsziele erreichen konnten.
Jetzt arbeite ich in einer Organisation, in der die meisten Projekte entweder Scrum oder Kanban verwenden. Oftmals werden Anforderungen/Geschichten direkt von den Benutzern/Kunden gegeben. Es gibt sehr wenig Priorisierung, die wir mit dem Kunden machen. Die Projektgröße variiert von 2 Entwicklern bis zu 20 Entwicklern. Die von den Entwicklern für ihre Geschichten gegebenen Schätzungen lassen manchmal den Aufwand für Unit-Tests, Codeüberprüfung/Überarbeitung außer Acht. Ich habe sie erzogen und jetzt haben sie angefangen, es richtig einzuschätzen.
Welche Prozesse kann ich einführen, damit die Qualitätsparameter wie Fehlerinjektionsrate, Code-Review-Effektivität, Softwaredesign-Effektivität die Kontrolle behalten? Ich denke, viele Entwickler verwechseln das agile/iterative Modell mit der Abkürzungsentwicklung. Sie zu erziehen ist das erste, was ich tue.
Ich möchte die Experten hier fragen, ob es Faustregeln gibt, die ich verwenden kann, oder ob es bewährte Verfahren gibt, die ich implementieren kann, damit alle Projekte einem ähnlichen Prozess folgen, Projekte einem vorhersehbareren Weg folgen und die Anzahl der gelieferten Geschichten höher ist und Qualitätsparameter erreicht werden.
Ich denke, dass Sie bei den agilen Methoden wahrscheinlich andere Qualitätsmetriken zum Nachverfolgen benötigen werden.
In einem agilen Projekt, insbesondere in Bezug auf die Design-, Code- und Testaktivitäten, ist es sehr iterativ und es gibt möglicherweise keine klare Trennung dieser Aktivitäten, sodass phasenbasierte Metriken (z. B. Messung der Effektivität von Design- und Code-Reviews) verwendet werden hart. Da das Testen normalerweise gleichzeitig und kontinuierlich erfolgt, glaube ich nicht, dass Sie typische Fehlerankunftskurven erhalten werden.
Ich denke, Sie sollten das Agile Manifest im Hinterkopf behalten, wenn Sie neue Metriken entwickeln, um die Qualität zu verfolgen. Insbesondere bevorzugt das Agile Manifest „Individuen und Interaktionen“ und „Kundenzusammenarbeit“. Sie sollten auch die Prinzipien hinter dem Agilen Manifest im Auge behalten , insbesondere das erste: „Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen“.
Ihre erste Kennzahl sollte die Kundenzufriedenheit sein. Eine gute Anfangsmessung wären Mängel, die von Kunden und Endbenutzern gemeldet werden. Wenn Sie den gemeldeten Schweregrad oder die Priorität verfolgen, könnte dies Teil dieser Messung sein. Sie können auch die Anzahl der Iterationen zur Behebung von Fehlern verfolgen (wahrscheinlich basierend auf Priorität und/oder Schweregrad). Diese Art von Metrik bezieht sich auf die Fehlerbearbeitungszeit (Zeit zwischen Meldung und Verifizierung) oder die Fehlerreaktionszeit (bestätigte Fehler, die vom Entwicklungsteam behoben werden). Sie könnten sogar Ziele rund um diese Datenpunkte aufbauen, um Ihre Qualitätsaktivitäten bis zu einem Punkt von 0 „erheblichen“ (basierend auf Ihrer Definition von „erheblichen“) Problemen zu verbessern, die von Kunden in Veröffentlichungen gemeldet wurden.
Eine gute agile Metrik für die Kundenzufriedenheit wäre möglicherweise die Anzahl oder der Prozentsatz der User Stories, die am Ende des Sprints akzeptiert wurden. Idealerweise solltest du jede geplante Geschichte fertigstellen und jede fertige Geschichte würde angenommen. Das ist jedoch nicht immer der Fall.
Da Sie auch Kanban verwenden, kann das Verfolgen einer Schweregradverteilung (etwas, das von kosmetischen Fehlern bis hin zu Blockierungsproblemen reicht) und einer Prioritätsverteilung (etwas, das von niedrig bis hoch reicht) zusammen mit dem Verantwortungsbereich, in dem sich das Arbeitselement befindet, interessante Daten liefern. Wenn ein Entwickler beispielsweise sagt, dass eine Geschichte oder Aufgabe mit der Entwicklung abgeschlossen ist, sollten keine Probleme mit Blockierung oder hoher Priorität darin gefunden werden. Nachzuverfolgen, dass eine große Anzahl von Elementen es mit Fehlern über einem bestimmten Schweregrad oder einer bestimmten Priorität in den Abnahmetest schaffen, könnte Maßnahmen auslösen.
Etwas näher am Entwicklungsteam kann die automatisierte Testabdeckung eine gute Metrik sein. Die agilen Methoden tendieren dazu, kontinuierliche Integration zu bevorzugen, und automatisierte Einheiten-, Integrations-, System- und Regressionstests werden in dieser Art von Umgebung gut unterstützt. Die Nachverfolgung der Abdeckung, insbesondere in neuem Code, kann nützlich sein. Testabdeckung ist natürlich keine Qualitätsmetrik (siehe auch: Wie man Codeabdeckung missbraucht), da es nicht aussagt, wie gut Ihre Tests sind, aber Sie können es mit anderen Fehlerberichten verwenden, die während der Test- oder Post-Release-Aktivitäten gefunden wurden, um zu wissen, wie gut Sie sind. Sie können es jedoch als schnelle Überprüfung verwenden, um sicherzustellen, dass einige Tests für neuen Code geschrieben werden und dass, wenn Probleme gefunden werden, Tests für die Aufnahme in Testsuiten geschrieben werden, um das Problem zu beweisen und dann, dass das Problem behoben wurde .
Aus Sicht der Anforderungen sollten die in den Sprint eingebrachten Geschichten relativ gut verstanden sein und woran Sie arbeiten werden. Obwohl Agile die Tatsache anerkennt, dass Anforderungen sich ändern können und dies auch tun, und Sie Änderungen annehmen sollten, möchten Sie normalerweise keine größeren Änderungen an den Stories, die Teil der aktuellen Iteration sind. Sie sollten wahrscheinlich die Volatilität von Stories messen wollen, die Sie in den Sprint eingebracht haben – sobald sie den Grooming-Prozess durchlaufen haben und vom Team akzeptiert wurden, verfolgen Sie die Anzahl der Änderungen an einigen Aspekten der Story (einschließlich hinzugefügter Stories oder ENTFERNT). Das Hinzufügen oder Entfernen einer Story ist in einem Burn-Down- oder Burn-Up-Diagramm sichtbar, aber Änderungen an einer Story werden dort möglicherweise nicht wiedergegeben.
Abgesehen von den Anforderungen bin ich besorgt, wenn Sie sagen, dass Ihre Benutzer und Kunden Anforderungen und Geschichten direkt bereitstellen und dass beim Kunden nur sehr wenig Prioritäten gesetzt werden. Wenn Sie keinen Benutzer oder Kunden vor Ort haben, der als Product Owner fungieren kann, sollte es eine Person in Ihrem Team geben, die in dieser Funktion handeln kann und ein solides Verständnis der Bedürfnisse und Wünsche der Benutzer und des Kunden hat. Der Product Owner sollte für die Priorisierung von Storys und die Bereitstellung klarer Akzeptanzkriterien verantwortlich sein. Priorisierte Geschichten und klare Akzeptanzkriterien werden in Kennzahlen wie Anforderungsvolatilität und entdeckten Mängeln nach einer Veröffentlichung sichtbar.
Obwohl es den Overhead erhöht, sollten Sie, wenn Sie an einem Vertrag arbeiten, der bereits Zeiterfassung erfordert, die Zeiterfassung für bestimmte Aufgaben in Betracht ziehen. Es hängt davon ab, wie Sie Ihre Arbeit in Aufgaben aufteilen, aber wenn Sie die geleisteten Arbeitsstunden nachverfolgen müssen, können Sie die Qualitätskosten nachverfolgen. Achten Sie darauf, wie viel Zeit Sie mit dem Schreiben und Ausführen von Tests (manuell und automatisiert), mit Peer-Reviews von Designs oder Code und mit der Überarbeitung von Designs oder Code aufgrund fehlgeschlagener Tests verbringen. Achten Sie natürlich darauf, dass dies nicht viel Mehraufwand verursacht - es ist möglicherweise nicht für Projekte geeignet, die keine Zeiterfassung erfordern.
Untersuchen Sie aus Sicht der Prozessqualität, wie gut Ihre Schätzungen sind. Mit Story Points pro Story ist es etwas schwieriger, aber Sie können Ihre Gesamtgeschwindigkeit über Sprints hinweg verfolgen. Nach ein paar Iterationen sollten Sie in der Lage sein, konsistent zu sagen, wie viele Story Points Sie in einem einzigen Sprint abschließen und dann diese Zahl erreichen können (vielleicht mit einigen geringfügigen Abweichungen). Ihre Burndown-Diagramme und Geschwindigkeitsverfolgung können im Laufe der Zeit betrachtet werden, um sicherzustellen, dass Sie Ihre Arbeitsaufgaben richtig eingrenzen und ausführen.
Ich habe noch ein letztes Wort der Vorsicht. Ich würde empfehlen, die Lean-Software-Entwicklungsprinzipien zu übernehmen . Stellen Sie sicher, dass alle Messungen und Metriken, die Sie sammeln, tatsächlich einen Mehrwert für den Kunden, das Team oder die Organisation darstellen. Wenn Ihre Metriken oder Indikatoren ein Problem anzeigen, ermächtigen Sie das Team, Entscheidungen über das weitere Vorgehen zu treffen und Korrekturmaßnahmen zu ergreifen.
jmort253