Erzwingt Agile, dass Entwickler mehr Zeit damit verbringen, tatsächlich zu arbeiten?

25

Wenn ich mir die gängigen Agile-Praktiken anschaue, scheint es mir, dass sie Entwickler (absichtlich oder ungewollt?) Dazu zwingen, mehr Zeit für die eigentliche Arbeit zu verwenden, als Blogs / Artikel zu lesen, zu chatten, Kaffeepausen zu machen und einfach nur zu zögern.

Bestimmtes:

1) Pair Programming - der größte Work-Forcer, nur weil es unpraktisch ist, all diesen Aufschub zu machen, wenn zwei von Ihnen zusammensitzen.

2) Kurzgeschichten - Wenn Sie einen RIESIGEN Teil Ihrer Arbeit in zB einem Monat erledigen müssen, ist es ziemlich üblich, in den ersten drei Wochen nachzulassen und für die letzten in den OMG DEADLINE-Modus zu wechseln.

Und mit den kleinen Stücken (die in einem Tag oder weniger erledigt werden müssen) ist es genau umgekehrt - Sie haben das Gefühl, dass die Zeit knapp ist, es keinen Handlungsspielraum gibt und Sie bald für die Aufgabe zur Rechenschaft gezogen werden müssen, also fangen Sie an sofort arbeiten.

3) Teamkommunikation und Zusammenhalt - wenn Sie in einem langsamen, distanzierten und stillen Umfeld unterdurchschnittlich abschneiden, fühlt es sich vielleicht in Ordnung an, aber wenn am Ende des Scrum-Meetings jeder das Erreichte vorträgt und Sie nichts zu sagen haben, können Sie sich tatsächlich fühlen beschämt.

4) Testen und Rückmeldungen - erneut wird verhindert, dass Sie Aufgaben "zu 99% bereit" halten (wenn es tatsächlich um 20% geht), bis die Frist plötzlich eintritt.

Haben Sie das Gefühl, dass Sie unter Agile mehr arbeiten als unter "konventionellen" Methoden? Wird dieser Druck durch die angenehmere Umgebung und das Gefühl ausgeglichen, die richtigen Dinge schnell zu erledigen?

Fixpunkt
quelle
2
Lesen Sie dies. steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
Rob Stevenson-Leggett
3
Ich denke, dass Agilität Programmierer effizienter macht, indem sie es glücklicher macht. Natürlich überwindet es den Aufschub, weil sich die beiden Programmierer sehen und das Gefühl, Ideen von Codes zu teilen, weitaus lohnender ist als das Lesen von Blogs oder das Beantworten von Fragen auf SE.com
Takt
1
Agiles Programmieren scheint also EPISCHES GEWINN zu sein, oder?
Adam Arold
2
Vom "Deadline-Effekt" gehört? Kurz vor dem Termin verdoppelt sich die Effizienz beinahe - Agilität hält 2-wöchige Iterationen aufrecht, um Langeweile (Leerlauf) auszugleichen, und die Angst, Sie könnten produktiv sein!
PhD
Mit Agile erledigen Sie Ihre Arbeit nur mit Eigenverantwortung! Wenn es DEIN ist, verbringst du mehr Zeit damit als Kaffee, Surfen, Blogs. Und da es DEIN ist, wirst du einen positiven Grund haben, es anzuerkennen und zu beenden - genauso wie die anderen. Daher sind die Chancen, dass das "Team" das Ziel erreicht, besser! :)
PhD

Antworten:

38

Die Grundidee hinter den agilen Methoden ist es, Ihnen zu helfen, produktiv zu sein - im positiven Sinne. Es interessiert niemanden, ob Sie eine Stunde lang jeden Tag surfen, wenn Sie die Frist einhalten. Jeder wird sauer, wenn Sie jeden Tag eine halbe Stunde surfen, aber Ihre Deadline verpassen. Die Lösung: Erleichtern Sie Ihnen das Einhalten der Frist.

