Welche Tools und Techniken sollten zuerst eingeführt werden, wenn Sie mit Agile/Scrum beginnen?

Scrum ist wahrscheinlich das schwierigere der beiden, von Grund auf neu zu implementieren. Folgendes würde ich vorschlagen:

Erste Phase: Vorbereitung

1) Verbringen Sie etwas Zeit damit, Ihren Rückstand zu pflegen und zu priorisieren. Der Schlüssel hier ist, die Backlog-Elemente in ausreichend kleine Stücke zu zerlegen. Die meisten neuen Scrum-Teams scheitern früh, weil sie am Ende eines Sprints keine Software liefern können, und das liegt normalerweise daran, dass ihre Backlog-Elemente (User Stories) zu groß sind.

2) Lassen Sie Ihr Team sich über den Scrum-Prozess informieren und besprechen Sie mit ihm den Umsetzungsplan. Holen Sie sich ihr Feedback und fühlen Sie, wo Sie zurückgedrängt werden. Sprechen Sie mit ihnen über TDD / BDD .

Zweite Phase: Sprint 1

3) Richten Sie Ihren ersten Sprint ein. Ich empfehle normalerweise 3 Wochen. Wenn Ihr Team nach 2 Sprints Schwierigkeiten hat, funktionierende Software bereitzustellen, verkürzen Sie Ihre Sprintlänge auf 2 Wochen . Dies zwingt Sie dazu, Ihre Backlog-Elemente in kleinere Stücke zu zerlegen. Die Erhöhung der Sprintlänge ist normalerweise ein schwarzes Loch, aus dem Sie nie herauskommen.

4) Implementieren Sie alle erforderlichen Besprechungen, einschließlich des täglichen Standups.

Dritte Phase: Automatisierung

5) Wenn Sie sie noch nicht haben, ist es jetzt an der Zeit, Ihre CI-Builds einzurichten und am täglichen Workflow Ihres Entwicklers zu arbeiten. Ermutigen Sie sie, den Ablauf „Neueste abrufen“ > „Build“ > „Code“ > „Build“ > „Neueste abrufen“ > „Build“ > „Einchecken“ zu verwenden .

6) Wenn Ihr Projekt noch nicht über umfangreiche automatisierte Tests verfügt, ist es jetzt an der Zeit, deren Erstellung wirklich zu fördern. Ihre Sprints werden produktiver sein und Ihr Arbeitscode wird „funktionierender“, wenn Sie eine gute Codeabdeckung für Ihre CI-Builds erreichen können. Erwägen Sie eine Richtlinie zum Einchecken, die eine Erhöhung der Codeabdeckung für ein erfolgreiches Einchecken erfordert. Dies kann später aufgegeben werden, sobald sich alle daran gewöhnt haben, Komponententests für ihren neuen Code zu schreiben.

Wenn Sie so weit gekommen sind und noch keine Revolution erlebt haben, können Sie jetzt über die Einrichtung automatisierter Bereitstellungen, das Pushen von TDD/BDD, die Implementierung einer Codeüberprüfungsrichtlinie und die Formalisierung eines Eingabe-/Feedback-Prozesses mit Ihrem Product Owner sprechen das ist durchgehender. Der letzte Teil kann ziemlich schwierig sein. Die meisten Teams enden mit dem, was wir Water-Scrum-Fall nennen, bei dem die Product Owner eher wie ein Wasserfall agieren und nur an den Anfangs- und Endpunkten beteiligt sein wollen. Je weiter Sie die Agilität in der Organisation vorantreiben können, desto mehr Vorteile werden Sie sehen.

Was die Technologien betrifft, empfehle ich TFS 2012. Ich habe hier einen ziemlich anständigen Überblick über das Einschalten von Stackoverflow geschrieben . Um es noch einmal zusammenzufassen, es vereint so ziemlich alles, was Sie sowohl von der PM-Seite als auch von der Entwicklerseite benötigen, unter einem Dach.

Eine letzte Anmerkung: Es ist möglich, dies in fast genau umgekehrter Reihenfolge zu tun, mit Ausnahme der Pflege Ihres Rückstands (das sollte fast immer zuerst kommen). Sie können sich auch darauf konzentrieren, die täglichen Gewohnheiten Ihrer Teammitglieder zu entwickeln, bevor Sie die Struktur von Scrum implementieren. Bringen Sie sie dazu, Ihre Codeabdeckung mit automatisierten Tests zu erhöhen, führen Sie einen CI-Build ein und richten Sie (hoffentlich) zuerst automatisierte Bereitstellungen ein und erstellen Sie dann die Sprint-Struktur darum herum. Sprechen Sie mit Ihrem Team und finden Sie heraus, was sie bevorzugen würden. Bei Scrum dreht sich alles um kontinuierliche Wertschöpfung, die durch Automatisierung und kontinuierliche Kommunikation erreicht wird. Holen Sie sich während des gesamten Prozesses den Input Ihres Teams, aber wenn Sie etwas Gegenwind bekommen, müssen Sie möglicherweise eine gewisse Struktur durchsetzen. Hoffentlich werden sie nach ein paar Sprints die Vorteile sehen.

