Das erste Problem, das ich sehe, ist, dass der Schätzprozess etwas weit geht. Ja, Entwickler sollten mitbestimmen, wie viel Arbeit sie voraussichtlich übernehmen werden. Nein, das bedeutet nicht, dass das Hinzufügen einer einzelnen Schaltfläche zu einem Webformular jetzt eine Geschichte von zwei Entwicklerwochen ist (wie viele Punkte auch immer im Schätzungsprozess Ihres Unternehmens entsprechen). Wenn dies der aktuelle Stand der Dinge ist, sollten Sie als Projektmanager eine zweite Vermutung anstellen.
Zweitens höre ich "von Anfang (Design) bis Ende (Implementierung und Unit-Test)" und der erste Gedanke, der mir einfällt, ist "Sie machen es falsch". Ihre Komponententests sind Teil Ihrer Entwurfsarbeit als Entwickler / Entwicklungsteam und sollten zuerst durchgeführt werden. Sie nehmen die grundlegenden Anforderungen, destillieren sie in eine einfache "Checkliste" von "Wenn ... Wann ... Dann ..." - geben Sie Sätze ein und konvertieren diese Sätze dann in eine Reihe grundlegender Tests, die bestätigen, dass das Programm diese erfüllt Behauptungen und damit die Anforderungen. Dies geschieht, bevor Sie eine Zeile des Produktionscodes schreiben, die den Aussagen der Tests entspricht. Wenn Ihre Komponententests zuletzt durchgeführt werden, verlieren Sie nach der Implementierung der Software mehrere wichtige Aspekte des Komponententests. Im Allgemeinen können Ihre Entwickler nicht "auf Grün programmieren".
Für Entwickler, die ihre Funktionen "besitzen", gibt es ein Ja und ein Nein. Zunächst einmal ist eine ziemlich häufige Erschütterung durch "selbstorganisierende Teams" eine Tendenz für Entwickler, paarweise oder zu dritt loszulegen und an Dingen zu arbeiten, die sie am besten kennen. Angenommen, Sie verfügen über ein umfassendes Know-how für Entwickler, sodass das Team alle in jeder Iteration auf diese Weise auszuführenden Arbeiten abdecken kann, können Sie dies einfach zulassen. Dies ist eine gute Sache für die Geschwindigkeit, da Entwickler sich weiterhin auf die Bereiche der Codebasis konzentrieren und mit diesen vertraut sind, in denen sie von Iteration zu Iteration gearbeitet haben.
Ein Entwickler, der eine Funktion fürs Leben besitzt, ist jedoch eine gefährliche Denkweise, da sie die "LKW-Nummer" Ihres Teams senkt (ganz offen definiert als "wie viele Personen von einem LKW getroffen werden könnten, bevor das Team nicht funktionieren könnte" Worst-Case-Szenario, in dem bestimmte Personen getroffen werden und das daraus resultierende Wissen verloren geht. Wenn derjenige, dem Sie die Funktion "Dateiimport" Ihrer Software zugewiesen haben und der sie 2 Jahre lang besitzt, drei Wochen in den Urlaub fährt, einen längeren FMLA-Urlaub nimmt, ändert sich dies Jobs oder im Extremfall werden wirklich von einem Lastwagen angefahren und sterben. Jetzt gibt es niemanden mehr, der diese Funktion kennt, da dieser Bereich der Codebasis seit Jahren der ausschließliche Zuständigkeitsbereich eines Mannes ist. Während sich jemand anderes mit ihm vertraut macht mit diesem bestimmten Stück der Codebasis,Sie werden erheblich an Geschwindigkeit verlieren, und Sie werden sich auch zusätzlichen Problemen mit Fehlern öffnen, da der neue Mann, der gerade erst mit der Funktionsweise der Codebasis vertraut ist, möglicherweise völlig unwissend bleibt, was er daran ändern kann und was nicht .
Stattdessen sollten Sie versuchen, eine Arbeitsteilung zu pflegen, bei der Ihre LKW-Nummer mindestens 2 oder mehr und in einem größeren Team (ein Dutzend oder mehr) näher bei 3 oder 4 liegt. Auf diese Weise, wenn ein Mann die Arbeit nicht erledigen kann Aus irgendeinem Grund gibt es mehrere andere Leute, die einspringen können. Manchmal schütteln sich Teams auf natürliche Weise auf diese Weise aus, besonders wenn Sie ein paar XP-Techniken wie Paar- oder Dojo-Programmierung einbringen (ein Typ schreibt in einer neuen Behauptung, die darauf basiert bei Anforderungen, die der Code nicht erfüllt; der nächste Code codiert dann, um diesen Test zu bestehen, fügt dann eine weitere Anforderungszusicherung hinzu, die fehlschlägt, und gibt sie weiter). In diesen Situationen haben Sie per Definition mehrere Augen, die den Code betrachten, ihn entwickeln und sich mit ihm vertraut machen.
Insgesamt besteht die Idee von Agile darin, eine "leichte" Entwicklung zu fördern. Ihr Team scheint sich in einer Vielzahl von Prozessen und Dokumentationen festgefahren zu haben, wenn der Hauptfokus gemäß dem Agilen Manifest auf den Teammitgliedern und ihren Interaktionen und natürlich auf funktionierendem Funktionscode liegen sollte. Die Prozesse, die Agile inhärent sind, sind ein Mittel zum Zweck, und es gibt keinen Weg, Agile zu folgen. Selbst die primären agilen Frameworks wie SCRUM sind je nach Ihren Anforderungen als Unternehmen, Team und sogar von Tag zu Tag formbar (achten Sie bei solchen Änderungen nur darauf, die Grundideen der Werte, die durch diese Prozesse bereitgestellt werden, im Auge zu behalten).