Scrum, Kanban oder Sonstiges für 4 Personen Entwicklerteam [geschlossen]
Wir haben ein vierköpfiges Entwicklungsteam, das ein formalisiertes Projektmanagementsystem benötigt. Ich habe ein allgemeines Verständnis von Scrum und Kanban, aber es ist schwer zu verstehen, bis es versucht wurde. Wir haben nicht den Luxus, einen für ein paar Wochen zu versuchen und dann zu einem anderen zu wechseln, also hoffte ich, dass jemand da draußen in einer ähnlichen Situation Gedanken darüber haben könnte, was besser für sie funktioniert und warum. Auch über andere Systeme zur Verwaltung der Entwicklung, die funktionierten, wäre es großartig, davon zu hören.
Noch ein Hinweis: Es besteht natürlich die Möglichkeit, dass das Team wächst, also würden wir ein System brauchen, das gut skaliert.
Noch ein Hinweis: Wir arbeiten an drei verschiedenen Software-Anwendungen in Windows, die alle auf einer zentralen Bibliothek basieren, die wir auch geschrieben haben (also könnte ich sagen, vier Projekte).
6 Antworten
Sowohl Scrum als auch Kanban sind wirklich "Skelette". Beides ist nicht spezifisch für die Softwareentwicklung. Scrum wurde von Softwareentwicklungsunternehmen populär gemacht, ist jedoch als allgemeine Verwaltungstechnik und nicht als Software-Projektmanagementtechnologie positioniert. Kanban entstand aus der Fertigung und wurde zunächst von Wartungsteams an die Softwareentwicklung angepasst. Sowohl Scrum als auch Kanban zielen darauf ab, den Arbeitsfluss durch das Team, das diese Arbeit erledigt, zu steuern, zu messen, wie schnell Arbeitsabläufe ablaufen, so dass Schätzungen immer genauer gemacht werden können, und Engpässe sichtbar zu machen, damit sie angegangen werden können.
Da beide nicht spezifisch für die Softwareentwicklung sind, fügen Teams, die Scrum und Kanban verwenden, dem Prozess Softwareentwicklungspraktiken hinzu, um sie inkrementell und iterativ zu helfen, die Software freizugeben und zu verbessern. Die meisten Teams, egal ob sie in einem Scrum- oder Kanban-Prozess arbeiten, übernehmen die technischen Praktiken von XP und die reflektierenden Praktiken von Crystal.
XP ist im Grunde Scrum, das auf ein einzelnes Team angewendet wird, plus Richtlinien darüber, was Code "hochwertig" macht und wie Programmierer das erreichen können. Crystal Clear gilt auch für kleine Teams, die nebeneinander angesiedelt sind, aber es ist flexibler in Bezug auf Programmierpraktiken, obwohl es auch die XP-Praktiken empfiehlt (das Buch beschreibt den Prozess als exzellent und mit unschätzbarem Rat, egal für welchen Prozess Sie sich entscheiden). Scrum-Teams übernehmen in der Regel auch die reflektierenden Praktiken von Crystal: regelmäßige "Heart-Beat" -Retrospektiven und größere Retrospektiven nach jedem wichtigen Meilenstein. Kanban erfordert ständige Reflexion und Verbesserung, aber einige Teams verwenden auch Retrospektiven.
Wenn Sie einen inkrementellen / iterativen Prozess in einem kleinen Programmiererteam anwenden wollen, dann ist XP ein guter Prozess, weil er die Messlatte für die technischen Fähigkeiten ziemlich hoch setzt und sehr gut dokumentiert ist. Wie Continuous-Flow und Kanban am besten für verschiedene Bereiche der Softwareentwicklungsbranche gelten, wird auf der kanban-dev-Mailingliste und anderswo immer noch diskutiert.
Ich würde Ihnen auch empfehlen, regelmäßige Retrospektiven durchzuführen, um den Prozess zu verbessern und ihn an Ihre spezifische Situation anzupassen.
Der wichtigste Teil besteht darin, einen reflektierenden / rückblickenden Mechanismus zu haben, der kontinuierliche Verbesserungen ermöglicht. Beginne mit einem Prozessmodell und entwickle es im Laufe der Zeit für deine Bedürfnisse. Hör auf Dinge zu tun, die es nicht wert sind. Machen Sie weiter Dinge, die einen hohen Wert haben. Probieren Sie neue Dinge aus, von denen Sie denken, dass sie wertvoll sein könnten oder um spezifische Probleme anzugehen.
Ich denke Scrum funktioniert für kleine bis mittlere Teams. Im Vergleich zu XP werden einige Details weggelassen, so dass Sie sich von XP ausleihen oder etwas Sinnvolles tun können. Egal welche Methode Sie wählen, Sie müssen die Rolle von Hühnern (Kunden / Manager / Stakeholder / Domänenexperten) in Betracht ziehen. Manchmal musst du die Rollen selbst spielen, aber viele agile Methoden funktionieren, weil es ein externes Tempoauto mit fundiertem Wissen über die Domäne gibt.
Weitere wichtige Aspekte sind die Kommunikationsebene zwischen Ihrem Team und eine Art Qualitätssicherungsmechanismus. Es ist schwierig, eine Paarprogrammierung durchzuführen, wenn Sie sich nicht im selben Gebäude befinden. Scrum versucht, innerhalb eines Sprint-Zyklus eine Funktion zur Akzeptanz zu bringen, und XP versucht, die Funktion innerhalb eines Tages durch Unit-Tests, Code-Review und kontinuierliche Integration zu integrieren.
*) Sprint kann zwischen 15 und 30 Tagen dauern.
Sie profitieren nicht viel von all dem Overhead, den ein formallisiertes System dieser Teamgröße auferlegen wird. Versuchen Sie stattdessen eine gute Verwaltungstechnik , um sicherzustellen, dass jeder sich gegenseitig zuhört und blockiert sind entfernt.
Ich habe mit einem Team dieser Größe gearbeitet und noch größer bei zwei Teams, die einige gemeinsame Bibliotheken teilten. Scrum hat gut für uns funktioniert. Jetzt arbeite ich mit einem Team mit 6 Mitgliedern und wir verwenden XP und ich denke, es funktioniert auch. Das erste Team entwickelte ein Produkt und die Einflüsse aus dem "Weltraum" waren nicht so groß. Längere Iterationen haben also gut funktioniert. Nein, wir entwickeln ein Kundenprojekt und daher sind kürzere Release-Zyklen besser für uns.
Aber SCRUM und XP sind mehr als das. Jetzt verwenden wir TDD und Pair-Programming (beides mehr aus der XP-Welt). Wir haben auch tägliche Standup-Meetings, die mehr SCRUM sind. Also haben wir XP und SCRUM übernommen, um für unser Projekt und unsere Situation zu arbeiten.
Ich würde mit kurzen Zyklen (1 Woche) und Besprechungen dieses Zyklus beginnen. Es wird einige Zeit brauchen, um eine neue Methodik in Ihrem Team zu übernehmen, aber wenn die Mitglieder bereit sind zu lernen und zu verändern, wird es funktionieren.
Tags und Links project-management scrum kanban