Wie entwickelt man Software ohne Akzeptanzkriterien?

70

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.

user1450877
quelle
33
Ich würde sagen, entwickeln Sie es, wie Sie wollen. Solange Sie sich wohl fühlen, in ein Meeting zu gehen und zu demonstrieren, wie Ihr Produkt mit der skizzenhaften "Spezifikation" und den Screenshots übereinstimmt, sind Sie in Ordnung. Natürlich können Sie jederzeit den Ersteller der Spezifikation nach weiteren Details fragen ...
FrustratedWithFormsDesigner
10
Grundsätzlich handelt es sich hierbei um eine Eigenentwicklung oder "Cowboy Coding". Entwickler geben die Details ein. Entwickler haben die Mehrheitskontrolle. Grundsätzlich werden Sie nie formale Anforderungen haben. Entwickeln, Demo für Stackholder, Feedback einholen, spülen und wiederholen.
Jon Raynor
11
Ist dem Produktbesitzer klar, dass dies eine hervorragende Möglichkeit ist, Kosten und Zeit immer weiter zu erhöhen? Nicht-Informatiker verstehen häufig nicht die Bedeutung gut geschriebener klarer Spezifikationen. Beispielsweise stößt die US-Regierung häufig auf ähnliche Probleme, wenn sie die Erwartungen an neue militärische Hardware ändert. Dies ist einer von mehreren Gründen, warum militärische Hardware häufig überfordert und hinter dem Zeitplan zurückliegt. joelonsoftware.com/2000/10/02/…
nickalh
35
"Uns wurde gesagt, dass es einfach sein wird, so dass diese Dinge nicht erforderlich sind. ... Wir haben eine harte Frist erhalten. ... 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. " Sie haben mein Mitgefühl. Dies sind Kennzeichen von "Keine Ahnung, wie das Schreiben von Software funktioniert. Überhaupt."
jpmc26
13
Sie wurden für einen Fehler eingerichtet. Dies ist die Art von Dingen, die zum Management eskaliert werden müssen. Wenn Sie die harte Frist nicht hatten, könnten Sie iterieren, bis Sie erfolgreich waren. Wenn die Stakeholder für Feedback verfügbar wären, könnten Sie schnell genug iterieren, um (möglicherweise) die Frist einzuhalten. Das Gleiche gilt für eine einigermaßen detaillierte Spezifikation. Aber etwas muss geben . Dies ist der Teil, in dem Sie Ihren Chef sehr nett bitten, Ihr @ $$ aus dem Feuer zu ziehen.
Jared Smith

Antworten:

130

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.

Robert Harvey
quelle
114
Man sollte hinzufügen: "Stellen Sie einfach sicher, dass Sie pro Stunde bezahlt werden" und nicht "nur bezahlt, wenn dem Kunden die Ideen ausgehen, was fehlt".
Doc Brown
22
Stellen Sie auch sicher, dass Sie dokumentieren, was der Kunde denkt, damit es zumindest in Notizen festgehalten wird. Es kann sein, dass es keine formalen Annahmekriterien sind, aber es ist von großer Relevanz, wenn Sie versuchen, die nächsten Schritte tatsächlich
durchzuführen
4
@ Doc Brown: OP bearbeitet, um hinzuzufügen "Der Kunde ist intern" - so ist die stundenweise Zahlung hoffentlich kein Problem.
sleske
8
+1 Ich habe diesen Prozess für viele interne Projekte verfolgt und festgestellt, dass er sehr gut funktioniert und außerdem insgesamt Zeit spart. Ein Tipp ist, die Iterationen kurz zu halten: ein oder zwei Wochen.
Bob Tway
13
Ich habe die Erfahrung gemacht, dass dies gut funktioniert, wenn der Grund für das Fehlen formaler Annahmekriterien darin besteht, dass noch niemand weiß, was er wirklich will. Prototypen helfen ihnen dabei, Meinungen zu bilden, und Sie akzeptieren, dass Sie eine große unsichere Aufgabe zu bewältigen haben. Aber es funktioniert ziemlich schlecht, wenn die Stakeholder keine Zeit finden, über das nachzudenken, zu sprechen oder zu schreiben, was sie wollen, oder wenn Stakeholder widersprüchliche Anforderungen haben, die sie aus politischen Gründen nicht ausdrücklich äußern können. Dann tritt ein Prototyp nur die Dose die Straße hinunter, und nichts verbessert sich, bis Sie einen kräftigen Stock finden.
Steve Jessop
58

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.

