Ich habe zwei verwandte Fragen zu Scrum.

Unser Unternehmen versucht, dies umzusetzen und ist sich sicher, dass wir über die Hürden springen.

Bei beiden Fragen geht es um "Fertig bedeutet Fertig!"

1) Es ist wirklich einfach, "Fertig" für Aufgaben zu definieren, die - eindeutige Testakzeptanzkriterien - vollständig eigenständig sind - am Ende von Testern getestet wurden

Was ist mit folgenden Aufgaben zu tun: - Architekturdesign - Refactoring - Entwicklung einiger Dienstprogrammklassen

Das Hauptproblem dabei ist, dass es sich fast ausschließlich um eine interne Entität handelt und es keine Möglichkeit gibt, sie von außen zu überprüfen / zu testen.

Als Beispiel ist die Implementierung von Features eine Art Binärdatei - sie ist abgeschlossen (und besteht alle Testfälle) oder sie ist nicht abgeschlossen (besteht einige Testfälle nicht).

Das Beste, was mir in den Sinn kommt, ist, einen anderen Entwickler zu bitten, diese Aufgabe zu überprüfen. Es gibt jedoch keine eindeutige Methode, um zu bestimmen, ob es vollständig durchgeführt wurde oder nicht.

Die Frage ist also, wie definieren Sie "Fertig" für solche internen Aufgaben?

2) Debug / Bugfix Aufgabe

Ich weiß, dass eine agile Methodik keine großen Aufgaben empfiehlt. Zumindest wenn die Aufgabe groß ist, sollte sie auf kleinere Aufgaben aufgeteilt werden.

Nehmen wir an, wir haben ein ziemlich großes Problem - ein großes Modul-Redesign (um die neue veraltete Architektur durch eine neue zu ersetzen). Sicher, diese Aufgabe ist auf Dutzende kleiner Aufgaben aufgeteilt. Ich weiß jedoch, dass wir am Ende eine ziemlich lange Debug / Fix-Sitzung haben werden.

Ich weiß, dass dies normalerweise das Problem des Wasserfallmodells ist. Ich denke jedoch, dass es schwierig ist, es loszuwerden (insbesondere bei ziemlich großen Veränderungen).

Sollte ich spezielle Aufgaben für Debug- / Fix- / Systemintegrationen usw. zuweisen?

Wenn ich das tue, ist diese Aufgabe normalerweise nur sehr groß im Vergleich zu allem anderen und es ist schwierig, sie auf kleinere Aufgaben aufzuteilen.

Ich mag diesen Weg nicht, wegen dieser riesigen Monolithaufgabe.

Es geht auch anders. Ich kann kleinere Aufgaben erstellen (die mit Fehlern verbunden sind), sie in den Rückstand legen, Prioritäten setzen und sie am Ende der Aktivität zu Iterationen hinzufügen, wenn ich weiß, was die Fehler sind.

Ich mag das nicht, weil in diesem Fall die gesamte Schätzung falsch ist. Wir schätzen die Aufgabe ein, markieren sie jederzeit als erledigt. Und wir werden die neuen Aufgaben für Fehler mit neuen Schätzungen eröffnen. Wir werden also am Ende die tatsächliche Zeit = geschätzte Zeit haben, was definitiv nicht gut ist.

Wie lösen Sie dieses Problem?

Grüße, Victor