Wie kann Agile auf Anwendungen mit komplexer Verarbeitung angewendet werden?

12

Der größte Teil der Agilitätsliteratur scheint auf CRUD-Geschäftsanwendungen ausgerichtet zu sein, bei denen der Benutzer ziemlich genau weiß, was hinter den Kulissen vor sich geht. (Das ist in Ordnung, da der größte Teil des Codes, der geschrieben wird, wahrscheinlich zu dieser Klasse gehört.)

Bei dieser Art von Anwendung ist die Beziehung zwischen User Storys (Anforderungen) und Entwicklungsaufgaben meist unkompliziert: Teilen Sie die User Story einfach in einige Aufgaben auf.

Es gibt jedoch eine andere Art von Anwendung, bei der der größte Teil des Codes mit komplexen Vorgängen zu tun hat, die für den Benutzer nicht direkt sichtbar sind. Beispiele wären:

  • Compiler
  • Bildanalysesysteme für selbstfahrende Autos
  • Systeme zur Strömungssimulation

Hier kann es sehr schwierig werden, Aufgaben und User Stories in Beziehung zu setzen. Gibt es Techniken, um dieses Problem zu lösen, oder müssen wir nur akzeptieren und das Beste daraus machen?

agile project-management user-story task Frank Puffer
quelle
6
Nicht der Abwähler, aber ich gehe davon aus, dass die Frage auf einer falschen Prämisse basiert. IMO komplexe Systeme sind noch besser geeignet für eine agile Stil Entwicklung auf Grund der Tatsache , dass sie sind komplexer. Je komplexer das System ist, desto wahrscheinlicher sind neue Anforderungen. Agile SwDev wurde entwickelt, um neuen Anforderungen besser gerecht zu werden.
RubberDuck
4
@RubberDuck: "Ich gehe davon aus, dass die Frage auf einer falschen Prämisse basiert.": IMO, dies würde eine Antwort begründen, in der die falsche Prämisse erklärt wird, keine Ablehnung.
Giorgio
Ob der Benutzer die Logik versteht oder nicht, spielt für den agilen Prozess keine Rolle. Es ist Aufgabe des Teams, eine User Story auf eine Implementierung abzubilden UND abzuschätzen, wie lange dies dauern wird. Wenn es kompliziert und / oder arbeitsintensiv ist, kann das Team die Geschichte in kleinere aufteilen. Die Art der Logik spielt keine Rolle.
Martin Maat
2
"Die meiste Literatur zu Agile scheint auf CRUD-Geschäftsanwendungen ausgerichtet zu sein" - und die meiste Literatur zu Java scheint auf die Ausgabe der Zeichenfolge "Hello World" auf der Konsole ausgerichtet zu sein (oder alternativ die n-te Fibonacci-Zahl zu berechnen). Das heißt nicht, dass das das einzige ist, wofür Java gut ist. Der Grund ist in beiden Fällen der gleiche: Es ist schwierig, realistische Beispiele in einem Blog-Beitrag oder in einem Tutorial zu erklären. [Anmerkung: Dies ist ein hyperbolischer Kommentar, der versucht, die Grundlage für die falsche Prämisse zu veranschaulichen.]
Jörg W Mittag,
1
Agile erfordert keine Aufgaben und User Stories. Sie können jede Form der Spezifikation verwenden, die Sie wünschen. Der springende Punkt ist Flexibilität.
Frank Hileman

Antworten:

9

Es stellte sich heraus, dass dies länger war als geplant (es hatte als Kommentar begonnen), aber ich hoffe, dass die hinzugefügten Längen / Details hilfreich sind und Sie sie als gerechtfertigt ansehen.

Agile ist nicht spezifisch für CRUD-Apps

Der größte Teil der Agilitätsliteratur scheint auf CRUD-Geschäftsanwendungen ausgerichtet zu sein, bei denen der Benutzer ziemlich genau weiß, was hinter den Kulissen vor sich geht. (Das ist in Ordnung, da der größte Teil des Codes, der geschrieben wird, wahrscheinlich zu dieser Klasse gehört.)

