Geekly articles weekly

Methodik als Konstruktor: Montageanleitung

Vom modernen LEGO Designer kann nur ein Spielzeugmodell zusammengebaut werden, beispielsweise ein Flugzeug. Anpassen? Sie können Pilotensitze tauschen - das ist alles Anpassung. Vor ungefähr 30 Jahren war es vom Designer möglich, fast alles, vom Flugzeug bis zum LKW, mit der gleichen Anzahl von Teilen wie bei modernen zusammenzubauen. Die Schöpfer der modernsten Methoden in der Kindheit spielten das alte Lego. Diejenigen, die jetzt Methoden verwenden, haben bereits in der Moderne gespielt. Der Unterschied in der Konstruktionspraxis ist enorm.



Im Rahmen des Schnitts wird Philip Delgado ( dph ) über den technischen Ansatz zur Bildung einer Methodik sprechen. Alle Projekte und Teams sind unterschiedlich und Führungskräfte sind einzigartig. Fit eine Methode für alle wird nicht funktionieren - es gibt einfach keine. Wir müssen einen Designer nehmen und daraus etwas Einzigartiges bauen. Bei der Entschlüsselung eines der besten TeamLead Conf- Berichte gibt es keine geheimen Geheimnisse der Shaolin-Mönche - nur Banalitäten, die durch Erfahrung bestätigt wurden. Wir warten auf einen Katalog mit Details zur Entwicklungsmethodik, worauf beim Entwerfen und Implementieren zu achten ist, sowie auf die Regeln für die Neuerstellung von Methoden. Für alle Ideen werden reale Beispiele aus der Erfahrung von Philip gegeben. Während seiner Karriere versuchte er alles von Visual Basic bis Hardcore SQL, entwickelte die größte Buchmacher-Engine in Russland und Yandex.Money und arbeitet jetzt an geladenen Java-Projekten. Sie hält regelmäßig Präsentationen auf verschiedenen Konferenzen, darunter HighLoad ++.



Herausforderung


Vor einigen Jahren kam ich erneut zu einem Projekt, um ein Zahlungssystem von Grund auf neu zu erstellen. Zu Beginn des Projekts gab es nichts: keine Entwickler, keine Prozesse, keine Produktionen. Wo soll ich anfangen zu arbeiten, wenn es nichts gibt? Etwas sofort einzuführen ist seltsam und sogar dumm. Daher besteht der erste Schritt darin, zu verstehen, was von der Technik tatsächlich benötigt wird.

Kent Beck schrieb am Ende seines Buches über SCRUM:

Alle Methoden basieren auf Angst. Sie versuchen, Ihre Gewohnheiten zu entwickeln, um zu verhindern, dass Ihre Ängste Wirklichkeit werden.

Daher ist das erste, was zu tun ist , aus dem Geschäft herauszufinden, wovor es Angst hat .

Normalerweise hat das Unternehmen Angst vor dem gesamten Projekt: Es ist beängstigend, zu lange oder gar nicht zu tun . Technologisch hat er Angst um Zuverlässigkeit und Sicherheit . In unserem Fall sind diese Befürchtungen berechtigt: Das Zahlungssystem besteht aus Gegenparteien, Geld und ernsthaften Verpflichtungen.

Unterschiedliche Ängste führen zu unterschiedlichen Methoden. Die Angst vor Überzahlung führt dazu, dass billige Entwickler eingestellt werden, die leicht zu ändern sind - es ist SCRUM. Die Angst vor Fehlern führt zu GOSTs oder RUPs mit einer Reihe formalisierter Dokumente.

Entwickler haben auch ihre eigenen Befürchtungen: nicht unterstützt zu schreiben oder schlecht zu machen . Leider entwickelt fast niemand Methoden aus Angst vor Entwicklern. Nur XP erwähnt kurz, dass Entwickler Angst haben, schlecht abzuschneiden. Versuchen wir, ihnen zu helfen, ihre Arbeit gut zu machen.

Neben Ängsten hat das Unternehmen auch Wünsche , um Prozesse zu optimieren:

  • schnell
  • billig;
  • vorhersehbar;
  • auf kontrollierte Weise;
  • qualitativ;
  • skalierbar
  • HYIPOVO.

Wählen Sie eine Option, und vielleicht, vielleicht, eines Tages, wahrscheinlich, wenn nichts passiert und der Mars im Steinbock mit dem Mond konvergiert, werden Sie Erfolg haben. Die meisten Optimierungswünsche beziehen sich auch auf Angst, aber in einem anderen Wortlaut: billig - über Angst vor Überzahlung, kontrolliert - über Angst, tu es nicht, vorhersehbar - über Angst gibt es keine Zeit.

