it-swarm.com.de

Ist es eine "agile" Arbeitsweise, feste Liefertermine für Elemente zu haben?

Uns wird immer wieder gesagt, dass wir von der Geschäftsleitung agil an einem neuen Projekt arbeiten werden. Sie haben Stand-Ups, Sprint-Planungen, Rückblicke usw. usw. eingerichtet. Jetzt haben sie jedoch einen Plan erstellt, in dem alle Arbeiten aufgeführt sind, die wir mit Daten für jedes Element liefern sollen, und die Daten erneut mit den jeweils vorgestellten Demos präsentiert werden einer. Dieser Plan gilt für das zweite Quartal 2017.

Für mich scheint dies im schlimmsten Sinne ein Wasserfall zu sein. Es wurde ein Plan ohne Eingaben des technischen Teams erstellt, in dem bestimmte Geschichten auf dem Plan sehr unklar sind und keine vom Entwicklerteam geschätzt wurden.

Ich weiß jedoch, dass ihr Argument lautet: "Senior Stakeholder müssen Termine haben und es muss einen Plan geben, wir können nicht einfach aus einem Rückstand heraus arbeiten." Für mich scheint dies, dass hochrangige Stakeholder sich nicht für Agile entschieden haben, und daher sind wir dazu verdammt, die Implementierung auf einer niedrigeren Ebene zu scheitern.

Ist das ein faires Urteil oder überreagiere ich auf diesen Plan?

47
Sutty1000

Es gibt einen Unterschied zwischen der Einhaltung der Frist und der Erfüllung aller Anforderungen. Es ist wie das alte Sprichwort "schnell, gut oder billig, wählen Sie zwei".

Hier haben Sie also feste Liefertermine - das ist gut, es bedeutet, dass Sie zeitlich festgelegt sind, dass das, was Sie am Ende Ihres letzten Sprints liefern, das Endprodukt sein wird. Sie erinnern sich, dass Sie immer am Ende jedes Sprints funktionierende Software veröffentlichen müssen, nicht wahr?.

Was passieren kann ist, dass der endgültigen Software einige Funktionen fehlen. Nun, dies geschieht mit allen Entwicklungsmethoden, einschließlich Wasserfall. Alles, was passieren wird, ist, dass Sie danach mit der Erstellung eines Patch-Releases oder einer Version 2 beauftragt werden. Dies setzt natürlich voraus, dass Ihre endgültige Lieferung gut genug ist!

Feste Termine sind also keine unagile Arbeitsweise. Agil bedeutet nicht, dass Sie ein unbegrenztes Budget haben, um mit Ihren neuen Planungstools zu spielen. Es bedeutet, dass Sie sich auf die Lieferung konzentrieren müssen, das ist nie eine schlechte Sache.

60
gbjbaanb

Nein. Dies ist genau die Art von Dingen, die Nicht-Software-Unternehmen tun. Es gibt Pläne, Fristen und Budgets. Und es wird unweigerlich scheitern, da die Menschen die Zukunft nicht vorhersagen können.

Lassen Sie uns hier die verschiedenen Punkte durchgehen:

Uns wird immer wieder gesagt, dass wir von der Geschäftsleitung agil an einem neuen Projekt arbeiten werden.

Wenn Sie agil wären, hätten Sie selbstorganisierte Teams, denen das Management nicht sagt, wie sie arbeiten sollen.

Jetzt haben sie jedoch einen Plan ausgearbeitet, in dem alle Arbeiten aufgeführt sind, die wir mit Daten für jedes Element liefern sollen, und die Daten erneut mit den in jedem einzelnen vorgestellten Elementen präsentieren.

Nee. Das ist so ziemlich das Gegenteil von iterativer Entwicklung. Es wird etwas passieren (jemand wird krank, jemand geht, eine Anforderung wurde vergessen, Ihre Server sterben, was auch immer) und dann verfehlen Sie eines dieser Ziele. Jetzt kann das Management entweder den gesamten Plan neu berechnen oder die Peitsche bei der Entwicklung knacken.