Wie Sie bemerkt haben, sorgt die Paarprogrammierung dafür, dass Sie konzentriert bleiben (neben anderen Vorteilen wie der Verbesserung der Verbreitung von Fähigkeiten / Wissen, besserem Code, weniger Fehlern, einheitlichem Design usw.).

Ich fand, dass Disziplin für mich immer ein Kampf ist. Wenn ich mich mit jemandem paare, ist die Wahrscheinlichkeit groß, dass einer von uns heute etwas Arbeit möchte und den anderen mitnimmt. So wird die "Arbeit für einen Monat" oft zu "Arbeit für eine Woche zusammenarbeiten", und man wundert sich, wie viel Arbeit am Ende erledigt wurde, einen Tag oder so damit verbracht wurde, sich zu erholen (Refactoring, Beheben von TODOs im Code, Hinzufügen von a ein paar Tests, mit gutem Gewissen surfen) und dann den nächsten Monat der Arbeit packen.

Nettoergebnis: Ich bin viel entspannter (mehr als trotz ständiger Aufsicht), der Zusammenhalt im Team ist viel besser, die Arbeit wird schneller erledigt, die Leute bleiben nicht stunden- oder tagelang bei einem kleinen Problem (weil es jemand anderes kann) das Problem viel schneller erkennen).

Wenn Sie sagen "Sie schämen sich vielleicht wirklich", ist das nicht eine gute Sache? Es bedeutet, dass Sie das Gefühl haben, falsch zu liegen, und Sie sollten es tun. Du wirst nicht dafür bezahlt, dass du nichts tust. Wenn Sie nichts erledigen, fühlen Sie sich hilflos, unglücklich, unwürdig und elend. Anstatt sich zu schämen, treten Sie zurück und denken Sie: "Warum habe ich heute nichts erreicht?" Brauchst du Hilfe? Gibt es etwas, das du nicht verstehst? Ist die aktuelle Aufgabe zu schwer? Gefällt es dir nicht Vielleicht kannst du die Aufgabe mit jemand anderem tauschen. Vielleicht kann Ihnen jemand anderes helfen, durchzukommen. Agil bedeutet: Verantwortung übernehmen, anstatt wie eine Marionette auf Streichern im Mikro verwaltet zu werden. Benötigen Sie ein Werkzeug? Geh zu deinem Chef und frag danach. Lernen Sie zu argumentieren. Lerne aufzustehen und zu schreien, wenn du musst.

Bei Tests gibt es einen Sweet Spot, wenn Ihr Code plötzlich von "schön" zu "perfekt" zusammenbricht. In diesem Moment stellen Sie fest, dass Sie Feature X implementieren müssen, und Sie dachten, dass dies ein Albtraum wird, und stellen plötzlich fest, dass der Code fast da ist. Nur ein kleines Refactoring hier und da. Eine neue Klasse und fertig. Aus vier Wochen Arbeit wurde plötzlich ein Tag. Sieg! Triumph!

Aaron Digulla
quelle
20

Genau.

Paar-Programmierung

Ist eine sehr intensive und umfassende Arbeitsweise, und ich wende sie nur an, wenn ich einige Entwickler habe, die von anderen geschult werden müssen (zum Beispiel Neulinge).

Kurzgeschichten

Teamkommunikation und Zusammenhalt

Testen und Feedback

Ja. Agil und speziell Scrum ist eine enorme Produktivitätssteigerung. Bei korrekter Anwendung kann der Umsatz bis zu 20% betragen (1 Entwickler auf 5 verlässt das Unternehmen).

Der Grund ist einfach: Scrum bietet keine höhere Produktivität it provides the whole company with much more visibility on what's going on(natürlich auch nicht in der Verwaltung).

  • Es ist für einen Entwickler unmöglich, nur das Nötigste zu tun. Das nackte Minimum ist jetzt der Mannschaftsdurchschnitt!

  • Es macht es dem Management unmöglich, nicht richtig zusammenzuarbeiten.