Ich denke, das liegt daran, dass es einfacher ist, einfach zu verfolgende Beispiele dieser Art zu erstellen, und nicht wirklich daran, dass die Methodik auf diese Art von Systemen abzielt. Wenn Sie ein nicht so einfach zu verfolgendes Beispiel erstellen, besteht die Gefahr, dass der Leser feststeckt und versucht, das Beispiel zu verstehen, in dem der Leser über agile Konzepte unterrichtet werden sollte.

User Stories! = Anforderungen

Bei dieser Art von Anwendung ist die Beziehung zwischen User Storys (Anforderungen) und Entwicklungsaufgaben meist unkompliziert: Teilen Sie die User Story einfach in einige Aufgaben auf.

Eine User Story ist nicht dasselbe wie eine Anforderung. Es kann zwar zu Überschneidungen kommen, abhängig davon, wie hoch die Anforderung ist, aber im Allgemeinen nicht die gleiche. Ich habe den Eindruck, dass Sie in die gleiche Falle geraten, in die sich viele meiner ehemaligen Manager verliebt haben: User Stories einfach als Synonyme für "Anforderungen" zu verstehen, ähnlich wie bei SVN-Benutzern, die versuchen, auf Git umzusteigen, dies aber beibehalten Denken in Bezug auf SVN. (Sie stoßen dann aufgrund der schlechten Startannahmen auf Probleme.)

Meiner Meinung nach besteht ein wesentlicher Unterschied zwischen Anforderungen und User Storys darin, dass Anforderungen im Detail festlegen, wie sich bestimmte Systemkomponenten verhalten sollen. Es handelt sich um Spezifikationen , die Eingaben, Ausgaben, Annahmen / Voraussetzungen, mögliche Ausnahmen usw. umfassen. Sie konzentrieren sich auf das, was das System tut.

OTOH, User Stories konzentrieren sich auf das erwartete Ergebnis für den Endbenutzer, ohne zu versuchen, eine detaillierte Verhaltensspezifikation für Systemkomponenten zu erstellen. Sie konzentrieren sich auf die erwartete Benutzererfahrung .

Früher habe ich, und dies war eine Praxis, die mein Team übernommen hat, User Storys in Aufgaben unterteilt. Ihre Aufgaben könnten so spezifisch oder vage sein, wie Sie es wollten / brauchten, aber sie sollten Ihre Fortschrittsindikatoren für die tatsächliche Arbeit sein, um die Geschichte in einen Zustand zu versetzen, in dem sie erledigt ist.

Beispiel

Ich erinnere mich grob an die USA, an denen ich vor Jahren gearbeitet habe und an denen Benutzer Testfälle selbst zuweisen mussten, damit jeder im Team wusste, an welchen TCs sie arbeiteten, um Doppelarbeit zu vermeiden. Die Benutzeroberfläche war eine (n interne) Webanwendung. Der Benutzer sah nur eine Schaltfläche, aber die Story war in mehrere Aufgaben unterteilt, die einige Details zur technischen Implementierung usw. enthielten.

Sichtbarkeit des Benutzers

Es gibt jedoch eine andere Art von Anwendung, bei der der größte Teil des Codes mit komplexen Vorgängen zu tun hat, die für den Benutzer nicht direkt sichtbar sind.

Ist es möglich, es auf irgendeine Weise für den Benutzer sichtbar zu machen?

Betrachten Sie ein GPS. Wenn Sie nicht an der Reihe sind, sehen Sie den tatsächlichen Prozess der Neuberechnung der Route nicht, aber der Benutzer erhält einige nützliche Rückmeldungen (z. B. "Neuberechnung ...").

Compiler können Warnungen oder Fehler anzeigen oder neue Einstellungen / Optionen in die GUI aufnehmen, damit Benutzer sehen können, dass etwas Neues hinzugefügt wurde. Ich würde denken, die Benutzer für Compiler wären Programmierer, oder? Würden sie nicht Unterstützung für einen neuen Standard sehen?

Während die Unterstützung eines neuen Standards wahrscheinlich auf Feature- Ebene erfolgt und in User Storys unterteilt werden müsste, haben Sie sichergestellt, dass Sie zumindest in einigen Fällen keine Storys verwenden, wenn Sie stattdessen Features verwenden sollten ?

