Frage:
Mein agiles Team verbesserte eine vorhandene Funktion und fand schwerwiegende Fehler im ursprünglichen Code. Ist es unsere Verantwortung, sie zu reparieren?
0ldg33zer
2018-10-19 19:45:18 UTC
view on stackexchange narkive permalink

Wir haben den Aufwand für die Durchführung unserer Softwareverbesserung auf der Grundlage der ursprünglichen Funktion geschätzt, die wie geplant funktioniert. Beim Testen stellten wir fest, dass es erhebliche Mängel aufwies und nicht wie geplant funktionierte. Wir haben alle unsere Änderungen rückgängig gemacht und bewiesen, dass der ursprüngliche Code diese Mängel bei der Veröffentlichung aufwies. Das ursprüngliche Team behauptete etwas anderes, obwohl wir dies auf unverändertem Code bewiesen hatten.

Wir haben die Fehlerquelle gefunden, dürfen sie jedoch nicht entfernen. Stattdessen mussten wir alle betroffenen Funktionen reparieren (weit über den ursprünglichen Rahmen unserer Geschichte hinaus) und werden nun gebeten, alle alten Funktionen zu testen.

Der Umfang der Tests ist enorm. Wie bringen Sie die anderen Teams dazu, ihre ursprüngliche Arbeit erneut zu testen? Sie alle behaupten, es habe nichts mit ihnen zu tun, obwohl wir bewiesen haben, dass die Funktionalität in der veröffentlichten Version des Codes nicht funktioniert hat.

Ein Vorgesetzter muss eingreifen. Bringen Sie dies zu Ihrem Chef.
Was genau macht das zu einem Problem?Sind Sie gezwungen, dafür Überstunden zu machen?Werden Sie irgendwie dafür verantwortlich gemacht?Dinge zu reparieren und zu bauen ist Ihre Aufgabe;Wenn das Unternehmen der Meinung ist, dass Ihr Team am besten dafür geeignet ist, sollte dies kein Problem sein.
Wenn Sie gebeten werden, all diese neuen Arbeiten zu erledigen, wird von Ihnen erwartet, dass Sie dies in der gleichen Zeit tun?
Wo war Ihr SQA-Team, als das Unternehmen zum ersten Mal veröffentlicht wurde?(mit Mängeln)
Wie wird der Besitz von Anwendungen in Ihrer Abteilung gehandhabt?Wem gehört die technische Verschuldung, die Ihr Team gefunden hat?Die Antworten auf diese Fragen werden entscheiden, ob dies für Ihr Team in Frage kommt oder nicht.Schneiden Sie diese in beiden Fällen als neue Geschichten aus. Arbeiten Sie nicht mit demselben Ticket.
Fünf antworten:
Jason
2018-10-20 03:49:07 UTC
view on stackexchange narkive permalink

Ich würde sagen, dass Sie Ihren Scrum Master und Product Owner einbeziehen. Letztendlich sollte der Product Owner derjenige sein, der die Entscheidung trifft und alle neuen Arbeiten priorisiert, die sich daraus ergeben.

Genau das hätte ich geschrieben.Wenn die Verbesserung des alten Codes relevant ist und der PO mit dem Kunden priorisieren muss.
paparazzo
2018-10-19 20:51:21 UTC
view on stackexchange narkive permalink

Bei der Erstellung einer Schätzung ist davon auszugehen, dass die Funktionen wie geplant funktionieren. Sie sollten kritische Funktionen testen, können jedoch nicht alle Funktionen testen.

Es ist nicht sinnvoll, vorhandene Fehler zu beheben und alle Funktionen zu testen, wenn dies nicht im Rahmen der Arbeit liegt.

Im Umfang der Arbeit / Schätzung sollten Sie immer angeben, dass alle Funktionen wie geplant funktionieren.

Klingt nicht so, als würden Sie sehr weit direkt zum anderen Team gelangen.

Sie müssen dies Ihrem Chef mit dem Nachweis früherer Fehler und einer überarbeiteten Schätzung von bringen Umfangserweiterung. Sie können mit Ihrem Chef nichts anfangen und wenn ja, müssen Sie einfach tun, was Sie können. Es könnte sein, dass ihm von seinem Chef gesagt wurde, dass es so ist. Wenn das Projekt über das Budget hinausgeht, muss die Erweiterung des Anwendungsbereichs erläutert werden.

Es kann sinnvoll sein, dass Ihr Team Fehler behebt und testet, anstatt darauf zu warten, dass ein anderes Team vorhandene Fehler behebt. Nicht fair, wenn Ihnen nicht mehr Zeit oder Ressourcen zugewiesen werden, aber manchmal ist das Leben nicht fair.

mxyzplk - SE stop being evil
2018-10-21 03:42:19 UTC
view on stackexchange narkive permalink

Sie sind ein agiles Team. Wenn dies echt und nicht zur Schau ist, sollten Sie am Ende die Antwort auf diese Frage bestimmen.

Protokollieren Sie es als ein oder mehrere fehlerhafte Tickets für die Fehler. Bestimmen Sie dann, was in Ihrer Situation das "Richtige" ist - ist es, den Sprint zu brechen und ihn jetzt zu übernehmen oder ihn für den nächsten Sprint ganz oben im Rückstand zu platzieren oder ihn einfach für später zu protokollieren? Arbeiten Sie miteinander zusammen - das technische Personal sollte die Auswirkungen und den LOE (Aufwand) der Fehlerbehebung bereitstellen. Der Product Owner trägt zur Priorisierung und zum Verständnis anderer zeitlicher Verpflichtungen bei. Dann tun Sie es jetzt oder später oder nie, je nachdem, was für diesen Dienst und seine Benutzer und Ihr Unternehmen richtig ist.

Agilität ist eine Stärkung, aber sie bringt Verantwortung mit sich. Wenn eines meiner Teams sagte: "Nun, wir haben mit dem kritischen Fehler geliefert, weil wir ihn gesehen haben, aber niemand uns gebeten hat, ihn zu beheben", hätte dies bedauerliche Konsequenzen.

Ich finde es sehr enttäuschend, dass andere Antwortende entweder nicht viel über Agile wissen oder in "fake agile" Umgebungen arbeiten. "Der Chef sagt Ihnen, was zu tun ist" ist ein BS der alten Schule, der im Widerspruch zu einem gut funktionierenden agilen Geschäft steht.

gnasher729
2018-10-22 03:50:46 UTC
view on stackexchange narkive permalink

Was hätte passieren sollen: Sie hatten Aufgaben, die eigentlich recht einfach zu handhaben waren und nicht viel Zeit in Anspruch nahmen. Dann haben Sie herausgefunden, dass es aufgrund vorhandener Fehler viel schwieriger war, diese Aufgaben erfolgreich abzuschließen (ohne Fehler anzuzeigen) als gedacht.

Sie sollten eine neue Aufgabe hinzugefügt haben: "Bestehende Probleme beheben". Markieren Sie es als Blockierung Ihrer Aufgaben, markieren Sie Ihre Aufgaben als blockiert. Sie können Ihre Aufgaben also nicht erledigen. Sie wählen andere Aufgaben aus und währenddessen kontaktiert Ihr Scrum-Master den Verantwortlichen für die Blockierung und bittet ihn, diese so schnell wie möglich zu beheben.

Wenn es, wie Sie sagten, nicht möglich ist, die Ursache des Problems zu ändern, müssen Sie festlegen, wie Ihre Aufgaben bei Vorhandensein der vorhandenen Fehler implementiert werden sollen. Dies wird offensichtlich viel komplexer sein. Übrigens. Es ist eine Aufgabe an sich, die einige Zeit in Anspruch nehmen wird. Dann fügen Sie alle zusätzlichen Aufgaben hinzu, die durch die Sturheit einer Person verursacht werden, schätzen sie und führen alle diese Aufgaben aus.

Als Endergebnis kann niemand sagen, dass Sie 10 Tage gearbeitet haben, aber 30 Tage gebraucht haben, aber Sie sagen, dass 10 Tage Arbeit eigentlich 30 Tage waren Arbeit wert, weil andere nicht kooperativ waren und wir die 30 Tage Arbeit in 30 Tagen erledigt haben ".

Der Punkt ist, dass es nicht wirklich wichtig ist, wer die Arbeit macht. Der Punkt ist, dass Sie Beweise dafür vorlegen, dass Ihre Arbeitsbelastung stark zugenommen hat und Sie damit umgegangen sind.

Strader
2018-10-19 20:34:35 UTC
view on stackexchange narkive permalink

Nichts als Teil des Teams, was Sie tun können oder sollten, denke ich. Es gibt keine zusätzliche Arbeit :)

Ihr Chef / Teamleiter hat Optionen, abhängig von der Art Ihres Engagements. ob Sie Teil des Unternehmens oder des angeheuerten Teams sind?

Erstellen Sie eine Liste mit neuen Aufgaben, die alle erforderlichen Aufgaben enthält, und aktualisieren Sie die Frist für das Projekt.

  1. melden Sie die Befehlskette im Unternehmen an seinen Chef
  2. ol>

    Oder

    1. kommen mit neuer Zeitleiste, neuem Budget und neuer Rechnung zum Kunden zurück Arbeit erledigt
    2. ol>

      Update: Wenn Sie nicht einverstanden sind, stimmen Sie bitte nicht einfach ab, sondern schreiben Sie eine Zeile in die Kommentare. Wir können darüber diskutieren.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...