Es scheint, dass die Welt gute Arbeit bei der Verwaltung funktionaler Anforderungen für ein System leistet – Sie können sie mit Vorteilen verknüpfen, sie priorisieren und ihren Implementierungszeitplan verwalten (nehmen wir eine ideale Welt an :)
Betrachten Sie nun "Ilities" wie Modifizierbarkeit, Benutzerfreundlichkeit, Anpassungsfähigkeit, Wiederverwendbarkeit, Sicherheit, Zuverlässigkeit, Verfügbarkeit usw. usw.
Technisch gesehen kann man sie mit potenziellen Endnutzen verknüpfen und auch ihre Bedeutung für ein Unternehmen priorisieren – aber WIE sollte man ihre Implementierung handhaben? Angenommen, Sie priorisieren die Funktionen und die Hilfsmittel sozusagen im selben „Stapel“, ist es möglich, dass die Verfügbarkeit niedriger ist als das Feature-Set „Tickets buchen“ (z. B.).
Agilisten mögen argumentieren, dass das Design sich selbst offenbaren sollte und dass sie Verfügbarkeit oder Sicherheit usw. später „umgestalten“ können. Ehrlich gesagt, kann alles durch Refactoring zum System hinzugefügt werden, aber die Kosten können unerschwinglich sein, und deshalb muss man meiner Meinung nach einige Zeit (möglicherweise mehr) im Voraus aufwenden, um solche Unannehmlichkeiten zu berücksichtigen.
Meine Frage lautet also: Sollten Sie eine separate Priorisierung für ilities vornehmen? Sollten sie sich in einem eigenen „Stapel“ (oder Rückstand) befinden? Was sollte eine gute Reihenfolge bei der Implementierung des Systems sein? Wenn Sie tatsächlich zwei unabhängige Priorisierungsaktivitäten durchführen, wie können Sie diese dann vergleichen und die Stakeholder davon überzeugen, dass Sie tatsächlich zuerst wertvolle Dinge tun? Wie würden Sie im Grunde rechtfertigen, ility-Management/Planung/Design gegenüber Feature-Set-Design zu betreiben?
Da mit Ilities Kompromisse verbunden sind, müssen Sie in der Lage sein, sie gut auszubalancieren, und später darüber nachzudenken oder YAGNI zu folgen (Sie werden es nicht brauchen), wird nicht ausreichen. Was schlagen Sie vor?
Nicht-funktionale Anforderungen, „Ilities“ oder (meiner Meinung nach besserer Name) Qualitätsattribute haben erheblichen Einfluss auf die Architektur. Da Qualitätsattribute nicht wirklich etwas sind, was Ihr System tut , sondern eher etwas, das Ihr System ist , sollten Sie sie anders behandeln als funktionale Anforderungen.
Aus diesem Grund ist es nicht angebracht, Qualitätsattribute genauso zu behandeln wie andere Elemente in Ihrem Backlog. Sie in das Backlog zu stellen bedeutet, dass sie "erledigt" werden können, was niemals passieren kann, da viele Qualitätsattribute über viele Iterationen hinweg Einfluss auf viele Funktionen haben - so etwas wie Testbarkeit oder Skalierbarkeit oder Wartbarkeit ist nichts, was ein Kunde für einen Sprint auswählen kann, Behandeln Sie es also nicht wie ein Feature im Backlog.
Meine Frage lautet also: Sollten Sie eine separate Priorisierung für ilities vornehmen?
Ja. Qualitätsattribute werden in der Regel als Szenario erfasst. Dies können „formale“ 6-teilige Szenarien oder einfache Anwendungsgeschichten sein. Das Wichtigste ist, die Reize, die Reaktion und die Umgebung aufzuzeichnen. Je konkreter und messbarer, desto besser. Am besten sammelt man die großen, die wichtigsten am Anfang mit einer Technik wie dem Quality Attributes Workshop . Das Ergebnis der QAW ist eine priorisierte Liste von Qualitätsattributszenarien.
Sollten sie sich in einem eigenen „Stapel“ (oder Rückstand) befinden?
Ja. Qualitätsattribute sollten separat verfolgt werden . Zwei Gründe.
Was sollte eine gute Reihenfolge bei der Implementierung des Systems sein?
Der Haken dabei ist, dass Sie (bei einigen Kunden) diskrete technische Schuldengeschichten in den Rückstand aufnehmen können. Das heißt - diskretes Tasking, das bestimmte Qualitätsattribute direkt beeinflusst. Ein Beispiel: "Das XYZ-Modul hat viele Fehler, weil der Code schlecht geschrieben ist, wir müssen umgestalten, um es wartbarer zu machen."
Es gibt viele Strategien für den Umgang mit Schulden – Low Hanging Fruits, das Zerquetschen von „Bug Farms“, das „Reißen“ von Schulden mit Funktionen, die sicherstellen, dass Sie den Überblick behalten …
Wenn Sie tatsächlich zwei unabhängige Priorisierungsaktivitäten durchführen, wie können Sie diese dann vergleichen und die Stakeholder davon überzeugen, dass Sie tatsächlich zuerst wertvolle Dinge tun? Wie würden Sie im Grunde rechtfertigen, ility-Management/Planung/Design gegenüber Feature-Set-Design zu betreiben?
Es kann Kompromisse innerhalb eines Designs geben – zum Beispiel ist Sicherheit wichtiger als Leistung – weshalb es so wichtig ist, die großen im Voraus zu kennen. Denken Sie daran, dass Qualitätsattribute das Design beeinflussen ; sie sind nicht das gelieferte Artefakt. Sie machen keine Sicherheit , dies ist eine Eigenschaft der Software, die Sie erstellen. Nur wenn Sie dies im Voraus vereinbaren, können Sie sicherstellen, dass die von Ihnen gelieferten Funktionen die richtige Qualität erreichen. Es könnte eine Million Möglichkeiten geben, ein Problem zu lösen – aber nur wenige mit den gewünschten Eigenschaften. Wenn Sie diese verpassen, werden Ihre Funktionen jedes Mal abgelehnt. "Ja, es berechnet XYZ korrekt... aber zwei Minuten sind einfach zu lang..."
Sollten Sie eine separate Priorisierung für ilities vornehmen? Sollten sie sich in einem eigenen „Stapel“ (oder Rückstand) befinden?
Die anderen Antworten hier sind auf dem richtigen Weg. Funktionen für Entwickler sollten sich in derselben Warteschlange wie Funktionen für andere Geschäftsbeteiligte befinden.
Auf diese Weise können Sie Abhängigkeiten zwischen geschäftsbezogenen Funktionen und ilityFunktionen nachverfolgen. Hilft auch bei deiner nächsten Frage:
Was sollte eine gute Reihenfolge bei der Implementierung des Systems sein? Wenn Sie tatsächlich zwei unabhängige Priorisierungsaktivitäten durchführen, wie können Sie diese dann vergleichen?[?]
Sobald Sie alle Funktionen gleich behandeln, können Sie sie auch gleich priorisieren:
...[wie können Sie] die Stakeholder davon überzeugen, dass Sie tatsächlich zuerst wertvolle Dinge tun? Wie würden Sie im Grunde rechtfertigen, ility-Management/Planung/Design gegenüber Feature-Set-Design zu betreiben?
In Teams, in denen ich gearbeitet habe, haben wir den Begriff „Technische Schuld“ verwendet , um den Geschäftsbeteiligten zu helfen, die Bedeutung der Verwaltung der Codebasis zu verstehen.
ilityFunktionen in derselben Warteschlange angezeigt werden. Ich schlage nicht vor, dass es als Eimer zum Einwerfen von Gegenständen oder als unbegrenzte Ressourcensenke verwendet wird. Sie implementieren keine Funktionen oder nehmen Änderungen vor, es sei denn, Sie müssen und/oder haben das Budget und haben eine fundierte Vorhersage darüber getroffen, welchen Nutzen dies bringen wird. Dies ist dasselbe wie Funktionen, die direkt aus den Kerngeschäftsanforderungen stammen. Meinten Sie etwas anderes?ilitiesdies immer eine höhere Priorität hat. Elemente sollten auf der Grundlage von Kosten und Nutzen priorisiert werden, was auf einer möglichst realistischen Vorhersage basieren sollte. Die Vorhersage sollte sich auf Grundkosten, Kostenabhängigkeiten und Kosten "Zinsen" beziehen. Wenn Sie dies zB jetzt implementieren, kostet es weniger, oder wenn Sie A vor B implementieren, wird B billiger. In vielen Fällen kann diese Vorhersage getroffen werden, indem der Umfang jeder Geschäftsfunktion und der Code, den sie wahrscheinlich berühren wird, dann ein Code-Grep und möglicherweise eine Spike-Implementierung verstanden wird.Ich würde sie im selben Backlog behandeln wie alle Ihre Geschichten. Wir gehen normalerweise auf drei Arten mit nicht funktionalen Anforderungen um (in der Reihenfolge ihrer Präferenz):
Als Teil unserer Definition of Done , wo es auf die gesamte Anwendung anwendbar ist.
In unseren Akzeptanzkriterien für diejenigen, die nur für eine Geschichte oder eine Teilmenge von Geschichten gelten.
Als eine Geschichte , in der sie nicht direkt als Teil der ersten beiden betrachtet werden können, aber wir wollen sie nicht vergessen.
ilitysparallel zu Business Analysts sammeln, die Anforderungen an Kernfunktionen sammeln. Die Priorisierung davor (wofür überhaupt Anforderungen erhoben werden sollen) muss auf Intuition und Vereinbarung zwischen den Beteiligten basieren (Entwickler sind die Fähigkeiten der Beteiligten).Haben Sie immer einen einzigen Rückstand und lassen Sie die geschäftlichen Anforderungen die Prioritäten bestimmen.
Nicht-funktionale Anforderungen sind normalerweise schwieriger auszubügeln als funktionale Anforderungen, und ob Sie dann über oder unter funktionalen Anforderungen priorisieren sollten, ist eine Frage, die Sie den Stakeholdern oder dem Product Owner stellen müssten
Die Priorisierungsreihenfolge hängt vollständig vom Kontext/Geschäftsbedarf Ihres Produkts ab .
Ich arbeite beim Testen von eingebetteten Systemen für Organisationen der öffentlichen Sicherheit und für einen Streifenpolizisten (unser typischer Benutzer). Die Zuverlässigkeit des Produkts ist von größter Bedeutung und ist in Bezug auf die Priorität gegenüber neuen Funktionen, die das Produkt zu bieten hat, meilenweit voraus.
Promotion
Merlyn Morgan-Graham