keine wurde vom Entwicklerteam geschätzt.

Woher weiß das Management, dass dieser Plan überhaupt realisierbar ist ? In Agile ist Arbeit eine Verhandlung. Das Geschäft sagt: Das würde uns gefallen. Das Engineering sagt: Okay, unter der Annahme von XYZ wird das 3 Wochen dauern. In dem, was Sie beschreiben, gibt es keine Zusammenarbeit mit Kunden. Keine Individuen und Interaktionen.

Für mich scheint dies, dass hochrangige Stakeholder sich nicht für Agile entschieden haben, und daher sind wir dazu verdammt, die Implementierung auf einer niedrigeren Ebene nicht durchzuführen.

Du bist nicht unbedingt zum Scheitern verurteilt, aber wenn nicht, ist es nur ein Zufall. Wenn die gesamte Arbeit angezeigt wird, weil das Management die Zukunft nicht sehen kann, verpassen Sie Ihre Daten (oder produzieren schlechten Code oder benötigen mehr Ressourcen als erwartet). Das wird dann deine Schuld sein. Das Management wird Sie dann wahrscheinlich unter Druck setzen, mehr Stunden zu arbeiten, um das Datum zu erreichen, oder vielleicht Leute auf das Problem aufmerksam machen.

Bester Fall, das Management ist tatsächlich agil und intelligent genug, um den Umfang zu reduzieren. Das heißt, sie haben die ganze Zeit damit verbracht, einen großen detaillierten Plan zu erstellen, der wertlos ist.

37
Telastyn

Wenn erwartet wird, dass bestimmte Funktionssätze zu bestimmten Terminen bereitgestellt werden, ist dies kein agiles Projektmanagement. Agiles Projektmanagement ist empirischer Natur. Projektionen basieren nicht auf den Wünschen der Führungskräfte, sondern auf der Analyse der vorherigen Leistung.

Ihre Beschreibung stimmt mit dem überein, was ich für frachtkultig halte. Der Fokus liegt auf den spezifischen Prozessen und Zeremonien und nicht auf den Kernkonzepten des evidenzbasierten Projektmanagements. Sie könnten etwas Glück haben, Geschäftsleute zu verstehen, wenn Sie dies mit Lean oder TPS in Verbindung bringen. Das eigentliche Problem, das Sie hier lösen müssen, besteht darin, das Management über die Angst vor dem Unbekannten hinauszubringen. Die richtige Antwort an die Führungskräfte lautet: "Wir können Ihnen jetzt nicht sagen, wann die Dinge erledigt werden, aber sobald wir anfangen, Wert zu liefern, können wir auf der Grundlage unserer Erfahrung Projektionen erstellen." Entwickler neigen dazu, Dinge wie "es ist fertig, wenn es fertig ist" und "Ich weiß nicht, wann es fertig sein wird" zu sagen. Manager werden den Führungskräften solche Dinge nicht sagen, es lässt sie wie Nincompoops klingen. Sie tun einfach das, was sie wissen.

Höchstwahrscheinlich wird der Plan scheitern und muss überarbeitet werden. Das größte Risiko für das Team besteht darin, dass die Termine eingehalten werden und die Qualität darunter leidet. Irgendwann werden Sie nicht mehr am Ziel sein (höchstwahrscheinlich wird es die erste Frist sein) und es wird einen Push geben, um dieses Datum zu erreichen. Überstunden werden erwartet und es wird Druck geben, Ecken zu kürzen (Unit-Test überspringen, Code-Überprüfungen usw.). Dies ist ein rutschiger Hang, und sobald Sie diesen Weg eingeschlagen haben, ist es eine Art Abwärtsspirale und die Dinge werden hässlich. Die Produktivität wird sich verschlechtern, wenn das Projekt auf diese Weise fortgesetzt wird.