Normalerweise will ein Unternehmen alles auf einmal . Halten Sie sich beim Sammeln von Anforderungen an die Voraussetzung "Der Patient lügt immer". Wenn ein Unternehmen alles will, lügt er. Versuchen Sie zu verstehen, was das Unternehmen wirklich will, und versuchen Sie, es ihm zu verkaufen. Dies ist nicht die Standardkompetenz eines Teamleiters. Wenn Sie jedoch nicht wissen, wie Sie die tatsächlichen Anforderungen eines Unternehmens ermitteln können, müssen Sie eine Person finden, die dies kann.

Zusätzlich zu den Wünschen des Unternehmens müssen Sie die wesentlichen Einschränkungen herausfinden.

  • Enge Fristen . In meinem Fall gab es keine feste Frist, zum Beispiel die Olympischen Spiele, bei denen es nur zwei Möglichkeiten gibt: entweder pünktlich zu sein oder nicht.
  • Strenger Vertrag . Wenn Sie mit einem staatlichen Unternehmen zusammenarbeiten, darf der Vertrag nicht verletzt werden. Alles andere kann nach Ihren Wünschen durchgeführt werden. Dies wirkt sich stark auf die Technik aus.
  • Regelmäßiger Versand . Sie müssen ständig neue Funktionen einführen, dies ist wichtig für das Geschäft.
  • Zertifizierung: CB, PCI DSS . Dies ist die Haupteinschränkung des Entwurfs des Zahlungssystems. Die größten Risiken und Bedenken betreffen die Zertifizierung von Wertpapieren, PCI DSS und anderen.

Es sind die wesentlichen Einschränkungen, die beispielsweise FixPrice-Prozesse von Zeit- und Materialprozessen unterscheiden.

Wie sich herausstellte, war es in unserem Projekt des Zahlungssystems beängstigend, zu lange zu arbeiten und keine Angst zu haben, beängstigend für Zuverlässigkeit und Sicherheit, aber es ist ratsam, alles schnell zu erledigen. Gleichzeitig gibt es zu Beginn der Arbeit keine Produktionen, keine Entwickler, aber Spezialisten auf dem Gebiet (zum Beispiel ich). Nur große und völlig voneinander unabhängige Blöcke sind klar: Verarbeitung, Kunden, Integrationen, Backoffice und Frontoffice.

Nachdem Sie die Ziele und Einschränkungen herausgefunden haben, können Sie mit der Erstellung einer Methodik beginnen, um genau zu verstehen, wie wir das gewünschte System entwickeln werden - zumindest in der ersten Phase.

Wir entwickeln eine Methodik zum Starten eines Projekts


Aber was ist eine Technik? Was wollen wir generell bauen? Die Antwort auf die Fragen ist ein wunderschönes Bild von Alistair Cowber mit einer Reihe von Punkten.



Aus diesem Bild heraus sind uns drei Dinge wichtig: Menschen - diejenigen, die es tun; Prozesse - wie sie funktionieren; und Artefakte - was getan werden muss. Wir haben noch keine Mitarbeiter und Prozesse, daher werden wir herausfinden, welche Artefakte wir benötigen.

Das Beginnen mit Artefakten ist ein gutes Muster beim Entwerfen einer Technik , auch wenn bereits Personen und Prozesse vorhanden sind. Es ist ratsam, mit der Gestaltung von Artefakten „vom Ende“ mit dem gelieferten Wert der Artefakte zu beginnen, die beim Verkauf ausgelegt oder an den Kunden gesendet werden. Warum ist es so besser - eine separate Frage für einen separaten Artikel. Wenn Sie die Antwort kennen - schreiben Sie in die Kommentare.

Artefakte auswählen


Wir nehmen Ängste und verstehen, welche Artefakte welche Ängste schließen.

Die Angst, „zu lange an einem Projekt zu arbeiten“, wird durch einen langfristigen Plan und einen Meilenstein beseitigt . Aus Angst um Zuverlässigkeit - Autotests . Aus Angst vor "Nicht-Tun" - erhöhen Sie den "Fast-Kampf" -Stand. Wir werden den Geschäftsfortschritt demonstrieren . So können Sie sofort sehen, was ist und was funktioniert, und zur Not veröffentlichen wir zumindest einige Ergebnisse.

Wir bilden Prozesse


Wir stehen am Anfang der Entwicklung, daher gibt es keine Zeit und keinen Grund, komplexe formalisierte Prozesse zu erstellen. Deshalb vereinfachen wir alle Prozesse und konzentrieren uns auf die Erleichterung der Kommunikation .

Infolgedessen gibt es genau zwei Prozesse: eine große Aufgabe herauszufinden - über eine Lösung nachzudenken und zu überprüfen, was abgeschlossen wurde . Diese Prozesse sind langwierig, forschend und wenig miteinander verbunden, was zu geeigneten Entwicklungspraktiken führt.

Um es schnell zu machen - wir stellen coole Mitarbeiter ein . Aber coole Spezialisten gehen nicht zu einem Zahlungssystem, das niemandem auf dem Markt bekannt ist. Irgendwie hat es geklappt, aber die Lösung für dieses Problem ist eine separate Diskussion. Schreiben Sie übrigens in die Kommentare, wie Sie es zu Hause gelöst haben und haben Sie sich überhaupt entschieden?


