it-swarm.com.de

Wie entwickelt man Software ohne Akzeptanzkriterien?

Wie können Sie gemeinsam Software in einem Team von 4-5 Entwicklern ohne Akzeptanzkriterien entwickeln, ohne zu wissen, worauf die Tester testen werden, und mit mehreren (2-3) Personen, die als Product Owner fungieren?.

Alles, was wir haben, ist eine skizzenhafte 'Spezifikation' mit einigen Screenshots und ein paar Aufzählungspunkten.

Uns wurde gesagt, dass es einfach sein wird, so dass diese Dinge nicht erforderlich sind.

Ich weiß nicht, wie ich vorgehen soll.

Zusätzliche Information

Wir haben eine harte Frist bekommen.

Der Kunde ist intern, wir haben theoretisch einen Product Owner, aber mindestens 3 Personen, die die Software testen, können ein Arbeitselement nicht bestehen, nur weil es nicht so funktioniert, wie sie denken, dass es funktionieren sollte, und es gibt wenig bis keine Transparenz darüber, was sie erwarten oder worauf sie tatsächlich testen, bis es fehlgeschlagen ist.

produktbesitzer sind nicht ohne weiteres verfügbar, um Fragen zu beantworten oder Feedback zu geben. Es gibt keine regelmäßigen geplanten Besprechungen oder Anrufe mit ihnen und Feedback kann Tage dauern.

Ich kann verstehen, dass wir keine perfekte Spezifikation haben können, aber ich dachte, es wäre "normal", Akzeptanzkriterien für die Dinge zu haben, an denen wir tatsächlich in jedem Sprint arbeiten.

68
user1450877

Ein iterativer Prozess wird dies ohne detaillierte Spezifikationen gut erreichen.

Erstellen Sie einfach einen skizzenhaften Prototyp, bitten Sie den Kunden um Feedback, nehmen Sie Änderungen basierend auf dem Feedback vor und wiederholen Sie diesen Vorgang, bis die Anwendung abgeschlossen ist.

Ob der Kunde geduldig genug ist, dies auf diese Weise zu tun, ist eine andere Frage. Einige Kunden und Entwickler bevorzugen diesen Prozess tatsächlich. Da der Kunde immer aktiv ist, bekommt er (irgendwann) genau das, was er will.

Es sollte selbstverständlich sein, dass Sie auf diese Weise keinen Festkosten- oder Zeitvertrag abschließen.

129
Robert Harvey

Wenn das, was Sie sagen, wahr ist und die Spezifikation bei weitem nicht gut genug ist, um überhaupt zu beginnen (und Sie in dieser Einschätzung ehrlich sind), empfehle ich diesen Ansatz:

  1. Lesen Sie die Skizzen und die "skizzenhafte" Spezifikation, die Sie erhalten haben.
  2. Schreiben Sie Ihre eigene Spezifikation auf eine Ebene, die gerade genug ist, damit Sie codieren können. Möglicherweise müssen Sie eine Menge Vermutungen anstellen.
  3. Zeigen Sie dem Kunden Ihre Spezifikation zur Überprüfung. Notieren Sie sich die Teile, die ihnen gefallen, und erhalten Sie weitere Informationen zu den Teilen, bei denen sie glauben, dass Sie etwas falsch gemacht haben.
  4. Wiederholen Sie die Schritte 2 und 3, bis Sie und der Kunde synchron sind.
  5. Sie haben jetzt eine angemessene Spezifikation.

Wenn Ihr Kunde Recht hatte, als er sagte "es wird einfach", dann sollte diese Übung ein Kinderspiel sein.

Wenn sich Ihr Kunde geirrt hat und tatsächlich alle möglichen Probleme und Lücken in den Anforderungen bestehen, wird Ihr Entwurf der Spezifikation das Problem schnell veranschaulichen und ihm mitteilen, dass er sich geirrt hat (ohne dass Sie mit dem Finger zeigen oder argumentieren müssen), da dies der Fall ist Sei direkt vor ihnen und offensichtlich. Außerdem dient Ihre Spezifikation als hervorragendes Diskussionsinstrument zur Lösung dieser Unklarheiten und als Aufzeichnung wichtiger Entscheidungen, wenn Sie sie mit ihrem Feedback überarbeiten.

57
John Wu

Der Produktbesitzer hat Ihnen einen Prototyp übergeben. gib ihm bessere zurück (bis du fertig bist)

Es hört sich so an, als hätten Sie einen Papierprototyp erhalten, um das Projekt zu starten. Das ist kein schrecklicher Anfang. Ich schlage vor, dass Sie in derselben Sprache mit dem Geschäftsinhaber kommunizieren, indem Sie progressiv fähige Prototypen bereitstellen.

Ihre Prototypen sollten mit Papier beginnen, auf digitale Modelle umsteigen und dann mit „echten“ Technologien erstellt werden.

Baumhaus hat einen ausgezeichneten Leitfaden dafür, der abschließt:

Das Wunderbare am Prototyping mit einem Framework ist, dass der Prototyp oft nur zum realen Standort wird, da die Struktur und das Design bereits vorhanden sind. Es ist nicht erforderlich, die Site von Grund auf neu zu erstellen, wenn dasselbe Framework verwendet werden soll.

Möglicherweise möchten Sie auch eine formale Spezifikation bereitstellen, insbesondere wenn Sie weiterhin besorgt sind, für ein schlechtes Ergebnis verantwortlich gemacht zu werden. Aber Sie werden wahrscheinlich mehr Feedback von den Prototypen erhalten.

Halten Sie Ihre Frist ein

Beachten Sie, dass Ihre späteren Bemühungen nicht wie alle klassische "Prototypen" sein werden, da sie nicht wegwerfbar sind (oder Teile davon nicht). Die letzte, leistungsfähigste Iteration, die Sie vor Ablauf der Frist durchführen, wird zu Ihrem Ergebnis.

Ihre Frist ist die am besten definierte Anforderung, die Sie haben. Haben Sie etwas Vollständiges und Kohärentes, das Sie pünktlich liefern können.

Arbeiten Sie mit Ihren Testern zusammen

Wenn dieser lose Prozess für Ihr Unternehmen neu ist, sind Ihre Tester wahrscheinlich noch ratloser als Sie und suchen möglicherweise nach einer Anleitung für Sie. Sie müssen zu Beginn des Prozesses einen Teil ihrer Zeit in Anspruch nehmen. Lassen Sie ihren Chef wissen, dass Sie versuchen, ihm zu helfen, einen aussagekräftigen Test durchzuführen, ohne formelle Akzeptanzkriterien zu erhalten.

Finden Sie heraus, ob die Tester etwas Festes haben, das sie bereitstellen müssen, z. B. eine Testnachweisdokumentation, in die Sie „zurückkehren“ können.

Versuchen Sie Test First Design

Da Sie keine formalen Anforderungen haben, bietet die Entwicklung von Testfällen eine gewisse Struktur.

Machen Sie sich mit Test First Design und/oder testgetriebene Entwicklung vertraut und geben Sie Ihren Testern bei Bedarf Anleitungen zum Prozess. Für ein schnelles Projekt wie dieses müssen Sie kein Experte in diesem Prozess sein. Die Verwendung einer bewährten Methodik wird sich jedoch gut auf Sie und Ihre Tester auswirken.

Halten Sie sich an Standards, insbesondere für die Benutzeroberfläche

Sie haben keine Anforderungen an das Erscheinungsbild, aber Sie haben eine Frist. Verwenden Sie die Entwurfsarbeit eines anderen, um den Arbeitsaufwand für die Erstellung eines professionell aussehenden Artefakts zu minimieren.

Wählen Sie eine Standard-Benutzeroberfläche für Ihre Website und passen Sie sie erst an, wenn Sie dazu aufgefordert werden. Ich weiß nicht, für welche Plattform Sie entwickeln, aber Bootstrap oder Google Material Design sind zwei Beispiele.

Kommunizieren Sie, aber belästigen Sie nicht

Ich würde vorschlagen, täglich eine E-Mail an den Product Owner zu senden. Senden Sie nur dann mehr, wenn es sich um einen Notfall handelt.

Wenn Sie Fragen haben, beschreiben Sie, wie Sie vorgehen, wenn Sie keine Anleitung erhalten. Zum Beispiel:

Müssen die Benutzer dieser App mit mobilen Geräten darauf zugreifen? Im Moment gehen wir davon aus, dass dies ein Desktop/Laptop-System sein wird.

Keine Panik

Ich war an vielen Projekten für Leute beteiligt, die den Begriff "Anforderung" nicht kannten. Die meisten waren erfolgreich. Hands-off-Produktbesitzer geben Ihnen den Spielraum, großartige Lösungen zu entwickeln.

Beachten Sie, dass einige Projektbesitzer in diesen Projekten nicht zufrieden waren und sich hinter der Entschuldigung "Ich bin zu beschäftigt, um ..." für ihre Inkompetenz versteckten. Die meisten waren jedoch von den Endergebnissen „begeistert“.

18
Tim Grant