Wenn Sie das Entwicklerteam dazu bringen können, eine einheitliche Front zu präsentieren, sollten Sie wirklich zurückschieben und die Qualität beibehalten. Ich habe die Erfahrung gemacht, dass Projektmanager dazu neigen, die Software-Ausgabe für linear zu halten. Das heißt, jede Periode X erzeugt Y 'Prozentsatz vollständig'. Das heißt, wenn Sie nach der Hälfte der zulässigen Zeit nicht zu 50% fertig sind, fangen die Klaxons an zu dröhnen. Wenn Sie es richtig machen, dauert das erste Feature in der Regel viel länger als das 50. Feature (von ähnlicher Größe). Wenn Sie diese anfängliche Gefahrenkrise überstehen können ("Was passiert?", "Ich nicht". Ich sehe nichts erledigt! ") Du wirst wahrscheinlich in Ordnung sein.

18
JimmyJames

Willkommen im echten Geschäft.

Es gibt einen älteren Geschäftsstil, den ich eher spöttisch als "traditionelle Entwicklung" bezeichne, und dann gibt es einen neuen Stil, "agile Entwicklung". Wenn ich versuche, diese als gegensätzliche Ideale zu behandeln, sehen wir eine klare Trennung in der Mitte: Pläne und Anforderungen gehen in die traditionelle Spalte, Entdeckung und Evolution in die agile Spalte. Es ist ordentlich, ordentlich und falsch.

In Wirklichkeit ist das Geschäft eine Suche nach dem glücklichen Medium zwischen beiden. Es ist leicht zu zeigen, dass jedes Extrem tatsächlich flach auf sein Gesicht fällt. Wir, die wir Agile lieben, demonstrieren eifrig alle Fragen des reinen Ideals der traditionellen Entwicklung, und es gibt viele, die zeigen können, auf welche Weise reines Agile auseinander fällt. Die erfolgreichen agilen Unternehmen sind diejenigen, die ihr besonderes Gleichgewicht zwischen den beiden finden. Die erfolgreichen traditionellen Unternehmen sind diejenigen, die ihr besonderes Gleichgewicht zwischen den beiden finden. Sie können keines ohne das andere haben.

Sogar unser gesegneter SCRUM-Prozess zeigt ein Gleichgewicht zwischen beiden. Während es einen klaren Versuch gibt, die Agilität zu maximieren, gibt es einige wichtige Kompromisse. Zum Beispiel hat der Product Owner die mächtige Aufgabe, sich für alle Kunden einzusetzen. SCRUM gibt absichtlich nicht an, wie diese Interaktion funktioniert. Es wird absichtlich darauf hingewiesen, dass jeder am Ende des Tages bezahlt werden muss. Es ist die Aufgabe des Product Owners, die Illusion zu erzeugen, dass das keine Rolle spielt.

(Es ist interessant zu bemerken, dass pure Agile großartig funktioniert, solange Sie erst bezahlt werden, wenn Sie ein Produkt produzieren, und Sie erst dann Zugriff auf proprietäre Informationen erhalten, wenn Sie unverfallbar sind. Ich denke, die einzigen Software-Ingenieure, die sich wohl fühlen mit diesem Handel sind die Unternehmer)

Das Management hat also festgelegt, welche Funktionen dort enthalten sein sollen und wann sie vorhanden sein müssen. Das ist gut. Ein Satz, den ich gehört habe, ist "Der Kunde wählt das Was und Wann, der Produzent das Wer und das Wie." Sie wurden für das "Was" und das "Wann" angemeldet. Sie haben nichts über das Wer oder Wie gesagt, außer Ihnen die Möglichkeit zu bieten, "Agile" als Ihr Wie zu verwenden. Alles, was übrig bleibt, ist dem Management zu helfen, zu verstehen, wie viele Leute sie einstellen müssen, um ihre Bedürfnisse zu erfüllen.

In einer perfekten Welt ist Ihr Unternehmen von außen agil. Es interagiert agil mit seinen Kunden und lässt die Entwickler agil für sie entwickeln. Sehr oft muss das Unternehmen jedoch mit dem Äußeren interagieren, während es sich innen agil entwickelt. Dazwischen gibt es immer eine komplexe Reihe von Kompromissen, die für jedes Unternehmen einzigartig sind.

Persönlich betrachte ich diese Situation als Testfall für jeden, der glaubt, die agile Entwicklung zu verstehen. Irgendwann in der Zukunft müssen Sie ein Produkt für eine Frist entwickeln, und dieses Produkt/Frist-Paar wird relativ fest sein. Wenn ein festes Produkt/eine feste Frist Ihren Prozess erschüttert, können Sie wirklich sagen, dass Sie überhaupt agil waren?

Mein Rat: Betrachten Sie dies nicht als Wasserfall. Sie steuern immer noch das "Wie". Sie können immer noch all das schnelle Sprinten und flexible Prototyping durchführen, für das Agile so berühmt ist. Sie haben nur um sich bewusst zu sein, dass der Gummi auf die Straße trifft und man liefern muss. Dies ist die reale Welt, nicht die ideale Welt. Wäre es für sie besser gewesen, Sie überhaupt zu fragen? Sicher. Möglicherweise war es nicht Ihr Anruf. Es kann tausend geschäftliche Gründe dafür geben, die Sie einfach nicht vollständig verstehen. Fühlen Sie sich frei, sie zurückzudrängen, aber verstehen Sie, dass sie möglicherweise einen sehr guten Grund für das haben, was sie getan haben.

9
Cort Ammon

JEDES geschäftsrelevante Projekt hat Einschränkungen:

  • Zeit
  • Ressourcen
  • Ein erwarteter Mindestfeaturesatz

Das ist nichts anderes. Agilität zu entwickeln bedeutet nicht, dass "die Leute uns Geld bezahlen, damit wir entwickeln können, wofür wir wollen, wann immer es fertig ist" - Sie haben immer einen gewissen Zeitrahmen. Es wird immer ein Datum mit einigen Mindestanforderungen geben, und wenn diese nicht erfüllt sind, wird das Projekt abgebrochen und als Fehler bezeichnet. Sie können manchmal implizit sein - der Manager weiß also: "Wenn ich nach 4 Wochen keine funktionierende Benutzeroberfläche mit diesen Funktionen habe, ist dieses Projekt zum Scheitern verurteilt" - oder es gibt Aktionäre, die sich ein Ziel setzen.

Es gibt viele Projekte, die sich aus der Gesetzgebung ergeben. - Wenn die Regierung beschließt, Feature X bis 2017 zu implementieren, um ein neues Gesetz einzuhalten, haben Sie eine nicht verhandelbare Frist und eine Reihe von Features, die bereit sein müssen. Die einzige Variable ist die Menge an Ressourcen, die das Management der Aufgabe zuweisen kann. - Und in diesen Projekten, in denen die Frist eine externe Entscheidung ist, müssen sie Ihre Fortschritte beobachten, Ihre Prognose hören und die Teams besetzen oder einen Teil der Arbeit auslagern, um ihre Ziele zu erreichen.

All dies widerspricht nicht der agilen Entwicklung. Sie haben immer noch Ihre Sprints und entwickeln Ihre Funktionen in Ihrem eigenen Zeitrahmen. Sie erhalten Ihre Funktionsprioritäten immer von einem Kunden - und Sie werden daran arbeiten, so viele dieser Funktionen wie möglich bis zum Stichtag bereitzustellen.

Ob die Frist tatsächlich mit den verfügbaren Ressourcen eingehalten wird, ist ein Verwaltungsproblem. Sie können Ihre Prognose und wöchentliche/tägliche Statusaktualisierungen angeben und sie können entscheiden, ob sie mehr Ressourcen benötigen. Andernfalls arbeiten Sie weiter in Sprints und liefern Runnables - genau wie bei jedem anderen Projekt.

4
Falco

Agile hindert Sie nicht daran, Meilensteine ​​zu planen (z. B. werden wir V 1.0 in 3 Monaten veröffentlichen), aber was in jedem Meilenstein steckt, kann nicht behoben werden.

Ich denke, wie Sie reagieren sollten, hängt von der Art des Projekts ab. Wenn das Projekt bis zum zweiten Quartal 2017 einen Mann zum Mond schicken soll, sind sich alle einig, dass es zum Scheitern verurteilt ist. Wenn Sie glauben, dass Sie bis Ende des zweiten Quartals 2017 einen MVP liefern können, sollten Sie Sprint für Sprint daran arbeiten.

Wenn das Management der Meinung ist, dass Ihr Team sein Bestes gibt und Sie bei jedem Sprint Fortschritte zeigen können, sollten Sie in der Lage sein, länger zu verhandeln.

4
Chamindu

Wie jemand bereits vor dem Manifest betont hat:

Individuen und Interaktionen über den Prozess

Ich würde vorschlagen, dass Sie sich den vorgelegten Plan ansehen und Änderungen vorschlagen. Denken Sie daran, das Manifest besagt, dass der Rückstand niemals endgültig ist, sondern sich ständig weiterentwickelt.

So können Sie Ihre Vorschläge an das Team weiterleiten. Wenn Sie eine gültige Begründung haben und das Team damit einverstanden ist, wird jeder Produktbesitzer, der sein Salz wert ist, diese berücksichtigen und den Rückstand auflösen, um die Meinung des gesamten Teams widerzuspiegeln.

Dies ist der Punkt, an dem es zwei Wege gehen könnte.

  1. Der Product Owner und das Unternehmen stimmen Ihrer Argumentation zu und können die Ressourcen erhöhen, um die Frist einzuhalten, wenn dies eine Option ist. OR Sie können einige Funktionen löschen, um die Frist einzuhalten.

  2. Sie möchten vielleicht immer noch an ihrer eigenen Version gegen die kollektive Meinung des Teams festhalten.

Wenn das Ergebnis # 2 ist, ist dies nicht agil.

Wenn Sie auf Platz 1 landen, würde ich sagen, dass das Team auf dem richtigen Weg ist, denn bei Agile geht es nicht nur um die Entwickler, die auf Veränderungen reagieren, sondern auch darum, dass das Unternehmen auf Veränderungen reagieren kann.

3
Pratik

Stellen Sie sich vor, Sie bitten jemanden, eine Wand, ein Haus und dann eine ganze Straße für Sie zu streichen. Wie viel Zeit würden Sie dieser Person dafür geben?

Was auch immer Ihre Antwort ist, Sie werden sich irren. Das ist es.

Es gibt keine Möglichkeit, dass sie in Bezug auf Daten Recht haben, wenn sie die Leute, die die Arbeit erledigen müssen, nicht fragen, was sie denken.

Übrigens, wenn Sie (als Team) akzeptieren diese Daten, dann sind Sie dort falsch.

Sie sollten einige Zeit in Anspruch nehmen, um gemeinsam mit den Stakeholdern an dieser Planung zu arbeiten, damit Sie Prioritäten setzen können, je nachdem, wie einfach und schnell die Erledigung der Aufgaben ist.

Zum Beispiel wird die endgültige Arbeit vielleicht doppelt so lange dauern, wie sie gedacht haben, aber sie könnten eine Beta viel früher als erwartet verwenden.

Alles in allem können Sie nicht zulassen, dass die Leute glauben, Sie könnten X in Y-Zeit ausführen, wenn Sie nicht schneller können oder könnten. Es liegt in Ihrer Verantwortung, klar zu machen, was Sie in Bezug auf Details und Zeit benötigen.

2