Rückzug: über die Einstellung


Bei der Einstellung sehen sie sich normalerweise die Standard-Stellenbeschreibungen und die üblichen Abstufungen der Kandidatenstufen an und zeichnen dabei eine solche Karte der Rollen im Team:



Standardbeschreibungen erlauben es uns jedoch nicht, die Notwendigkeit einer bestimmten Person in einem Projekt zu verstehen. Normalerweise versuche ich, verschiedene Karten für verschiedene Projekte im Kopf zu behalten, um verschiedene Rollen und Kompetenzen hervorzuheben, die für das Projekt wichtig sind. Zum Beispiel technologisch .

Fehlerbehebung . Dies ist eine Person, die 2 Tage lang ohne Dokumentation und Tests in einen Legacy-Code mit einem Fehler eintauchen kann und mit dem Satz "Ersetzen Sie in dieser Zeile + durch - und es wird funktionieren."

Und es wird funktionieren. Menschen wie der vierblättrige Kleeblatt sind selten. Leider schätzt der Markt solche Menschen nicht, es ist schwierig, dem Unternehmen zu erklären, dass ein Troubleshooter dringend benötigt wird und Respekt und ein hohes Gehalt verdient. Infolgedessen gehen die meisten von ihnen an Teamleiter, und diese Ressource ist erschöpft. Es bleibt nur, um den Nutzen solcher Spezialisten zu fördern, und vielleicht wird sich die Situation nach einiger Zeit ändern.

Integrator Dies ist eine Person, die weiß, wie man aus mehreren verschiedenen Komponenten, Bibliotheken und Modulen etwas Integrales erstellt. Er ist kein XML-Programmierer mehr, sondern einer, der die interne Struktur versteht. Dies ist eine äußerst seltene Fähigkeit, die in der realen Entwicklung normalerweise sehr gefragt ist.

Guru: Framework, Sicherheit, Datenbank, DevOps . Über den Guru ist alles klar - dies sind Menschen, die mit Fragen zu relevanten Themen kontaktiert werden können.

Darüber hinaus gibt es auch "nicht-technologische" Rollen, eine soziale Rollenkarte. Ein Ideengeber ist eine Person, die sich etwas einfallen lassen kann. Kritiker - wer kann konstruktiv kritisieren. Erfahren - eine erfahrene Person, die sagen kann: "Wir haben es versucht und es hat sich als Unsinn herausgestellt." Ein Perfektionist ist eine Person, die möchte, dass alles gut ist. Dies ist eine wichtige Rolle. Wenn es nicht da ist, verfällt normalerweise schnell alles, weil es niemanden gibt, der dir sagt: "Du hast es wieder, alles ist falsch - lass es uns reparieren!"

Wenn eine Rolle in der Rollenzuordnung für Ihr spezifisches Projekt nicht besetzt ist, muss das Team sie erfüllen.

Überlegen Sie sich daher, wen Sie nehmen möchten, und denken Sie daran, dass unterschiedliche Interviews für unterschiedliche Rollen und Positionen geeignet sind . Mit einem erfahrenen Senior wird das Interview schnell sein - finden Sie einfach heraus, was er getan hat. Normalerweise muss man lange mit einem Junior sprechen, Testaufgaben geben und herausfinden, was er kann.

Je höher das Niveau des Kandidaten, desto kürzer das Interview.

Welche anderen Leute brauchst du?

Ein Extrovertierter ist einer, der außerhalb der Entwicklung aktiv kommunizieren will und kann. Wir haben keine genauen Produktionen, daher brauchen wir einige Leute, die die Endbenutzer verstehen können, einschließlich interner, zum Beispiel unserer Buchhalter. Ein Extrovertierter hat keine Angst davor, sich zu unterhalten, die Bedürfnisse solch ungewöhnlicher "Nicht-Programmierer" herauszufinden - und es gibt nur wenige solcher Leute.

Kritiker - Ich brauche zuerst einen Kritiker von mir. Dies ist die Person, die meine Entscheidungen kritisieren wird. Ohne Kritik habe ich Angst, dass ich etwas Unsinn mit mir herumtrage. Wenn sie mich kritisieren, muss ich ernsthaft über die Argumente nachdenken, und es stellt sich heraus, dass dies kein völliger Unsinn ist.

Spezialist für monotone Probleme : Berichte, Integrationen. Ich wusste mit Sicherheit, dass wir eine große Anzahl von Berichten im Projekt haben werden. Sechs Monate, um Buchhaltungsberichte zu schreiben und nicht verrückt zu werden - eine seltene Fähigkeit. Es ist auch unpraktisch, diese Funktion auf verschiedene Personen zu verteilen, daher brauchte ich einen Spezialisten für monotone Probleme.

