Flexibilität ist ohne Zweifel eine gute Sache, und das Agile-Manifest macht Sinn. Im Vergleich zu der fragilen Praxis, die als Wasserfall bezeichnet wird, ist Agile deutlich besser. In der Praxis verursachen flexible Ansätze jedoch häufig tiefe Schäden, und tatsächlich ist die Dichotomie zwischen Agilität und Wasserfall hier kaum angemessen.

Ich habe gesehen, wie viele agile Varianten namens Scrum das Unternehmen wirklich töten. Mit "töten" meine ich nicht "kulturelle Verschlechterung", sondern wenn die Aktien des Unternehmens in zwei Jahren um fast 90% fallen.

Was ist agil?

Agile ist aus einer Web-Beratungsumgebung hervorgegangen, die einige Vorteile mit sich brachte: Wenn Sie mit anspruchsvollen Kunden arbeiten, die nicht wissen, was sie wollen, müssen Sie normalerweise zwischen zwei Optionen wählen. Oder um den Klienten zu besiegen: Erwartungen festlegen, angemessene Bezahlung für Änderungen vornehmen und Gleichheitsbeziehungen aufrechterhalten, nicht Unterordnung. Oder akzeptieren Sie das falsche Verhalten des Kunden (wie es beispielsweise viele Designer tun müssen) und richten Sie den Arbeitsablauf auf die Funktionsstörung des Kunden aus.

Programmierer arbeiten normalerweise nicht sehr gut mit Clients. Wir sind zu wörtliche Menschen. Wir mögen Systeme mit genau definiertem Verhalten. Dies erschwert unsere Interaktion mit den Geisteswissenschaften, da wir jede Anfrage eher wörtlich nehmen, als herauszufinden, was sie wirklich wollen. Auf Unternehmensebene gehen agile Methoden (außerhalb des Beratungsumfelds) noch weiter und legen nahe, dass die Ingenieure nicht klug genug sind, um zu verstehen, was ihre internen „Kunden“ wollen. Dies bedeutet, dass die Arbeit auf „User Stories“ und „Iterationen“ gesprüht wird, die uns oft die Zufriedenheit mit der geleisteten Arbeit sowie die Hoffnung auf eine langfristige Vision davon nehmen, wohin die Dinge gehen.

Im Allgemeinen werden zwei Arten von Arbeiten erstellt, entweder innerhalb des Unternehmens oder für den Auftragnehmer. Auf hohem Niveau werden hochqualifizierte Spezialisten eingestellt. Unten - alle Arbeiten, die sie nicht machen wollen, werden zur Seite geworfen. Offensichtlich erhält eine Beraterklasse Respekt, die andere nicht. Schlecht geführte Beratungsunternehmen landen oft als Müllschlucker für gering qualifizierte Arbeitsplätze. Scrum scheint für Unternehmen entwickelt worden zu sein, in denen die Kundenbeziehungen so schlecht sind, dass Ingenieure täglich überwacht werden müssen, da sie zu einem Sedimentationstank für Basisarbeiten geworden sind, der für eine Karriere, die niemand machen möchte, nutzlos ist (und wahrscheinlich ist dies keine sehr wichtige Aufgabe , daher niedrige Raten und Respekt).

Gewalttätige Transparenz

Es gibt viele Trends am IT-Arbeitsplatz, die eine Programmierkarriere äußerst unattraktiv machen, insbesondere für kreative, kluge Leute.

Das ungeheuerlichste Beispiel sind Großraumbüros. Sie sind nicht produktiv. Es ist schwierig, sich auf sie zu konzentrieren. Sie sind antiintellektuell, da die Menschen Angst haben, bei der Arbeit beim Lesen von Büchern (oder beim Nachdenken) erwischt zu werden. Wenn Sie Menschen dazu bringen, sich als produktiv auszugeben, verlieren sie tatsächlich an Produktivität. Großraumbüros dienen im Allgemeinen nicht der Produktivität. Dies ist ein Unternehmensimage. Venture-finanzierte Startups verwenden diese Layouts, um Investoren zu demonstrieren, dass das Büro geschäftig aussieht . (Einfach ausgedrückt, ein offener Programmierer wird eher als Büromöbel geschätzt als als der Code, der schreibt). Aus verschiedenen kulturellen Gründen wurde die Open-Plan-Option dadurch „cool“ und „schmutzig“ und infiziert nun die gesamte Unternehmenswelt.

Es ist bekannt, dass kreative Menschen ihre Kreativität verlieren, wenn sie während der Arbeit zur Erklärung aufgefordert werden. Gleiches gilt für die Software. Programmierer müssen oft einseitig transparent arbeiten. Diese agilen Systeme werden häufig missbraucht und erfordern trotz mangelnder Gegenseitigkeit eine demütigende Transparenz des Betriebs. Anstatt an tatsächlichen langfristigen Projekten zu arbeiten, mit denen eine Person mitgerissen werden könnte, müssen sie nur noch an atomisierten, funktionalen „User Stories“ arbeiten und dürfen häufig nicht an Verbesserungen arbeiten, die nicht mit den kurzfristigen, unmittelbaren Anforderungen des Unternehmens zusammenhängen (oft von oben nach unten). Diese falsche, aber häufig verwendete Version von Agile schließt das Konzept des Eigentums aus und betrachtet Programmierer als austauschbare, identische Komponenten.

Scrum ist die schlechteste Option, mit der Dummheit von zweiwöchigen „Iterationen“. Dies führt zu unnötigen Bedenken hinsichtlich Mikrofluktuationen bei der menschlichen Leistung. Es gibt absolut keine Beweise dafür, dass dieser Ansatz die Entwicklung auf lange Sicht wirklich beschleunigt oder verbessert. Es macht die Leute nur nervös. Viele in der Branche halten dies für einen guten Ansatz, da die Arbeit "schneller geht". Ich bin seit zehn Jahren in der IT-Branche tätig, als Manager und als arbeitende Biene. Das ist nicht wahr.

Agile und Scrum-spezifische Fehler

1. Geschäftsorientierte Entwicklung.

Agile wird oft im Vergleich zu einem „Wasserfall“ serviert. Was ist ein Wasserfall?

Der Wasserfall-Ansatz ist wirklich schrecklich. Darin rollt „Arbeit herunter“, wobei jede Ebene der Organisationshierarchie das auswählt, was er als „interessantes Material“ betrachtet, und es weitergibt. Projekte werden von Managern festgelegt, Architektur wird von Architekten entworfen, persönliche Fristen werden von mittleren Managern festgelegt, die Implementierung wird von Arbeitspferden (Programmierern) der obersten Ebene durchgeführt, und dann werden Operationen und Tests auf Pferde der unteren Ebene übertragen. Dies ist ein äußerst nicht funktionierendes Schema. Wenn Menschen das Gefühl haben, dass alle wichtigen Entscheidungen bereits getroffen wurden, haben sie keine Motivation, so gut wie möglich zu arbeiten.

Der Wasserfall reproduziert das Sozialmodell einer dysfunktionalen Organisation mit einer bestimmten Hierarchie. Im Gegenzug repliziert Agile häufig das Sozialmodell einer dysfunktionalen Organisation ohne eine klar definierte Hierarchie.

Ich habe gemischte Meinungen über Berufsbezeichnungen wie "Senior" und "Regisseur" und dergleichen. Sie sind wichtig, und ich selbst werde wahrscheinlich keine Position unter dem Niveau des Regisseurs akzeptieren, aber ich hasse ihre Bedeutung. Wenn Sie sich Scrum ansehen, werden den älteren, fähigsten Ingenieuren ausdrücklich die Rechte entzogen, da sie hier verpflichtet sind, etablierte Prozesse einzuhalten (nur an erstellten Aufgaben arbeiten, 5-10 Stunden pro Woche an Segelflugzeugen). Diese Prozesse sind für Personen gedacht, die vor einem Monat mit dem Programmieren begonnen haben.

Wie der gescheiterte kommunistische Staat, der die Menschen durch die Verbreitung von Armut ausgleicht, stellt Scrum in seiner reinsten Form die gesamte Entwicklung auf das gleiche niedrige Niveau: nicht klar definiert, aber deutlich unter das Niveau der Geschäftsleute, die die volle Entscheidungsbefugnis haben, woran sie arbeiten sollen.

Agile erhöht in seiner üblichen Implementierung die Häufigkeit von Rückmeldungen und gibt den Ingenieuren immer noch keine wirkliche Leistung. Dies ist ein Verlustgeschäft, da es bedeutet, dass Programmierer eher gezogen oder bestraft werden, wenn der Job länger dauert, als es angeblich dauern sollte. Dies schafft viel Angst und Eile, aber in der Tat hat es wenig mit dem zu tun, was wirklich wichtig ist: großartige Produkte zu schaffen.