Die Bildanalyse in einem Auto könnte so formuliert werden, dass der Benutzer weiß, dass die Wahrscheinlichkeit eines Autounfalls verringert wurde. Beispielsweise:

Als Passagier in einem selbstfahrenden Auto muss die Wahrscheinlichkeit, dass das Fahrzeug durch einen Zusammenstoß mit einem nicht erkannten Objekt einen Unfall verursacht, so nahe wie möglich bei Null liegen, damit ich sicherer fahren kann.

Die USA erfassen auf hohem Niveau Dinge, die Sie normalerweise mithilfe einer Kombination aus funktionalen und nicht funktionalen Anforderungen spezifizieren müssten, einschließlich Sicherheit, Sicherheit usw.

Eine Anforderung bezieht sich jedoch möglicherweise eher auf das System. z.B:

Für die Funktion abcin der Komponente Amuss der Toleranzschwellenwert im Bildvergleichsalgorithmus verringert werden, um Objekte, die sich langsam bewegen, besser erkennen zu können.

Für mich wäre dies leicht eine Aufgabe in der oben erwähnten User Story mit dem Titel: Verringern Sie die FunktionstoleranzA.abc und fügen Sie dann andere relevante Details hinzu.

Für ein Fluidsimulationssystem könnte es sogar eine Fortschrittsanzeige geben, die Rückmeldung zu Hintergrundaufgaben gibt, die das System ausführt, wenn dies sinnvoll ist. (Es gibt immer eine Möglichkeit, den Benutzer über etwas zu informieren, auch wenn Sie Spam vermeiden möchten.)

Ich weiß nicht genug über die bestimmten Domänen, die Sie erwähnt haben, um bessere und / oder realistischere Beispiele zu finden, aber wenn es hier einen Ausweg gibt, können Sie auf verschiedene Arten Benutzerfeedback zu etwas geben, das weniger sichtbar ist Das System könnte dies tun, dh es könnte Möglichkeiten geben, unsichtbare Dinge ein bisschen sichtbarer zu machen. (Auch wenn es darauf hinausläuft, eine Reihe von Versionshinweisen zu verfassen, die dokumentieren, wie viel schneller die Systemleistung jetzt aufgrund Ihrer Bemühungen ist usw.)

Beziehung zwischen Geschichten und Aufgaben

Hier kann es sehr schwierig werden, Aufgaben und User Stories in Beziehung zu setzen.

Unser Ansatz war es, User Storys darauf zu konzentrieren, was die Anfrage war, warum sie gestellt wurde und welche Dinge zutreffen mussten , um die USA als "erledigt" zu betrachten. Das How wurde immer aus den USA ausgelassen und den Entwicklern überlassen.

Die Entwickler würden das in den USA beschriebene Problem in eine Reihe von Aufgaben aufteilen, an denen sie arbeiten würden.

Ich sage dies als jemand, der zum größten Teil Back-End-Programmierung auf dem Server durchgeführt hat, was für den Endbenutzer wahrscheinlich so "unsichtbar" ist.

Je nachdem, was ich tun musste, verwendete ich manchmal AJAX, um eine einfache "Lade ..." - Animation / GIF anzuzeigen, damit der Benutzer wusste, dass er ein bisschen warten musste, bis etwas anderes abgeschlossen war, ohne den falschen Eindruck zu bekommen. Manchmal war es so einfach. Eine Aufgabe hierfür wäre angebracht.

Anderes Paradigma, Übung und Erfahrung

Gibt es Techniken, um dieses Problem zu lösen, oder müssen wir nur akzeptieren und das Beste daraus machen?

Jenseits des Akzeptierens des Paradigmenwechsels, des Übens und der gesammelten Erfahrung, gibt es wahrscheinlich nicht viel mehr zu sagen. Ich habe oft Leute gesehen, die versucht haben, Abkürzungen durch den Prozess zu nehmen. Ich würde dagegen raten, besonders wenn Sie anfangen. Wenn Sie mehr Erfahrung sammeln, können Sie etwas Flexibilität zulassen, aber vermeiden, sich selbst zu untergraben.

