Effektive Möglichkeiten, um Agile am Arbeitsplatz einzuführen?

Was sind nach Ihrer Erfahrung (anekdotisch oder auf andere Weise) einige effektive Möglichkeiten, um Agile in eine nicht-agile Organisation oder ein Unternehmen einzuführen?

AKTUALISIERT: Kann jemand mit Fällen sprechen, in denen Sie versucht haben, Agile einzuführen, aber "abgeschossen" wurden? Haben Sie jetzt auch ein nachträgliches Verständnis dafür, warum Sie "abgeschossen" wurden?

ES IST SCHWER ABER NICHT UNMÖGLICH. Es sei denn, Sie leben im Paradies. Für bestimmte Schritte, die Sie unternehmen könnten, empfehle ich von ganzem Herzen, ein Exemplar von Fearless Change abzuholen

• Holen Sie sich zunächst die Unterstützung des Managements . Wenn Sie nichts anderes tun, wird dies wieder wettgemacht. Wenn die obere Ebene aus "Die Frist ist gestern" besteht, "Arbeitswochenenden für die nächsten 3 Monate", "Warum schreiben Sie Tests, wenn Sie es sollten?" Codierung? .. können wir später testen. ' Der Dodo fliegt einfach nicht.
• Prüfen Sie, ob die Kultur Ihrer Organisation für Agilität geeignet ist. Das habe ich verpasst. Eine Zeile aus dem Buch auszuleihen. Der Prozess wird einfacher und schneller, wenn die Kultur neue Ideen unterstützt und fördert, den Menschen Zeit zum Lernen und für neue Dinge lässt. Es ist geduldig genug, Innovationen zu unterstützen Langzeitleistungen und betrachtet das Scheitern nicht als Todesurteil
• Die Menschen : Identifizieren Sie die Innovatoren: Early Adopters: Early Majority: Late Majority: Laggards Ratio. Die ersten 3 sind anfangs Ihre Zielgruppe. Sie sollten zwischen 30 und 40% liegen. Das gibt Ihnen die kritische Masse, um ins Rollen zu kommen. Das Problem ist, dass Agile das Rampenlicht auf die Elefanten im Raum richtet. Mängel und Probleme werden leicht sichtbar. Wenn Sie an einem Ort leben, an dem eine "Bozo-Explosion" stattgefunden hat (um Guy Kawasakis Begriff zu zitieren) , wäre das eine echte Veränderung langsam und schmerzhaft .. wenn überhaupt. Wir gehen davon aus, dass eine gute Idee akzeptiert wird. Nicht wahr. Viele soziologische Gründe erheben den Kopf.
• Versuchen Sie nicht zu viele Dinge auf einmal. Mach es langsam. Mach es ruhig . Der Trick besteht darin, einen Refactoring-Legacy-Code-ähnlichen Ansatz zu verwenden. Hier und da finden Sie kleine Wunden und flicken sie mit einem wendigen Verband. Stellen Sie sicher, dass die Menschen die Praxis und die Vorteile verstehen und sie im Laufe der Zeit übernehmen sollten. Nicht alles wird kleben bleiben, aber bald wird es im Großen und Ganzen besser. Wie bald hängt von einer Reihe von Variablen ab, von denen einige außerhalb Ihrer Kontrolle liegen.
• Es ist eine enorme persönliche Investition, um dies zu erreichen . Überprüfen Sie erneut, ob Sie bereit sind, diese Verpflichtung einzugehen, und gehen Sie die damit verbundenen Höhen und Tiefen durch. Möglicherweise müssen Sie den Staffelstab auch an eine andere Person oder eine höhere Person übergeben. Seien Sie bereit, den Eigentümerwechsel für das Wohl der Allgemeinheit aufzugeben. Fallen Sie nicht in das "Its my baby" -Syndrom.
• Agile ist für jedes Team und jede Organisation unterschiedlich . Nicht alles, was Sie lesen / vorschlagen, wird funktionieren. Lassen Sie sich von der Akzeptanz zu den Dingen führen, die für Ihr Szenario funktionieren. Finden Sie andere Möglichkeiten, um die Praktiken zu kompensieren, die keine Wurzeln schlagen.

Hoffe das hat Sinn gemacht .. wie du vielleicht vermutet hast bin ich schon länger dabei :)