Silicon Valley hat vor allem in den letzten fünf Jahren viele Fehler gemacht, aber etwas richtig gemacht. Darunter wurde das Konzept des "Engineering" -Unternehmens eingeführt. Für Ingenieure ist es nicht immer besser, das gesamte Unternehmen zu leiten, aber wenn Ingenieure die Entwicklung verwalten und Prioritäten setzen, gewinnt jeder: Ingenieure sind mit der Arbeit zufrieden, die ihnen zugewiesen wurde (oder, noch besser, sie sind sich selbst zugewiesen), und das Unternehmen erhält eine viel höhere Entwicklungsqualität.

Aber Sie haben eine "Geschäftsfirma", das ist in Ordnung. Stellen Sie dann keine Ingenieure ein, wenn Sie Talent benötigen. Sie können die besten Leute als Berater gewinnen (ab 200 USD pro Stunde und stark von diesem Niveau an steigend), aber nicht als Vollzeitbeschäftigte eines „Unternehmens“. Gute Ingenieure möchten in Unternehmen arbeiten, die von Ingenieuren geführt werden, wo sie in die Arbeitsplanung einbezogen werden, ohne sich bei den „Scrum Masters“, „Product Owners“ und verschiedenen Ebenen von Geisteswissenschaftlern entschuldigen zu müssen.

Letztendlich sind Agile (wie praktiziert) und Waterfall Formen der geschäftsorientierten Entwicklung, und daher eignet sich keine von ihnen zur Entwicklung hochwertiger Software oder zur Motivation von Mitarbeitern.

2. Die untergeordnete Position der Jugend.

Leider hat sich in der Softwareentwicklung eine Kultur der jungen Unterordnung mit dem (äußerst fehlerhaften) Konzept der Programmierung als „Spielzeug junger Männer“ entwickelt, obwohl fast keiner der besten Ingenieure jung ist und einige der besten überhaupt keine Männer sind.

Das Problem mit den zweiwöchigen Agile-Iterationen (oder Sprints) und User Stories ist, dass es keine Exit-Strategie gibt. Es gibt keine Option "Wir müssen dies nicht mehr tun, wenn wir [X] erreichen." Dieses System soll für immer sein: Geschäftsorientierte Rallyes werden niemals verschwinden. Architektur, F & E und Produktentwicklung verlassen die Arbeit des Programmierers, da sie nicht in atomisierte „User Stories“ und zweiwöchige Sprints passen.

Daher ist es für mehr oder weniger erfahrene Programmierer unangenehm, auf diese Weise zu arbeiten, da sie die in dieser Struktur ignorierten Projekttypen übernehmen möchten und solche Projekte im Hinblick auf den kurzfristigen Geschäftswert schwer zu rechtfertigen sind. Technische Exzellenz ist wichtig, aber es ist sehr schwierig, Menschen von dieser Tatsache zu überzeugen, wenn sie hartnäckig nicht überzeugt werden wollen.

Ich habe einmal für ein Unternehmen gearbeitet, in dem ein Produktmanager sagte, dass der Unterschied zwischen einem leitenden Ingenieur und einem jungen Ingenieur in der Fähigkeit besteht, genauere Zeitschätzungen vorzunehmen. Naja eigentlich nicht. Und es ist sogar beleidigend. Ich hasse Bewertungen, weil sie Richtlinien generieren und die Arbeit nicht schneller oder besser erledigen (in der Tat normalerweise das Gegenteil).

Das Schlimmste an Bewertungen ist, dass sie die Leistung der Arbeit fördern, die bewertet werden kann. Dies führt dazu, dass Programmierer einfache Dinge auf niedriger Ebene bevorzugen, die Unternehmen nicht wirklich benötigen (selbst wenn ungeschickte Manager auf mittlerer Ebene anders denken), aber es ist „sicher“. Alles, was sich wirklich lohnt, hat eine Ausfallwahrscheinlichkeit ungleich Null und zu viele unbekannte Parameter für eine vernünftige Schätzung des Zeitrahmens. Der Fokus von Agile auf den kurzfristigen Geschäftswert drängt die Menschen letztendlich von der Arbeit ab, die das Unternehmen wirklich benötigt, um den Ruf jedes Programmierers in Echtzeit zu verwalten.

Eine solche Kultur legt nahe, dass Programmieren Kindlichkeit ist, die Sie bis zum Alter von 35 Jahren loswerden müssen. Ich stimme dieser Meinung nicht zu. Tatsächlich denke ich, dass dies ein schlechter Gedanke ist. Ich bin über 30 und ich habe das Gefühl, dass ich gerade erst anfange, gut zu programmieren. Es ist eine schreckliche Idee, hochrangige Programmierer zu belästigen, nur weil sie genug Erfahrung haben, um zu wissen, dass dieser flexible / Scrum-Prozess nichts mit Informatik zu tun hat und keinen Mehrwert bietet.

