Wie entwickelt man Software ohne Akzeptanzkriterien?

Wie entwickelt man gemeinsam Software in einem Team von 4-5 Entwicklern ohne Akzeptanzkriterien, ohne zu wissen, für was die Tester testen und mit mehreren (2-3) Personen, die als Produktbesitzer 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 gegeben.

Der Kunde ist intern, wir haben theoretisch einen Produktbesitzer, aber mindestens 3 Personen, die die Software testen, könnten ein Arbeitselement nicht bestehen, nur weil es nicht so funktioniert, wie sie es für nötig halten, und es gibt wenig oder keine Transparenz darüber, was sie erwarten was sie tatsächlich testen, bis es fehlgeschlagen ist.

Produktbesitzer sind nicht bereit, 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 in jedem Sprint tatsächlich arbeiten.

Ein iterativer Prozess wird dies ohne detaillierte Spezifikationen erreichen.

Erstellen Sie einfach einen skizzenhaften Prototyp, fordern Sie Feedback vom Kunden an, nehmen Sie basierend auf dem Feedback Änderungen vor und wiederholen Sie diesen Vorgang, bis der Antrag abgeschlossen ist.

Ob der Kunde dazu geduldig genug ist, ist eine andere Frage. Einige Kunden und Entwickler bevorzugen diesen Prozess. Da der Kunde immer praktisch ist, wird er (irgendwann) genau das bekommen, was er will.

Es versteht sich von selbst, dass Sie auf diese Weise weder einen Fixkosten- noch einen Fixzeitvertrag abschließen.

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

1. Lesen Sie die Skizzen und die "skizzenhaften" Angaben, die Sie erhalten haben.
2. Schreiben Sie Ihre eigene Spezifikation bis zu einer Stufe, die gerade ausreicht , um Code schreiben zu 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 erfahren Sie mehr über die Teile, bei denen sie der Meinung sind, dass Sie etwas falsch gemacht haben.
4. Wiederholen Sie die Schritte 2 und 3, bis Sie und der Kunde synchronisiert 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 Ihr Kunde sich geirrt hat und es tatsächlich alle möglichen Fallstricke und Lücken in den Anforderungen gibt, wird Ihr Pflichtenheft 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 direkt vor ihnen und offensichtlich sein. Außerdem dient Ihre Spezifikation als hervorragendes Diskussionsinstrument zur Lösung dieser Unklarheiten und als Aufzeichnung der wichtigsten Entscheidungen, wenn Sie sie mit ihrem Feedback überarbeiten.

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 Papier-Prototyp erhalten, um das Projekt zu starten. Das ist kein schrecklicher Anfang. Ich schlage vor, dass Sie dem Geschäftsinhaber in derselben Sprache antworten, indem Sie fortschrittliche Prototypen bereitstellen.

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

Treehouse hat dafür einen hervorragenden Leitfaden, der zu folgendem Schluss kommt:

Das Wunderbare am Prototyping mit einem Framework ist, dass der Prototyp oft nur zur realen Site 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 Bedenken haben, für ein schlechtes Ergebnis verantwortlich gemacht zu werden. Aber Sie werden wahrscheinlich mehr Feedback von den Prototypen bekommen.

Halten Sie Ihre Frist ein

Beachten Sie, dass Ihre späteren Bemühungen nicht wie alle klassischen "Prototypen" sein werden, da sie nicht wegwerfbar sind (oder Teile davon nicht sein werden). Die letzte, leistungsfähigste Iteration, die Sie abschließen, bevor die Frist abgelaufen ist, 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 rechtzeitig liefern können.

Arbeiten Sie mit Ihren Testern zusammen

Wenn dieser lose Prozess eine neue Sache für Ihr Unternehmen ist, sind Ihre Tester wahrscheinlich noch mit einem Verlust , als Sie sind, und zu suchen können Sie für die Führung. Sie müssen etwas von ihrer Zeit in den frühen Prozess bekommen. Lassen Sie ihren Chef wissen, dass Sie versuchen, einen aussagekräftigen Test durchzuführen, ohne formelle Akzeptanzkriterien zu erhalten.