Hören Sie auf das Team, das Management, die Stakeholder und suchen Sie nach Hinweisen. Sie haben wahrscheinlich Schmerzen in einer Reihe von Bereichen, die von Agile direkt angesprochen werden.

Halten Sie sich an Vorschläge, die diese Schmerzen direkt lindern können. "Du kannst nicht heilen, was du nicht fühlen kannst" - sozusagen.

Dies dauert eine lange verdammte Zeit, aber es ist von größter Wichtigkeit, Vertrauen aufzubauen. Aufgrund der Erfolge in der Vergangenheit und des Vertrauens Ihres Teams und Ihres Managers werden Sie zu Rate gezogen, wenn es darum geht, Entscheidungen zu treffen.

Ich habe es mit eigenen Augen gesehen, nachdem ich jahrelang frustriert war, Menschen dazu zu bringen, die Art und Weise zu ändern, wie wir Software bereitstellen. Und obwohl ich jetzt Erfolge habe, bin ich bei weitem nicht vollständig. Es gibt Unmengen von Verbesserungsmöglichkeiten, und ich habe derzeit den größten Erfolg mit der Einführung kleiner Änderungen, die sich direkt auf eine Art von Schmerz beziehen, den wir fühlen.

Zuletzt würde ich nur sagen, sehr einfühlsam zu sein. Ich habe den Fehler gemacht, die meisten Ideen zu verwerfen, bevor ich sie wirklich durchgesehen habe, weil ich in "XYZ Agile Book" nicht darüber gelesen habe. Wenn Sie Ihrem Team zuhören und versuchen, einige ihrer Vorschläge umzusetzen, ist dies ein langer Weg.

Viel Glück!

Wenn wir die Technik überspringen, haben wir festgestellt, dass die Suche nach einer Gruppe innerhalb des Unternehmens, die sich für agile Methoden und die Bereitstellung eines „Prüfstands“ eignet, von entscheidender Bedeutung ist. Wir hatten viele Mitarbeiter in unserem Unternehmen, die unterschiedliche agile Begriffe nicht verstanden, die von Begriffen und Prozessen verwirrt waren, und es gab allgemeine Befürchtungen.

Meine Forschungsgruppe war sehr daran interessiert, Scrum zum Laufen zu bringen (zusammen mit mehreren anderen agilen Methoden). Aufgrund unseres Interesses konnten wir im Unternehmen einen Prüfstand aufbauen, um die verschiedenen Elemente auszuprobieren. Wir haben viel unterrichtet - Flurgespräche mit Leuten, Präsentationen für Führungskräfte der Firma usw. Wir haben nicht viel Druck gemacht - wir haben uns weitergebildet. Dann haben wir um Erlaubnis gebeten, es einfach mit unserer Gruppe auszuprobieren.

Es wird viele Antworten geben, um empirisch zu zeigen, wie Dinge wie Pair Programming, testgetriebene Entwicklung, Scrum usw. Zeit sparen können, aber am Ende des Tages denke ich, dass der Beweis aus Ihrem Unternehmen kommen muss. Suchen Sie sich eine Gruppe, die Sie als Prüfstand verwenden können, und lassen Sie sie dies tatsächlich tun. Nichts kann Ängste besser lindern als zu zeigen, dass Ihre Gruppe es schafft.

Cram es in den Hals, aber ohne dass sie es merken;)

In den letzten 6 Monaten habe ich langsam versucht, agile Prinzipien (hauptsächlich Scrum) in meinem Arbeitsplatz umzusetzen. Ich habe zuerst tägliche Stand-Ups eingeführt, an die sich jeder gewöhnen musste, aber es funktioniert ganz gut. Da wir alle an verschiedenen Programmen arbeiten, die alle Teil eines Systems sind, ist es ein wenig schwierig, Scrum per Definition zu befolgen. Mein nächster Schritt ist es, Sprint-Meetings zu starten, um jede unserer Veröffentlichungen zu verfolgen. Wir fahren bereits einen Monat lang, so dass die Sprintlänge kein Problem darstellt. Ich plane auch, bei unserem nächsten Großprojekt die Scrum-Prinzipien vollständig zu befolgen. Ich bin einer von zwei Entwicklern im Team für das Projekt, und er ist alles für die kontinuierliche Verbesserung. Ich hoffe, dass das Management die Vorteile dessen sieht, was ich erreichen möchte.

