Saucy Bird Structures: Entwicklungsfluss

Wenn Sie die Struktur Ihrer Organisation, Abteilung und allgemeinen Arbeit an Ihren Fingern nicht beschreiben können, bedeutet dies, dass Sie dies ineffizient tun.

Effizienz und Transparenz sind nie dasselbe. Sie können ineffektive Dinge transparent und undurchsichtige Dinge effektiv tun.

Der Aufbau einer Arbeitsstruktur ist ein komplexer, individueller Prozess mit einem Hauch von Kühnheit. Weil wir nicht nur Mut und Reflexion brauchen („wir arbeiten ineffizient, warum?“), Sondern auch die Fähigkeit, anmutige Haufen zu machen.



Anmutige Haufen sind der Schlüssel zur Schaffung von Strukturen. Es scheint, "wir brauchen nicht, wir arbeiten und in Ordnung, warum brauchen wir zusätzliche Schichten", aber tatsächlich - eine durchdachte Schicht wird Ihre Arbeit auf ein neues Niveau heben. Es ist ein Haufen, aber es ist elegant. So etwas wie Abhängigkeitsinjektion oder die Verwendung von Photoshop anstelle von Farbe.

Wenn Sie jetzt dachten "Nein, bei uns ist alles effektiv" - hoffen Sie nicht einmal. Ineffektiv. Selbst wenn Sie absolut nie vollständig in Ihrer Arbeit stecken bleiben, leben Sie einfach in Illusionen. Es ist unmöglich. Effizienz ist ein verdammter Prozess, keine Selbstverständlichkeit. Und eine bestimmte Person muss diesen Prozess bereitstellen. Und andere - zu unterstützen. Nicht weil "sie es gesagt haben", sondern weil es allen gut gehen wird - alle werden so arbeiten, wie sie sich wohl fühlen und effektiv sind.

Kurz gesagt, wir nennen unsere Idee von anmutigen Haufen „den frechen Vogel der Strukturen“ oder „Entwicklungsfluss“. Jetzt werden wir ihn beschreiben und in Streitfällen auch ein paar Ihrer Hunde essen.

Warum wird es gebraucht?

Development Flow wurde entwickelt, um 4 Verpflichtungen zu erfüllen:

• Prozessstrukturierung
• Lösungen für Probleme
• Gibt Feedback
• Bietet eine universelle Interaktionssprache

Development Flow ist ein Tool zur Systemerstellung .

Das System

Das System besteht aus Elementen, die Elemente sind unterschiedlich und „aktuell“ durchläuft sie - den Arbeitsprozess. In der IT ist „Talk“ der Code, das Design, die Dokumente und andere Dinge, mit denen wir arbeiten und an denen wir arbeiten.

Systeme fehlen

Wenn Sie nicht wissen, in welcher Phase Ihres privaten Ablaufs Sie sich gerade befinden (z. B. „Entwickeln einer Funktion“), und nicht wissen, in welcher Phase Sie sich im allgemeinen Ablauf befinden (z. B. in der vierten Phase nach dem Product Owner, dem Scrum-Assistenten und dem Designer) und welche Die Bühne sollte nach dir gehen, was sind seine Rückkehrkriterien und viele andere kleine Dinge noch ...

Oder wenn Sie es wissen, sollte der Projektmanager für Ihre Arbeit neben Ihnen sitzen und Sie daran erinnern, was genau Sie in dieser Sekunde tun sollten (reißen Sie sich nicht vom Monitor los, unmittelbar nach den Programmen) ...

Oder wenn Sie sich einfach unwirksam fühlen ...

... dann haben Sie höchstwahrscheinlich kein System.

Das System funktioniert nicht richtig

Nicht alles Gold, das glänzt. Nicht alle V12 befinden sich unter der Haube. Und vor allem - nicht jeder Motor funktioniert richtig, auch wenn er unterwegs ist (Hallo, geliebte Autoindustrie).

Es ist wichtig, ein ordnungsgemäß funktionierendes System zu haben, da dies unser Vertrauen ist. In seiner Arbeit, in der Arbeit des gesamten Systems. Sie werden sofort Probleme finden, von denen Sie die meisten lösen können.

Ein laufender Motor hat ein Geräusch. Er ist rhythmisch, angenehm. Wenn es ein Problem gibt, wird es vom empfindlichen Ohr des Masters gehört. Knarren, Niesen, Rhythmusstörungen, Klopfen. Es zerstört den Motor langsam oder schnell und die "Geschäftsmaschine" bricht gerade zusammen, als Sie eine Dollarkredit auf einen Drei-Rubel-Schein im Ring aufgenommen haben.

Im System der Arbeit der Menschen sind diese Geräusche - Fristenverletzung, Unzufriedenheit, Personalleckage, geringer Ton der Mitarbeiter, Probleme für die nächste Abteilung - und vieles mehr. Ein guter Manager geht mit gespreizten, überempfindlichen Ortungsgeräten anstelle von Ohren durch das Büro. Er kennt den bevorstehenden Sturm, er spürt, dass der Druck gesunken ist. Er hört alle kurzen Seufzer und bemerkt seine zurückgezogenen Augen. Er ist das System.

Entwicklungsablauf: System

Das DF-System umfasst zwei Abschnitte: General Flow (Funktionsweise des gesamten Systems) und Private Flow (Funktionsweise seiner einzelnen Teile).

Gesamtdurchfluss

Das System besteht aus Elementen, die in einer Struktur kombiniert sind, um das beabsichtigte Ziel zu erreichen.
Das Ziel in der IT ist es, das Produkt zur richtigen Zeit und in der richtigen Qualität freizugeben. Systemelemente - Teilnehmer am Prozess: Product Owner, Projektmanager, Scrum Master, Entwickler, Designer, Tester, technischer Redakteur ... Dies sind alles Elemente, und nicht alle sind ständig vorhanden. Manchmal werden Rollen kombiniert. Sie müssen Ihre Elemente hervorheben.

Sie müssen Ihre Elemente hervorheben. Schreiben Sie sie auf und zeichnen Sie Ihren ersten Flusspfeil. Dies wird als Common Flow bezeichnet.

Besitzer → SM → Designer, Entwickler → Tester → Technischer Redakteur

Die Aufgabe besteht darin, die Elemente zu einer Struktur zu kombinieren und zu zeigen, welche professionellen Interaktionen möglich sind. Unprofessionell - dass der Designer und der Besitzer des Produkts zusammenleben, ist nicht notwendig. Es sind nur notwendige Rollen. Der Eigentümer sollte nicht mit dem Designer oder Entwickler interagieren. Nur Scrum Master. Nur. Scrum Master.

Wenn wir die Interaktionen, diese Pfeile, hervorheben, müssen wir zeigen, was der Erste gibt und dass der Zweite es als Feedback zurückgibt. Das System beginnt also zu leben.

Besitzer → gibt eine Beschreibung der Aufgabe → SM

SM wird es sowohl für den Eigentümer als auch für den Rest neu formulieren. Die ungefähre Bewertung der Aufgabe richtet sich aus. Aber die Aufgabe von SM - von einer einfachen Beschreibung, die einen anmutigen Haufen anwendet, um SUFFICIENT_DESCRIPTION zu machen. Er wird Teile davon VOR dem Team besprechen und verteilen.

SM → gibt Teile an → Designer und Entwickler

DO enthält ein Schema, alle möglichen Zustände und vieles mehr (ich möchte mich noch nicht stapeln). Jeder bekommt seinen Teil. Nicht immer zur gleichen Zeit. Normalerweise ist der Designer dem Entwickler einen Sprint voraus.

Designer und Entwickler bei einer täglichen Kundgebung als Feedback von SM gibt ihm seine Vision der Aufgabe zurück. Wir stellen sicher, dass wir alles gleich verstehen. Es dauert 25-28 Sekunden. Und das spart Stunden und Wochen.

Entwickler → übergibt nach seinem privaten Ablauf (dazu später mehr) den Code → an den Tester

Der Entwickler gibt den Code, der Tester betrachtet seinen Teil des TO und erfüllt seinen Ablauf. Das Feedback des Testers gilt für SM → „positiv“, dh wie er die Aufgabe versteht, und für den Entwickler → „negativ“ - nur wenn sie fehlerhaft ist.

Der Entwickler hat keine Ahnung, dass sein Code getestet wird, bis es Probleme gibt.

Ich denke, dass General Flow wie folgt richtig formuliert ist. Der erste gibt an den zweiten, der zweite Prozess gibt "positives" oder "negatives" Feedback zurück und geht im allgemeinen Ablauf weiter. Positives Feedback ist der Glaube, dass alles wie beabsichtigt funktioniert; negatives Feedback - zeigt, wo und was schief gelaufen ist.

Privater Fluss

In diesem Artikel werde ich als Beispiel den privaten Fluss von Eigentümer, CM und Entwickler skizzieren. Wenn Sie interessiert sind, werde ich den Rest der Arbeit veröffentlichen.

Der Besitzer

Das Hauptziel
Erklärung des Problems (Rückstand ← Beschreibung), lesen Sie das Feedback

Was weiter
Wenn die Aufgaben vom Eigentümer formuliert werden, beschreibt der SM sie → führt zu einer ausreichenden Beschreibung.

Feedback von
Der SM schreibt die Aufgabe neu und bespricht die wichtigsten Meilensteine ​​schnell mit dem Eigentümer, einschließlich der Zeitrahmen.

Interagiert mit
SM

SM

Das Hauptziel
Akzeptieren Sie die Aufgabe, bringen Sie sie in die Form von Adequate_Description, bewerten Sie die Aufgaben, verteilen Sie sie, lesen Sie das Feedback

Was weiter
Verteilt Aufgaben an Mitarbeiter

Feedback von
Designer, Entwickler, Tester, Tech Writer

Interagiert mit
Inhaber, Designer, Entwickler, Tester, Tech-Autor

Entwickler

Das Hauptziel
Funktionsentwicklung und Fehlerbehebungen. In General Flow erhält er Aufgaben von SM und implementiert diese mithilfe seiner beruflichen Tätigkeit (Git Flow, Rebase Flow, Feature Flow usw.).

Was weiter
Er kann Änderungsvorschläge machen und diese mit SM und dem Designer besprechen.

Feedback von
CM, Designer, Tester

Interagiert mit
SM vom Designer (es ist wichtig - er kann keine Interaktion mit dem Tester erzeugen)

(In dieser Beschreibung gefällt mir das Schema nicht wirklich, dies ist meine Präsentation mit einer anderen Beschreibung, und ich freue mich mehr, damit zu arbeiten. Aber ich erkunde Optionen, versuche, verfeinere und es stellte sich so heraus.)

Im trockenen Rückstand

Development Flow löst die folgenden Probleme:

• Prozessstrukturierung
• Probleme lösen
• Gibt Feedback
• Bietet eine universelle Sprache, über die wir noch kein Wort gesagt haben

Die Hauptvorteile - jeder weiß, was los ist, was zu tun ist und ist nicht mit unnötiger Arbeit belastet.

Scrum Masters haben viel Arbeit (Timlid, CTO). Aber es sollte so sein, er ist der Haupttraktor in diesem Ansatz.

sehr kurze und trockene Präsentation

Bleiben Sie im Dunkeln oder schaffen Sie mutige Strukturen. Wir bieten unseren Vogel an, aber er ist groß und dies ist in erster Näherung nur ein Teil. Wir brauchen mehr als jeden Fall. Deshalb frage ich Sie - hängen Sie alle Hunde an mich, ich möchte ein besseres Thema knacken.

(Ich musste viel schneiden, um die Größe des Artikels zumindest ein wenig zu verringern. Aus diesem Grund könnte ich etwas verpassen, aber ich werde es schnell korrigieren, schreiben.)