Cheeky Bird Structures: Entwicklungsfluss

    Wenn Sie die Struktur Ihrer Organisation, Abteilung oder Arbeit im Allgemeinen nicht beschreiben können, dann tun Sie dies ineffizient.

    Effizienz und Transparenz sind nie dasselbe. Sie können auf transparente Weise unwirksame und undurchsichtige Dinge tun.

    Der Aufbau einer Arbeitsstruktur ist ein komplexer, individueller Prozess mit einem Hauch von Kühnheit. Denn wir brauchen nicht nur Mut und Überlegung („wir arbeiten ineffizient, warum?“), Sondern auch die Fähigkeit, anmutige Pfähle 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 Ebenen", aber in der Tat wird eine durchdachte Ebene Ihre Arbeit auf ein neues Niveau heben. Dies ist ein Haufen, aber es ist elegant. So etwas wie Abhängigkeitsinjektion oder Verwendung von Photoshop anstelle von Farbe.

    Wenn Sie jetzt dachten "nein, bei uns ist alles effektiv" - hoffen Sie nicht einmal. Ineffektiv. Auch wenn Sie absolut nie in Ihrer Arbeit hängen 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 - um zu unterstützen. Nicht weil "sie es sagten", sondern weil es allen gut gehen wird - alle werden so arbeiten, wie sie sich wohl fühlen und effektiv sein.

    Kurz gesagt, wir nennen unsere Idee von anmutigen Haufen „den frechen Vogel der Strukturen“ oder „Entwicklungsfluss“. Jetzt werden wir ihn beschreiben, und wir werden auch ein paar Ihrer Hunde in Streitigkeiten 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, mit dem das System erstellt wird .

    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 welchem ​​Stadium Ihres Private-Flow Sie sich gerade befinden (z. B. "Features entwickeln") und nicht wissen, in welchem ​​Stadium Sie sich im General-Flow befinden (z. B. im vierten nach Product Owner, Scrum-Master und Designer) , und welche Phase sollte nach Ihnen verlaufen, was sind seine Rückgabekriterien und viele andere kleine Dinge ...

    Oder wenn Sie wissen, aber für Ihre Arbeit mit Ihnen, sollte der Projektmanager neben Ihnen sitzen und Sie daran erinnern, was genau Sie tun sollten (reißen Sie sich nicht vom Monitor weg und beobachten Sie sofort Programme) ...

    Oder wenn Sie nur das Gefühl haben, ineffektiv zu sein,

    dann haben Sie höchstwahrscheinlich kein System.

    Das System funktioniert nicht richtig.

    Nicht alles Gold, das glänzt. Nicht alle V12 sind unter der Haube. Und das Wichtigste: Nicht jeder Motor funktioniert auch auf Reisen einwandfrei (Hallo, geliebte Autoindustrie).

    Es ist wichtig, ein funktionierendes System zu haben, denn es ist unser Vertrauen. In seiner Arbeit, in der Arbeit des gesamten Systems. Sie werden sofort Probleme finden, von denen die meisten Sie 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örung, Klopfen. Es zerstört den Motor langsam oder schnell, und die "Business-Maschine" bricht gerade zusammen, als Sie eine Dollar-Hypothek auf einen Drei-Rubel-Schein im Ring aufgenommen haben.

    Im System der Arbeit der Menschen sind diese Geräusche - Terminüberschreitung, Unzufriedenheit, Personalabbau, schwache Tonlage der Mitarbeiter, Probleme für die nächste Abteilung - und vieles mehr. Ein guter Manager geht mit weit verbreiteten sensorischen Lokalisatoren anstelle von Ohren durch das Büro. Er kennt den bevorstehenden Sturm, er spürt, dass der Druck nachgelassen hat. Er hört alle kurzen Seufzer und bemerkt seine zurückgezogenen Augen. Er ist das System.

    Entwicklungsablauf: System


    Das DF-System besteht aus zwei Abschnitten: Allgemeiner Ablauf (Funktionsweise des gesamten Systems) und Privater Ablauf (Funktionsweise der einzelnen Teile).

    Gesamtdurchfluss


    Das System besteht aus Elementen, die in einer Struktur zusammengefasst sind, um das angestrebte Ziel zu erreichen.
    Das Ziel in der IT ist es, das Produkt zur richtigen Zeit und in der richtigen Qualität auf den Markt zu bringen. Elemente des Systems sind am Prozess beteiligt: ​​Product Owner, Projektmanager, Scrum Master, Entwickler, Designer, Tester, Technical Writer ... Dies sind alles Elemente, und nicht alle sind ständig vorhanden. Manchmal kommen die Rollen zusammen. 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 gemeinsamer Fluss bezeichnet.

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

    Die Aufgabe besteht darin, die Elemente zu einer Struktur zusammenzufassen 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 Rollen notwendig. Der Eigentümer sollte nicht mit dem Designer oder Entwickler interagieren. Nur Scrum Master. Nur. Scrum Master.

    Wenn wir die Wechselwirkungen, diese Pfeile, hervorheben, müssen wir zeigen, was der Erste gibt und dass der Zweite es als Rückmeldung zurückgibt. So beginnt das System zu leben.

    Besitzer → gibt eine Beschreibung der Aufgabe → SM Die

    SM formuliert sie sowohl für den Besitzer als auch für den Rest neu. Die Bewertung der Aufgabe - ungefähre - wird sich ausrichten. Aber die Aufgabe von SM - von einer einfachen Beschreibung, die einen anmutigen Haufen anwendet, um SUFFICIENT_DESCRIPTION zu machen. Er wird Teile davon mit dem Team besprechen und verteilen.

    SM → gibt Teile von DO → 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. In der Regel ist der Designer dem Entwickler einen Sprint voraus.

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

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

    Der Entwickler gibt den Code, der Tester schaut sich seinen Teil der Software an und erfüllt seinen Flow. Das Feedback des Testers ist für SM → „positiv“, das heißt, 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 Common Flow wie folgt richtig formuliert ist. Der erste gibt an den zweiten zurück, der zweite verarbeitet, gibt "positive" oder "negative" Rückmeldung zurück, geht im allgemeinen Ablauf weiter. Positives Feedback ist der Glaube, dass alles wie beabsichtigt funktioniert. negatives feedback - zeigt wo und was schief gelaufen ist.

    Privatfluss


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

    Der Besitzer


    Das Hauptziel
    Die Erklärung des Problems (Backlog ← Beschreibung), lesen Sie das Feedback

    Was kommt als nächstes
    Wenn die Aufgaben vom Eigentümer formuliert werden, beschreibt der CM sie → führt zu einer ausreichenden_Beschreibung.

    Das Feedback des
    SM schreibt die Aufgabe neu und bespricht mit dem Eigentümer schnell die wichtigsten Meilensteine, einschließlich des Zeitrahmens.

    Interagiert mit dem
    CM

    CM

    Der Hauptzweck
    nehmen Problem, bringen es in den Blick Dostatochnogo_Opisaniya, um Aufgaben zu bewerten, verteilen, lesen Feedback

    Was als nächstes
    zuteilen Aufgaben an Mitarbeiter

    Rückmeldungen von den
    Designern, Entwicklern, Testern, Tehpisatel

    interagiert mit dem
    Besitzer, Designer, Entwickler, Tester, Tehpisatel

    Entwickler


    Das Hauptziel ist die
    Entwicklung von Funktionen und Fehlerkorrekturen. In General Flow erhält er Aufgaben von SM und setzt diese mit Hilfe seiner beruflichen Tätigkeit um (Git-Flow, Rebase-Flow, Feature-Flow usw.).

    Was kommt als nächstes?
    Er kann Änderungsvorschläge machen und diese mit SM und dem Designer besprechen.

    Feedback vom
    SM, Designer, Tester

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

    (In dieser Beschreibung gefällt mir die Schaltung nicht wirklich, dies ist meine Präsentation mit einer anderen Beschreibung, und ich arbeite gerne damit. Aber ich erkunde Optionen, versuche, verfeinere und dann ist es passiert.)

    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 in erster Näherung nur ein Teil. Wir brauchen mehr als jeden Fall. Deshalb bitte 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 ein wenig einzugrenzen. Aus diesem Grund könnte mir etwas fehlen, aber ich werde es schnell korrigieren, schreiben.)

    Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte komm rein .

    Nnado?

    • 0% Wir haben alles 0
    • 0% Niemand braucht 0
    • 0% Es ist für alle notwendig, aber niemand wird 0 verwenden
    • 33,3% Ich brauche 1
    • 66,6% Wir brauchen 2
    • 0% Niemand braucht, aber jeder wird 0 verwenden

    Jetzt auch beliebt: