Agile 40-Stunden-Woche

Haben Sie schon einmal an einem (Vollzeit-)Projekt gearbeitet, bei dem Sie mit agilen Methoden tatsächlich eine 40-Stunden-Woche erreichen konnten? Wenn ja, was waren die wertvollsten agilen Praktiken?

Antwort auf "Agile 40-Stunden-Woche " 8 von antworten

Scrum und Management, das bereit ist, sich darin einzukaufen.

Fair Sprint Planung. Wenn Sie Ihren eigenen Sprint aushandeln, können Sie auswählen, was Ihr Team leisten kann, anstatt Aufgaben von oben überliefern zu lassen. Wenn Sie Ihr Sprint-Engagement festsperren lassen (das Management kann es im Sprint nicht ändern), wird die Freiheit von allen wechselnden Launen der Menschen.

Ein gut gepflegter, priorisierter Rückstand, der kooperativ vom Produktbesitzer und oberen Management aufrechterhalten wird, ist sehr nützlich. Es zwingt sie, sich zusammenzusetzen und über die Funktionen nachzudenken, die sie wollen, wann sie sie wollen und die damit verbundenen Kosten. Sie werden oft sagen, dass sie ein Feature jetzt brauchen, aber als sie erkannten, dass sie etwas anderes aufgeben müssen, um das zu bekommen, was sie wollen, werden ihre Erwartungen realistischer.

Zeitboxen. Wenn Sie große Probleme haben, beginnen Sie, Features aus dem Sprint zu entfernen, anstatt zusätzliche Stunden zu arbeiten.

Sie brauchen Management-Unterstützung für Sie Prozess ohne es agil ist nur ein Wort.

Habe ich ein aufgeklärtes Management erwähnt?

Ja, ich bin auf einer 40-Stunden-Woche (eigentlich sind es 37,5 Stunden oder so, das sagt mein Vertrag) auf einem Projekt, das von Anfang an mit SCRUM lief. Das war vor etwa 2 Jahren und das erste Mal, dass wir SCRUM implementiert haben. Es ist das Projekt mit der geringsten Menge an Überstunden für mich persönlich, und es ist auch ein PC-Spiel, das wir entwickeln. Ich bin nicht einmal im "Crunch"-Modus im Moment, obwohl wir eine offene Beta am Freitag versenden.

Wir haben seitdem viel über SCRUM und Agile gelernt. Die wertvollste Lehre aus meiner Sicht ist: Pod-Größen müssen vernünftig sein ... Wir begannen mit Pods mit 12-20 Mitgliedern, das hat überhaupt nicht gut geklappt. Maximal 10 sollten nicht überschritten werden. Es ist zu einfach, sich auf "flaky" und "vague" Aufgaben zu einigen, weil sonst die Standup & Aufgabenplanung Sitzungen zu lange dauern würde. Halten Sie also die Pod-Größe klein und die Aufgaben spezifisch und erhalten Sie den Produktbesitzer oder die Abmeldestellen zusammen mit denen, die an der Aufgabe arbeiten.

Außerdem müssen Sie mit einem zweiwöchentlichen Aufgabenplanungszeitplan jeden Produktbesitzer dazu bringen, sich auf die Aufgabenliste und die Prioritäten für den aktuellen Sprint zu einigen, und neue Aufgabenanforderungen sollten vor dieser Planungsbesprechung ausgegeben werden, andernfalls wird sie für den aktuellen Sprint ignoriert. Dies zwang uns, die Kommunikation zwischen den Hülsen zu verbessern.

Nicht in der Lage, die Aufgaben in einer 40-Stunden-Woche zu erfüllen könnte aufgrund mehrerer Dinge sein.

Ich sehe, dass dies in den frühen Sprints eines Scrum-Projekts passieren könnte, weil das Team nicht sicher war:

  1. die Menge an Arbeit, die sie im Sprint leisten können und mehr beißen können, als sie kauen können, und
  2. ihre Fähigkeit, die Menge der Punkte genau zu schätzen, die an Arbeitsblöcke vergeben werden müssen, oder
  3. die Menge an Arbeit, die erforderlich ist, um "einen Punkt" auszuführen.

Sie können auch zu optimistisch sein, was sie in der Zeit zutun können.

Danach kommen wir in mehrere der schlechten Gerüche von Scrum, speziell:

  1. ein Team darf nicht seine eigene Arbeitsbelastung besitzen, und vielleicht
  2. Management überschreibt Entscheidungen darüber, was in einem Sprint sein sollte

Wenn einer dieser eingeschnitten, dann sind Sie:

  1. Scrum nur im Namen, und
  2. "up the creek".

Es gibt nichts, was Man tun kann, außer Probleme in der ersten Liste zu korrigieren, aber das wird nur erfahrungsgemäß sein.

Die Korrektur der beiden Punkte in der zweiten Liste erfordert ein großes Umdenken darüber, wie das Unternehmen stranguliert, nicht verwendet, Scrum Best Practices.

HTH

grüße,

Rob

Sicherlich.

Für mich die wichtigsten Dinge, die geholfen haben (in der Reihenfolge der Bedeutung):

  1. Cross-funktions-Team - Programmierer, Tester, technische Autoren und Vertriebs/Dienstleister im selben Team und das Gespräch miteinander täglich (täglicher Anruf) war toll.
  2. Regelmäßige Builds und kontinuierliche Integration
  3. Häufige Bewertungen/Demos für Stakeholder und Kunden. Dies reduziert das Risiko und die Zeit, die ihm nur für den Zeitraum der Iteration (Sprint) verloren gehen.
  4. Tägliches Call- oder Stand-Up-Meeting

Hinzu kommt zu all den oben genannten (ungenaue Schätzungen, schlecht implementiertscrum, etc.), könnte das Problem das Unverständnis für Ihr Team Velocity, something as simple as "how much work a team can accomplish", but which is not that sein, etwas so einfach wie "wie viel Arbeit ein Team leisten kann", aber das ist nicht das easy to find as it may seem. .

Als Scrum Master und Personalmanager war ich ein starker Verfechter der 40-Stunden-Woche. Ich rate Teammitgliedern aktiv davon ab, mehr als 40 Stunden zu arbeiten, da die Produktivität schnell sinkt, wenn sich die Work-Life-Balance verschiebt. Ich habe festgestellt, dass die Erholung von einem spätabendlichen Arbeitstag oft länger dauert als die zusätzlichen Arbeitsstunden.

Wenn es gut ausgeführt wird, hilft Scrum bei der Minimierung des "Cram", das häufig am Ende einer Iteration auftritt, indem es ein konsistentes Tempo im gesamten Durchweg fördert (erfordert?) und Tools wie Geschwindigkeit und Burndowns gut funktionieren, um den Fortschritt zu planen und zu verfolgen.

Ich habe in mehreren Geschäften gearbeitet, die verschiedene agile Methoden praktizieren. Die interessanteste hatte 4 "Sitzungen" im Laufe des Tages, die etwa anderthalb Stunden lang waren, mit einer 20-minütigen Pause dazwischen. Freitag war Personal Dev Tag, so dass die letzten beiden Sitzungen waren für das, was Sie arbeiten wollten.

Die wichtigsten Dinge für uns waren Kommunikation, wirklich nageln das Konzept der User-Storys, definieren getan, um "in der Produktion" zu bedeuten, und Vertrauen. Wir haben auch dafür gesorgt, dass wir die Geschichten in Stücke aufteilen, die nicht länger als einen Tag waren, und idealerweise 1-2 Entwicklungssitzungen. In der Regel haben wir paare in jeder Sitzung zu jeder anderen Sitzung getauscht.

Derzeit führe ich ein 20+ Personen-Entwicklungsteam, das teilweise verteilt ist. Der Hauptmieter für mich ist nachhaltiges Tempo - und das bedeutet, dass ich nicht will, dass meine Teams > 40 Stunden Wochen arbeiten, auch nicht gelegentlich. Natürlich, wenn jemand zu spät bleiben und an Dingen arbeiten will, liegt das an ihnen, aber im Allgemeinen kämpfe ich hart, um sicherzustellen, dass wir innerhalb der Geschwindigkeit arbeiten, die uns eine 40-Stunden-Woche gibt.

Es mag hart klingen, aber lassen Sie uns realistisch sein. Die Verwendung von agilen oder anderen Geschmack seeinem Softwareprozess hat nichts mit einer 40-Stunden-Woche zu tun. Normalerweise ist die Höhe der wöchentlichen Arbeitsstunden im Arbeitsvertrag festgelegt und Entwickler können ihr Ermessen nutzen, um zusätzliche unbezahlte Arbeit zu setzen.

Bitte lassen Sie’s keine magischen Heilungskräfte zu, was auch immer Ihr bevorzugter Softwareprozess ist. Sie kann einen anderen Ansatz für das Risikomanagement, einen unterschiedlichen Planungshorizont oder eine bessere Einbeziehung der Interessenträger bieten; Aber es sei denn, Sklaverei ist dort noch rechtmäßig, Sie leben den Arbeitstag beginnt, wenn Sie durch die Tür kommen und endet, wenn Sie nach Hause gehen.

Es ist ebenso Aufgabe eines Bauträgers, dafür zu sorgen, dass der Arbeitsvertrag nicht verletzt wird, ebenso wie gegen sein Management. Ihr Einsatz ist begrenzt durch die Höhe des Lohns, den Sie erhalten, und die Höhe der ehrlichen Arbeitsstunden, die Sie im Gegenzug zu geben vereinbart haben, unabhängig von einer verwendeten Methodik.