Aus diesem Grund habe ich (in meinen anderen Antworten zu ähnlichen Fragen) gesagt, dass Agile NICHT für jede Organisation (und für alle) gilt.

Zum Beispiel ist der öffentliche Sektor wirklich nicht für Agile geeignet.

Agile als Druckmittel eingesetzt? Das habe ich natürlich schon oft gesehen. Es macht die Dinge nur noch viel schlimmer.


quelle
7
Re: anstrengend. Wir programmieren Paare in meinem Büro. Es sind 8 Stunden super intensives Zeug ... und dann kannst du einfach nach Hause gehen. 40 Stunden Arbeitswoche im Herzen des Silicon Valley. (Verhindert Burnout).
2
+1 für "Agile ist NICHT für jede Organisation".
Ryan Hayes
Gute Antwort. Haben Sie auch eine Quelle für dieses "(1 Entwickler auf 5 verlässt das Unternehmen)". Wäre interessant, die ganze Geschichte zu lesen.
Jan_V
@Jan_V: Ken Schwaber selbst (2008). Leider wurde das nicht aufgezeichnet.
+1: Sehr gute Antwort. Agile ermöglicht es, die Entwicklung viel genauer zu verfolgen, erhöht jedoch nicht unbedingt die Produktivität. Viele Programmierer brauchen keine Paarprogrammierung, um motiviert zu sein: Ein interessantes Problem kann ausreichen, um sie 10 Stunden hintereinander am Laufen zu halten. In bestimmten Situationen kann SCRUM die Produktivität um 50% oder mehr senken. Aber all diese Geschichten werden immer mit dem folgenden Satz erklärt: "Du machst es nicht richtig."
Giorgio
8

Haben Sie das Gefühl, dass Sie unter Agile mehr arbeiten als unter "konventionellen" Methoden? Wird dieser Druck durch die angenehmere Umgebung und das Gefühl ausgeglichen, die richtigen Dinge schnell zu erledigen?

Es bringt mich dazu, mehr zu arbeiten, aber vor allem bringt es mich dazu, an der richtigen Sache zu arbeiten. Zu jedem Zeitpunkt weiß ich, was ich tun soll .

Es ist eine Art Überdruck. Das ist etwas ganz anderes als bei einigen anderen "Du bist bereits hinter dem Zeitplan zurück, arbeitest mehr, machst Überstunden!" Art von Druck.

Joonas Pulakka
quelle
7

Eigentlich bin ich mit den herkömmlichen Methoden viel produktiver. Mit der konventionellen Methode erstelle ich zB innerhalb weniger Monate eine detaillierte Anforderungsanalyse, eine Machbarkeitsstudie, eine Funktionsspezifikation, eine technische Spezifikation und viele Besprechungsprotokolle! Möglicherweise erstelle ich sogar einige Codezeilen, wenn die Auswirkungsanalyse abgeschlossen ist!

Alles, was ich erschaffe, sind ein paar Ergebnisse.

user281377
quelle
4

In unserem Unternehmen,

Paarprogrammierung - Wenn etwas wirklich komplex ist und eine umfassende Analyse erfordert, würden sogar wir zwei hervorragende Personen zusammenbringen und die Aufgabe in SCHNELLER Zeit erledigen. Hier entscheidet die Komplexität der Aufgabe über die Notwendigkeit der Paarprogrammierung.

Kurzgeschichten - Dann für 3 Wochen (ca. 5-6 Stunden pro Tag) nachlassen und im letzten Moment (ca. 12 bis 14 Stunden pro Tag) als Entwickler loslegen. Ich mag es nicht, wenn meine Arbeitsbelastung schwankt. Arbeiten Sie ungefähr 8 Stunden pro Tag und halten Sie Ihren Zeitplan stabil und das sieht immer COOL aus.

Teamkommunikation und Zusammenhalt - In Scrum Meetings teilen wir nicht nur den Aufgabenstatus, sondern auch die Hindernisse. Wenn jemand wirklich Hilfe benötigt, kommen andere Mitglieder auf ihre Ideen, um ihm zu helfen. Aber dafür brauchst du auf jeden Fall ein exzellentes Team und wir sind :)

Testen und Feedback - Natürlich möchte ich als Entwickler nicht, dass ich endlich mit Bugs belastet werde. Der nächste Moment, nachdem Sie einen Bug gefunden haben, war, ihn zu beheben, und dies würde mir eine gute Prognose darüber ermöglichen, was sollte / kann als nächstes durchgeführt werden und die Frist (falls erforderlich) entsprechend verschieben.

Als Entwickler bin ich also sehr zufrieden mit der Art der Aufgabe, die ich mir stelle, und verdammt sicher kann ich sagen, dass ich nie den WIRKLICHEN Termindruck verspürt habe.

Gopi
quelle
4

Haben Sie das Gefühl, dass Sie unter Agile mehr arbeiten als unter "konventionellen" Methoden?

  • Wenn Sie meinen, fühle ich mich unter Agile produktiver, würde ich sagen, es kommt darauf an .
     
    Normalerweise denke ich an Ferrari (wie konventionell) und Landrover (wie Scrum). Beim Fahren auf einer Autobahn schlägt Ferrari die Hölle aus Landrover.
     
    Es ist das Gelände, wenn man keinen Sportwagen braucht - ich meine, wenn Ihre Anforderungen unregelmäßig sind und / oder wenn die Teamarbeit und die Managementerfahrung nicht so gut sind, müssen Sie sich für Scrum entscheiden - einfach, weil Sie versuchen werden, konventionell zu fahren du steckst fest - wie Ferrari im Gelände stecken bleibt.

Was "Arbeit mehr" angeht, denke ich, dass solche Dinge den IQ des Programmierers und dessen Fähigkeit, sich an verschiedene Formen von Management-Demenz anzupassen, wahrscheinlich unterschätzen .

Bisher habe ich an zwei Scrum-Teams teilgenommen, die in verschiedenen Unternehmen ganz unterschiedliche Projekte durchgeführt haben. In beiden Teams habe ich keine Änderung meiner Gewohnheiten im Vergleich zu zB Wasserfall / iterativ bemerkt.

Ich wäre stolz darauf zu behaupten, dass das so ist, weil ich so speziell und unbesiegbar bin, aber ehrlich gesagt habe ich gesehen, dass die Gewohnheiten aller anderen Jungs im Team auch unbesiegbar sind.

Mücke
quelle
"Was" Arbeit mehr "angeht, ich denke, man kann davon ausgehen, dass solche Dinge den IQ von Programmierern und ihre Fähigkeit, sich an verschiedene Formen von Management-Demenz anzupassen, unterschätzen." Konzentrieren Sie sich auf ihre Aufgaben. IMO gilt dies insbesondere für unerfahrene Entwickler und schlechte Planer. Für erfahrene Programmierer sehen diese Praktiken natürlich wie Management-Demenz aus , dh sie können nur sehr wenig oder gar keinen Nutzen daraus ziehen.
Giorgio
@Giorgio yeah Ich habe so etwas gemeint, als ich sagte, dass "wenn das Team nicht so gut ist" ein guter Grund ist, Agilität zu bevorzugen. Ich möchte nur bemerken, dass es eine Art Utopie ist, von Agilität zu erwarten, dass sie "mehr arbeiten" - oder genauer gesagt, ein bisschen zu einfach, um gut zu funktionieren. Ich habe es erfolgreich verwendet zu sehen lehrt besser unerfahrene Entwickler und schlechte Planer Arbeit und Plan / mehr
gnat
2
Darüber hinaus können für erfahrene Programmierer alle SCRUM-Rituale den Denkprozess beeinträchtigen. Um mit Ihrer Metapher fortzufahren: Wenn Sie einen Ferrari auf einer geraden Straße fahren, werden Sie nur langsamer, wenn Sie alle 2 km anhalten müssen, um zu überprüfen, ob Sie in die richtige Richtung fahren. Aber ja, es wird (schlechten) Managern helfen, ein Gefühl der Kontrolle zu haben.
Giorgio
@ Giorgio einverstanden. Soweit ich das beurteilen kann, stimmt meine Metapher perfekt :)
Mücke
2

Agile zwingt Programmierer zu nützlicherer Arbeit, da die verschiedenen Techniken der agilen Entwicklung viel Arbeit und Arbeit, die einfach nicht benötigt wird, aussortieren.

Jay Godse
quelle
2
Zitat benötigt. Das ist eine kühne Behauptung; Ich habe viel Arbeit in "agilen" Umgebungen gesehen.
2

Es ist unpraktisch, diesen ganzen Aufschub zu machen, wenn zwei von euch zusammensitzen.

Ich stimme dir nicht zu. Ich habe mit einer Gruppe von Rauchern zusammengearbeitet und sie haben es alle geschafft, ihre gemeinsame Pause für längere Zeit einzulegen, weil "alle das gemacht haben".

häufig in den ersten drei Wochen nachlassen

Dies ist ein Zeichen für ein schlechtes Management, unabhängig von der Methodik. Selbst wenn ein großer Teil in einem Monat fällig ist, würde ich Ende der ersten Woche etwas erwarten.

Sie haben nichts zu sagen, Sie könnten sich tatsächlich schämen.

Wenn du bereit bist, drei Wochen lang zu wichsen, fällt dir ein Scheiß ein.

4) Testen und Rückmeldungen - erneut wird verhindert, dass Sie Aufgaben "zu 99% bereit" halten (wenn es tatsächlich um 20% geht), bis die Frist plötzlich eintritt.

Wasserfallprojekte können Tests und tägliche Builds haben.

Persönlich würde ich es hassen, Code zu schreiben und einen Monat lang nichts damit zu tun haben. Ich bevorzuge die kürzere Rückkopplungsschleife für meinen Code, unabhängig davon, ob es sich um eine codierte Überprüfung oder eine Benutzerabmeldung handelt. Es lohnt sich, andere von meiner Arbeit überzeugen zu lassen. Es ist, als würde die Katze eine Maus vor Ihrer Haustür abwerfen, um Sie wissen zu lassen, dass sie ihren Job macht.

JeffO
quelle
1

Agile zwingt Entwickler nicht dazu, mehr zu arbeiten , sondern effizienter zu arbeiten

greuze
quelle
1
und produktiver, was semantisch wichtiger ist.
Tut es aber
Casey
0

Die Formulierung der Frage, ob Entwickler gezwungen werden sollen, mehr zu arbeiten, wirkt sich ein wenig negativ aus, aber ist es sicherlich positiv, wenn wir tatsächlich mehr erledigen und weniger zögern?

Das heißt, es ist ein guter Punkt. Ich habe mich in diesem Jahr ein bisschen agil gefühlt, aber das ist ein riesiger, ungeschriebener Vorteil, den ich nicht anerkannt habe.

Ich würde zustimmen, dass Agilität dazu führen kann, dass Entwickler produktiver sind. Ihre Aussagen zu Sichtbarkeit, Rechenschaftspflicht und der Tendenz, weniger zu zögern, sind zutreffend.

Agilität kann und sollte aber auch dazu führen, dass Entwickler aus positiven Gründen härter arbeiten - die Karotte gegen die Peitsche. Wenn Sie dies gut machen, erhalten Entwickler durch Agilität mehr Interaktion mit Benutzern, weniger Bürokratie und mehr Kontrolle über ihre Arbeit. All dies kann dazu führen, dass Sie mehr aus Ihrem Team herausholen.

