Wie wichtig ist es, die Funktionalität vor dem Codieren zu kennen?

Ich arbeite für eine Softwareentwicklungsfirma, bei der die Entwicklungsarbeit auf uns verlagert wurde. Das On-Shore-Team kümmert sich um den Support und spricht direkt mit den Kunden. Wir sprechen nie direkt mit den Kunden, sondern nur mit Leuten aus dem On-Shore-Team, die direkt mit den Kunden sprechen.

Wenn Anforderungen kommen, spricht das On-Shore-Team mit den Kunden, erstellt Anforderungsdokumente und informiert uns. Wir erstellen Entwurfsunterlagen, nachdem wir die Anforderungen untersucht haben (wir folgen dem traditionellen Wasserfallmodell).

Es gibt jedoch ein Problem im gesamten Prozess: Niemand im Offshore- oder Onshore-Team versteht die Funktionalität der Anwendung vollständig. Wir wissen nur, dass es sich um eine große komplexe Web-App handelt, die komplexe Auftragsabwicklung, Katalogverwaltung, Kampagnenverwaltung und andere Aktivitäten abwickelt. Wir haben Probleme mit dem Designdokument, da die Anforderungen nicht klar wären. Anschließend wird eine Reihe von Fragen / Antworten zwischen dem On-Shore-Team, dem Off-Shore-Team und den Kunden gestellt. Wir werden oft aufgefordert, die Funktionalität anhand des Codes zu verstehen. Dies ist jedoch normalerweise nicht möglich, da die Codebasis sehr groß ist und das Verstehen eines einfachen Menüelements Tage, wenn nicht Wochen dauert. Wir haben versucht, den Kunden zu sagen, dass sie uns Wissenstransfer geben sollenüber die Anwendung, aber ohne Erfolg. Unser Manager hat uns oft angewiesen, mit dem Codieren zu beginnen, selbst wenn das Designdokument nicht vollständig ist oder die Anforderungen nicht klar sind. Wir würden zunächst den Teil der Anforderungen codieren, der klar erscheint, und auf den Rest warten.

Dies würde die Bereitstellung normalerweise um einen Monat verzögern. In extremen Fällen hätten wir sehr geringe Fehler in der Entwicklung und Produktion, aber die Kunden würden sagen, dass dies nicht das ist, was sie gefragt haben. Das würde ein Schuldspiel und eine Reihe von Änderungswünschen auslösen und wir würden am Ende etwas ganz anderes entwickeln.

Meine Frage ist, wie würden Sie Entwicklungsarbeit leisten, wenn Sie die Funktionalität der App nicht vollständig kennen?

AKTUALISIEREN

Die Entwicklungsmethode ist nicht wirklich meine Wahl und ich bin nicht der Leiter meines Teams. So hat es begonnen. Ich habe versucht, den Leuten von den Vorteilen von Agilität zu erzählen, aber ohne Erfolg. Außerdem glaube ich nicht, dass mein Team die notwendige Einstellung hat, um in einer agilen Umgebung zu arbeiten.

Kurzfassung:

Wissen, was zu tun ist ≠ Ihren Kunden kennen.

Stellen Sie sich Folgendes vor: Sie sind ein Unternehmen, das mit der Immobilienentwicklung zu tun hat. Sie bitten Ihren Partner, einen großen Komplex zu bauen. Der Partner sagt, dass er trotz aller Dokumente, die Sie ihm gegeben haben, auch direkt mit den Leuten sprechen muss, die die Wohnungen in diesem Komplex kaufen würden. Ernsthaft?

Lange Version:

Es ist immer schön zu wissen, wie eine bestimmte Anwendung verwendet wird, weil es Spaß macht, Dinge zu lernen, aber bei großen Projekten ist dies nicht immer möglich.

Einige Domänen sind einfach zu komplex. Wenn Sie nur ein Entwickler sind und an mehreren Anwendungen aus mehreren Domänen arbeiten, können Sie einfach nicht immer verstehen, was der Endbenutzer tut , da Sie fünf Jahre lang Buchhaltung lernen müssen, zehn Jahre an der medizinischen Fakultät. sechs Jahre in der juristischen Fakultät usw.

Auf der anderen Seite ist ein Softwareprodukt, das ohne Verständnis der spezifischen Domäne hergestellt wurde, bestenfalls ein bisschen unbrauchbar .

Aus diesem Grund müssen funktionale und nicht funktionale Anforderungen von Personen geschrieben werden, die die Domäne vollständig verstehen. Im Allgemeinen umfasst das Sammeln von Anforderungen gleichzeitig:

1. Techniker (zum Beispiel Entwickler, die sagen würden, dass eine bestimmte Funktion unmöglich ist, dass diese andere viel besser sein kann, wenn sie auf diese Weise ausgeführt wird, und diese kostet Tausende von Dollar, während es eine viel billigere Alternative gibt),

2. Auf Projektmanagement spezialisierte Personen,

3. Personen, die auf die Domäne des Kunden spezialisiert sind und das vollständige Verständnis dieser Domäne und die genauen Bedürfnisse des Kunden haben. Dies kann natürlich der Kunde selbst sein.

Eine funktionale und eine nicht funktionale Anforderung sind geschrieben und präzise genug. Als Person, deren Aufgabe es ist, diese Anforderungen in Code zu übersetzen, benötigen Sie nichts anderes.

In Ihrem speziellen Fall beschreiben Sie die Ursache des Problems selbst:

Wir haben Probleme mit dem Designdokument, da die Anforderungen nicht klar wären.

Es ist nicht der Mangel an Wissen über den Kunden, der alle Probleme verursacht , sondern die geringe Qualität der Anforderungen. In einem korrekt verwalteten Projekt müssen die funktionalen und nicht funktionalen Anforderungen vollkommen klar und eindeutig sein. Wenn das Anforderungsdokument nicht klar ist oder wenn es Ihnen sagt, dass "das visuelle Design des Produkts attraktiv sein muss" oder andere Dummheiten wie diese, liegt es daran, dass es von Leuten geschrieben wurde, die nicht wissen, wie man es schreibt.

Wenn man das weiß, muss man anders handeln:

• Wenn Sie wissen, dass das Team, das die Anforderungen sammelt, verzweifelt ist und Ihr eigenes Team über qualifizierte Mitarbeiter für das Sammeln von Anforderungen verfügt, erklären Sie Ihrem Vorgesetzten die Situation und sagen Sie, dass das andere Team durch eine kompetente Person ersetzt werden muss , z. B. die Mitarbeiter von Ihnen.

• Andernfalls (dh wenn sie nicht verzweifelt sind) versuchen Sie, die interne Ursache für diese geringen Anforderungen zu ermitteln und sie davon zu überzeugen, dass eine korrekte Arbeit nur die Gesamtkosten des Projekts senkt . Es ist hier eine gute Idee, Statistiken darüber zu zeigen, wie schlecht geschriebene Anforderungen das Projekt beeinflusst haben, indem sie die Kosten erhöht haben (wie viel?) Und das Risiko, nicht für die Frist bereit zu sein.

Wahrscheinlich ist das Anforderungsdokument nur unvollständig. Ich sehe das die ganze Zeit: Unerfahrene Projektmanager sind nur davon überzeugt, dass ein einseitiges Dokument ausreicht, und verstehen nicht, warum sie jemals drei- bis vierhundert Seiten anstelle von einer schreiben würden. Wenn dies in Ihrem Unternehmen der Fall ist, zeigen Sie, dass mehr Zeit für Anforderungen die Kosten senken würde.

Sie verwenden genau die falsche Entwicklungsmethode für die Probleme, mit denen Sie konfrontiert sind.

Durch die Verwendung von Waterfall verpflichten Sie sich zu:

1. Die richtigen Anforderungen im Voraus stellen - das funktioniert offensichtlich nicht
2. Codierung der Anforderungen vom Kunden weg - Sie können Probleme mit dem Kunden nicht effektiv prüfen, da Sie sich verpflichtet haben, die Anforderungen zu erfüllen
3. Die erste Chance für den Kunden, seine Funktionalität zu sehen, besteht beim Testen - dies ist angesichts der Probleme, die Sie haben, viel zu spät

Erwägen Sie, wenn möglich, eine andere Art der Projektverwaltung. Agile Software Development verfügt über mehrere Funktionen, mit denen Sie die Probleme lösen können, mit denen Sie konfrontiert sind.

Vor einiger Zeit wurde ein anständiger Vergleich zwischen Waterfall und Agile geschrieben. Lassen Sie uns ein paar Zitate daraus ziehen, die Ihre Probleme hervorheben:

Missing the Mark:

Sobald eine Phase in der Wasserfallmethode abgeschlossen ist, gibt es kein Zurück mehr, da die meisten im Rahmen der Wasserfallmethode entwickelten und implementierten Software je nach Zeit und Benutzeranforderungen nur schwer zu ändern sind. Das Problem kann nur behoben werden, indem ein völlig neues System entworfen wird, eine sehr kostspielige und ineffiziente Methode.

Festgebunden...

Agile Methoden ermöglichen Spezifikationsänderungen gemäß den Anforderungen des Endbenutzers und bedeuten Kundenzufriedenheit. Wie bereits erwähnt, ist dies bei Anwendung der Wasserfallmethode nicht möglich, da Änderungen vorgenommen werden müssen, sodass das Projekt erneut gestartet werden muss.

... und kann sich nicht bewegen

Um den Unterschied zwischen beiden zusammenzufassen, kann man sagen, dass die klassische Wasserfallmethode für Vorhersagbarkeit steht, während die agile Methode Anpassungsfähigkeit bedeutet. Agile Methoden sind gut geeignet, um Gemeinkosten wie Begründung, Begründung, Dokumentation und Besprechungen zu reduzieren und sie so gering wie möglich zu halten. Aus diesem Grund kommen agile Methoden eher kleinen Teams mit sich ständig ändernden Anforderungen zugute als größeren Projekten.

Wo du jetzt bist, ist schlecht; Sie erfüllen nicht die Anforderungen des Kunden, und wenn Sie die Schuld an der Softwareentwicklung tragen, wird die Produktivität aus dem Fenster gehen, das Misstrauen wird steigen und die Dinge werden wahrscheinlich schlechter, nicht besser.

Die Beziehung zum Kunden ist kritisch ; Hier klingt es so, als ob Sie nicht in der Lage sind, ihre Probleme effektiv zu sammeln und sich an die sich ändernden Anforderungen anzupassen, wie Sie gerade arbeiten. Daher müssen Sie nach Möglichkeiten suchen, dies zu ändern.

So funktioniert es nicht, oder? Eines der Themen meiner aktuellen Ausbildung ist die Analyse und die Beziehung zu einem Kunden. Der Schwerpunkt lag immer auf der klaren Definition des Projekts. Stell dir das vor:

• Sie befehlen einer Baufirma, ein Haus zu bauen, wissen aber nicht, wie es aussehen soll. Sie passen einfach den ersten Stock an, damit das Team ein Haus bis zum ersten Stock baut. Dann möchten Sie, dass das Erdgeschoss anders angelegt wird. Hoppla...

Wenn Sie nicht sehr sicher sind, dass Sie (teilweise) die richtigen Grundlagen für die Anwendung schaffen können, würde ich dem Kunden nur sagen, dass es keinen anderen Weg gibt, als mit klar definierten Zielen und Funktionen. Denn wenn Sie nur versuchen, was es sein könnte, riskieren Sie, viel Geld und Zeit in den Abfluss zu werfen.

Hier sind einige Dinge, die helfen, die Probleme zu überwinden:

1. Verbessern Sie die Kommunikation zwischen den beiden Teams. Bitten Sie das andere Team, die Anforderung auf 3 Wörter zu komprimieren, und der Programmierer implementiert diese Wörter genau. Die Wörter müssen nur richtig sein. Ohne diese Worte wird nichts umgesetzt. Jedes Wort gibt Ihnen 2000 Codezeilen. Die Implementierung beginnt, wenn ein neues Wort bekannt ist.
2. Wenn Ihren Programmierern ein Wort nicht sofort klar ist, können sie einzelne Fragen stellen . Die Frage muss wieder richtig sein. Es muss sofort beantwortet werden - die Antwort kann nicht auf eine Rundreise von der anderen Seite der Welt warten, muss aber vorher bekannt sein. Die Implementierung beginnt unmittelbar nach Erhalt der Antwort und die Antwort wird bis zum Brief befolgt.
3. Wenn während der Implementierung unklare oder unscharfe Anforderungen vorliegen, können Sie diese zunächst lösen, indem Sie sich zunächst die (vorhandenen) 3 Wörter ansehen. Wenn es immer noch unklar ist, macht der Programmierer die bestmögliche Vermutung . Jede Verzögerung in diesem Prozess ist absolut verboten; und das andere Team um Hilfe zu bitten, ist nicht der richtige Weg, um es zu lösen - sie hatten bereits die Chance, die Anforderungen zu ändern, indem sie die richtigen 3 Wörter entschieden.
4. Wenn die Anforderung nach all dem immer noch unklar oder unmöglich zu implementieren ist, besteht die richtige Vorgehensweise darin, die drei Wörter , die den Fehler verursacht haben , abzulehnen und mit den nächsten Wörtern fortzufahren. Alle abgelehnten Wörter werden gesammelt und an das andere Team weitergeleitet. Diese müssen geändert werden, bevor sie erneut in das System eingegeben werden können. Das Ablehnen von Wörtern verschiebt immer die Frist und die Implementierung muss erneut geplant werden.
5. Die Teams müssten anhand der Anzahl der abgelehnten Wörter bewertet werden. Nachdem die Anforderung implementiert wurde, ist sie für immer behoben und kann nicht mehr geändert werden . Alle Versuche, bereits implementierte Funktionen zu ändern, werden abgelehnt.
6. Das eigentliche Problem mit der Frage ist, dass davon ausgegangen wird, dass mehr Informationen die Implementierung erleichtern. Das ist nicht wahr. Je mehr Freiheit Ihre Programmierer haben, desto einfacher ist die Implementierung . Durch die Komprimierung der Anforderungen können große Informationsmengen kommuniziert werden, ohne dass die Programmierer zu stark eingeschränkt werden dürfen.