Ich denke, der Schlüssel ist, es langsam anzugehen. Menschen, die jahrelang in der gleichen Position waren, sind im Allgemeinen gegen aufdringliche Veränderungen, aber wenn Sie es Stück für Stück schleichen können, sollten sie es nicht bemerken. Beginnen Sie zunächst auch mit den kleinen regelmäßigen Treffen. Wenn sie kurz gehalten werden, sollte das Management sie nicht als Zeitverschwendung ansehen.

Testgetriebene Entwicklung. Demonstrieren, wie Unit-Tests Ihre Entwicklung beschleunigen können. Zeit zu verbringen und gleichzeitig den Code stabiler zu machen, ist ein guter erster Schritt, um die agile Kool-Aid zu trinken.

Verbessere dich zuerst. Ja wirklich. Beispiel ist die starke Art, über Agilität zu sprechen. Vermeiden Sie darüber hinaus, wie bereits gesagt, technische Definitionen und verwenden Sie nur Begriffe, die Manager und Führungskräfte verstehen können. Zwei Wochen stattdessen Sprint; Planung statt Sprintplanung oder Planspiel; Produktmanager anstelle von Product Owner und so weiter. Michele Sliger hat einen tollen Vortrag über Agile in der Waterfall Enterprise gehalten . Wirklich ein Muss Video zu sehen. Möglicherweise interessieren Sie sich auch für andere Videos zum Thema Agile Adoption .

Wo ich arbeite, lerne ich, dass Scrum ein guter Weg ist, um agil zu werden, weil das Management es schnell versteht. Es ist einfach und hat einen schönen Namen. Wenn Sie Retrospectives durchführen, können Sie XP-Praktiken als Verbesserungen vorschlagen, und es ist recht einfach, dass die Leute diese zumindest akzeptieren und ausprobieren.

Mit freundlichen Grüßen

Wir haben es als zweiwöchigen Sprint in unsere Wartungsaufgaben (Fehler, Änderungen mit geringen Auswirkungen usw.) eingeführt. Die Entwickler, die an längerfristigen Projekten arbeiteten, blieben also unverändert, aber wir hatten einen wechselnden Wartungssprint. So konnte jeder Burn-Down-Charts und Poker-Schätzungen verwenden, ohne die großen Projekte zu stören.

Am Ende jedes größeren Projekts haben wir das nächste mit agilen 2-Wochen-Sprints gestartet. Dieser ganze Prozess dauerte ein paar Monate, bevor alle Sprints absolvierten, aber das bedeutete, dass es weniger Störungen gab und sich alle in den Prozess „einlassen“ konnten

Innerhalb des Entwicklungsteams haben Sie mehr Kontrolle über die Einführung von Agile.

Ich sehe jedoch das Hauptproblem in der Anforderung, die Agile hat, um fortlaufendes Feedback von Ihrem "Kunden" oder Kundenvertreter zu erhalten.

Daher müssen Sie sich wirklich auf die Bildungsseite der Dinge für diejenigen außerhalb Ihres direkten Entwicklungsteams konzentrieren, da sie wahrscheinlich ihre Arbeitsweise ändern müssen (dh viel mehr Kontakt mit dem Entwicklungsteam).

Ich würde sagen, der beste Weg ist, sich auf die inhärenten Vorteile eines agilen Prozesses zu konzentrieren und diese Ihrem Kunden klar zu vermitteln. Wenn Sie in Ihrem Unternehmen einen Verkaufs- / Kontobereich haben, gilt dies natürlich auch dort.

Schritt 1: Stellen Sie sicher, dass Ihr Projekt einen starken Rückstand aufweist, und stellen Sie sicher, dass es priorisiert ist

Schritt 2: Einführung in SCRUM-Praktiken (verwaltbare Iterationen, tägliche Stand-ups, Scrum-Master, Product-Owner, Burndown-Charts)

Schritt 3: Jedes iterative Teamergebnis mit dem Burndown