John Wu
quelle
27
Manchmal können Sie den Kunden täuschen, indem Sie Ihre Spezifikation als "Arbeitszeitplan" bezeichnen (den die Gehirne von Nicht-Programmierern als eine freundliche und nützliche Sache für ein Projekt akzeptieren), anstatt als "Spezifikation" (was im Fall von Kunden der Fall ist) wie diese, die allen Grundprinzipien des Engagements im Entwicklungsprozess feindlich gegenüberstehen, empfinden ihre Nicht-Programmierer-Gehirne als langwierigen, umständlichen Papierkram, den Programmierer sie ohne triftigen Grund erledigen lassen.
Steve Jessop
Beim zweiten Punkt würde ich vorschlagen, dass Sie nur die technischen Spezifikationen für den Entwickler schreiben. Andernfalls kann der Entwickler nicht mit seiner Arbeit beginnen. Auf diese Weise können Sie parallel mit dem Geschäftsteam über die Art der zu entwickelnden Arbeit zusammenarbeiten. Auf diese Weise werden sowohl die Entwicklung als auch das Geschäftsteam auf die Anforderungen abgestimmt.
Karan
3
your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious- Ich möchte darauf hinweisen, dass Kunden, denen klar ist, wie offensichtlich dies alles ist, genau die Kunden sind, mit denen Sie niemals dieses Problem haben werden. Oder, um es kurz zu machen: Die Lösung impliziert das Nichtvorhandensein des Problems (ein Paradoxon, das ich in allen Bereichen des Lebens immer öfter erkenne) ...
Radu Murzea
1
Es gibt einige Leute, die es nie "bekommen", aber meiner Erfahrung nach hilft es oft, ihnen ein Beispiel für die Detailgenauigkeit zu zeigen, die Sie benötigen, und ihnen die Art von "falschen" Entscheidungen zu zeigen, die Sie treffen können, wenn die Anforderungen erfüllt sind mehrdeutig.
John Wu
18

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“.

Tim Grant
quelle
Der einzige Punkt, der nicht erwähnt wird, ist die harte Frist: Es wird wichtig sein, dass etwas an diesem Datum geliefert wird und dass es funktioniert (durchläuft die Bewegungen), auch wenn die Glocken, Pfeifen und schnelleren Streifen fehlen. Mit dieser Einschränkung sollten alle anderen Punkte, die @Tim macht, in Ordnung sein
Philip Oakley
@PhilipOakley, danke für das Feedback. Ich fügte hinzu, dass der iterative Prototyping-Prozess zunehmend akzeptable "Leistungen" erbringen sollte, um Terminüberschreitungen zu vermeiden. Lassen Sie mich wissen, ob das hilft.
Tim Grant
Das ist eine Verbesserung. Vielleicht ändern Sie sogar "Meeting" in "Meet", um die Notwendigkeit zu erhöhen. Fügen Sie dann vielleicht auch die Aussage hinzu, dass, wenn sie ein Datum ohne die anderen Sachen angegeben haben, dies die Schlüsselanforderung wird, so dass die folgende 'Anmerkung' Kontext hat. (Oft sind Kunden nur um Zeit und Kosten besorgt, der Rest ist Kosmetik und Mode, wie Sie sicher wissen ;-)
Philip Oakley
10

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 ;-))

Christophe
quelle
1
Ich liebe den ersten Satz. Das Bücherstück dazu ist, dass der Kunde: 1) nicht sicher ist, was er will, 2) seine Meinung ändert, 3) etwas Unerreichbares will. Aber wenn es sich tatsächlich um ein einfaches Projekt handelt, dann hat es gute Erfolgschancen.
1
Dieser ist Gold.
Bruno Guardia
8

" 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.

Null eins
quelle
8

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.

DVK
quelle
3

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.

Grimm der Opiner
quelle
-1

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.

Robert Baron
quelle
-2

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.

gnasher729
quelle
6
"Sie benötigen eine ausführliche, überprüfbare Spezifikation, bevor Sie mit dem Schreiben von Code beginnen können. Das ist eine Tatsache, und es gibt keine Umgehung." Meine Kollegen und ich haben dies bei vielen Projekten getan, und wir hatten viele Erfolge und nur sehr wenige Misserfolge. Ihr Anspruch ist nicht absolut.
Whatsisname
1
@whatsisname vereinbart. Ich habe auch Code auf diese Weise geschrieben. Dies geschieht, wenn die Aufgabe einen explorativen Aspekt aufweist. Jetzt hat das Codieren ohne Spezifikation einige Nachteile, aber manchmal sind sie akzeptabler, als zu sagen, dass Sie ein Ziel nicht erreichen können.
Cort Ammon
1
@whatsisname, die Formulierung könnte verbessert werden, aber die grundlegende Wahrheit ist, dass Sie eine Anfrage nicht erfüllen können, ohne zu verstehen, was es ist. Wenn ich nur sage: "Schreiben Sie mir ein Programm in Java", ist es für Sie unmöglich , dieses Programm zu schreiben. Sie können sich eine Vorstellung davon machen, was das Programm tun soll - mit anderen Worten, Sie können Ihr eigenes Ziel erfinden und es dann erreichen -, aber es ist eine reine Unmöglichkeit , ein Ziel zu erreichen , das von niemandem, einschließlich Ihnen, angegeben wurde. Dies gilt für alle Anfragen, egal ob groß oder klein. Die Bedürfnisse und Wünsche müssen verstanden werden, bevor Sie sie tun, produzieren und / oder präsentieren können.
Wildcard
Das heißt ... der Detaillierungsgrad, den eine Anfrage tatsächlich benötigt, um verstanden und erfüllt zu werden, kann drastisch überschätzt werden. Es kann auch sein , unter geschätzt. Die einzige Lösung dafür ist die Kommunikation.
Wildcard
@Wildcard: Ja, ich denke, die Formulierung könnte gut angenommen werden. Was Sie sagen wollen, erinnert an das Paradoxon von Zeno, ist aber weniger überzeugend.
Whatsisname