Was tun gegen „Fehlergesteuerte Entwicklung“?

In unserem Shop sind wir bestrebt, agil zu sein. Und ich würde sagen, wir machen große Fortschritte. Das heißt, einige von uns haben ein Muster entdeckt, das wir als "Failure Driven Development" bezeichnen.

Failure Driven Development kann grundsätzlich als ein agiler Release- / Iterationszyklus beschrieben werden, bei dem die Fehler / Features nicht von Aufgaben und Storys mit Akzeptanzkriterien, sondern von in die Fehlerverfolgungssoftware eingegebenen Fehlern geleitet werden.

Unser Team hat einen großartigen Projektmanager, der sich bemüht, die Akzeptanzkriterien von den Kunden zu erhalten, aber das ist nicht immer möglich. Von meinem Entwicklungsstuhl aus ist dies darauf zurückzuführen, dass der Kunde entweder nicht genau weiß , was er will, oder (und das ist der Kicker), dass zwei verschiedene "Camps" im Hauptbüro des Kunden miteinander in Konflikt stehen, wie eine Story umgesetzt werden soll. Camp A wird lose, auf dem Feature X funktioniert wie diktiert dies , dann wird Camp B es scheitert nicht wie funktioniert das . Daher der Begriff "FDD". Der Prozess wird durch "Fehler" angetrieben.

Dies führt zu meiner Frage: Hat dies jemand anderem begegnet und wenn ja, irgendwelche Tipps / Vorschläge für den Umgang damit?

Wir haben natürlich versucht, Lager A und B zu einer Einigung zu bewegen, aber jeder weiß, dass dies nicht immer der Fall ist.

Vielen Dank

Wild widersprüchliche Anforderungen sind in der Unternehmenswelt keine Seltenheit. Und dies ist häufig der Grund für das "Scheitern" von Geschäftsprozessautomatisierungsprojekten. Es kann so einfach sein, wie es in der Richtlinie und im Verfahrenshandbuch heißt, dass X ausgeführt werden muss, während die Personen, die die Arbeit tatsächlich ausführen, Y ausführen. Wenn die Software Y ausgeführt wird, besteht die Person, die für die Software bezahlt, darauf, dass die Software von ihrer Seite fehlerhaft ist Perspektive. Die Software zum Laufen bringen X bedeutet, dass die Leute, die die Arbeit tatsächlich erledigen, die Arbeit nicht erledigen können.

Normalerweise entscheiden die meisten Entwicklungsunternehmen, was die Manager über das sagen, was die Arbeiter sagen, denn so werden die Rechnungen bezahlt. In der idealen Welt gibt es keine Impedanzinkongruenz zwischen schriftlichen und tatsächlichen Richtlinien. In der realen Welt ist ein Großteil der Büroarbeit informell aufgeteilt und nicht dokumentiert.

Lager A wird mit Sicherheit vorschreiben, dass Feature X so funktioniert, und Lager B wird scheitern, weil es nicht so funktioniert.

Das Missverhältnis zwischen CampA und CampB ist ein politisches Problem und kein Softwareproblem. Um das Problem zu lösen, muss man mit den Leuten sprechen und einen klaren Gewinner finden.

Einer der Hauptgründe für die Verwendung der iterativen Entwicklung ist, dass Sie eine Kundengruppe haben, die nicht genau weiß, was sie will.

Das ist kein Misserfolg. Viele Kunden haben einfach keine Ahnung, was sie genau brauchen, bis sie etwas in die Hand bekommen. Dies ist der Grund, warum der Kunde das System zum ersten Mal sieht, wenn es nicht fertig ist. Lassen Sie sie es früh und oft sehen.

Mit anderen Worten, wenn dies das einzige Problem war, besteht kein Grund zur Panik, es sei denn, Sie befinden sich in einer Situation, in der es nur endlose Wiederholungsversuche gibt.

Das Problem der Meinungsverschiedenheit zwischen den Kunden ist ein Produktmanager-Problem, das nicht an Sie weitergegeben werden sollte. Das meiste, was Sie sehen sollten, ist Rückstand / Aufgaben / was auch immer. Natürlich wird der PM oft in den Entwicklungsbereich vordringen, da dies der einzige Ort ist, den er kann, der Sie jedoch nicht beeinträchtigen sollte.

Wie es gehandhabt wird, hängt stark davon ab, wer Lager A und Lager B sind.

Wenn Lager A und Lager B zwei höhere Ebenen darstellen, holen Sie sich jemanden, der das System tatsächlich verwendet, um Ihnen mitzuteilen, was Sie benötigen. Manchmal kommt es zu Luftverdünnungen im Managementland, die eine Trennung von der Realität bewirken. Jemand, der praktisch ist, kann oft den Idealismus durchtrennen und aufzeigen, was wirklich gebraucht wird.

Wenn A und B Benutzergruppen sind, verwenden Sie die entgegengesetzte Methode, um jemanden vom Management dazu zu bringen, das Gesetz festzulegen.

Perfektion ist in jedem Fall der Feind des Guten.

Was Sie beschreiben, ist eine typische falsche Implementierung von Agile. Du umarmst keine Veränderung, du bist ihr Sklave .

Haben Sie einen Produktbesitzer? Können Sie nach Bedarf mit ihnen sprechen? Machst du einen Sprint-Review mit den Usern? Sind Benutzer (über den Product Owner) an der Sprint-Planung beteiligt? Hast du Tester im Hauptteam?

Ich empfehle dringend, dass Sie einen agilen Trainer engagieren und / oder Ihr Team zu einem Training schicken.

Eine andere Lösung ist, Agile zu beenden.

Wenn sie Ping-Pong spielen (A sagt do x, B lehnt ab, sagt y, dann lehnt A ab und zurück zu x), müssen Ihre Leads (PO oder was auch immer Sie haben) sie verprügeln, um sich zu entscheiden .

Es ist in Ordnung, wenn die ersten Schritte nicht ihren Bedürfnissen entsprechen (der springende Punkt dabei ist, ihnen etwas zum Anschauen zu geben), aber wenn sie dort sitzen und bei nachfolgenden Iterationen hin und her schwingen, werden Sie nie fertig.

Das Problem hier scheint nicht "Ich werde es wissen, wenn ich es sehe" zu sein. Wireframes können (bis zu einem gewissen Punkt) bei diesem speziellen Problem helfen.

Das Problem hierbei sind meines Erachtens die beiden konkurrierenden Fraktionen innerhalb Ihres Kunden. Im Idealfall haben die Lager A und B eine ausgehandelte gemeinsame Vision, die sie Ihnen vorstellen können.

Vielleicht werden sie gezwungen, an den Tisch zu kommen, indem Sie erklären, wie viel die Kämpfe sie kosten, während Sie noch einmal wiederholen, was A nach B verlangt hat (oder umgekehrt).

Hier wäre es hilfreich, detaillierte Notizen über Ihren Zeitaufwand zu machen. (Meine Arbeit hat eine einfache Anwendung für die Zeitmessung geschrieben: einfach zu verwenden, einfach zu melden und die Zeit in 15-Minuten-Blöcken zu melden. Es macht es einfach zu sagen, dass ich n Stunden mit Feature X verbracht habe.)

Es bedeutet, dass Sie ein gewisses Risiko haben, den Kunden zu verärgern oder schlecht auszusehen, egal was Sie tun, da das, was Sie für B tun, A verärgern könnte (oder umgekehrt).

Hoffentlich finden Sie beim Kunden einen Champion, der sich um die Kämpfe kümmert.

Meiner Meinung nach kann das Problem nur an einem Ort beim Kunden effektiv gelöst werden, was schwierig sein wird.

Sie erwähnen, dass Sie nach Agilität streben, also nehme ich es aus der Perspektive von Scrum, dem agilen Prozess, den ich am besten kenne.

