Scrum, Kanban oder andere für 4-Personen-Entwickler-Team

Question

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 funktionierte und warum. Auch andere Systeme zur Verwaltung der Entwicklung, die funktionierten, wären großartig.

Ein weiterer Hinweis: Es gibt natürlich die Möglichkeit, dass das Team wächst, also würden wir ein System brauchen, das gut skaliert.

Noch eine andere Anmerkung: Wir arbeiten auf drei separaten Softwareanwendungen unter Windows die alle auf einer zentralen Bibliothek basieren, die wir auch geschrieben (so dass ich denke, man vier Projekte sagen könnte)

Answer 1

Sowohl Scrum als auch Kanban sind wirklich Prozess "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 für die Softwareentwicklung nicht spezifisch sind, fügen Teams, die Scrum und Kanban verwenden, dem Prozess Softwareentwicklungspraktiken hinzu, um sie inkrementell und iterativ zur Freigabe und Verbesserung der Software zu unterstützen. 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 für ein einzelnes Team plus Richtlinien darüber, was Code "hohe Qualität" 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 möchten, dann ist XP ein guter Prozess, weil er die Messlatte für technische Fähigkeiten sehr hoch legt und sehr gut dokumentiert ist. Wie Continuous-Flow und Kanban am besten in den verschiedenen Bereichen der Software-Entwicklung Anwendung finden, wird immer noch auf der Kanban-Dev-Mailing-Liste und anderswo diskutiert.

Ich würde auch empfehlen, regelmäßige Retrospektiven durchzuführen, um den Prozess zu verbessern und ihn an Ihre spezifische Situation anzupassen.

Answer 2

Der wichtigste Teil ist zu eine Reflexion/rückblickende Mechanisierung haben, die kontinuierliche Verbesserung ermöglicht. Beginnen Sie mit einem Prozessmodell und entwickeln Sie es im Laufe der Zeit für Ihre 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.

Answer 3

Was ist deine Frage? Ist es die am besten geeignete Methode?

Answer 4

Von all dem Overhead, den ein formallisiertes System dieser Teamgröße auferlegt, profitieren Sie nicht besonders. Versuchen Sie stattdessen a good management technique, um sicherzustellen, dass jeder sich gegenseitig zuhört und Blöcke entfernt werden.

Answer 5

Ich denke, Scrum funktioniert für kleine bis mittlere Team. Im Vergleich zu XP gibt es einige Details aus, damit Sie sich von XP etwas 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 Pace-Car mit fundiertem Wissen über die Domain 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 15 bis 30 Tage reichen.

Answer 6

Ich habe mit einem Team von diesem sice gearbeitet und noch größer auf 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 Bewertungen dieses Zyklus beginnen. Es wird einige Zeit dauern, bis eine neue Methodik in Ihrem Team angenommen wird, aber wenn die Mitglieder bereit sind zu lernen und zu verändern, wird es funktionieren.