Jan M.

Guten Abend,
ich beschäftige mich momentan mit dem Thema Vorgehensmodelle, überwiegend mit Scrum und dem V-Modell XT. Scrum sagt mir persönlich sehr zu, allerdings gibt es ein kleines Problem. Das Team besteht akutell aus nur zwei Programmierern, d.h. wir können keine klare Rollenverteilung vornehmen (drei Rollen / zwei Personen ).
Generell arbeitet jeder für sich an einem Projekt, es geht uns jedoch um die strukturierte Konzeption und Dokumentation, vor allem da das Team in den nächsten Jahren vorrausichtlich größer wird.

Ich sehe jetzt drei Lösungen:
1) Wir arbeiten mit einem anderen Vorgehensmodell
2) Wir entwickeln auf der Grundidee von Scrum ein eigenes Vorgehensmodell und steigen später auf Scrum um. Das könnte zum Beispiel so Aussehen:
Hr. Foo ist Project Owner für das Projekt "A", Hr. Bar stellt das "Team" für dieses Projekt dar. Es fehlt der ScrumMaster.
Im gegenzug ist, weil zwei Projekte gleichzeitig laufen, Hr. Bar der Project Owner von Projekt "B", das "Team" besteht aus Hr. Foo.

Ich denke mir, viele von euch werden sich jetzt an den Kopf packen, aber ich beschäftige mich noch nicht sehr lange mit diesem doch komplexen Thema und ich würde mir eine Diskussion wünschen, welche mir hilft eine Lösung für uns zu finden.

Gruß,
Jan

Mister Ad

dr.e.

Hallo Jan,

Dann eignet sich Scrum aber nicht als Lösung. Scrum bedeutet, dass die Entwickler eines Teams zusammen an einem Projekt arbeiten um Knowhow zu spreaden und mit der gemeinsamen "Kraft" des Teams das "Problem" zu beseitigen. Sofern jeder an einem eigenen Thema arbeitet sind klassische Vorgehensweisen sinniger.

Ich arbeite derzeit auch als Entwickler/Scrum-Master in einem 2er Team, jedoch ist hier der Fokus auf die gemeinsame Entwicklung gerichtet. Der Kunde ist in diesem Fall Product Owner.

Aus meiner Warte empfehle ich daher ganz klar eine Trennung der Verantwortung der Entwickler für je ein Projekt. Das entfernt nicht nur den Rollen-Overhead, sondern gibt den Entwicklern auch das Gefühl von Wertschätzung, wenn sie selbständige Projekt-Verantwortung übernehmen. Wichtig ist dabei nur, dass sie auch die Skills für derartige Aufgaben mitbringen. Es gibt nämlich häufig gute Entwickler, die in Koordination und Kommunikation Defizite aufweisen und umgekehrt.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jan M.

Hallo dr.e.,
vielen Dank für deine Antwort. Wie handhabt ihr den Product Owner wenn es keinen Kunden gibt (Beispielsweise für das APF)?

fufubaer

huhu,

ich bin im mom auch Teil einer Team-Scrum Philosophie, die aber sehr auf unsere Bedürfnisse zugeschnitten ist. Da ihr ein recht "kleines" Team seit, würde ich auch klassische Methoden vorziehen. Die Rollen in Scrum empfinde ich als eher störend, da man hier viel Zeit für eigtl. Projektunrelevantes verschwenden kann. Die Verantwortungen und Kompetenzen einmal geklärt und gut is. Wichtige Aspekte sind das Product-Backlog, der Sprint-Backlog und der/das Burndown Chart. Gutes Monitoring ist entscheidend um den Entwicklungsfortschritt zu überwachen und Aufwände besser einschätzen zu können. Bei grossen Projekten ist der Einsatz von Teil-Sprints sinnvoll, in dem eine Art Meilenstein erreicht werden muss. Zerstückeln und verteilen von Aufgaben ist der Hauptzweck in der Praxis, um Aufgaben optimal auf das Team aufzusplitten.

Ich würde dir empfehlen, dir ein eigenes Scrum-Project-Framework zu "basteln" und eure Gegenheiten und Best-Practices mit einfliessen zu lassen.

Persönlich kann ich Scrum nur empfehlen, aber nur in modifizierter Fassung

Jan M.

Vielen Dank an euch beide, wir haben uns jetzt für eine modifizierte Fassung von Scrum entschieden.

dr.e.

Bei der Entwicklung des APF gibt es Mehrheits-Entscheidung der Community bzw. derjenigen, die sich aktiv daraus an einem Thema beteiligen. Sofern ein Feature (=Mini-Projekt) also nur einen Beteiligten hat, trifft dieser seine Entscheidung alleine. Sofern derjenige seine Entscheidung nicht alleine treffen kann/möchte, fragt er die Community.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~