Ein Projekt ist der Vorgang der Verringerung der Unsicherheit, bis die Gewissheit erreicht ist:

  • Am Anfang herrscht immer ein gewisses Maß an Unsicherheit. Manchmal ist es ein wenig mehrdeutig in den Anforderungen. Manchmal sind es sehr lückenhafte. Sie müssen im Rahmen des Jobs trainieren.
  • Der Trick besteht darin, diese Unsicherheit iterativ zu reduzieren (Analyse, Design und Implementierung zu kombinieren), User Stories zu verfeinern und Ihr System zu implementieren.
  • Testfälle/-szenarien und Akzeptanzkriterien müssen auf die gleiche Weise geklärt werden. Sie tragen unter anderem dazu bei, die Unsicherheit über Qualität und Korrektheit zu verringern.
  • Am Ende ist eine ausreichende Sicherheit erreicht: Der Kunde erhält ein getestetes Produkt, das seinen Bedürfnissen entspricht und verwendet werden kann.

Das ist das Prinzip der fortschreitenden Ausarbeitung: Die Anforderungen, Kriterien und Ergebnisse werden Schritt für Schritt ausgearbeitet, ebenso wie das Verständnis des Kunden für seine eigenen Erwartungen und Anforderungen durch seine Beteiligung am Entwicklungsprozess.

Ist das ein Problem?

Je skizzenhafter die anfänglichen Anforderungen sind, desto höher ist die Unsicherheit und desto höher ist die für die Ausführung der Aufgaben erforderliche Zeit. Es geht also nur darum, wer die zusätzliche Arbeit erledigt und wer die Kosten übernimmt.

Die Antwort auf diese beiden Fragen sollte im Vertrag enthalten sein. Oder wird Gegenstand einer Verhandlung sein. Und der Kunde muss eine zusätzliche Beteiligung akzeptieren (das Hauptargument wird "Müll rein, Müll raus" sein, obwohl ich Ihnen dringend raten würde, es diplomatischer zu präsentieren ;-))

10
Christophe

" Es gibt keine regulären geplanten Besprechungen ". Nun, warum nicht planen Sie zunächst regelmäßige Besprechungen dann? Die Tatsache allein, dass Sie mehrere Produktbesitzer haben, garantiert, dass Ihr Projekt NICHT einfach wird, da jede dieser Personen widersprüchliche Anforderungen hat, die mit allen anwesenden Stakeholdern persönlich besprochen werden MÜSSEN.

Außerdem empfehle ich Ihnen wirklich, wirklich, wirklich führen Sie ein detailliertes Entscheidungsprotokoll. Zumindest schreiben Sie alles auf, was jemand entschieden hat, mit dem Datum und einer Liste der Personen, die anwesend waren, als die Entscheidung getroffen wurde. Noch besser, wenn Sie aufschreiben können, WARUM etwas so entschieden wurde, wie es war. Es spielt keine Rolle, ob es sich um eine Datei auf Ihrem PC, eine Seite in Ihrem Intranet-Wiki oder ein Notizbuch auf Ihrem Schreibtisch handelt. Das Protokoll schützt Sie und das Projekt: Wenn ein Tester sagt, dass ein Element "fehlschlägt", können Sie darauf hinweisen, dass dies bei diesen Personen so entschieden wurde, und es ist nicht Ihr Problem, sondern zwischen ihnen und den Testern. Wenn dies dazu führt, dass die Spezifikationen geändert werden, ist dies in Ordnung, aber zu diesem Zeitpunkt können sie nicht damit rechnen, eine von ihnen vorgesehene Frist einzuhalten - oder sie müssen den Umfang an einer anderen Stelle einschränken.

8
ZeroOne

Ein Projekt ohne klare Anforderungen, lose Führung, keine Definition von erledigt (DoD), niemand, der bereit ist, dafür verantwortlich zu sein, dass Sie über die Informationen verfügen, die Sie benötigen, um Ihre Arbeit rechtzeitig zu erledigen und sich zu treffen Ihre Frist ist ein Rezept für einen Projektfehler.

Die iterative Entwicklung ist kein schlechter Vorschlag, erfordert jedoch eine enge Zusammenarbeit zwischen den Produktbesitzern und den Entwicklern. Versuchen Sie, jemanden auf den Haken zu bringen, indem Sie sagen: "Wir wissen, dass wir Fragen haben werden. Wer kann regelmäßig verfügbar sein, um sicherzustellen, dass diese beantwortet werden, damit die Projektabwicklung nicht verzögert wird?" Planen Sie regelmäßige Zeiten mit jemandem, um den Fortschritt zu überprüfen und Hindernisse zu beseitigen. Wenn sie nicht angezeigt werden oder sich weigern, führen Sie eine höfliche schriftliche Korrespondenz durch und dokumentieren Sie Verzögerungen oder Nichtantworten. Wenn die Produktbesitzer nicht verfügbar sind, bitten Sie sie, einen Vertreter zur Verfügung zu stellen.