Ist mir egal . Dies ist eine Person, die sich nicht darum kümmert, welche Aufgaben zu erledigen sind, wenn nur zu bezahlen. Diese Rolle ist für das Projekt äußerst wichtig, da es verschiedene Aufgaben gab: eintönig, aber komplex, wahnsinnig interessant oder aufgrund der eingeschlichenen externen Anforderungen überhaupt nicht mit unseren bisherigen Erfahrungen verbunden.

Kehren wir zu unserem Projekt zurück. Wir brauchen keine Fehlerbehebung, da das Erbe noch nicht vorhanden ist. Wir brauchten einen Integrator und eine Reihe von Gurus. Der Sicherheitsguru ist tatsächlich im Inneren gewachsen.

Database Guru wurde erfolgreich ausgelagert. Ich mag die Idee wirklich, „irgendwo außerhalb der Datenbank Kompetenz zu erwerben“ - eine solche Person im Personal zu finden, ist normalerweise unrealistisch, wenn Sie kein großes Unternehmen haben und mindestens 5 Personen erforderlich sind, um eine wichtige 24 * 7-Datenbank zu unterstützen. Wir haben auch zuerst DevOps Guru ausgelagert, aber nicht so erfolgreich, diese Rolle ist für externe Künstler schwieriger.

Es wurden auch soziale Rollen besetzt (und es gab sogar einige Kritiker).


Übe


Also haben wir die notwendigen Artefakte herausgefunden, herausgefunden, was Menschen brauchen und welche Prozessanforderungen. Was ist passiert, wie genau organisieren wir die Entwicklung:

  • Wir planen große Schläge. Wir haben keine Produktionen, daher ist es unmöglich, genauer zu planen. In drei Monaten muss ein persönliches Konto erstellt werden - und das ist alles. Wir führen Pläne in Confluence durch.
  • Jeder ist ein bisschen wie ein Analytiker . Es gibt keine normalen Produktionen und die Kompetenz im Fachgebiet liegt bei Personen, die nicht wissen, wie man Produktionen schreibt. Niemand hat sie unterrichtet, Sie müssen diese Informationen von ihnen entfernen. Aber wir haben "Extrovertierte".
  • Ein Tracker wird nicht benötigt . Wir haben nur 20 Hauptaufgaben für das Projekt - warum einen Tracker starten?
  • Ein Zweig in VCS. In der Anfangsphase ist keine komplexe Arbeit mit der Versionskontrolle erforderlich.
  • Die Prozesse sind ungefähr . Es gibt immer noch wenige Menschen, es gibt keine Kommunikation und Probleme, und das Projekt selbst ist instabil. Keine Notwendigkeit, etwas im Detail zu beschreiben.

Wenn Leute über ähnliche, nicht zu formalisierte Methoden sprechen, sagen sie oft einfach: „ Wir haben eine Agilität.“

Wir haben auch den Klassiker "We have Agile". Aber ich habe klar verstanden, warum eine solche Technik „agil“ ist und nicht etwas Spezifischeres und Komplexeres. Und ich (und das Geschäft), diese Technik war ziemlich geeignet.

Ein aufmerksamer Leser wird feststellen, dass wir bei der Entwicklung der Methodik zwei wichtige Befürchtungen vergessen haben: Angst um Sicherheit und die Notwendigkeit einer Zertifizierung . Versuchen wir herauszufinden, wie wir mit ihnen umgehen sollen.


Exkurs: Cowburn Matrix


1980 zeichnete Alistair Cowbern eine Matrix der Komplexität des Projekts .


Vertikal - die Kritikalität des Projekts . Was bei erheblichen Fehlern verloren gehen kann: vom Komfortverlust des Benutzers bis zum Verlust des Lebens des Benutzers, wenn wir beispielsweise Software für Kernkraftwerke entwickeln. Horizontal - die Größe des Teams . Die Größe beeinflusst die Anzahl der Kommunikationen. Kritikalität liegt im Detail dieser Mitteilungen. Alles in allem wirkt sich dies auf die Komplexität des Prozesses aus.

Alistair argumentiert, dass das Bewegen nach rechts oder oben in jedem Feld die Entwicklungskosten erheblich verkompliziert und erhöht. Dies ist logisch - mehr Menschen benötigen mehr Kommunikationskosten. Wenn formellere Beziehungen benötigt werden, sind mehr Kommunikationskosten erforderlich. Das heißt, Je weiter, desto mehr Ressourcen werden für unproduktive Aufgaben und Verluste aufgewendet.
Übrigens zeichnet Alistair als dritte Achse die Optimierung für unterschiedliche Geschäftswünsche.

Versuchen wir, unser Zahlungssystem auf dieser Matrix zu platzieren. Die Matrix ist sehr praktisch als Modell zum Verständnis der geschätzten Komplexität Ihres Projekts, Ihres Systems.

Wir haben ein Zahlungssystem, was bedeutet, dass wir zur Not etwas Benutzergeld verlieren werden. Dies ist natürlich unangenehm, führt aber nicht zu einer starken Zunahme der Komplexität.