Finden Sie heraus, ob die Tester über eine Firma verfügen, die sie bereitstellen müssen, beispielsweise eine Dokumentation zum Test, auf die Sie zurückgreifen können.

Probieren Sie Test First Design aus

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

Machen Sie sich mit Test First Design und / oder testgetriebener Entwicklung vertraut und geben Sie Ihren Testern bei Bedarf Anleitungen zum Prozess. Für ein schnelles Projekt wie dieses müssen Sie kein Experte für den 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 einer anderen Person, um den Arbeitsaufwand für die Erstellung eines professionell aussehenden Artefakts zu minimieren.

Wählen Sie eine Standardbenutzeroberfläche für Ihre Site 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, aber nicht belästigen

Ich würde vorschlagen, dem Produktbesitzer täglich eine E-Mail zu senden. Senden Sie mehr als das nur, wenn es ein Notfall ist.

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

Müssen die Benutzer dieser App mit Mobilgeräten darauf zugreifen? Im Moment gehen wir davon aus, dass dies nur 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. Eigenständige Produktbesitzer geben Ihnen die Freiheit, großartige Lösungen zu entwickeln.

Beachten Sie, dass einige Projektbesitzer in diesen Projekten unmöglich zufrieden zu stellen 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“.

Ein Projekt ist der Akt der Verringerung der Unsicherheit, bis Gewissheit erreicht ist :