Laut Scrum haben Sie eine bestimmte Rolle, den Product Owner, der für die Priorisierung von User Stories / Bugs / Releases usw. verantwortlich ist. Dies sollte idealerweise nur eine Person sein. Wenn es viele Interessenten mit unterschiedlichen Ansichten zur gleichen Software gibt, liegt es in der Verantwortung des Produktbesitzers, dass das Produkt alle Interessenten zufriedenstellt.

Es klingt für mich, dass Ihr Projektmanager diese Rolle hat. Aber da er als Projektmanager und nicht als Produktbesitzer bezeichnet wird, muss ich glauben, dass er auch mit anderen Aufgaben (traditionelle, nicht agile, Managementaufgaben?) Belastet ist und nicht genügend Zeit hat, um die zu verfolgen Rolle des Produktbesitzers.

Ich glaube, Sie brauchen eine Person, die für die Koordination der Anforderungen zwischen den verschiedenen Teams des Kunden verantwortlich ist und sicherstellt, dass die Anforderungen / User Stories, die an die Entwickler gesendet werden, von beiden Teams des Kunden überprüft wurden. Diese Rolle auszuüben, kann leicht eine Vollzeitbeschäftigung sein, insbesondere für den Kunden, den Sie haben.

Was wirklich ideal wäre, ist, diese Verantwortung auf den Kunden zu verlagern, damit einer der Mitarbeiter Ihres Kunden die Rolle des Product Owners übernimmt. Solange der Kunde diese Rolle nicht innehat, ist er nicht verpflichtet, seine internen Meinungsverschiedenheiten zu lösen, und er überlässt es Ihnen, das zu lösen, was Sie höchstwahrscheinlich nicht können. Und deshalb glaube ich, dass die einzig wirksame Lösung darin besteht, dem Kunden diese Verantwortung zu übertragen.

Angesichts der Tatsache, dass Sie bereits eine Zusammenarbeit begonnen haben, fällt es Ihnen meiner Meinung nach schwer, diese Änderung umzusetzen.

Damit Ihre Software von Ihrem Kunden akzeptiert wird, muss sie die vom Kunden festgelegten Anforderungen gemäß den Akzeptanzkriterien erfüllen.

Sie haben eine Reihe von Benutzeranforderungen in Form von Storys und Akzeptanzkriterien, aber Teile der Kundenorganisation haben unterschiedliche Interpretationen der User Storys, was zu Mehrdeutigkeiten führt.

Sie können aus dieser Situation herauskommen, indem Sie das funktionale Design und die implementierten Geschäftsregeln beschreiben und diese vom Kunden signieren lassen. Diese werden dann bei der Abnahme geprüft. Dies muss im Voraus vom Kunden vereinbart werden, um spätere Diskussionen über die Bedeutung aller Unterlagen zu verhindern.

Solange Ihre Gruppe die von Ihnen erstellte Software nicht so beschreiben kann, dass sich beide Gruppen einig sind, befinden Sie sich noch in der Anforderungsanalysephase des Projekts.

Ihr Projektmanager könnte / sollte im Rahmen des Projekts eine bezahlte Beratung anbieten, um die Mehrdeutigkeit der funktionalen Anforderungen zu beheben.

Ich denke, wir haben alle den Fall gesehen, in dem wir vom Benutzer detaillierte Anforderungen erhalten, diese implementieren und dann vom Benutzer hören, dass "Warten Sie, das wird bei mir nicht funktionieren", sobald es implementiert ist.

Eine Möglichkeit zur Qualitätssicherung der Anforderungen besteht darin, dem Benutzer detaillierte Beispiele mit dem erwarteten Systemverhalten zu geben. Zum Beispiel könnten Sie sagen: "Hier ist ein Beispielfall. Wenn wir X implementieren, ist Y das Ergebnis und Z eine der Konsequenzen." Auf diese Weise können Sie zu "Warten, das wird nicht funktionieren" gelangen, bevor Sie den Code schreiben, anstatt nachher.