dann ... führen Sie
TDD / BDD, Paarprogrammierung, Codeüberprüfungen (alles sehr vorsichtig) durch, und wenn Sie ein Team haben, das gut genug ist, suchen Sie sich alle Mitarbeiter (wenn möglich einen Teamraum).

Verstehen Sie vor allem, dass es Widerstand geben wird (WIRD), seien Sie also bereit, damit umzugehen.

Eine andere Sache, an die Sie sich erinnern sollten, ist, dass es eine Weile dauern kann, bis Sie das Gefühl haben, Fortschritte zu machen, wenn Sie Teil eines Unternehmens (groß oder klein) sind, das als Ganzes diese bewährten Methoden nicht befolgt.

Die Menschen sind immer resistent gegen Veränderungen, und es ist eine ziemlich große Herausforderung, zum Gedränge überzugehen. Motivation und Richtung sind der Schlüssel.

Der erste Schritt ist, die Leute zu motivieren, Scrum eine Chance zu geben. Ich fand, dass der Google Tech Talk von Ken Schwaber sehr nützlich war, um die Leute dazu zu bringen, die Vorteile von Scrum zu erkennen und gleichzeitig eine gute Einführung zu bieten. Beginnen Sie mit Leuten, von denen Sie glauben, dass sie für Veränderungen empfänglich sind, egal ob sie Entwickler oder Manager sind, damit Sie etwas Schwung aufbauen können. Es wird irgendwann eine Notwendigkeit sein, Manager an Ihre Seite zu holen, aber wie Sie damit umgehen, hängt von Ihrer Umgebung ab.

Danach muss jeder geschult werden, sei es, ein Buch zu lesen oder eine Vorlesungsreihe zu halten. Wenn die Leute nicht wissen, wie Scrum funktioniert, können Sie nicht versuchen, den Prozess zu implementieren.

Sobald die Mitarbeiter motiviert sind und eine Vorstellung davon haben, was sie tun müssen, müssen Sie Ihr erstes Planungstreffen abhalten und die erforderlichen Teile des Scrums (Scrummaster, tägliche Besprechungen usw.) einrichten.

Ich würde erwarten, dass das erste Planungstreffen nicht reibungslos verläuft und eine Lernerfahrung für alle ist. Auch die ersten Sprints werden sehr steinig sein und wahrscheinlich hinter dem Zeitplan zurückbleiben. Das Wichtigste ist jetzt Disziplin und Ausdauer. Lassen Sie tägliche Besprechungen nicht zu lange dauern, behalten Sie die Planungsbesprechungen im Blick und stellen Sie sicher, dass alle ihre Rollen korrekt ausführen.

Ich denke, die Leute, die am widerstandsfähigsten sind, sind Leute, die seit langer Zeit Softwareentwicklung betreiben, oder Leute, die das Gefühl haben, dass sie durch den Wechsel zu Scrum eingestehen, dass sie vorher etwas falsch gemacht haben. Es ist ein kniffliges Hindernis zu überwinden, aber ich denke, wenn Sie ihnen die Vorteile zeigen, können Sie sie langsam überzeugen. Es braucht nur Zeit. Nach meiner Erfahrung sind Produktmanager wirklich widerstandsfähig, weil sie gezwungen sind, ihre Anforderungen und Wünsche klarer zu formulieren. Aber sobald sie sehen, wie sie von dem agilen Prozess profitieren und ihr Leben leichter machen, steigen sie ziemlich schnell ein.

Viel Glück!

• Erfolg demonstrieren - siehe Antwort von mark
• Achten Sie besonders auf Grundsätze / Techniken, die die größten Auswirkungen auf das Unternehmen haben würden
• Denken Sie daran, es geht um agile Prinzipien und nicht um eine Prozess-Checkliste

Bevor Sie über die Einführung einer agilen Entwicklung nachdenken, prüfen Sie zunächst, welche für Ihre Organisation / Ihr Projekt am besten geeignet ist. Wenn Sie sich zum Beispiel mit Scrum befassen, überlegen Sie, ob Sie es streng verwenden möchten oder ob eine lockere Form von Scrum oder eine andere Methode insgesamt besser passen könnte. Meine Antwort ist dann auf Scrum als Ihre agile Methode.