3. Zu kurzfristiger Ansatz, der dumm und gefährlich ist.

Agile ist für sekundäre Beratungsunternehmen gedacht, die nicht über genügend Kredit verfügen, um mit Kollegen auf gleicher Augenhöhe zu verhandeln, und die mit engen Fristen konfrontiert sind. Jedes Kundenprojekt ist ein existenzielles Risiko. Er ist für die "marginalen" Außenseiter. Aber hier ist das Problem: Scrum wird häufig in großen Unternehmen und finanzierten Startups eingesetzt. Aber die Leute gehen zu solchen Unternehmen, weil sie keine Außenseiter sein wollen . Sie wollen Sicherheit. Deshalb arbeiten sie in diesen Unternehmen, anstatt ihre eigenen zu gründen. Niemand möchte zurückbleiben, wenn es keinen signifikanten persönlichen Nutzen gibt. Agilität in einem Unternehmen bedeutet Schmerz und Risiko ohne Belohnung.

Wenn jedes Kundenprojekt ein existenzielles oder ernstes Reputationsrisiko birgt, kann Agile die geeignete Lösung sein, da die Konzentration auf kurzfristige Iterationen nützlich ist, wenn das Unternehmen einem Risiko ausgesetzt ist und auf lange Sicht verschwinden kann. Aggressives Projektmanagement ist im Notfall sinnvoll. Dies ist als dauerhafte Vereinbarung nicht sinnvoll; Zumindest nicht für talentierte Programmierer, die weniger stressige und angenehmere Möglichkeiten haben.

Als Teil von Agile bauen sich technische Schulden auf und werden nicht gelöst, da die Geschäftsleute, die Aufgaben zuweisen, das Problem erst sehen, wenn es zu spät oder zumindest zu teuer ist, um es zu beheben. Darüber hinaus werden einzelne Ingenieure nur auf der Grundlage der aktuellen zweiwöchigen „Sprints“ belohnt oder bestraft, dh niemand sieht sich im Voraus fünf „Sprints“ an. Agile ist nur ein sinnloser, kurzsichtiger „Sprint“ nach dem anderen: kein Fortschritt, keine Verbesserungen, nur Ticket für Ticket, für Ticket.

Leute, die mit dem Mischen bedeutungsloser Aufgaben einverstanden sind, können es ertragen, aber wirklich gute Ingenieure hassen es, am Montagmorgen zur Arbeit zu gehen, ohne zu wissen, was sie an diesem Tag arbeiten werden.

4. Er hat nichts mit dem Aufbau einer Karriere zu tun.

Einzelne User Stories sind nicht gut für eine Ingenieurkarriere. Mit 30 Jahren wird von Ihnen erwartet, dass Sie auf der Ebene des gesamten Projekts arbeiten können und zumindest bereit sind, in Bezug auf Infrastruktur, Architektur, Forschung oder Führung über diese Ebene hinauszugehen.

Unabhängig davon, ob es sich um eine Beratung handelt, die einen wichtigen Kunden oder einen „Kriegsraum“ eines Unternehmens beruhigen soll, können Gedanken über einen Lebenslauf warten. Nur wenige Menschen geben ein paar Wochen unangenehmer oder anderer Arbeit auf, die nicht mit der beruflichen Entwicklung zusammenhängt, wenn dies für das Unternehmen wirklich wichtig ist. Die Bedeutung der Arbeit hat hier Priorität. Wenn Sie sagen können: „Ich saß im Hauptquartier und sprach 20 Minuten am Tag mit dem CEO“, rechtfertigt dies dumme Arbeit.

Aber wenn es keinen Notfall gibt, erwarten Programmierer, dass ihre Karriere ernst genommen wird. Sonst werden sie gehen. "Ich war im Scrum-Team" bedeutet, dass Sie ein Boxsack sind. Es ist eine Sache, einen dummen Job zu machen, denn der CEO hat anerkannt, dass eine unangenehme Aufgabe einen Mehrwert von mehreren Millionen Dollar bringt (und er wird sie entsprechend belohnen). Wenn Ihnen jedoch einfach „User Stories“ und Jira-Tickets zugewiesen wurden, gelten Sie als Verlierer.