In Anbetracht Ihrer vorherigen Formulierung denken Sie immer noch über Geschichten nach, als wären sie "umbenannte Anforderungen", was ich für eine falsche Annahme halte. Ich denke, dies ist ein Symptom für ein tieferes Problem in Bezug auf die grundlegenden Unterschiede zwischen agilen und nicht-agilen Ansätzen.

Zweitens denke ich, dass Sie akzeptieren sollten, dass Agilität ein Paradigmenwechsel im Vergleich zum Wasserfall ist, was bedeutet, dass der Prozess zwar ähnliche Ziele verfolgt, diese jedoch auf sehr unterschiedliche Weise durchgeführt werden. (Denken Sie SVN vs Git, wenn das hilft.)

Versuchen Sie, Ihr aktuelles Verständnis der konzeptionellen Unterschiede zwischen Anforderungen und User Stories zu verbessern, und akzeptieren Sie, dass sie nicht dasselbe sind.

Von Ihren Sprints lernen - Rückblicke

Was ich nicht genug betonen kann, ist die Retrospektive zwischen Scrum Master und Entwicklern am Ende jedes Sprints. Dies ist der Ort, an dem sie auf ehrliche / transparente Weise über Dinge diskutieren, die "gut gelaufen " oder "nicht gut gelaufen" sind , und welche umsetzbaren Änderungen für den nächsten Sprint vorgenommen werden, um die "nicht gut gelaufen" -Punkte anzugehen .

Dadurch konnten wir uns anpassen und sogar voneinander lernen, und bevor wir es wussten, hatten wir uns deutlich verbessert, gemessen an der allgemeinen Konstanz der Geschwindigkeit unseres Teams.