• Am Anfang herrscht immer ein gewisses Maß an Unsicherheit. Manchmal sind die Anforderungen etwas mehrdeutig. Manchmal ist es sehr lückenhaft. Sie müssen als Teil des Jobs trainieren.
• Der Trick besteht darin, diese Unsicherheit iterativ zu reduzieren (Analyse, Design und Implementierung 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 geprüftes Produkt, das seinen Bedürfnissen entspricht und verwendet werden kann.

Das ist das Prinzip der schrittweisen 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 länger dauert die Ausführung der Aufgaben. Es geht also nur darum, wer die zusätzliche Arbeit erledigt und wer die Kosten trägt.

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

" Es gibt keine regelmäßigen geplanten Besprechungen ". Warum planen Sie dann nicht gleich regelmäßige Besprechungen ? 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 , ein detailliertes Entscheidungsprotokoll zu führen . Zumindest notieren Sie alles, 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 "fehlgeschlagen" ist, können Sie darauf hinweisen, dass dies bei diesen Personen so entschieden wurde und es nicht Ihr Problem ist, 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 kürzen.

Ein Projekt ohne klare Anforderungen, lockere Führung, keine Definition von erledigt (DoD), niemand, der bereit ist, dafür verantwortlich zu sein, dass Sie die Informationen haben, die Sie benötigen, um Ihre Arbeit rechtzeitig zu erledigen und ihre Frist einzuhalten, ist ein Rezept für ein Projekt Fehler.

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 zur Verfügung stehen, um sicherzustellen, dass diese beantwortet werden, damit die Projektauslieferung 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, müssen Sie höfliche schriftliche Korrespondenz führen und Verzögerungen oder Nichtbeantwortungen dokumentieren. 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, einen Termin einzuhalten, wenn Sie keinen Zeitplan entwickeln können, und Sie können keinen Zeitplan 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 zur Funktionsweise haben, planen Sie die Zeit mit den Produktbesitzern, um sie zu diskutieren, und dokumentieren Sie die Antworten. Wenn Sie fertig sind, haben Sie Ihre Spezifikationen auf der Grundlage ihrer Entscheidungen, denen Sie die Produktbesitzer schriftlich zustimmen lassen können. Der Zweck einer Spezifikation besteht darin, Mehrdeutigkeiten zu beseitigen und eine DoD zu erstellen, die genau das ist, was eine Q & A-Sitzung bieten könnte. Wenn es einen Widerspruch zu einer Spezifikation gibt, bezeichnen Sie sie nicht als Spezifikation.

Glaube niemandem, wenn er dir 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 die Produktbesitzer gut genug kenne, um voll und ganz darauf zu vertrauen, dass die Anforderungen wirklich so einfach sind, wie sie sagen und die Spezifikationen, die ich hatte Die bereitgestellten Informationen sind selbsterklärend (wenn nicht, plane ich eine Q & A-Sitzung und dokumentiere sie). Ich war in zu vielen Situationen, in denen es aus operativer Sicht unglaublich schwierig ist, einfach zu seinaus entwicklungspolitischer Sicht, oder Sie denken, Sie sind völlig fertig und Sie hören die Worte der Verzweiflung ("Oh, wir haben es übrigens vergessen ..."). Beispiel ... "Alles, was Sie tun müssen, ist, diese PDF-Dateien aus einem Dokumentenspeicher zu lesen", was beim Akzeptanztest zu folgendem Ergebnis führte: "Oh, wir haben vergessen, dass einige davon in völlig inkonsistenter Weise seitwärts gelesen wurden, und Bei einigen ist die falsche Seitengröße definiert, und bei anderen müssen diese drei Seiten angehängt werden, und alle müssen gleich angezeigt werden. Das ist wirklich einfach zu beheben, oder? "

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

Ohne eine Spezifikation haben Sie Teamwork. Gehen Sie agil.

Setzen Sie sich mit der PO zusammen und erarbeiten Sie eine / n kleine (n) Startstory (s). "Wir liefern genau diesen Bildschirm mit genau dieser Schaltfläche, die 'bing!' Geht." Vereinbaren Sie einige ACs. Liefern Sie die Geschichte. Demonstrieren Sie die Geschichte. Es stellt sich heraus, dass die Tasten rot sein sollten. Löse einen Fehler oder eine neue Geschichte aus. Liefere die Knöpfe, die knallen und knallen. Und so weiter.

Spezifizieren und liefern Sie gemeinsam kleine vertikale Schnitte, die häufig demonstriert werden.

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

Ich habe mehrere Jobs mit Projekten verbracht, so wie Sie es beschrieben haben. Solange die PO weiß, welche Designentscheidungen Sie treffen und warum Sie sie treffen müssen, sollte es Ihnen gut gehen. Wenn sie andererseits die Entwurfsentscheidungen nicht verstehen, müssen Sie sie drücken, um mindestens ein schriftliches Benutzerabnahmetestdokument zu erhalten.

Sie benötigen eine detaillierte, überprüfbare Spezifikation, bevor Sie mit dem Schreiben von Code beginnen können. Das ist eine Tatsache, und daran führt kein Weg vorbei.

Wenn niemand sonst bereit ist, diese Spezifikation zu schreiben, müssen die Entwickler sie schreiben. Sie erhalten also eine unvollständige Spezifikation. Sie wandeln es in eine vollständige Spezifikation um (was bedeutet, "das ist, was ich implementieren werde, es sei denn, jemand anderes sagt mir, dass ich es nicht tun soll"). Sie übergeben diese Spezifikation den Stakeholdern und geben ihnen die Möglichkeit, die Spezifikation zu ändern. Nur eine Chance, die Spezifikation zu modifizieren - zum Beispiel durch das Sprichwort "Ich mag es nicht so". An diesem Punkt ist es Ihre Spezifikation, oder sie können eine andere Spezifikation liefern, aber die Spezifikation nicht entfernen.

Es kann eine gute Idee sein, eine kurze Bewertung von Ihren Kollegen zu erhalten, die die Spezifikation verbessern könnten. Aber wie auch immer, Sie haben eine Spezifikation, Sie schreiben den Code entsprechend, die Tester testen entsprechend. Und Sie haben Ihren Job gemacht: Sie hatten eine Spezifikation und haben sie implementiert. Wenn die Spezifikation nicht den Wünschen des Kunden entspricht, liegt dies direkt in der Verantwortung des Produktbesitzers oder des Kunden, der nicht die Mühe hatte, eine gute Spezifikation zu schreiben.