Mein Name ist Victor, ich bin Systemanalyst bei Sportmaster. Und heute möchte ich darüber sprechen, Aufgaben zu zerlegen und in die Entwicklung zu übertragen. Jedes Objekt besteht aus Teilen, sei es ein Auto oder ein Softwareprodukt. Und es wird einige Zeit dauern, bis eines dieser Objekte aus seinen Bestandteilen zu einem Ganzen zusammengesetzt ist. Manchmal ist es sogar sehr zeitaufwändig. Vor allem, wenn Sie vorher nicht nur den Hauptteil zerlegt haben, sondern sich entschlossen haben, auf atomarer Ebene dem auf den Grund zu gehen.
Wo liegt die Grenze zwischen einer angemessenen Aufgabenstellung und totalem Chaos? Ich werde ein Beispiel dafür geben, wie wir bei Sportmaster regelmäßig Entwicklungsaufgaben aus der Wirtschaft erhalten.
Wie Sie den obigen Beispielen entnehmen können, hängt die Beschreibung jeder Aufgabe weitgehend von der Vorstellungskraft und dem gesunden Menschenverstand des Kunden ab. Irgendwo ist es mehr, irgendwo ist es weniger, aber Analysten müssen irgendwie damit arbeiten. Manchmal geben sie auch die Grenzen der Funktionalität an und manchmal senden sie einfach ein Thema. Wenn wir eine solche Aufgabe direkt auf die Entwicklung übertragen, erhalten wir am Ende etwas Unverständliches. Was hast du zu tun?
Gehen Sie mit Ihren Füßen zum Kunden und fragen Sie nach allen Anforderungen. Klären Sie, was genau am Ausgang sein soll. Es stimmt, es gibt immer noch Goldkunden, von denen tatsächlich die Mehrheit - sie schreiben alle Anforderungen in ihren Confluence, sodass Sie ihn jederzeit lesen und Fragen stellen können. Und wenn mit dem Framework der Funktion alles klar ist, können Sie mit dem Schneiden der Aufgabe beginnen.
Warum zersetzen?
Das Hauptziel der Zerlegung besteht darin, dass das Unternehmen alle seine Wünsche schnell umsetzen kann und der Benutzer von der Idee selbst bis zum Erscheinungsbild der Funktionalität so wenig Zeit wie möglich benötigt. Zu diesem Zweck können Sie kleinere Aufgaben ausführen, von denen aus zwar kleine, aber dennoch funktionierende Funktionen den Benutzer erreichen.
Neben der Erreichung des globalen Ziels, Benutzer- und Geschäftsanforderungen zu erfüllen, können Sie durch die Aufgabenzerlegung schnelleres Feedback vom Kunden erhalten, unabhängig davon, ob die Entwicklung in die richtige Richtung geht oder ob sich herausstellt, was der Kunde sich vorgestellt hat.
Wenn die Aufgabe anfangs groß ist und wir sie sofort übernommen haben, werden wir viel Zeit damit verbringen und nach den Kommentaren des Kunden müssen wir alles wegwerfen. Nun, wenn die Aufgabe klein ist, höchstens ein oder zwei Tage Arbeit, ist es okay. Die Nacharbeit wird ungefähr den gleichen Betrag in Anspruch nehmen. Der zweite Ansatz ist auch billiger. Ganz zu schweigen von den geretteten Nerven auf beiden Seiten.
Wenn eine Funktionalität in mehrere Teile aufgeteilt ist, können Entwickler parallel daran arbeiten. Daher werden wir den Fluss parallelisieren und die Ausgabe der Funktionalität in prod beschleunigen. Wichtig ist, dass Aufgaben so wenig wie möglich voneinander abhängen.
Plus schnelle Tests und Fehlerbehebungen. Auch hier ist eine kleine Funktionalität viel einfacher und schneller zu testen als ein monströser Koloss. Und wenn etwas schief geht, wird der Entwickler sehr wenig für das "Reparieren" ausgeben und alles wird schneller funktionieren.
In der Phase der Aufschlüsselung von Aufgaben können Sie gemeinsam mit dem Kunden sofort verstehen, welche Funktionen hier und jetzt wichtig sind, um Gewinne zu erzielen, was für später übrig bleiben kann und was möglicherweise als unnötig herausfällt.
Für Unternehmen ist es wichtig zu wissen, wie schnell die Arbeitsfunktionen angezeigt werden. Und wenn wir in Aufgaben unterteilt sind, können wir die Zeit vorhersagen und genauer abschätzen, die erforderlich ist, um sie zu erledigen, als wenn Sie eine große Arbeitsfront haben. Neben der Tatsache, dass kleine Aufgaben in Bezug auf die Zeit, in der sie ausgeführt werden, einfacher zu bewerten sind, ist es für den Entwickler auch einfacher, die Risiken zu bewerten, die während des Arbeitsprozesses auftreten können.
Beispielsweise wurden Frameworks aktualisiert, einige Methoden außer Betrieb genommen, Probleme mit dem Code usw. Wenn wir kleine Aufgaben in die Arbeit aufnehmen, minimieren wir all diese Risiken, und selbst wenn eine solche Aufgabe etwas im Fluss blockiert, ist sie nicht so kritisch wie ein schweres Stück (das alles blockieren würde). Bei Bedarf wird es möglich sein, eine funktionierende Lösung zu finden und eine technische Verschuldung in den Rückstand aufzunehmen, die etwas später behoben werden kann, wenn die Probleme gelöst sind.
Grundlegende Ansätze und Zerlegungsregeln
Es gibt zwei Hauptansätze für die Aufgabenzerlegung - horizontal und vertikal. Bei horizontal werden Aufgaben nach Art der Arbeit, nach Ebene oder nach Komponente unterteilt. Zum Beispiel hat jede Aufgabe mehrere Phasen: Frontend, Backend, Datenbanken. Bei einem horizontalen Ansatz geht eine Aufgabe nach hinten, die zweite nach vorne und die dritte führt zu Änderungen in der Datenbank.
Warum ist dieser Ansatz schlecht? Nach Erhalt jeder einzelnen Aufgabe erhalten wir keine Arbeitsfunktionalität. Nur wenn wir die Ergebnisse aus drei Quellen sammeln, können wir eine Art Ergebnis und Feedback dazu erhalten. Aus diesem Grund wird eine horizontale Zerlegung meist nicht verwendet.
Viel praktischer ist der vertikale Ansatz, bei dem visuelle Funktionen für jede Aufgabe erstellt werden können - die Aufgabe durchläuft alle Phasen und die Ausgabe ist ein Ergebnis, das analysiert, getestet, dem Kunden gezeigt und gegebenenfalls korrigiert werden kann. Und schnell starten und verwenden.
Wenn wir über die Regeln sprechen, habe ich hier nur drei identifiziert. Erstens muss die Aufgabe logisch abgeschlossen sein, dh an sich unabhängig. Es sollte die Logik um sich herum nicht brechen und muss zumindest einen gewissen geschäftlichen Sinn haben, den der Benutzer als Ergebnis erhält. Gleichzeitig sollten Sie Aufgaben, die keinen geschäftlichen Sinn haben, nicht in Teile zerlegen (im Idealfall sollten sie überhaupt nicht existieren).
Zweitens sollte das Ergebnis einer kleinen Aufgabe kleine Änderungen bringen. Je kleiner die Änderungen sind, desto schneller gelangen sie in den allgemeinen Code, sodass der Code nicht veraltet ist. Darüber hinaus helfen kleine Aufgaben, Konflikte zwischen Entwicklern beim Zusammenführen zu vermeiden.
Drittens sollten Sie die Aufgabe nicht in sehr mikroskopische Teile zerlegen. Wenn die Aufteilung zu klein ist, dauert die Verwaltung dieser Aufgaben sehr lange. In jeder Phase müssen sie möglicherweise neu priorisiert und Abhängigkeiten neu festgelegt werden, und das ist alles. Somit wird die Entwicklungsgeschwindigkeit nicht zunehmen, sondern im Gegenteil stark abnehmen. Daher müssen Sie nach einem Mittelweg suchen.
Zersetzungsmethoden
Je nach Quelle variiert die Anzahl der Zerlegungsmethoden stark: Irgendwo werden nur acht, irgendwo zehn, irgendwo zwanzig angegeben. Ich möchte mich auf die Möglichkeiten konzentrieren, die ich jeden Tag bei der Arbeit anwenden muss.
Mehrere Bedürfnisse
Diese Methode ist am bequemsten anzuwenden, wenn die Story Konjunktionen „und“, „oder“ enthält. Zum Beispiel möchte ein Verbraucher eine Bestellung aufgeben und mit einer Karte oder einem Bonus bezahlen. Diese Aufgabe kann in drei Aufgaben unterteilt werden: die erste, bei der der Benutzer eine Bestellung aufgibt, die zweite, bei der er mit seiner Karte bezahlt, und die dritte, bei der Boni verwendet werden.
Nutzungsszenarien
Eine andere übliche Methode besteht darin, Aufgaben je nach Anwendungsfall aufzuteilen. In diesem Fall ist eine Geschichte ein Hauptpfad und mehrere alternative. Angenommen, ein Benutzer möchte einen Artikel kaufen, und das wäre das Hauptszenario. Es gibt jedoch noch alternative Möglichkeiten: Er kann das Produkt sofort in den Warenkorb legen und bezahlen, oder er möchte dieses Produkt vor dem Kauf mit anderen vergleichen. Und dann machen wir den Produktvergleich zu einer separaten Aufgabe.
Vielleicht möchte er jetzt nicht kaufen, sondern es irgendwo aufschieben, zu Favoriten hinzufügen, damit er später darauf zurückkommen kann. Oder der Benutzer mochte das Produkt und ist bereit, es zu kaufen, aber es ist nicht vorrätig. Sie müssen ihn also wissen lassen, wann die Ware erscheinen wird. Und so erhalten wir vier Szenarien.
Von einfach bis komplex
Die Hauptseite der "Sportmaster" -Seite besteht aus Bannern. Und das Einfachste, was wir tun können, ist, ein Bild aufzunehmen und es dem Benutzer zu zeigen. Dies ist der einfachste und schnellste Weg, um die richtigen Informationen zu vermitteln. Dann können wir die Funktionalität erhöhen und nicht ein Bild hinzufügen, sondern drei oder vier, die zu einem Raster zusammengefasst werden. Dies ist eine separate Aufgabe.
Mit diesem Ansatz sollte mit jeder nachfolgenden Aufgabe die Funktionalität erweitert werden. Zum Beispiel können wir aus dem Raster ein Karussell machen und dann einige Links, Texte, Schaltflächen und den Rest hinzufügen. Im Allgemeinen implementieren wir zuerst die einfachste und leistungsstärkste Version und gehen dann zu einer komplexeren über.
Erst kürzlich hatte ich eine ähnliche Aufgabe, ein Banner zu implementieren. Das Banner sollte am Hauptbanner hängen und vom CMS aus gesteuert werden. Wenn Sie einen Kunden fragen, was genau er verwalten möchte, wird er ohne zu blinken gerne antworten - alle. Daher war es hier wichtig, ein wenig in das Thema einzutauchen und hervorzuheben, was gerade verwaltet werden muss, was nur oft vorkommt und was fast nie verwendet wird. Und damit die Implementierung priorisieren und in Aufgaben aufteilen.
Operationen (CRUD)
Dies ist wahrscheinlich die häufigste Art der Zersetzung. Hier sind die Aufgaben in Vorgänge zum Erstellen, Lesen, Aktualisieren und Löschen unterteilt. Es eignet sich für Aufgaben, bei denen Sie etwas verwalten oder konfigurieren müssen. Zum Beispiel ist die Aufgabe, eine Bestellung aufzugeben, in vier kleinere unterteilt: Erstellen einer Bestellung, Anzeigen, Bearbeiten und Löschen.
Schnittstellenoptionen
Wird verwendet, wenn mehrere Schnittstellenoptionen unterstützt werden müssen. Beispielsweise muss eine Site mehrere Sprachen unterstützen. Zuerst machen wir die russische Version. Wenn wir dann in anderen Ländern starten, fügen wir Englisch hinzu. Wenn das Land eine andere Sprache als Englisch verwendet, können wir dies ebenfalls hinzufügen. In diesem Fall ist es einfacher, alles zuerst in einer Sprache zu erledigen und dann schrittweise Übersetzungen hinzuzufügen.
In jüngerer Zeit haben wir ein Projekt für ein persönliches Konto für juristische Personen abgeschlossen, das mehrsprachige Unterstützung benötigte. Die Fristen waren eng, so dass sie zunächst alles in einer Sprache erledigten, aber den Grundstein für die weitere Übersetzung legten. Das Hinzufügen von Unterstützung für eine neue Sprache erfordert nur noch eine kleine Aufgabe. Wenn Sie mehrere Sprachen gleichzeitig hinzufügen müssen, wird für jede eine eigene Aufgabe erstellt.
Trennung nach Rolle
Geeignet für Situationen, in denen die Funktionalität den Betrieb mehrerer Rollen und Benutzergruppen impliziert. Auf der Sportmaster-Website kann ein Benutzer verschiedene Rollen haben. Beispielsweise werden Benutzer nach Rollen in einen autorisierten Benutzer, einen anonymen Benutzer und beispielsweise einen Callcenter-Benutzer unterteilt. Die letztere Rolle kann auch in zwei Teile unterteilt werden - es kann sich entweder um einen normalen Benutzer oder um einen Administrator handeln.
Für jede Rolle können wir eine separate Aufgabe erstellen. Beginnen Sie mit der Anzeige für einen anonymen Benutzer und fügen Sie dann einige erweiterte Funktionen als Teil einer Aufgabe für einen autorisierten Benutzer hinzu. Und vergessen Sie nicht die technischen Rollen der Call Center-Betreiber und deren Funktionalität.
Fehlerverarbeitung
Wenn die Fristen knapp sind und die Mindestfunktionalität so schnell wie möglich benötigt wird, können Sie die Fehlerbehandlung in eine separate Aufgabe übernehmen. Hier geht es nicht um das Schreiben von Tests, sondern um den Umgang mit Fehlern von Benutzern und Systemen, in die die Site integriert ist. Stellen Sie sich vor, wir verarbeiten eine Katalogseite, die eine Produktkachel enthält. Jede Karte enthält eine Beschreibung, ein Foto und zusätzliche Informationen.
Es kam vor, dass einige der Informationen nicht aus den Datenbanken stammen.
Wenn es sich um eine Marke oder ein Material handelt, kann dies möglicherweise vernachlässigt und einfach nicht angezeigt werden. Aber wenn der Preis oder Name nicht bekannt ist, lohnt es sich, diese Karte vorzuzeigen?
Was tun in einer solchen Situation? Diese Frage kann in einer separaten Aufgabe herausgenommen und dann jedes einzelne Feld verarbeitet werden. Das heißt, wenn der Preis nicht gekommen ist, führen wir eine Aktion durch, die Beschreibung des Produkts geht verloren - eine andere. Dies gilt auch für Benutzerfehler. Wenn er etwas falsch eingegeben hat und ein Fehler angezeigt wurde, z. B. "Seite nicht gefunden" oder Fehler 500, müssen wir ihm spezifische Informationen darüber anzeigen, was passiert ist, und ihm ein Skript anbieten, was er als Nächstes tun kann.
Diese Methode eignet sich auch für Situationen, in denen Sie schnell Feedback zur Funktionalität erhalten müssen, um zu entscheiden, ob Sie sie beibehalten möchten oder nicht.
Statisch dann dynamisch
Dies ist eine meiner Lieblingsmethoden. Geeignet in Situationen, in denen es möglich ist, Funktionen "auf Stubs" zu implementieren, dh externe Systeme sind nicht bereit, die Funktionen zu unterstützen. Beispielsweise können einige Blöcke auf der Hauptseite nicht vom CMS aus gesteuert werden. Oder ein Menü, wenn wir es in unseren Code aufnehmen und dem Benutzer anzeigen, es aber gleichzeitig nicht vom Unternehmen gesteuert werden kann. Und um Änderungen vorzunehmen, muss das Unternehmen ständig zur Entwicklung gehen und darum bitten.
Hier priorisieren wir Benutzeranforderungen und Gewinn. Der Benutzer erhält sofort vorgefertigte Funktionen, auch wenn im Inneren einige Unannehmlichkeiten auftreten können. Daher teilen wir die Aufgabe in mehrere auf und stellen den neuen Block zunächst dem Benutzer zur Verfügung, aber das Unternehmen kann ihn noch nicht direkt verwalten. Aber dann können wir uns in ein System oder eine Datenbank integrieren, in der das Unternehmen selbst Elemente austauschen und neue hinzufügen kann, und wir werden sie ohne Entwicklungsbeteiligung zeichnen.
Wir verwenden häufig diese Methode: Zuerst erstellen wir Funktionen für unsere eigenen Daten, die nicht von außen gesteuert werden können, und fügen dann Dynamik hinzu und beginnen, Daten von Systemen von Drittanbietern zu empfangen.
Performance
Wenn die Aufgabe insgesamt komplex und umfangreich ist und nicht klar ist, von welchem Ende aus sie angegangen werden soll, kann die Leistung vernachlässigt werden. Die erste Aufgabe besteht darin, die vorgefertigte Funktionalität herauszubringen, die zwar langsam, aber irgendwie funktioniert hat. Und die nächste Aufgabe ist es, die Arbeit zu beschleunigen. Zum Beispiel kann es eine langsame Arbeit sein, nach Waren zu suchen, Filter anzuwenden, Informationen zu erhalten.
Manchmal wird der größte Teil des Aufwands in die schnelle Erstellung einer Funktion investiert - die anfängliche Implementierung ist nicht so schwierig. Sie können jedoch viel aus der langsamen Implementierung lernen und sie hat einen gewissen Wert für den Benutzer, der sonst keine wichtigen Aktionen ausführen könnte. In all diesen Fällen werden Aufgaben in „Lass es funktioniert“ und „Mach es schnell“ unterteilt.
Mögliche Schwierigkeiten
Wenn Sie sich für die Verwendung der Aufgabenzerlegung in Ihren Projekten entscheiden, besteht die erste Schwierigkeit wahrscheinlich in der Abhängigkeit der Aufgaben voneinander. Nach meiner Erfahrung ist dies das häufigste Problem beim Blockieren von Threads. Um dies zu vermeiden, sollte die Zersetzung verantwortungsbewusst angegangen und ausreichend Zeit eingeräumt werden.
Eine weitere Schwierigkeit besteht darin, festzustellen, wie fein Sie die Aufgabe zerlegen müssen. Und hier wirkt nur der gesunde Menschenverstand als Grenze. Zum Beispiel nehmen wir die Stadtauswahlkomponente. Es hat Schaltflächen, Text, ein Eingabefeld. Wie klein solltest du diese Aufgabe bestehen?
Wir haben für uns selbst die Regel abgeleitet, dass die Aufgabe über den gesamten Ablauf in nicht mehr als einer Woche (ca. 40 Stunden) erfolgen soll. Wir sprechen über alle Phasen: die Phase der Analyse, Entwicklung, Prüfung. Außerdem werden zwei Phasen der Backend- und Frontend-Entwicklung berücksichtigt, einschließlich Überprüfung und Test.
Wir hatten auch ein Problem damit, dass die Grenzen des Epos nicht immer klar sind. Kürzlich wurde uns die Aufgabe übertragen, eine Bestellung aufzugeben. Wo sind ihre Grenzen? Was soll die Ausgabe sein? Es war uns nicht klar, ob wir alle Funktionen bis zum Ende ausführen oder einen Teil auswählen mussten. Beinhaltet dieses Epos die Zahlung oder ist es bereits ein separates Epos?
Es gibt Aufgaben, die schwer zu verstehen sind, wie und wann sie zu zerlegen sind. Wir zerlegen die meisten Aufgaben in der Phase des Empfangs des Epos, aber es gibt Situationen, in denen dies erledigt werden muss, beispielsweise in der Phase der Analyse. Wir übernehmen die Aufgabe zu arbeiten und glauben, dass alle erforderlichen Daten bereits in unseren Integrationssystemen vorhanden sind. Während der Analyse stellt sich jedoch heraus, dass wir entweder mit dem Datenformat nicht zufrieden sind oder dass das Problem in der Qualität der Daten selbst liegt oder dass Verbesserungen bei anderen Systemen erforderlich sind, mit denen wir sind verbunden. Dann müssen wir die Aufgabe "auf Stubs" ausführen und dem Backlog ein weiteres Element hinzufügen, das wir starten, nachdem wir die Hauptprobleme gelöst haben.
Das scheint alles zu sein. Es ist großartig, wenn Sie in den Kommentaren Geschichten darüber teilen, welchen Ansatz zur Aufgabenzerlegung Sie verwenden und warum.
Danke fürs Lesen!