code_dredd
quelle
"User Stories! = Requirements": Ich wollte nicht sagen, dass die beiden Synonyme sind. Nicht jede Anforderung ist eine User Story. Aber ich denke, dass alle User Stories Anforderungen sind. Ich betrachte Anforderungen als hierarchische Struktur, in der User Stories eine bestimmte Detailebene darstellen. Würdest du zustimmen?
Frank Puffer
@FrankPuffer Ich denke, dass das Anzeigen von User Stories, als ob sie sich auf einer anderen Ebene in einer Hierarchie von Anforderungen befinden, grundsätzlich unterschiedliche Konzepte vermischt. Auf der agilen Seite sieht eine Hierarchie eher so aus: Themen >> Epics >> Features >> User Stories >> Aufgaben . Die Anforderungen sind normalerweise in funktionale und nicht funktionale Anforderungen unterteilt, aber ich bin nicht auf eine tatsächliche Hierarchie gestoßen. Das heißt, ich wäre nicht überrascht, wenn jemand eine Anforderung rekursiv in kleinere "Teil" -Anforderungen zerlegen würde. In jedem Fall mischen Sie verschiedene Konzepte.
Code_dredd
Anforderungsmanagementsysteme wie PTC Integrity behandeln Anforderungen als Hierarchie. Dies kann von Vorteil sein, wenn Anforderungen einem Spezifikationsdokument zugeordnet werden.
Frank Puffer
@FrankPuffer Ja, deshalb habe ich gesagt, ich wäre nicht überrascht. Das heißt, ich frage mich, meine Antwort hat etwas für Sie geklärt. War die SVN vs Git-Analogie hilfreich? (Es wird davon
ausgegangen,
Ok, ich habe das "würde" falsch verstanden als "würde". Und ja, ich finde Ihre Antwort sehr hilfreich und werde sie wahrscheinlich akzeptieren. Ich brauche wahrscheinlich nur etwas Zeit, um mich an die Idee zu gewöhnen, User Stories nicht als Anforderungen zu betrachten.
Frank Puffer
4

In diesen Fällen können durchaus agile Prinzipien angewendet werden. Wie?

  • Compiler können später in separaten User Stories neue Sprachfunktionen hinzufügen
  • Bei Bildanalysesystemen können neue Funktionen als unterschiedliche Bildklassifizierungen hinzugefügt werden
  • Strömungssimulationssysteme können unterschiedliche Modellaspekte in ihren Simulationen berücksichtigen

Sie müssen nicht den gesamten Elefanten auf einmal essen. Agile verlangt nur, dass Sie zeigen, dass Sie Ihren Teller vor der nächsten Portion Elefanten gereinigt haben.

kandierte_orange
quelle
Dennoch denke ich, dass eine oder mehrere User Stories verbleiben, die viele sogenannte Basisfunktionen erfordern. Sie passen oft nicht in einen einzelnen Sprint. Wie soll damit umgegangen werden?
Frank Puffer
1
Sie messen den Erfolg mit ausführbaren Anwendungen, die Kunden testen, sehen oder berühren können. Wenn dies der Fall ist, geben Sie ihnen ein Spielzeug, das auf diese Weise das Gefühl des Fortschritts erzeugt. Zum Beispiel können Sie wahrscheinlich kein selbstfahrendes Auto im ersten Sprint veröffentlichen, aber Sie können eine Demo davon machen, wie Ihr Algo Menschen aufspürt. Später, wie es Signale und Tiere aufklärt. Später, wie es Entfernungen, Größen usw. misst. Das selbstfahrende Auto ist weit weg in einem Fernsprint, der weiß, ob es jemals passieren wird.
Laiv
2
@Laiv: Das wäre schön, aber ich bin mir nicht sicher, ob es funktioniert. In der Regel kann die Software nach den ersten Sprints nichts tun, worauf sich der Kunde beziehen kann. Sie werden technischen Fortschritt haben, aber es wird schwierig, wenn nicht unmöglich, ihn dem Kunden mitzuteilen.
Frank Puffer
2
Warum? Weil es von jemandem geschrieben wurde, der nicht zu Ihrem Projekt gehört? Ich erwarte, dass sich Agile an meine Bedürfnisse anpasst, nicht anders. Wenn ich sage, ich kann dir das Skaten in 4 Wochen beibringen und wenn du am 5. immer noch nicht stehst, heißt das dann, dass du nicht Skaten lernst? Oder nur, dass es ein bisschen länger dauert? Das Agile Manifest wurde weder in Stein gemeißelt, noch sind die Regeln des Scrums die Tend Commandments.
Laiv
2
Bei den Sprints geht es darum, Ihren Kunden in Ihre Iterationen einzubeziehen. Um mit ihnen unter Verwendung des gelieferten Codes zu kommunizieren. Keine Pläne und Versprechen. Sie müssen sich darauf konzentrieren, das Problem zu lösen. Es ist nicht erforderlich, dass das erste, was Sie ausliefern, in Stein gemeißelt wird. Sie müssen beweisen, dass Sie es wert sind, jeden Sprint zu bezahlen.
candied_orange
1

Ich stelle fest, dass Leute, die sich strikt an User Stories halten, sich entweder nur auf eine sehr alberne Art und Weise darauf einlassen, wie sich technische Änderungen im Backend auf den Benutzer auswirken (natürlich ohne Wissen des Benutzers, weil sie nur ein bisschen naiv sind) Benutzer und Sie sprechen über komplexe Änderungen in Ihrer Datenanalyse-Pipeline (oder etwas in der Art), oder sie werden völlig ratlos sein für "Wie organisieren wir diese Arbeit möglicherweise!?!"

Ich denke, die offensichtliche Lösung ist, pragmatischer zu sein. Wenn die Arbeit sehr technisch ist und keine besonders auffälligen Auswirkungen auf den Benutzer hat, sollten Sie nicht den Schlaf verlieren, indem Sie erklären, wie sie funktioniert. Wählen Sie einfach einen offensichtlichen und einfachen Weg, von dem die Benutzer profitieren können, und orientieren Sie sich dann an den Details, die die Entwickler für ihre Arbeit benötigen. Ich finde es unglaublich frustrierend, wenn eine PO darauf besteht, keine technischen Informationen in der Story zu haben, wenn es absolut notwendig ist. Es ist nur keine ganzheitliche Sicht auf das, was dieses Artefakt (die Geschichte) wirklich ist. So wie sie denken, dass es nur für sie existiert, ist es in den meisten Fällen auch für die Ingenieure wichtig.

Für die meisten dieser technischen Aufgaben gibt es in Bezug auf die Auswirkung auf den Benutzer einige Probleme, unabhängig davon, ob dies die Effizienz verbessert, sodass zukünftige Lieferungen schneller erfolgen, die Leistung verbessert und die Zuverlässigkeit erhöht werden. Sie sind nicht wirklich das, woran die Leute denken, wenn sie an „User Stories“ denken, aber wenn das Unternehmen verstehen möchte, warum Sie technische Schulden oder etwas in diesem Sinne machen würden, dann sind diese Erklärungen normalerweise am einfachsten zu liefern.

Lassen Sie sich von einem Scrumnazi nicht das Leben zusätzlich erschweren, nur weil es zu groß ist, um sich anzupassen. Adaptiv zu sein ist schließlich ein zentrales Konzept von Agilität. Die strikte Einhaltung von Scrum oder Agile spricht normalerweise gegen Pragmatismus und Praktikabilität (was eigentlich am besten funktioniert).

evanmcdonnal
quelle
Ich bin alles dafür, flexibel zu sein, aber ehrlich gesagt kümmert sich der Benutzer nicht besonders um die technischen Details, solange seine Geschichten zufrieden sind. Sie müssen nicht "streng agil" sein, um gute Anforderungen zu haben. und mit guten anforderungen meine ich anforderungen, denen jeweils ein abnahmetest beiliegt, der eindeutig die erfüllung der anforderung belegt. Die Leute, die "sehr alberne Übungen machen", machen es offensichtlich falsch, aber das heißt nicht, dass sie einer Vorstellung von "striktem Gedränge" folgen.
Robert Harvey
@RobertHarvey Ich stimme zu, dass die technischen Details für den Benutzer irrelevant sind. Mein Punkt ist jedoch, dass die Artefakte, die User Stories enthalten, einen umfassenderen Zweck haben als nur zu kommunizieren, wie die Dinge für den Benutzer funktionieren (oder zumindest sollten). Wie setzt man Anforderungen in Bezug auf Architektur, Erweiterbarkeit, Leistung usw. durch, wenn sie reine User Stories schreiben? Ein reiner "User Story" -Ansatz motiviert Entwickler, Code mit schlechter Qualität zu schreiben. Und es sind nicht Benutzer, die die 'User Stories' lesen, sondern Entwickler und Entwickler. Es ist dumm, relevante Informationen bewusst auszuschließen, weil sie technisch sind.
evanmcdonnal
0

Ich denke, es geht darum, User Stories eine Bedeutung zu geben, die sie nicht haben. Scrum verwendet den Begriff PBI oder Product Backlog Item, was meiner Meinung nach unendlich besser ist. PBIs wird oft ein User Story - Format, zum Beispiel folgen, haben Sie vielleicht eine PBI haben wie „Abonnent der Lage sein sollten , ihre Abonnement - Daten zu sehen“, aber man könnte auch genauso gut eine PBI hat wie „Erstellen Sie eine gespeicherte Prozedur Teilnehmer Details zu erhalten ".

User Stories sind ein Werkzeug . Sie helfen Ihnen dabei, Funktionsbeschreibungen und Anforderungen zu erstellen, die darauf beruhen, dass Sie sich in die Lage eines Benutzers versetzen. Aber genau wie ein Schraubenschlüssel unbrauchbar ist, wenn Sie ein Bild aufhängen müssen, kann es vorkommen, dass Sie keine User Story benötigen.

Das heißt, viele Teams spielen eigentlich nur schnell und locker mit dem "User" -Part. Möglicherweise haben sie "User Storys" wie "Als Entwickler muss ich eine gespeicherte Prozedur aufrufen können, um Abonnentendetails abzurufen", im Wesentlichen sozusagen eine "Developer Story". Dies ist eine ebenso gültige Option, aber ich persönlich sage, solange Sie beschreiben können, was getan werden muss, und eine Reihe von Akzeptanzkriterien aufstellen können, ist es kaum von Bedeutung, ob Sie eine tatsächliche User Story dahinter haben oder nicht.

Chris Pratt
quelle
1
Ich stimme dem nur in sehr seltsamen und seltenen Fällen zu. In Scrum ist das WIE die Zuständigkeit des Entwicklungsteams und nicht der Produktbesitzer. Der Product Owner sollte jedoch für PBIs verantwortlich sein. Ein PBI wie "Create a Stored Procedure" entzieht dem Entwicklerteam das Recht, das WIE zu wählen. PBIs, ob User Story oder nicht, sollten erläutern, welchen geschäftlichen Wert die PBI hat. Beim Erstellen einer gespeicherten Prozedur geht es nicht um den geschäftlichen Wert, sondern um Implementierungsdetails.
RibaldEddie
Das ist nicht der Punkt. Das war nur ein Beispiel. Sie könnten einfach "gespeicherte Prozedur" in etwas generisches wie "einen Weg" ändern. Der Punkt ist, dass es nicht unbedingt eine User Story sein muss.
Chris Pratt
Der springende Punkt eines Beispiels ist, ein Vorbild zu sein. Wenn Ihr Beispiel "ist nicht der Punkt", was ist der Punkt des Beispiels?
RibaldEddie
-3

Solche Anwendungen sind genau diejenigen, bei denen unterschiedliche Fachkenntnisse vorhanden sind und sich weiterentwickeln werden. Die Teammitglieder haben aufgrund unterschiedlicher Ausbildung, unterschiedlicher Hobbyprojekte und unterschiedlicher Berufserfahrung unterschiedliche Fähigkeiten. Wenn jemand einen bestimmten Code entwickelt, muss der Entwickler derjenige sein, der den Code am besten kennt. Daher ist es möglicherweise sinnvoll, weitere Entwicklungsaufgaben mit demselben Code demselben Entwickler zu übertragen.

Im populärsten agilen Prozess, Scrum, ist Poker geplant, bei dem jeder Aufgabe ein Schwierigkeitsgrad zugewiesen wird. Der Schwierigkeitsgrad ist nicht abhängig von der Person, die diese Aufgabe gemäß dem Prozess ausführt. Dann werden die Leute während des Sprints als homogen betrachtet, sodass von jeder Person erwartet wird, dass sie jede einzelne Aufgabe auswählen und ausführen kann. In einfachen CRUD-ähnlichen Projekten gilt diese Annahme. In sehr komplexen und schwierigen Projekten ist dies jedoch nicht der Fall.

Für solche Projekte würde ich keinen agilen Prozess verwenden. Ihre beste Wahl ist es, formelle Prozesse zu vermeiden und nur ein gutes Projektmanagement zu verwenden. Berücksichtigen Sie bei der Entscheidung, wer ein bestimmtes Feature implementiert, die für dieses Feature erforderlichen Kenntnisse und die besten Kenntnisse des vorhandenen Codes. Hierfür ist kein Prozess erforderlich. Sie werden wahrscheinlich gute Designdokumente für alle Funktionen schreiben und diese auf dem neuesten Stand halten wollen. Beachten Sie, dass ich hier kein wasserfallähnliches Modell bewerbe: Die Konstruktionsdokumente werden nicht alle zu Beginn des Projekts geschrieben. Sie werden stattdessen neue Designdokumente schreiben, wenn neue Funktionen benötigt werden.

juhist
quelle
5
Nicht wirklich mit meiner Frage verwandt, aber es kann gefährlich sein, immer denjenigen mit den besten Fähigkeiten ein Feature implementieren zu lassen. Es behindert die Wissensverbreitung im Team. Wenn eine Wartung erforderlich ist und der Experte das Team verlassen hat oder vorübergehend nicht verfügbar ist, sind Sie in Schwierigkeiten.
Frank Puffer
@FrankPuffer Für einige der von Ihnen aufgelisteten Systeme, z. B. selbstfahrende Autos, sind Sie in Schwierigkeiten, wenn der Experte das Team verlässt. Zeitraum. Während es wahrscheinlich nicht der Fall ist, dass die Codierung zentralisiert werden sollte, ist es auch völlig unvernünftig, von einer angemessenen "Wissensverbreitung" auszugehen, um den Experten in einem angemessen kurzen Zeitraum ersetzen zu können. Das sind Leute, die sich über ein Jahrzehnt lang mit dem Problem befasst haben und sich vermutlich ganz oben auf ihrem Gebiet befinden. Sie werden wahrscheinlich mehrere Personen mit unterschiedlichen Fähigkeiten benötigen. Solche Projekte sind von Natur aus riskant.
Derek Elkins hat SE