Ein weiteres Kennzeichen der iterativen Entwicklung ist, dass eine Änderung der Anforderungen eine Änderung der Zeitachse erforderlich macht. Sie können sich nicht dazu verpflichten, eine Frist einzuhalten, wenn Sie dies tun Sie können keine Zeitleiste entwickeln, und Sie können keine Zeitleiste entwickeln, wenn Sie keine gute Vorstellung davon haben, was zu tun ist. Anstatt dogmatisch nach einer Spezifikation zu fragen, überprüfen Sie die aktuelle Spezifikation, dokumentieren Sie alle Fragen, die Sie oder das Team bezüglich der Funktionsweise haben, planen Sie Zeit mit den Produktbesitzern, um diese zu besprechen, und dokumentieren Sie die Antworten. Wenn Sie fertig sind, haben Sie Ihre Spezifikationen basierend auf ihren Entscheidungen, denen Sie dann die Produktbesitzer (schriftlich) zustimmen lassen können. Der Zweck einer Spezifikation besteht darin, Mehrdeutigkeiten zu beseitigen und ein DoD zu erstellen, genau das, was eine Q & A-Sitzung bieten könnte. Wenn es Widerspruch zu einer Spezifikation gibt, nennen Sie sie keine Spezifikation.

Glauben Sie niemandem, wenn er Ihnen sagt , dass es einfach sein wird . Manchmal ist es wirklich so einfach, wie es sich anhört, und ich könnte das glauben wenn (und nur wenn) Ich kenne die Produktbesitzer gut genug, um voll und ganz darauf zu vertrauen, dass die Anforderungen wirklich sind so einfach wie sie sagen, und die Spezifikationen, die mir zur Verfügung gestellt wurden, sind selbsterklärend (wenn nicht, plane ich eine Q & A-Sitzung und dokumentiere sie). Ich war in zu vielen Situationen, in denen einfach aus betrieblicher Sicht unglaublich schwierig ist vom Standpunkt der Entwicklung aus, oder Sie denken, Sie sind völlig fertig und Sie hören die Worte der Verzweiflung ("Oh, übrigens, wir haben vergessen ..."). Beispiel ... "Alles, was Sie tun müssen, ist, diese PDF - Dateien aus einem Dokumenten-Repository zu lesen", was sich beim Abnahmetest in "Oh, wir haben vergessen, dass einige davon gelesen wurden in völlig inkonsistenter Weise seitwärts, und einige haben die falsche Seitengröße definiert, und einige müssen diese drei Seiten anhängen, und wir müssen sie alle gleich anzeigen. Das ist wirklich einfach zu beheben, oder? ".

Der Punkt ist, es könnte wirklich einfach sein, und eine schnelle Besprechung könnte dies bestätigen, sodass Sie alle Annahmen dokumentieren und die Bestätigung erhalten können, dass sie korrekt und korrekt sind. Ich empfehle, aufzustehen, um Hindernisse zu beseitigen, die Sie beim Schreiben von Arbeitscode haben müssen, der ihren Erwartungen entspricht, denn unabhängig davon, ob Sie auf die Zehen treten, wird am Ende wahrscheinlich sowieso jemand unglücklich sein. Wenn Sie hartnäckig Fragen beantworten und jemanden irritieren möchten, wird er dies vergessen, wenn Sie ein großartiges Produkt pünktlich liefern, das den Anforderungen entspricht. Wenn Sie keine Klärung erhalten und nicht liefern, wird sich niemand daran erinnern, dass Sie angewiesen wurden, sie nicht zu nerven.

8
DVK

Ohne Spezifikation haben Sie Teamwork. Gehen Sie agil.

Setzen Sie sich mit der PO zusammen und konkretisieren Sie eine/mehrere kleine Startgeschichten. "Wir werden nur diesen Bildschirm liefern, mit nur diesem Knopf, der 'bing!' Entscheiden Sie sich für einige ACs. Liefern Sie die Geschichte. Demonstrieren die Geschichte. Es stellt sich heraus, dass die Tasten rot sein sollten. Erhöhen Sie einen Fehler oder eine neue Geschichte. Liefern Sie die Knöpfe, die Bong und Bang gehen. Und so weiter.

Geben Sie gemeinsam kleine vertikale Schnitte an und liefern Sie sie, die häufig demonstriert werden.

Wenn der Kunde auf diese Weise nicht mit Ihnen zusammenarbeitet, suchen Sie nach einem Ausweg.

3