Wir haben jedoch fast eine Bank, und in einigen Fällen kann bei Verstößen gegen die Standards oder Anforderungen der Zentralbank eine Lizenz von der Bank bezogen werden. Dies ist bereits ein Verlust von viel Geld, fast ein Geschäft zu schließen, sehr traurig.


Wir haben ein Team von ungefähr 20 Leuten, also betreten wir den E30- Platz. Das ist schlecht, denn ein gutes Beispiel für die Technik in diesem Quadrat wird der vollwertige Rational Unified Process sein - formale Prozesse, viele Dokumente, klare Aussagen. 20-30 Menschen können damit nicht umgehen. Sie müssen 50 einstellen, und die Schwierigkeit wird wie ein Schneeball wachsen. Ähnliche Systeme in solchen Methoden werden normalerweise von Hunderten oder mehr Personen geschrieben.

Was zu tun ist? Ärger? Nein, nicht das gesamte Projekt ist gleichermaßen kritisch . Wir haben nur wenige kritische Teile.

  • Geldwäsche-Scheck - für den die Zentralbank hart auf den Kopf getroffen hat.
  • Arbeiten mit Bankkarten - für die weltweite Zahlungssysteme hart auf den Kopf treffen.
  • Speicherung personenbezogener Daten - dafür hat der Staat den Kopf hart getroffen.

Lassen Sie uns einzelne kritische Module hervorheben . Wir werden für sie spezielle Praktiken für die Arbeit speziell mit diesen Teilen unseres Projekts schreiben: ein vollwertiges PCI-DSS-Audit für jedes Commit , eine gute Dokumentation, eine doppelte Codeüberprüfung, einen speziellen Berechnungsprozess und vieles mehr. Lassen Sie nur ältere Entwickler diese Teile des Projekts schreiben.

Aber solche Teile gibt es nur wenige. Daher lautet die Cowbern-Matrix für das Projekt wie folgt.


Für verschiedene Teile des Projekts wird es unterschiedliche Komplexität der Methodik geben, unterschiedliche Praktiken. Am schwierigsten und schrecklichsten sind drei Personen . Zahlungslogik - Person 8. Alle anderen weniger wichtigen Aufgaben, bei denen es sich vor allem um ein Hilfesystem oder das Layout einer Site für das Backoffice handelt, bei denen der Fehler nicht grundlegend ist, werden vor allem von Personen erledigt. Aber dort können Prozesse am einfachsten und informellsten sein.

Ein großes komplexes Projekt kann für seine verschiedenen Komponenten unterschiedliche Vorgehensweisen verwenden.

Dies ist einer der großen Vorteile der Microservice-Architektur - die Fähigkeit, ein Bild vorzuschreiben, in dem verschiedene Services nicht so sehr auf unterschiedliche Techniken, sondern auf unterschiedliche Praktiken innerhalb derselben Technik reagieren. Gleichzeitig bleiben wichtige Dinge gemeinsam: Planung, Artefakte, ein gemeinsamer Ansatz zur Interaktion.


Zusammenfassend


Wir haben die Anforderungen an die Methodik herausgefunden : Ziele und Grenzen. Identifizierte die Grundelemente : Prozesse, Artefakte und Menschen. Sie beschrieben Praktiken : wie Prozesse implementiert werden, Anforderungen an Artefakte, welche Art von Personen benötigt werden.

Dies ist ein klassisches Konstruktionsschema: Wir haben Anforderungen, dann haben wir die Architektur spezifiziert und dann programmiert.

Das Entwerfen von Methoden ist eine Konstruktionspraxis, ein Konstruktionsprozess, der sich nicht von der Programmierung eines Moduls unterscheidet.

Übungen der ersten Stufe


Eine kleine Übung, um von der Theorie zur Realität abzulenken.

Recht auf "Warum?"


Dies ist meine Lieblingspraxis.

Jeder Mitarbeiter hat das Recht, nach einer Aufgabe zu fragen: Warum, warum, warum und wer braucht das überhaupt?


Die Menschen haben Angst, nach dem Warum zu fragen - vielleicht weil sie in ihrer Kindheit solche Fragen noch nicht beantwortet haben. Wenn Sie explizit „können und sollten“ viele Male aufgeschrieben und wiederholt haben, tun es die Leute. Sobald Sie auf allen Ebenen, einschließlich des Geschäfts, nach dem Warum fragen, nimmt das Aufgabenvolumen um ein Vielfaches ab und die Motivation steigt ebenfalls. Die Menschen verstehen die Bedeutung von Arbeit und erledigen sie schneller und wirtschaftlicher.

Verallgemeinern Sie nicht auf drei


, . , , .


— , , . — — , . , , .

IDE Driven Development


JetBrains — ! , IDE.


, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .


, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .


. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .


, — , . : , ,

, : . . .

  • . , , .
  • . , , , , - .
  • . 3 -, , , , . , .
  • . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .


.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .


— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?


Planning poker . « » — . , , . Planning poker , .