Benjamin Wootton
quelle
1
Wenn Sie Recht haben, geht es bei Agile nicht darum , härter zu arbeiten, sondern effizienter an den wertvollsten Dingen zu arbeiten . Aufgrund meiner jahrelangen Erfahrung arbeiten Entwickler weniger hart, da sie realistischere Termine und Ergebnisse haben. in der gleichen Zeit viel produktiver zu sein , führt dies zu * Effizienz *
Bei No Agile geht es nicht darum, die Arbeit effizienter zu gestalten (und dies gilt nicht für alle Besprechungen, Sprint-Überprüfungen usw.), sondern es ist vorhersehbarer : Sie legen keine Frist fest und arbeiten dann effizient, um diese einzuhalten, sondern überwachen der Prozess, damit die von Ihnen gesetzten Fristen angemessener werden. Es geht also nicht um Produktivität, sondern um Berechenbarkeit .
Giorgio
0

mehr arbeiten ist noch nicht semantisch korrekt oder relevant für agile, das ziel ist produktiver zu sein . Es konzentriert sich speziell darauf, weniger an der falschen Sache zu arbeiten, sondern mehr darauf, normal an der richtigen Sache zu arbeiten. Das heißt nicht, mehr zu arbeiten , nur produktiver .

Ein Nebeneffekt ist, dass Faulenzer aufgedeckt werden und diejenigen, die sehr schnell ineffizient oder unfähig sind. Was eher nach dem klingt, worauf du hinaus willst.

Die Methodik spielt keine Rolle, ob ein Entwickler nicht arbeitet oder nicht . Prozess ist, auch in Wasserfällen, Management-Überprüfungen und Code-Überprüfungen können diese Dinge ebenso aufdecken, nur nicht so transparent wie die meisten agilen Methoden.


quelle
-2

"Gewehre töten nicht Leute. Leute töten Leute!" So ist es auch mit Agile. Agilität bringt Menschen nicht dazu, mehr zu arbeiten, Manager bringen Menschen dazu, mehr zu arbeiten.

DPD
quelle
2
Manager bringen Menschen nicht dazu, mehr zu arbeiten. Klare Sichtbarkeit und schnelles Feedback machen Lust auf mehr Arbeit.
Sean McMillan
Ja, aber bis zu welchem ​​Punkt? In einem Sprint erhälst du 10 Geschichten, im nächsten Sprint: 15, im nächsten Sprint: 20, im nächsten Sprint: 25. Wie lange dauert es, bis das Team sein menschliches Limit erreicht und der nicht wirklich agile Manager entscheidet, es höher anzusetzen? Vielleicht warst du mit einer solchen Situation nicht konfrontiert. In einem wirklich agilen Projekt entdecken Sie die Geschwindigkeit Ihres Teams im Verlauf der Sprints. Möglicherweise können Sie höchstens mit einer Marge von 10% arbeiten. Nichts mehr.
DPD
2
Bei den erfolgreichen agilen Projekten, die ich durchgeführt habe, verwenden wir das Wetter von gestern, um unsere Iterationen zu planen. Die Anzahl der Punkte, die wir bei der letzten Iteration abgeschlossen haben, ist jedoch so hoch, wie wir diese Iteration planen. Der Manager kann alles, was er will, beschwören / schreien, aber das Team entscheidet, womit es sich wohl fühlt, und genau das wird geplant. (Natürlich hatten wir Director-Level - Buy-in, das heißt, wenn der Manager des Team zu zwingen versucht, er in Schwierigkeiten geraten würde.)
Sean McMillan
@ Sean McMillan - Vielleicht ist ein Manager nicht so ein Unterschiedsmacher, wenn ein Regisseur total agil ist, aber das ist selten der Fall.
JeffO