Scrum eignet sich hervorragend für Projekte, die Innovation erfordern, bei denen wenig bekannt ist und experimentiert werden muss. Es ist nicht die beste Lösung, um beispielsweise vorhandene Produkte zu warten oder wiederkehrende Wartungsarbeiten durchzuführen. Glücklicherweise ist Scrum ein lockeres Framework und Sie können es so gut wie möglich verwenden.

Bei Wartungsarbeiten ist Kanban möglicherweise besser für Sie, oder Sie probieren ein paar Scrum-Elemente aus, um den Sprint zu managen und Dinge wie das tägliche Aufstehen zu erledigen. Ich nenne das "scrum-but", "ja, wir machen scrum in unserer Firma, aber ...". Das ist in Ordnung, fühl dich nicht schlecht dabei.

Für die Einführung von Scrum in Ihrem Unternehmen müssen Sie den Product Owner und den Stakeholder einbeziehen. Wenn Sie eine kleine Firma sind, ist dieser Typ möglicherweise eine Person, der Chef, und in einer größeren ein Produktmanager und der Abteilungsleiter / Chef. Ich würde zwei Wege für die Einführung von Scrum vorschlagen:

1) Sie können Scrum in einer etwas lockeren Form verwenden, um vorhandene Arbeitswarteschlangen sofort zu verwalten. Aber schauen Sie auch in Kanban.

2) Verwenden Sie Scrum in einer strengeren Form für ein neues Projekt, das Innovation, frühzeitiges Feedback und Unbekanntes erfordert. Sie können dem Chef / Product Owner vorschlagen, dass Scrum für dieses neue Projekt ideal wäre.

Aber erinnere dich! Hierbei geht es nicht nur um Code, der Product Owner hat einen entscheidenden Anteil und muss seine Rolle verstehen und erfüllen. Das bedeutet zum Beispiel, nicht alle Spezifikationen im Voraus zu schreiben, sondern mit dem Minimum zu beginnen, schnell zu iterieren, Feedback zu erhalten, das zu lernen und wieder einzuspeisen und so weiter. Versuchen Sie, mit einem Produktmanager zusammenzuarbeiten, der genauso gerne Scrum einführt wie Sie, aber von der Seite des Produktbesitzers. Idealerweise sollte er / sie stark genug sein, um Managementanfragen abzuwehren und den Sprint zu schützen.

Die Entwicklung und das Produktmanagement werden gemeinsame Anstrengungen erfordern, um Scrum einzuführen.

Versuchen Sie bei einem solchen neuen Projekt, das neue Team in einen separaten Raum zu verlegen, und verwenden Sie Haftnotizen, um die Arbeit in den verschiedenen Zuständen wie Rückstand, in Bearbeitung usw. zu visualisieren. Lassen Sie sich in dieser Phase nicht in elektronischen Werkzeugen festsitzen , halte die Dinge so einfach wie möglich. Fühlen Sie sich nicht albern, wenn Sie anfangen, Poker mit Karten zu planen. Sobald Ihr Team auf dem neuesten Stand ist, werden Sie sie wahrscheinlich nicht mehr verwenden, sondern nur noch die Zahlen nennen.

Nach meiner Erfahrung ist es einfacher, Scrum zunächst in reiner Form einzuführen, als es für Warteschlangen mit mehr Wartungsarbeiten zu vereinfachen. In umgekehrter Richtung ist es schwieriger.

Mein letzter Kommentar ist, sich vor dem Gedanken in Acht zu nehmen, dass Scrum ein Allheilmittel für die Entwicklung ist. Scrum ist ein nützliches und einfaches Framework für Produktinnovationen. Sie können jedoch auch andere Methoden ausprobieren, die sich kombinieren lassen, wenn Ihr Unternehmen dies erfordert, und sich dabei nicht schlecht fühlen.

Vor einigen Jahren war ich Berater in einem sehr großen Unternehmen (fast 20.000 Mitarbeiter), das viele große Unternehmenssoftwareprojekte leitete. Ich war auf einem von ihnen. Ein ziemlich kritischer.

Wir hatten viele Probleme und der Druck war stark auf uns, das Entwicklerteam, gerichtet. Probleme gab es nur in der Softwareindustrie, aber das Management verfügte über eine eher infrastrukturorientierte Erfahrung und nur über sehr wenige softwareorientierte Erfahrungen. Also war alles auf uns gerichtet. Ich dachte, es wäre eine großartige Idee, dem Management von Scrum zu erzählen.

Ich sah mich einer starken Zurückhaltung gegenüber, weshalb ich die Idee für eine Weile fallen ließ. Die Probleme summierten sich jedoch weiter, so dass wir uns beim Sponsor des Teamleiters entschlossen, Scrum trotzdem selbst herzustellen.

Jeder, einschließlich mir, hatte Erfahrung mit Scrum. Also haben wir den Rahmen entdeckt, indem wir ...

Heute wird Scrum durch ein Programm, das von einem zertifizierten Trainer verwaltet wird, für das gesamte Unternehmen verallgemeinert. Ich weiß nicht, ob unsere Initiative der Auslöser war. Das heißt, ich weiß, dass es eine echte Revolution in einer ziemlich starren Gesellschaft war.

Ich denke, um etwas in ein Unternehmen wie dieses einzuführen, müssen Sie die folgenden Grundsätze beachten:

• Es muss sich ändern, ist notwendig . Wenn es keinen zwingenden Grund dafür gibt, dass die Änderung vorgenommen werden muss, gibt es keinen Grund, warum Managementteams vorhanden sind, um Risiken einzugehen.

• Wir müssen uns auf die Probleme des Managements konzentrieren und die Probleme der Entwickler nicht erwähnen, es sei denn, sie sind Teil des Managements. Mit anderen Worten, Sie müssen eine Lösung für sie finden, nicht für Sie. Versetzen Sie sich in die Lage des Managements. Was sind ihre Anliegen?

• Sie sollten nicht vorschlagen, die gesamte Organisation auf einmal zu ändern . Sie müssen ein Pilotprojekt vorschlagen, für das Sie die Verantwortung übernehmen würden. Ich rate Ihnen, realistische Ziele anzugeben, wie die deutliche Erhöhung der Sichtbarkeit dessen, was im Projekt vor sich geht. Dies ist meiner Meinung nach der Hauptbeitrag von Scrum zum Software-Management. Es ermöglicht dem gesunden Menschenverstand, zu operieren und sich somit vorwärts zu bewegen.

• Schließlich muss unbedingt sichergestellt werden, dass erfahrene Personen die Kontrolle über diese Einführung haben. Lesen Sie nicht nur ein oder zwei Bücher. Sie müssen zum Training und ich würde sagen, es ist eher notwendig, einen erfahrenen Trainer zu verwenden. Natürlich kann man darauf verzichten, aber es wird weh tun :)

Wenn Sie den Grundsätzen folgen und mit Fakten kommen, wird es funktionieren. Über Fakten informiert das Buch Software in 30 Tagen: Wie agile Manager die Gewinnchancen meistern, ihre Kunden begeistern und Konkurrenten im Staub lassen . Es ist das neueste Buch der Schöpfer von Scrum, Ken Schwaber und Jeff Sutherland .

In einem Blogpost von Ken über das Buch können Sie lesen:

Jeff Sutherland und ich haben es geschafft. Wir haben zusammen ein Buch geschrieben, unser erstes gemeinsames Schreiben seit der Erstveröffentlichung von Scrum im Jahr 1995. Was hat uns dazu veranlasst? Die Frage, die uns häufig gestellt wird:

Wie verkaufen wir Scrum an unser Management?

Diese Frage hat mich immer verwirrt. Warum müssten Sie mehr Vorhersehbarkeit, Produktivität, Qualität, Wert, Risikokontrolle, zufriedene Kunden, engagierte Mitarbeiter und weniger Verschwendung an irgendjemanden im Management verkaufen? Ich sprach jedoch mit Jeff und wir stellten uns vor, dass dort, wo Rauch war, Feuer sein musste.

Wir haben das letzte Halbjahr 2011 damit verbracht, das Buch zu schreiben. Jeder Manager, von oben bis unten, kann dieses Buch leicht aufgreifen und lesen.

[...]

Wir sehen es die ganze Zeit. (vollständige Offenlegung: Ich entwickle eine Projektmanagement-Anwendung). Das Problem ist, dass agile Methoden eine inhärente Spannung in traditionell verwaltete Organisationen einbringen. In der Regel möchten Führungskräfte vorausschauend planen können. Sie wollen 3-Jahres-Pläne; sie wollen richtig geschätzte Projekte; sie wollen in der Lage sein, neue Leute einzustellen; Sie möchten in der Lage sein, wichtige Meilensteine ​​in Bezug auf Partner / Kunden zu setzen.

Aber dann entscheidet die F & E-Abteilung, dass es agil wird. Es geht nicht mehr darum, zwei Monate im Voraus zu planen, bevor Code geschrieben wird. Sprints werden kurz sein und jenseits von Sprints erhalten Sie Schätzungen mit sehr geringer Auflösung für die Inhalte, die im Backlog / in der Roadmap enthalten sind. F & E hat erkannt, dass sich die Anforderungen viel zu häufig ändern, als dass ein klassischer Wasserfall effektiv wäre. Produktmanager möchten jedoch eine klare, durchdachte und gut budgetierte Vorstellung davon, wie das Produkt in 12 Monaten aussehen wird.

Das Problem ist also, die beiden zu versöhnen. Wie gesagt, wir sehen das die ganze Zeit bei unseren Kunden. Unsere Lösung besteht daher darin, die Tools zu vereinheitlichen, die sowohl für Sprints als auch für die langfristige Planung verwendet werden. Okay, jetzt kommt der Teil des schamlosen Stopfens, also nimm ihn mit einem Körnchen Salz. Eine unserer einzigartigen Eigenschaften ist, dass wir eine zoombare Benutzeroberfläche zum Verwalten von Aufgaben verwenden. Das heißt, es ist sehr einfach, eine User-Story / Aufgabe aufzuspüren und zu erläutern. (Sie können sehen, wie es hier aussieht ). Tatsächlich gibt es überhaupt kein Konzept für ein "Projekt" in unserem System. Es sind alles Aufgaben, die andere Aufgaben enthalten und mit anderen Aufgaben verknüpft sind (eigentlich ein Fraktal). Dies erzeugt eine schöne Unschärfe zwischen User-Stories, Aufgaben, Projekten, Epen usw.

In der Praxis erstellen viele unserer Benutzer, die agile Methoden anwenden, einen Teleskopplan, in dem die langfristige Roadmap (oder der Rückstand) mit der Verwaltung der kurzfristigen Sprints (oder Iterationen) zusammengeführt wird. Die Manager sehen immer noch eine schöne, geschätzte Roadmap mit den wichtigsten Funktionen, die noch hinzugefügt werden müssen, und die Entwickler zoomen einfach tiefer hinein und beschäftigen sich mit den eigentlichen Arbeitsaufgaben. Dies hat den Vorteil, dass weniger "gefeilscht" wird, wenn Manager den Arbeitsplan überprüfen. Anstatt dass das Entwicklerteam nur sehr grobe Schätzungen liefert (dh "4-6 Wochen!"), Haben sie die Möglichkeit, in jede fragliche User-Story hineinzuzoomen und sie in kleinere Teile zu zerlegen. Wenn Sie das tun, gibt es plötzlich weniger Raum zum Feilschen. Sie verbringen 10 Minuten damit, eine 5-wöchige User-Story in Stücke zu zerlegen, die etwa 1 Tag lang sind. und plötzlich ist das Argument nicht mehr "nein, du kannst es schneller machen. nein, wir können nicht. ja, du kannst." Aber "hier ist, was in diese Bemühungen einfließt, einschließlich all der verborgenen Arbeit, die die ursprüngliche Schätzung nicht in Betracht gezogen hat. Was schlagen Sie vor, um sie zu beseitigen? Qualitätssicherung? Testen? Schulung des neuen Mannes? Einrichten der Build-Umgebung?".

Dieser Ansatz funktioniert, solange Sie ein Tool verwenden, mit dem Sie Pläne so schnell ändern können, wie Sie sie ursprünglich erstellt haben. Welches ist der wahre Grund, warum Menschen heutzutage den Wasserfall verabscheuen. Die meisten Systeme machen es äußerst schwierig, vorhandene Pläne vollständig zu wiederholen, und die Leute weigern sich sehr vernünftig, Zeit für diese Aktivität zu verschwenden.

Okay, ich habe das Gefühl, dies wird zu einem Verkaufsargument, also höre ich jetzt auf. :)