. :

  • ;
  • product owner ;
  • ;
  • .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?


, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

  • ;
  • ;
  • .

.

: , , .


Jira , « » ? - -? ?


Stellen Sie einen Projektsekretär ein, damit der ganze Unsinn nicht von einem Teamleiter beobachtet wird, der teure Zeit hat . In der Tat ist dies ein Junior-Produktmanager - eine Person, die nicht viel Geld kostet, aber den größten Teil der Qualitätsüberwachung bürokratischer Artefakte übernehmen oder sogar erstellen kann.

Manchmal bittet ein Unternehmen darum, den Überblick zu behalten, wann Programmierer kommen und gehen - lassen Sie die Sekretärin dies im Auge behalten. Dies spart Ihnen viel Geld und Entwicklungsaufwand. Sie lieben es, versorgt zu werden. Wenn die Sekretärin ihnen einen Martini serviert - ist das in Ordnung!


Überprüfen Sie vor dem Code. Ich höre regelmäßig, wie eine Person für ein großes Feature verantwortlich gemacht wurde, aber sie hat etwas falsch gemacht und muss überarbeitet werden. Lassen Sie uns den Code überprüfen, bevor wir ihn schreiben . Vor dem Schreiben von Code beschreibt ein Mitarbeiter von Jira einen Plan zur Lösung eines Problems in zwei Zeilen oder zwei Textabschnitten. Das Überprüfen dieser beiden Absätze ist schnell und einfach, aber globale Fehler werden frühzeitig erkannt, insbesondere wenn Sie einen Teamleiter oder einen Architekten haben.

Darüber hinaus ermöglicht diese Praxis dem Teamleiter oder Architekten, alle Änderungen in einem großen Projekt zu kennen. Er liest keinen krummen Code, sondern zwei Absätze darüber, was im Allgemeinen im System passiert, und fängt schnell Leute an der Hand. Dies gilt insbesondere für kritische Teile eines Produkts, z. B. die Zahlungslogik.

So ändern Sie die Methodik und beenden das Projekt nicht


In 9 Monaten haben wir drei Methoden geändert: „We have Agile“, eintägiges SCRUM und Kanban. Wie stellen Sie sicher, dass Sie keine Ressourcen verlieren? Wie kann man die Methodik überhaupt ändern und das Projekt nicht gleichzeitig beenden?

Wir haben es geschafft, die Methoden so zu ändern, dass einige Entwickler die Änderungen überhaupt nicht bemerkten. Niemand hat ihnen davon erzählt, sie arbeiten und die Methodik ist anders!

Die Hauptsache ist zu verstehen, wann man sich ändert.

Wenn Sie verstehen warum. Oft werden die Methoden geändert, weil ein neuer technischer Direktor gekommen ist, der alles wiederholen möchte. Das ist ein schlechter Grund. Nehmen Sie besser die alte und benennen Sie sie um - alles, die Technik ist anders, es ist besser. Wenn Sie die Frage warum nicht beantworten können, ist es besser, sich nicht zu ändern. Ich frage im Allgemeinen gerne warum.

Wenn Sie "wie" dachten. Wenn Sie verstehen, wie Sie von Punkt A nach Punkt B kommen, ändern Sie. Bis Sie mit - keine Notwendigkeit kommen.

Wenn zufrieden "wie viel." Das Ändern einer Technik ist fast immer ein teures Verfahren . Wenn Sie es gut machen, kostet der Austausch mehrere Mannmonate der Kosten für Teamleiter, HR- und Jira-Customizer. Wenn es schlecht ist, ein paar Monate der Arbeit des gesamten Unternehmens. Ich habe oft den Übergang von Kanban zu SCRUM gesehen, dann zurück, von denen jeder einen Monat Arbeit während der gesamten Entwicklung gekostet hat. Wenn Sie für solche Kosten nicht bereit sind, starten Sie nicht.

Vorbereitung


Wir fangen im Voraus an. Für ein kleines Team beginnt die Vorbereitung einen Monat vor der Schicht.

Wir zeichnen User Stories. Der gleiche Ansatz wie beim Anwendungsdesign. Sie verwenden User Stories, wenn Sie Anforderungen beschreiben, hoffe ich?

Zum Beispiel:

  • User Story : Als Entwickler möchte ich meine nächste Aufgabe finden und mit deren Implementierung fortfahren.
  • Akzeptanzkriterien : Als Entwickler kann ich alle meine aktuellen Aufgaben anzeigen und die Dringlichkeit und Priorität von Aufgaben bewerten.
  • Ausnahmen: Wenn keine Aufgaben vorhanden sind, weiß der Entwickler, wen er fragen muss.
  • Links: Szenarien für die Erstellung eines kurzfristigen Plans, der zeigt, wo die nächste Aufgabe zu erledigen ist.

Gehen Sie auf diese Weise alle Ihre Hauptaktivitäten durch, die sich innerhalb Ihrer Methodik ergeben, und schreiben Sie User Stories.