5. Ziel ist es, niedrige Raten zu ermitteln, aber die Anzahl falsch positiver Ergebnisse ist inakzeptabel hoch.

Scrum wird als ein guter Weg vorgeschlagen, um „zurückgebliebene Mitarbeiter“ zu identifizieren. Das Problem ist, dass dadurch mehr ineffektive Programmierer entstehen, als sich herausstellt. Hierbei handelt es sich um ein Gesamtverfolgungssystem, bei dem einzelne Ingenieure den Fortschritt ihrer Arbeit detailliert darstellen und die Produktivität bewerten.

In einer Debatte über bürgerliche Freiheiten wird häufig ein häufiger Fehler erwähnt: das Argument "nichts zu verbergen". Einige Leute argumentieren gerne, dass die Verletzung der Privatsphäre, beispielsweise durch Strafverfolgungsbehörden, kein Problem darstellt, da sie selbst keine Kriminellen sind. Diese Leute vermissen ein paar wichtige Dinge. Zum Beispiel ändern sich diese Gesetze. Fragen Sie jeden, der in den 1930er Jahren Jude in Mitteleuropa war. Selbst für angesehene Menschen ist der Zustand der Überwachung ein Zustand der Angst.

Die Tatsache der Beobachtung verändert die Arbeitsweise der Menschen. In kreativen Bereichen tut es weh. Es ist fast unmöglich, kreativ zu arbeiten, wenn Sie jeden Tag über die Arbeit berichten müssen.

Ein anderes Thema fällt mir ein: Sensibilität für den Status . Programmierer tun gerne so, als hätten sie mehrere Millionen Jahre Evolution von Primaten im Zusammenhang mit dem sozialen Status überwunden, aber Tatsache ist, dass der soziale Status wichtig ist, und es ist nicht peinlich, diese Tatsache zuzugeben. Ältere Menschen, Frauen, ethnische Minderheiten und Menschen mit Behinderungen reagieren im Allgemeinen empfindlich auf den Status am Arbeitsplatz, da dies für sie eine Frage des Überlebens ist. Eine ständige Überwachung der Arbeit weist auf einen Mangel an Vertrauen und einen niedrigen sozialen Status hin, und die Statusempfindlichsten (auch wenn sie die besten Mitarbeiter sind) leiden als erste unter einer verstärkten Überwachung. Wenn sie das Gefühl haben, nicht vertrauenswürdig zu sein (und was wird sonst noch von der Kultur übertragen, wo jedes Element der Arbeit genehmigt werden sollte?), Dann verlieren sie schnell ihre Motivation.

Agile und insbesondere Scrum sind anfällig für den Fehler "nichts zu verbergen". Wenn Sie kein „schlechter Arbeiter“ sind, sind Sie nicht gegen tägliches Gleiten, oder? Die einzigen Leute, die gegen die täglichen Berichte über ihre Arbeit in Bezug auf den kurzfristigen Geschäftswert Einwände erheben, sind „Faulenzer“, die dem Unternehmen Geld stehlen wollen, oder? Nun, nein. Offensichtlich nicht.

Eine Kultur gewalttätiger Transparenz ist für die Statusunempfindlichsten konzipiert: junge, normalerweise weiße oder asiatische, privilegierte Männer, die noch nie bei der Arbeit unter Druck gesetzt wurden. Für diejenigen, die denken, dass HR und Management Zeitverschwendung sind und der Mitarbeiter einfach Demütigungen und Beleidigungen schlucken sollte.

Oft leiden die besten Mitarbeiter unter der Implementierung von Agile / Scrum, da F & E effektiv eliminiert wird. Die Besessenheit von kurzfristigen "Iterationen" oder Sprints bedeutet die Unfähigkeit, etwas Neues und Riskantes auszuprobieren.

Die Wahrheit über die zurückgebliebenen Mitarbeiter ist, dass Sie sie ohne Agile identifizieren können. Die Leute wissen, wer sie sind. Der Grund, warum einige Teams mit Faulenzern, inkompetenten oder giftigen Menschen gefüllt sind, ist, dass niemand etwas mit ihnen macht. Dies ist ein Managementproblem auf Personalebene und nicht auf Workflow-Ebene.

6. Der betrunkene Effekt.

Es scheint, dass aggressives Management einige leicht inkompetente Menschen arbeitsfähig machen kann. Ich nenne es den betrunkenen Effekt: Wenn Mädchen so lässig werden, aber wirklich süß, wollen sie nichts mehr mit dir zu tun haben. — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .