Ich habe es bemerkt. Die Zusammenarbeit mit einem Kunden ist einer Webanwendung sehr ähnlich. Der Artikel zeigt, wie Sie dieses Wissen nutzen können, um Prozesse zu verbessern.
Über wer ist der Controller und wer ist das Modell unter dem Schnitt.
In diesem Artikel wird davon ausgegangen, dass der Leser weiß, was MVC ist .
Beim Erstellen eines Modells gehe ich zu bewussten Vereinfachungen.
- Alle Teilnehmer an der Beziehung sind verantwortungsbewusste Personen und möchten ein einziges Ergebnis erzielen.
- Betrachten Sie eine typische benutzerdefinierte Entwicklung.
Schauspieler
Kunde - eine Person, die ein Produkt oder Projekt bestellt. Es kann sowohl extern als auch intern sein.
Unternehmen (Auftragnehmer) - Partei des Vertragsverhältnisses mit dem Kunden.
Manager - eine Person, die mit dem Kunden und dem endgültigen Ausführenden (Programmierer) interagiert. Es akzeptiert Aufgaben vom Kunden als Eingabe, übersetzt diese Aufgaben an den Auftragnehmer und gibt das Ergebnis an den Kunden zurück.
Der ultimative Executor ist ein Programmierer, der die Aufgabe implementiert. Im Idealfall kommuniziert nur mit dem Manager.
Der Prozess
Der benutzerdefinierte Entwicklungsprozess sieht ungefähr so aus:
- Der Kunde legt die Aufgabe für das Unternehmen fest.
- Das Unternehmen, das als Router fungiert, bringt die Aufgabe zum Manager.
- Der Manager klärt die Details mit dem Kunden.
- Der Manager legt die Aufgabe für den Programmierer fest.
- Der Programmierer führt die Aufgabe aus und überträgt die erledigte Aufgabe.
- Der Manager erkennt Mängel und kehrt zu Schritt 4 zurück.
- Liegen keine Mängel vor, überträgt der Manager die Aufgabe an den Kunden.
- Der Kunde erkennt Mängel und kehrt zu Absatz 3 zurück.
- Liegen keine Mängel vor, so bezahlt der Kunde die Arbeit.
Der süßeste Punkt für das Unternehmen ist Absatz 9. Der Weg dorthin ist jedoch normalerweise lang und dornig.
Problem eines solchen Prozesses
Auf den ersten Blick ist alles in diesem Prozess korrekt und es gibt nichts zu verbessern. Dies ist jedoch nicht so. Wir heben die Probleme hervor.
Ein sehr schlechter Manager ist nur ein Task-Router. Ich hoffe, dass Sie Glück haben und nicht mit solchen arbeiten Manager Router. Ich hatte Glück. Bei der Arbeit mit einem echten Manager gibt es auch Probleme.
Der Manager stellt dem Programmierer die Aufgabe, indem er sie mit seiner Stimme oder in einem Chatroom spricht. Klarstellungen zum Problem werden nirgendwo aufgezeichnet. Der Programmierer schien die Aussage des Problems zu verstehen. Aber natürlich habe ich es auf meine eigene Weise verstanden und nicht so, wie es der Manager erklärt hat (aus Sicht des Managers). Da die Erklärung des Problems nicht festgelegt ist, interpretiert jeder Teilnehmer sie auf seine eigene Weise.
Bei diesem Ansatz erscheinen viele Iterationen 4-6 und 3-8. Ein guter Manager unterscheidet sich von einem schlechten Manager durch das Verhältnis zwischen der Anzahl dieser Iterationen. Ein guter Manager hat eine Einheitszahl von Versuchen, eine Aufgabe an einen Kunden zu übergeben. Und der Versuch war sofort erfolgreich. Gleichzeitig können Iterationen mit dem Programmierer viel Arbeit bedeuten. Der Router überprüft nichts für den Programmierer und leitet die Aufgabe einfach an den Kunden weiter. Die Anzahl der Iterationen 3-8 erreicht ihre Maximalwerte und entspricht der Anzahl der Iterationen 4-6. Und natürlich ist der Programmierer für alles verantwortlich, weil er aus Sicht des Managers einen schlechten Job gemacht hat.
Eine große Anzahl von Kommunikationen zwischen dem Manager und dem Programmierer während des Übergebens der Aufgabe führt zu einer Zunahme des Negativs zwischen ihnen. Darüber hinaus werden die Fristen für die Erledigung der Aufgabe, Kostenüberschreitungen usw. unterbrochen. Gleichzeitig macht mir die Kommunikation während der Spezifikation der Anforderungen und in der Phase der Aufgabenstellung nichts aus.
Was tun, um solche unerwünschten Phänomene zu vermeiden?
Verbände
Schauen wir uns ein vereinfachtes Schema für die Zusammenarbeit mit dem Kunden an:
Ein erfahrener Entwickler wird eine vollständige Übereinstimmung mit MVC sehen:
Es ist sehr einfach, einen Vergleich von Entitäten durchzuführen.
- Kunde = Benutzer
- Manager = Controller
- Künstler = Model
- Arbeitsergebnis = Ansicht
- Firma = Gesamte Bewerbung
Nur ein Zufall? Ich glaube nicht. Wenn die Interaktionsschemata übereinstimmen, können Sie versuchen, die in der Entwicklung verwendeten Ansätze auf den Prozess der Verwaltung der benutzerdefinierten Entwicklung anzuwenden.
Erste Schritte zu beheben
Welche Tools haben wir bei der Entwicklung?
Wir definieren Anwendungsebenen. Wir definieren die Interaktionsverträge zwischen den Ebenen und teilen die Anwendung in Module auf. Versuchen wir, diese Tools hier anzuwenden.
Ebenen
Der Programmierer in seiner üblichen Rolle kommuniziert nicht mit dem Kunden. Er kann als Experte in die Phase der Spezifikation der Anforderungen einbezogen werden. In anderen Fällen kommuniziert nur der Manager mit dem Kunden, wodurch die Modellschicht von den direkten Auswirkungen des Kunden isoliert wird.
Bei der Übergabe der Aufgabe an den Kunden sollte der Programmierer, der die Aufgabe ausgeführt hat, nicht einbezogen werden. Niemals. Niemals überhaupt.
Zersetzung
Große Aufgaben müssen in kleine unterteilt werden. Eine kleine Aufgabe ist eine Aufgabe für maximal ein paar Tage.
TK
Jeder kennt den Ausdruck: Ohne eine klare TK - das Ergebnis von HZ.
Bei der Klärung der Anforderungen sollte beim Kunden ein Artefakt wie die Leistungsbeschreibung entstehen. Dann die Erklärung des Problems an den Programmierer angereichert ergänzt durch TK. Im Moment akzeptieren wir dies als Vertrag nicht nur zwischen dem Unternehmen und dem Kunden, sondern auch zwischen dem Manager und dem Programmierer.
In jedem normalen Unternehmen ist TK ein unverzichtbares Element der Aufgabe. Dies gilt zwar nur für große Aufgaben.
Es scheint, dass TK im Rahmen der Programmierung einem Vertrag ziemlich ähnlich ist. Was ich Probleme mit TK sehe:
- Für eine große Aufgabe gibt es TK mit Seiten von 400 oder mehr, die der Programmierer nicht vollständig in seinen Kopf passt. Ich fange an, auf Seite zehn einzuschlafen.
- Für eine durchschnittliche Aufgabe gibt es einen Link zu einem Abschnitt oder Absatz im ToR. Dann liest der Programmierer nur diesen Punkt. Dann stellt sich natürlich heraus, dass ein kleiner Punkt in einem anderen Abschnitt des TOR die gesamte Implementierung drastisch verändert
- Für eine kleine Aufgabe, die Teil des Supports ist, wird TK überhaupt nicht sein.
- TK wird von den Parteien des Entwicklungsprozesses nicht immer klar interpretiert. Und alles, was missverstanden werden kann, wird genau falsch und missverstanden sein.
Hier ist zu sehen, dass TK eindeutig nicht ausreicht. Die Frage ist, was zu tun ist?
Akzeptanzkriterien
In der Entwicklungspraxis nimmt das Testen einen hohen Stellenwert ein. Tests haben gezeigt, dass eine Qualitätsentwicklung erforderlich ist.
Können wir Tests in unserer Praxis anwenden? Ja, und so testen wir alles und selbst in der Beschreibung des Prozesses wird ein aufmerksamer Leser sagen. Ja, aber nein. Ich spreche ein wenig über andere Tests.
Das Testen in dem oben beschriebenen Prozess besteht darin, die Übereinstimmung des Ergebnisses mit der gelieferten TK manuell zu überprüfen. Jeder Teilnehmer solcher Tests, der sich mit TK vertraut gemacht hat, interpretiert es irgendwie in seinem eigenen Bild. Das Problem ist, dass jeder ein anderes Bild hat. Der Mensch ist ein unvollkommener Dolmetscher. Sie müssen die TK einmal in die Binärdatei kompilieren. Interpretieren Sie nicht oft und auf unterschiedliche Weise. Und einmal auf dem "Papier". Infolgedessen sollte eine bestimmte Reihe von Artefakten angezeigt werden. Dies können Testfälle oder Akzeptanzkriterien sein.
Akzeptanzkriterien sollten vom Manager zusammen mit dem Kunden entwickelt werden. Akzeptanzkriterien widersprechen TK nicht, sondern erklären sie nur. Annahmekriterien können oder sollten sogar ein separates Dokument werden, das vom Kunden und vom Unternehmen unterzeichnet wird. Dann nimmt der Kunde die Aufgabe nach den gleichen Annahmekriterien an.
Mit korrekt formulierten Akzeptanzkriterien kann der Programmierer keine Unstimmigkeiten in der ToR aufweisen und sogar bezweifeln, was genau er tun sollte.
Für eine kleine Aufgabe gibt es möglicherweise keine TK, aber Akzeptanzkriterien müssen vorhanden sein. Die Akzeptanzkriterien ähneln den vor der Implementierung geschriebenen Tests. Erinnert Sie das an irgendetwas?
Um die Akzeptanzkriterien zu beschreiben, können Sie die von BDD angebotene Gurkensprache verwenden. Um den Start zu vereinfachen, können Sie sie in der üblichen russischen Sprache beschreiben.
Einwände
Ich sehe eine Frage von Managern voraus:
Die Entwicklung von Akzeptanzkriterien erfordert zusätzliche Zeit. Wo kann man es bekommen?
Ohne sich die Zeit zu nehmen, Akzeptanzkriterien zu entwickeln, verteilen Sie diese Kosten in allen Phasen. Und sehr viele Menschen verbringen Zeit: Manager, Programmierer, Tester, Kunde.
Sie entwickeln aber immer noch Akzeptanzkriterien. Und mehr als einmal. Bei der Erstellung des ToR ergeben sich einige Akzeptanzkriterien im Kopf des Analysten und des Kunden. Beim Einstellen des Problems passiert dasselbe. Der Programmierer formt sie in seinem Kopf. Zum Zeitpunkt der Übergabe der Aufgabe wird zu jedem Zeitpunkt der gleiche Vorgang ausgeführt. Aber zu keinem Zeitpunkt erschien ein Artefakt. Das ist der ganze Unterschied.
Wenn es Akzeptanzkriterien gibt, wird die Anzahl der Iterationen vor der Annahme der Aufgabe durch den Kunden erheblich reduziert. Die Anzahl der negativen Kommunikationen wird natürlich reduziert. Dementsprechend werden die Beziehungen zum Kunden verbessert, an die das Unternehmen die Aufgabe zum ersten Mal weitergibt.
Ich wage Ihnen zu versichern, dass sich die Entwicklung von Akzeptanzkriterien gut auszahlt.
Ergebnis
Wie ändert sich der Prozess nach der Einführung von Akzeptanzkriterien zusammen mit TK?
Der Programmierer erledigt seine Arbeit gemäß den Akzeptanzkriterien. Der Manager nimmt den Job an. Dann macht der Kunde dasselbe. Und er hat keinen Grund, diese Aufgabe nicht zu bezahlen.
Funktioniert es immer ohne Störungen? Ich denke nicht. Erstens wird es Probleme mit der Entwicklung, Formulierung von Akzeptanzkriterien und deren Vereinbarung mit dem Kunden geben. Dies führt zu wiederholten Iterationen mit dem Programmierer und dem Kunden. Ihre Anzahl wird jedoch minimiert.
Was denkst du darüber?