Wie kann der Manager die Wirksamkeit des Plans sehen? Wie versteht ein Top-Manager, dass alles in Ordnung ist? Schreiben Sie User Stories und fügen Sie dann Details hinzu: Erstellen Sie ein Dashboard für Benutzer und Top-Manager - Akzeptanzkriterien bestehen, alles ist in Ordnung.

Wenn Sie bereits User Stories haben, können Sie diese in Praktiken umwandeln.

Ersetzen Sie alle Rollen durch echte Personen . Eine reale Person weiß immer mehr als eine Rolle. Dann finden Sie sofort den Engpass. Zum Beispiel verwenden alle Ihre User Stories eine bestimmte Person, obwohl sie einfach unterschiedliche Hüte trägt und unterschiedliche Rollen spielt. Das ist schlecht - finde heraus, wie man es entlädt.

Reduzieren Sie Artefakte und Kommunikation . Wenn es zu viele davon gibt - jede User Story schlägt ihre eigenen Artefakte und Kommunikationen vor -, muss etwas dagegen unternommen werden.

Suchen Sie nach Engpässen . Wenn es eine solche Story Map gibt, können Sie anfangen, etwas damit zu tun.

Werkzeuge auswählen


Das Tool identifiziert Features . Es gibt eine weit verbreitete Meinung, dass Werkzeuge nicht wichtig sind oder dass jedes Werkzeug geeignet ist - das ist Unsinn.

Wenn die Verwendung des Tools unpraktisch ist, werden sie nicht verwendet.

Darüber hinaus lügen Anbieter immer. Wenn sie sagen, dass ihr Werkzeug "1, 2 und 3" kann, können sie höchstwahrscheinlich manchmal nicht "1", "2" und "3", aber es ist sehr schlecht. Überprüfen Sie unbedingt alles.

Wir diskutieren aktiv


Ohne eine aktive Diskussion der Technik können Sie einige wichtige Funktionen, wichtige User Stories vergessen und jemanden beleidigen. Die beleidigte Person wird die Umsetzung der Methodik sabotieren : Er war anfangs beleidigt, vergessen, niemand sprach mit ihm, was er brauchte.

In diesem Stadium können Menschen negative frühere Erfahrungen mit der Einführung anderer Techniken zeigen.

- Ah, Unsinn! Wir hatten das schon und nichts kam daraus.

Um dies zu vermeiden, sammeln Sie die Schmerzen der Menschen und fragen Sie, was falsch ist. Nehmen Sie genau auf und demonstrieren Sie, was Sie aufgenommen haben - damit die Person versteht, dass sie ihn gehört hat.

Wiederholen Sie keine negativen Erfahrungen . Retrospektive nicht gegangen? Nun ist dies ein "Freitag Kuchen". Standups um 7 Uhr gingen nicht? Nun ist dies "Aufladen". Es hilft oft, denselben Praktiken unterschiedliche Namen zu geben, damit die Menschen ihre früheren negativen Erfahrungen nicht mit ihnen in Verbindung bringen.

Leider gibt es keine universellen Lösungen. Bauen Sie auf Ihre Situation auf.

Implementierung


Der Hauptwert im IT-Management ist Respekt.

Wir sparen jemand anderem Zeit . Wenn Sie Aufgaben von einem Trackersystem auf ein anderes übertragen müssen - schreiben Sie ein Skript und beauftragen Sie Mechanical Turk, dies für Sie zu tun. Lösen Sie dieses Problem, damit der Entwickler eine Woche lang nicht alle seine Aufgaben von einem System auf ein anderes überträgt - dies ist ein Ausdruck von Respekt.

Wir helfen beim Übergang . Wenn wir eine neue Praxis einführen, setzen wir uns neben eine Person und helfen ihr, das neue System zu verstehen. Wir bereiten Anweisungen im Voraus vor.

Wir beschreiben spezifische Aktionen. Wir machen sehr spezifische Dokumentationen, nur gemäß unseren User Stories: „Wir müssen eine neue Aufgabe übernehmen. Wie das geht, steht in der Dokumentation - du öffnest so und so eine Seite im Wiki, darin liest du so und so. “
Wir führen schrittweise ein - nicht alle Praktiken gleichzeitig . Unsere Entwickler haben keine Änderung der Methoden festgestellt, da wir nicht alle Methoden gleichzeitig implementiert haben. Als wir reibungslos von einem eintägigen SCRUM zu etwas anderem wechseln wollten, habe ich nicht jeden Tag Retrospektiven durchgeführt, die Aufgaben wurden etwas länger ausgeführt, die täglichen morgendlichen Besprechungen wurden leise auf einen Standard-Stand-up umgestellt. Den Leuten schien es, dass alles allmählich vor sich ging. Dann hat sich die Praxis ganz erheblich geändert. Zu einigen Dingen sagte ich ihnen natürlich: "Jetzt werden wir den Prozess der Arbeit mit Jira leicht ändern - jetzt wird es so sein."

Die Wege treten von selbst mit Füßen . Verschreiben Sie nicht sofort einen harten Workflow - lassen Sie die Leute die Wege selbst finden. Es ist für sie praktisch, die Aufgabe im Tracker von Status zu Status zu übertragen, auch wenn sie sie übertragen, und dann werden Sie sie beheben. Es ist schwierig, sofort vorherzusagen, was zweckmäßig sein wird, und es ist einfach, den angeforderten Übergang zu verbieten. Aber dann muss man lange leiden, um alles zurückzubekommen.

KUSS . Machen Sie es einfach, zumindest am Anfang. Nicht zu kompliziert.

Unterstützung


Wir reservieren Ressourcen im Voraus für den Übergangsprozess, da dieser teuer ist . Der Übergang von einer Technik zur anderen ist viel Geld. Reservieren Sie Ihre Zeit und Zeit für Personen, die Fehler in Ihrem Tracker, in Ihrem Workflow und in Berechnungsverfahren bearbeiten. Wenn es keine Ressourcen gibt und gleichzeitig eine Art Ansturm, wird alles schlecht.
Wir beheben Fehler so schnell wie möglich .

Fazit


Projekte sind anders, Menschen auch - jeder braucht ganz andere Techniken ! Alle glücklichen Familien sind gleichermaßen glücklich, alle unglücklich - auf ihre eigene Weise. Das gleiche gilt für Projekte - es gibt keine zwei identischen.

Das Erstellen einer Technik ist eine technische Aufgabe. Genau das gleiche wie das Programmieren und Entwerfen von Systemmodulen. So nähern Sie sich dem. Sie wissen, wie man technische Probleme gut löst - nutzen Sie also Ihr gesamtes Wissen in dieser neuen Praxis.

Die Änderung der Methodik ist ein klassisches SMART-Projekt . Verwenden Sie alles, was Sie über Projektmanagement wissen: Definieren Sie Erfolgskriterien, überprüfen Sie am Ende die Einhaltung der festgelegten Aufgaben, merken Sie sich die begrenzte Zeit usw.

Mein persönliches Manifest


Menschen sind wichtiger als Prozesse , weil Prozesse für Menschen durchgeführt werden müssen. Wenn das Unternehmen ein Durchschnittsalter von 50 Jahren hat und vom Militär stammt und Sie versuchen, Kanban sofort schnell umzusetzen, wird es höchstwahrscheinlich nicht starten. Die Leute sind nur an etwas anderes gewöhnt.

Der Hauptvorteil eines Programmierers ist seine Faulheit. Erstellen Sie Prozesse so, dass die Benutzer noch weniger Zeit mit ihnen verbringen, und Entwickler sind die ersten, die sie ausführen. Wenn Menschen nicht versuchen, Prozesse zu implementieren, verstehen sie nicht warum.

Es kommt vor, dass einige Praktiken schwer zu implementieren sind, da sie schwer zu verstehen sind. Manchmal ist es einfacher, die Praxis zu ändern, vielleicht entspricht sie nicht Ihren Aufgaben oder Ihren Mitarbeitern. Als letztes Mittel - Menschen ändern, aber es ist teurer als die Praxis zu ändern.

Das Ergebnis ist wichtiger als Gewohnheiten . Die schrecklichste Angewohnheit ist die Angewohnheit, von einem neuen Werkzeug zu hören, es nach Hause zu bringen und es sofort zu verwenden. Frachtkult ist eine schreckliche Angewohnheit, gegen die man kämpfen muss. Aber auch die Angst, eine Art von Praxis zu ändern, weil „wir das immer getan haben“, auch wenn sie bereits unwirksam ist, ist schädlich.

Und manchmal sind die Aufgaben im Allgemeinen so vielfältig, dass Gewohnheiten gefährlich werden. Zum Beispiel bei der Kommunikation mit lebenden Menschen.

Überzeugung ist effektiver als Befehle . Die beste Motivation ist, die Bedeutung Ihrer Arbeit zu verstehen und sie zu teilen. Entwickler möchten Benutzern das Leben erleichtern, Unternehmen Geld sparen und ihr Leben vereinfachen - informieren Sie sie also über die Ziele ihrer Aktionen. Lernen Sie zu überzeugen.

Alle drei Prinzipien sind mein persönliches Bild von der Welt. Wenn Sie andere Voraussetzungen haben, benötigen Sie wahrscheinlich eine andere Methode zum Erstellen von Techniken.

Im TeamLead Conf- Programmkomitee sind wir auch mit dem alten Lego besser vertraut, sodass wir Cubes in das Programm auswählen, aus denen Sie selbst die für Sie geeigneten Prozesse erstellen können. Für die Herbstkonferenz in St. Petersburg wurden bereits 15 Teile zusammengestellt, aber wir akzeptieren weiterhin Bewerbungen für Berichte - schreiben Sie .

Source: https://habr.com/ru/post/de456514/

More articles:


All Articles