Bearbeiten

Nach einigen Diskussionen mit meinen Kollegen glaube ich, dass ich etwas Wichtiges ausgelassen habe. Ich habe TDD/BDD erwähnt, aber nicht betont, wie wichtig es ist, Tests in Ihre Sprints zu integrieren. Sie müssen genügend Tests (Unit, Integration, Akzeptanz) in Ihre Sprints einbeziehen, um sicherzustellen, dass Ihre „funktionierende“ Software tatsächlich funktioniert und die Anforderungen des Product Owners erfüllt. Ich habe festgestellt, dass einer der effektivsten Wege, dies zu erreichen, multidimensionale Teams sind. Stellen Sie ein oder zwei Tester in Ihre Teams. Paired Programming mit einem Tester und einem Entwickler kann unglaublich erfolgreich sein, wenn sie zusammenarbeiten können.

Bevor Sie sich mit Scrum/Kanban beschäftigen, sollten Sie eines im Hinterkopf behalten: Es ist eine Partnerschaft mit dem Unternehmen. Wenn Sie kein Mitglied des Unternehmens haben, das Prioritäten setzen kann (dies kann eine Person, eine Gruppe, ein Komitee usw. sein), wird es nicht funktionieren.

Als ich Scrum zum ersten Mal einführte, musste ich wirklich hart arbeiten, um das Unternehmen davon zu überzeugen, daran teilzunehmen. Sie waren Scrum gegenüber zutiefst misstrauisch und sahen zunächst nicht den Vorteil der Zeit, die sie in den Prozess investieren mussten.

Vergessen Sie also die Unit-Test-Automatisierung und die technischen Elemente davon. Hier sind einige Fragen, die Sie und das Entwicklerteam sich stellen müssen:

1. Indem Sie die Scrum-Route einschlagen, übergeben Sie die Priorisierung an Ihren Product Owner. Damit Scrum erfolgreich ist, muss dies normalerweise jemand aus dem Unternehmen sein. Machst du das gerne?
2. Sie müssen den Rückstand vorbereiten und verwalten. Das bedeutet, das Team dazu zu bringen, Erpressungen für Arbeiten zu liefern, an denen Sie von Ihrem Product Owner festgehalten werden. Ist das Team bereit, eine angemessene Zeit mit der Schätzung zu verbringen, und ist es bereit, an seinen Schätzungen festzuhalten?
3. Das Team wird durch Priorisierung und Demos mit dem Unternehmen viel mehr Kontakt mit dem Unternehmen haben. Manche Leute mögen das und manche nicht. Mit ihnen?
4. Scrum ist unglaublich transparent. Früher schickten wir unserem Product Owner jeden Tag unser Burndown-Diagramm, also war es am vierten Tag offensichtlich, ob wir dahinter steckten. Vergessen Sie es, Dinge unter dem Teppich zu verstecken – wenn Sie Probleme haben, müssen Sie früher ehrlich mit dem Unternehmen sein anstatt später glaubwürdig zu bleiben. Sind Sie bereit, Ihre täglichen Statusberichte zu teilen?
5. Sobald Sie tatsächlich liefern, wird das Unternehmen eine schnelle Hochzeitsreise haben (sie werden Sie lobpreisen), aber sie werden sich bald an die konstante Lieferung gewöhnen. Machst du das gerne?

Kümmern Sie sich nicht um die technischen Dinge. Ist das Unternehmen und das Team bereit für Scrum? „Erklären“ Sie nicht einfach, dass Sie es tun, sprechen Sie mit dem Unternehmen darüber, was Sie tun möchten. Sprechen Sie es mit Ihrem Team durch und stellen Sie sicher, dass es versteht, worauf es sich einlässt.

Und dann jemanden zu einem ScrumMaster-Kurs schicken.

Ich empfehle nicht, Agile oder Lean einzuführen, da eines davon für Ihre Entwickler attraktiv ist.

Sie lieben es von Natur aus Neues auszuprobieren, und das ist völlig in Ordnung, aber Sie als Projektleiter sind für das Projekt verantwortlich und wenn Sie keinen Prozess haben, sollten Sie den Bedarf analysieren, anstatt Prozesse auszuprobieren .

Finden Sie heraus, was Ihre Kunden wollen, was die Schlüsselmomente im Leben der Projekte sind und kennen Sie die Vision . Wenn es keinen Prozess gibt, bedeutet das normalerweise, dass es keine Vision gibt.

Angenommen, Sie führen Scrum ein, aber Ihre Kunden möchten nicht an Demos teilnehmen und keine regelmäßigen Lieferungen wünschen. Sie haben viel Zeit und Geld für einen Prozess aufgewendet, der nicht passt. Zuerst kommt die Nachfrage, dann das Angebot .

Hier ist eine mögliche Liste für Sie:

1. Kundennachfrage
2. Vision
3. Prozessidee, die in die Vision und Anforderung passt
4. interner Prozesspilot
5. Ideenvalidierung mit dem Kunden (falls nicht passend, weiter mit Schritt 1)
6. Prozess Bildung
7. arbeiten