Ich begann bei einem Börsenmakler zu arbeiten, der mich und zwei weitere Entwickler anstellte, um eine Software zu entwickeln, die ihnen helfen sollte. Ich bin das neueste Mitglied des Entwicklungsteams. Mein Freund, ein weiterer Entwickler im Team, bat mich, ein Software-Engineering-Modell zu erstellen, das in dem Projekt angewendet werden soll, weil die Art und Weise, wie sie es jetzt tun, nicht funktioniert. Sie haben kein bestimmtes Modell, dem sie folgen müssen, sie entscheiden nur mündlich, was zu tun ist. Die beiden Eigentümer des Börsenmaklers (die in diesem Fall die Kunden sind) bitten sie, ein Feature zu entwickeln, damit die Entwickler einfach aufhören, was sie tun und beginnen, daran zu arbeiten, sie haben keine spezifische Liste von Voraussetzungen oder Merkmalen, die das Produkt haben sollte ...
Meine Idee war ursprünglich, zu versuchen, Scrum in folgenden Begriffen zu implementieren und anzupassen:
Erstellen Sie so schnell wie möglich ein Produkt-Backlog. Die Rolle des Product Owners würde von den Eigentümern des Unternehmens besetzt. Ich und der andere Entwickler wären das Scrum-Team. Einer der Entwickler wäre der Scrum Master. Wir hätten einen Sprint pro Woche. Treffen jeden Freitag, um den letzten Sprint zu überprüfen und den nächsten zu planen. (Sprint Review, Retrospektive und Planung) Die Notwendigkeit eines täglichen Review-Meetings sehe ich nicht. Ich dachte, wir könnten sporadische Meetings während Sprints machen, wenn eines der Mitglieder es für nötig hält. Ist es möglich, dass das funktioniert? Was kann ich tun, damit es besser wird?
Ist es möglich, dass das funktioniert?
Das ist ziemlich meinungsbasiert. Wenn Sie meine Meinung wollen, lautet die Antwort "vielleicht". Thomas spricht gute Punkte über mögliche Schwierigkeiten an, aber je nach Team können diese leicht überwunden werden. Was mich zu ...
Was kann ich tun, damit es besser wird?
"Ich weiß nicht, versuch es und sieh es dir an." Das wertvollste Einzelwerkzeug in Scrum (und wohl ganz Agile) ist die Retrospektive. Versuche etwas. Überprüfen Sie, wie gut es funktioniert hat. Anpassen. Die Regeln von Agile müssen nicht nur für das Produkt gelten. Sie können (und sollten) sich auch für das Verfahren bewerben.
Machen Sie sich also nicht zu lange Gedanken darüber, was Sie ausprobieren sollen. Wählen Sie einfach einen Prozess aus und probieren Sie ihn aus. Dann verfeinern Sie es (als ganzes Team) - oder verwerfen Sie es einfach und versuchen Sie etwas anderes.
Verwenden Sie Scrum nicht - es scheint für diese Situation nicht angemessen zu sein. Ich habe eine Antwort auf Software Engineering Stack Exchange über die Mindestanzahl von Personen zur Implementierung von Scrum geschrieben. Im Moment beschreiben Sie die absolute Mindestanzahl von Personen, um ein Scrum-Team zu bilden (ein Firmeninhaber als Product Owner, 3 Entwickler, von denen einer der Scrum Master ist).
Ich kann ein paar Schluckauf mit diesem Plan sehen. Erstens muss der Scrum Master in der Lage sein, sowohl für den Product Owner als auch für die Organisation ein Coach zu sein – kann die Person, die Sie für diese Rolle auswählen, den notwendigen Einfluss auf den Eigentümer haben, der als Product Owner fungiert, und den Rest von die Organisation? Zweitens, haben die Personen, die Sie identifiziert haben, die notwendige Zeit, das Wissen und die Erfahrung, um als Product Owner und Scrum Master zu fungieren?
Anstelle von Scrum würde ich zunächst einen Ansatz nach dem Vorbild von Kanban betrachten.
Erstellen Sie zunächst ein Board, das Arbeitselemente enthält. Arbeiten Sie mit dem Team und den Personen, die das Produkt verwalten, um festzustellen, welche Informationen für das Team erforderlich sind, damit es seine Arbeit erledigen kann. Dies wird manchmal als Definition of Ready bezeichnet . Anstatt die Eigentümer die Arbeit unterbrechen zu lassen, beginnen sie damit, ein Arbeitselement zu formulieren, das der Definition of Ready entspricht. Möglicherweise benötigen sie dafür jedoch Hilfe vom Team – nehmen Sie sich regelmäßig Zeit, um dies zu bewältigen. Sie können sich in Scrum-Sitzungen zum „Grooming“ oder „Backlog Refinement“ anleiten lassen, wie Sie die Definition of Ready verwalten und sicherstellen, dass die Arbeit in einem guten Zustand ist.
Priorisieren Sie dann die Arbeitselemente. Ich würde versuchen sicherzustellen, dass eine Person das letzte Wort bei der Prioritätsreihenfolge hat. Die Reihenfolge der Arbeitselemente bestimmt die Reihenfolge, in der die Entwickler arbeiten. Sobald ein Entwickler ein Arbeitselement fertig gestellt hat, schaut er sich den oberen Teil des Rückstands an und wählt das oberste Element aus, das er erledigen kann, und bringt es von „zu erledigen“ in einen erledigten Zustand. Es ist wichtig, Work-in-Progress (WIP)-Limits festzulegen und durchzusetzen.
Generell sollten die Prinzipien aus Lean Software Development hilfreich sein. Ihre Planungs-, Überprüfungs- und Retrospektivaktivitäten sollten angemessen erfolgen. Sie können einen Ansatz wählen, der eher Scrum ähnelt, wo diese in regelmäßigen Abständen stattfinden. Oder Sie wählen einen Ansatz, bei dem sie nach Bedarf stattfinden.
Wenn Sie einen anständigen Rückstand, gute Definitionen von „bereit“ und „erledigt“ für Geschichten und gute Gewohnheiten in Bezug auf Planung, Überprüfung und Retrospektive haben, sollten Sie in der Lage sein, Ihren Prozess zu skalieren. Wenn Ihr Team wächst, können Sie die Einführung eines Frameworks wie Scrum in Betracht ziehen. Wenn Sie anfangen, zu mehreren Teams zu wachsen, können Sie sich andere Frameworks wie Nexus oder LeSS für die Skalierung von Scrum ansehen. Sie können auch von Disciplined Agile Delivery in Bezug auf die Anpassung und Erweiterung Ihres Prozesses lernen.
Alan Larimer