TopMenue

Kurzüberblick über Scrumcess

Dieser Beitrag befindet sich noch in Bearbeitung!

Scrum ist der Rahmen, Scrumcess der Prozess

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

Was ist Scrumcess?  ^

Scrumcess ist ein leichtgewichtiger, nachhaltiger, auf Scrum und den Werten des agilen Manifests aufbauender Softwareentwicklungsprozess. Scrumcess setzt auf Klasse, statt auf Masse und läuft in kurzen, zeitlich eng begrenzten Zyklen, den Sprints, ab. Die Zyklen ihrerseits laufen in den Phasen Planung, Realisation, Abnahme, sowie Reflexion/Adaption. Das Ergebnis eines Zyklus ist ein lauffähiges Produktinkrement, das der Auftraggeber jeweils nach Abschluss ei­nes Zyklus testen kann, um sein Feedback zeitnah wieder in die Entwicklung einfließen lassen zu können.

In Scrumcess wird der Auftraggeber durchgehend in die Entwicklung mit einbezogen, da berücksichtigt wird, dass Softwareentwicklungsprojekte oft viel zu komplex sind, um sie bereits im Vorwege vollständig durchzuplanen und der Auftraggeber zumeist erst durch eine intensive Beschäftigung mit dem lauffähigen, jeweils nach Ende eines Zyklus ausgelieferten Produktinkrement in die Lage versetzt wird, Entscheidungen über die wirklich und konkret benötigte Funktionalitäten treffen zu können.

Implementiertes Scrumcess ist ein Teamprozess, in dem sich alle Beteiligten auf Augenhöhe begegnen, niemand jemand anderem gegenüber weisungsbefugt ist und die Zusammenarbeit auf Werten wie Achtung, Vertrauen, Konsensfähigkeit, Selbstbestimmung und -organisation, Konzentration auf das Wesentliche, Selbstreflexion und Adaption, sowie steter Verbesserung der projektspezifischen Prozessausprägung basiert. Dabei minimiert Scrumcess Organisations- und Verwaltungsaufwände und stellt die Produktqualität und den höchsten für den Auftraggeber erreichbaren Geschäftswert in den Vordergrund.

Was ist das Geheimnis von Scrumcess?  ^

Wenn Scrumcess ein Geheimnis hat, dann besteht es darin, dass Scrumcess bereits „out-of-the-box“ konsequent darauf ausgerichtet ist, den Teammitgliedern vollständige Konzentration auf ihre jeweilige Kernaufgabe zu ermöglichen, indem es auf eine strikte Aufgabentrennung zwischen den Rollen und auf die Vermeidung von Verantwortlichkeitsüberschneidungen setzt.

Die Teammitglieder arbeiten einander permanent rollenübergreifend zu und unterstützen sich gegenseitig intensiv im Erreichen des gemeinsamen Zieles. In den wenigen, über Zeitpunkt, Ablauf, Dauer und Reihenfolge gut aufeinander aufbauenden Prozeduren, tauschen sie zum Zweck teaminterner und rollenübergreifender Abstimmung informelle Artefakte aus.

In der Folge entstehen im Projekt eine effiziente Kommunikations- und Informationskultur als Basis für höchstmögliche Produktivität bei geringstmöglichem Aufwand.

Rollen  ^

Scrumcess kennt innerhalb des Projektteams 5 verschiedene Rollen,

Den klassischen Projektleiter gibt es in Scrumcess nicht. Seine Aufgaben verteilen sich auf das Scrum-Team.

Product-Owner  ^

Die Rolle des Product-Owner nimmt eine zentrale Position in Scrumcess ein.

Der Product-Owner trägt die Gesamtverantwortung für den wirtschaftlichen Erfolg des Projekts und ist von den Auftraggebern ermächtigt, alle notwendigen Entscheidungen dafür zu treffen. Er bindet die Auftraggeber tief in das Projekt ein und führt mit ihnen die permanente Anforderungsanalyse durch, mit deren Ergebnissen er fortwährend die Anforderungsliste (Product-Backlog) aktualisiert und priorisiert. Zudem achtet er darauf, dass die Auftraggeber keinen direkten Zugriff auf die Entwickler nehmen.

Zu Beginn jeder Iteration legt er gemeinsam mit dem Entwicklungsteam fest, wie viele und welche der höchst­priorisierten Einträge in der Iteration realisiert werden (Sprint-Planning), überträgt die Einträge in eine iterationsspezifische Anforderungsliste (Sprint-Backlog) und führt am Ende der Iteration die Abnahme der fertig gestellten Anforderungen durch (Sprint-Review).

Für Fragen aller Seiten ist er stets offen und ansprechbar und beantwortet sie geduldig, kompetent und zeitnah.  [mehr]

Scrum-Master  ^

Der Scrum-Master ist der Hüter des Prozesses.

Seine Aufgabe ist, sicherzustellen, dass alle Beteiligten Scrumcess kennen oder erlernen und durchführen können. Hierzu schult, unterstützt und begleitet er das Team in der Ausübung von Scrumcess. Er fördert die Kommunikation zwischen allen Beteiligten, schlichtet Streit, ist bei allen Besprechungen des Entwicklungsteams anwesend und moderiert diese, wenn notwendig.

Er achtet darauf, dass die Regeln von Scrumcess eingehalten werden und beseitigt zeitnah aufgetretene Hemmnisse, die die Produktivität des Teams einschränken. Die Hemmnisse (Impediments) führt er in einer Liste, dem Impediment-Backlog.  [mehr]

Development-Team  ^

Die Mitglieder des Entwicklungsteam sind die Produzenten des zu entwickelnden Produktes und dafür verantwortlich, dass das Produkt in höchstmöglicher Qualität produziert wird. Das Entwicklungsteam sollte mit ca. 5-9 Entwicklern besetzt und mit allem für die Entwicklung des Produktes notwendigem Knowhow versehen sein. Das Entwicklungsteam darf im Sprint nicht gestört, unterbrochen oder verändert werden.

Die Mitglieder des Entwicklungsteams arbeiten stets in enger räumlicher Nähe zueinander und miteinander. Sie treffen sich täglich zu einer max. 15 Minuten dauernden Besprechung (Daily-Scrum), um einander über die individuellen Fortschritte des vergangenen, bzw. die Planung des aktuellen Arbeitstages zu informieren.

Zu Beginn jeder Iteration (Sprint) legen sie gemeinsam mit dem Product-Owner fest, wie viele und welche der höchstpriorisierten Einträge in der Iteration realisiert werden (Sprint-Planning), übertragen die Einträge in eine spezifische Liste (Sprint-Backlog) und führen am Ende der Iteration die Abnahme der fertig gestellten Anforderungen durch (Sprint-Review).

Nach dem Abschluss der Iteration diskutieren die Entwickler die Qualität der Iteration (Sprint-Retrospektive), identifizieren Verbesserungspotential und beschließen konkrete Veränderungen, die dann in die folgenden Iterationen einfließen.

Für Fragen des Product-Owners sind sie stets offen, ansprechbar und beantworten sie zeitnah, mit den Stakeholdern kommunizieren sie nur über den Product-Owner.  [mehr]

Stakeholder  ^

Die Stakeholder sind Personen oder Gruppen, die ein vitales Interesse am Projektergebnis haben, aber außerhalb der eigentlichen Entwicklung stehen. Sie werden vom Product-Owner tief in das Projekt ein­gebunden. Sie können z.B. die Auftraggeber, die die Entwicklung finanzieren und nach Abschluss des Projektes das Produkt erhalten, sein, aber auch User, Fachbereich, Administratoren oder das Management.

Die Stakeholder (oder zumindest Teile von ihnen) befinden sich in einem permanenten Dialog mit dem Product-Owner, mit dem sie gemeinsam die Anforderungen definieren, welcher auch darauf achtet, dass sie an ihm vorbei keinen direkten Zugriff auf die Entwickler nehmen. Die Stakeholder können auf Einladung oder auf eigenen Wunsch am Planungs- und am Abnahme-Meeting (Sprint-Planning und Sprint-Review) als stille Gäste teilnehmen.  [mehr]

Management  ^

Das Management ist in Scrumcess keine ausdrücklich produktive Rolle. Es ist das Verbindungsglied zwischen dem Projektteam und der Administration des Unternehmens. Seine Aufgabe ist, bestmögliche Rahmenbedingungen für die Projekte zur Verfügung zu stellen und aufrecht zu erhalten. Dazu gehören optimale Räumlichkeiten, Arbeitsmittel, Technik, etc., sowie die Zusammenstellung des Teams.

In nicht-agilen Unternehmen steht das Management Scrumcess oftmals skeptisch gegenüber, da Scrumcess vom ihm eine weitgehende Verantwortungsübertragung in Richtung des Projektteams erwartet.

Treten während des Projektes Behinderungen auf, die die Produktivität des Entwicklungsteams einschränken, nimmt der Scrum-Master diese in sein Impediment-Backlog auf und wird sich häufig an das Management mit der Bitte der Beseitigung dieser Probleme wenden.  [mehr]

Prozeduren  ^

Sprint (Timebox fester Dauer im Bereich 1 – 4 Wochen)  ^

Der Sprint ist die Iteration, bzw. der weiter oben angesprochene Zyklus, in der die Entwickler das Produkt weiterentwickeln. Ein Sprint hat eine konstante Dauer, die im Bereich von 1 – 4 Wochen festgelegt ist und über das gesamte Projekt nicht verändert wird.

Der Sprint beginnt mit der Planung (Sprint-Planning) und endet mit der Präsentation und der Abnahme der fertiggestellten Anforderungen (Sprint-Review), sowie der selbstkritischen Beurteilung des Sprintablaufs durch das Entwicklungsteam und den Scrum-Master (Sprint-Retrospektive).

Das Ergebnis des Sprints ist ein potentiell auslieferbares Produkt-Inkrement in höchstmöglicher Qualität und stellt einen Fortschritt im Hinblick auf das zu realisierende Endprodukt dar.

Der Sprint ist für das Entwicklungsteam ein geschützter Bereich; im Sprint dürfen keine Veränderungen des Teams vorgenommen werden, Veränderungen des Sprint-Backlogs nur, nachdem das Einverständnis des Entwicklungsteams und des Product-Owner festgestellt wurde.

In Notfällen kann ein Sprint vom Product-Owner abgebrochen werden.  [mehr]

Daily-Scrumcess (Timebox 15 Minuten)  ^

Das Daily-Scrum ist ein öffentliches, tägliches durchzuführendes StandUp-Meeting des Entwicklungsteams, indem sie einander über die individuellen Fortschritte des vergangenen, bzw. die Planung des aktuellen Arbeitstages zu informieren. Das Daily-Scrum findet jeden Tag am gleichen Ort zur gleichen Zeit statt und darf 15 Minuten nicht überschreiten. Teilnehmer sind die Entwickler und der Scrum-Master, sowie eventuelle Gäste, die sich still verhalten müssen. Es werden im Daily-Scrum keine technischen oder fachlichen Diskussionen geführt, diese werden vom Team selbst, oder vom Scrum-Master abgebrochen und auf einen Zeitpunkt nach dem Daily-Scrum verschoben.  [mehr]

Sprint-Planning  ^

Die Sprintplanung findet jeweils zu Beginn eines Sprints statt und dient dazu, die Anforderungen zu bestimmen und vorzubereiten, die im Sprint realisiert werden sollen. Sie findet in 2 Phasen statt. Zuerst, in Phase 1 (Sprint-Planning-1), das Schätzen und Auswählen der Anforderungen für den Sprint und danach, in der Phase 2 (Sprint-Planning-2), das Zerlegen der Anforderungen in Arbeitspakete (Task).

Sprint-Planning, Phase 1 (Timebox 2 – 4 Stunden)  ^

In der Phase 1 des Sprint-Planning werden die im Sprint zu realisierenden Anforderungen ausgewählt und vorbereitet. Es handelt sich um ein öffentliches Meeting, vom Product-Owner organisiert wird und an dem der Product-Owner, das Entwicklungsteam und der Scrum-Master, sowie ggf. stille Gäste teilnehmen.

Der Product-Owner hat im Vorwege aus seiner Anforderungsliste (Product-Backlog) eine weitere Liste mit einer Auswahl der höchstpriorisierten Anforderungen extrahiert (Selected-Backlog), deren Inhalt er dem Entwicklungsteam für die Realisierung im Sprint vorschlägt. Diese Liste geht er gemeinsam mit den Entwicklern durch, wobei die sie miteinander (ohne fachlich oder technisch in die Tiefe zu gehen) über jede Anforderung kurz diskutieren, dann den Realisationsaufwand der Anforderung schätzen und sie dann in die Liste der im Sprint zu realisierenden Anforderungen (Sprint-Backlog) übertragen.

Ist aus Sicht des Entwicklungsteams eine Menge zu realisierender Anforderungen in das Sprint-Backlog aufgenommen worden, deren Realisation den Sprint zeitlich ausfüllt, wird diese Phase beendet und das Entwicklungsteam verpflichtet sich gegenüber dem Product-Owner dazu, die in das Sprint-Backlog übernommenen Anforderungen im Sprint vollständig zu realisieren.  [mehr]

Sprint-Planning, Phase 2 („Timebox“ 2 – 4 Stunden)  ^

In der Phase 2 des Sprint-Planning-2 werden die im Sprint-Backlog befindlichen Anforderungen vom Entwicklungsteam in einzelne Arbeitspakete (Tasks) zerlegt. Die Phase 2 ist ein nichtöffentliches Meeting, an dem das Entwicklungsteam, der Scrum-Master und, wenn möglich, der Product-Owner teilnehmen. Kann oder soll der Product-Owner nicht teilnehmen, sollte er zumindest kurzfristig für Rückfragen erreichbar sein.

Die einzelnen Anforderungen werden in einzelne, nicht weiter teilbare Arbeitspakete, Tasks, zerlegt, deren Realisationsaufwand jeweils in Stunden geschätzt wird. Ein Task sollte von jeweils einem Entwickler in einen Arbeitstag realisierbar sein. Ist der geschätzte Aufwand größer, muss der Task geteilt werden.  [mehr]

Sprint-Review (Timebox 2 Stunden)  ^

Das Sprint-Review ist ein öffentliches Meeting mit einer Dauer von ca. 2 Stunden, das am letzten Tag des Sprints stattfindet und durch das Entwicklungsteam organisiert wird. Teilnehmer sind das Entwicklungsteam, der Scrum-Master und der Product-Owner, sowie eventuell eingeladene Gäste, die still anwesend sein dürfen.

Das Entwicklungsteam präsentiert dem Product-Owner im Sprint-Review die gemäß der „Definition of Done“ vollständig fertiggestellten Anforderungen, woraufhin der Product-Owner jeweils entscheidet, ob er die präsentierte Anforderung akzeptiert oder ablehnt.  [mehr]

Sprint-Retrospektive (Timebox 0,5 – 2 Stunden)  ^

Bei der Sprint-Retrospektive handelt es sich um ein nichtöffentliches Meeting, das ca. 0,5 – 2 Stunden dauert und am letzten Tag des Sprints nach dem Sprint-Review stattfindet. Es wird durch das Entwicklungsteam oder den Scrum-Master organisiert und an dem i.A. auch nur das Entwicklungsteam und der Scrum-Master teilnehmen; jedoch kann bei Bedarf auch der Product-Owner eingeladen werden.

Die Teilnehmer der Sprint-Retrospektive diskutieren offen und ehrlich in kollegialer Atmosphäre, konstruktiv, ohne gegenseitige Anschuldigungen, Schuldzuweisungen oder direkter Konfrontation über die Qualität des Sprints. Identifizieren sie verbesserungswürdige Bereiche, überlegen sie sich gemeinsam, wie eine Verbesserung aussehen könnte, beschließen konkrete Veränderungen, die sie im nächsten Sprint umsetzen.  [mehr]

Estimation-Meeting (Timebox 2 – 4 Stunden)  ^

Das Estimation-Meeting ist ein öffentliches Meeting und der Phase 1 des Sprint-Planning sehr ähnlich. Es handelt sich um eine Vorplanung für die als Nächstes nach dem aktuellen Sprint zu realisierenden Anforderungen und sollte ungefähr im letzten Drittel des Sprints stattfinden.

Der Product-Owner organisiert das Meeting, Teilnehmer sind das Entwicklungsteam, der Scrum-Master und der Product-Owner. Gäste können eingeladen werden und dürfen still anwesend sein.

In diesem Meeting gibt der Product-Owner dem Entwicklungsteam einen Ausblick auf die als nächstes zu bearbeitenden Anforderungen, die dann jeweils vom Entwicklungsteam ohne tiefgehende Diskussion grob geschätzt werden, was für beide Seiten, Entwicklungsteam und Product-Owner von hohem Wert ist; das Entwicklungsteam bekommt einen Ausblick auf die kommenden Anforderungen und der Product-Owner die Möglichkeit, seine Planung anhand der Schätzungen zu verfeinern.  [mehr]

Artefakte  ^

Product-Vision  ^

Die Product-Vision ist eine möglichst klare und deutliche, plausible und überzeugende, emotionale und mitreißende Beschreibung des zu entwickelnden Produktes.

Sie wird vom Product-Owner in Zusammenarbeit mit den Stakeholdern im Vorfeld des Projektes definiert und zeichnet ein deutliches Bild, das die interne Kompassnadel des Projektes auf das zu erreichende Ziel ausrichtet und jeden einzelnen Beteiligten und das gesamte Projektteam insgesamt zu jeder Zeit darin unterstützt, den Weg des Produktes auf das skizzierte Ziel auszurichten.  [mehr]

Product-Backlog  ^

Das Product-Backlog ist eine stetig wachsende Liste aller aktuell bekannten Anforderungen. Die Pflege und Aktualisierung des Product-Backlogs gehört zu den wichtigsten Aufgaben des Product-Owners. Auch wenn jedes Projektteam-Mitglied Einträge hinzufügen darf, ist er jedoch der Einzige, der sie in vollem Umfang bearbeiten, d.h. auch die hinzugefügten Einträge übernehmen und verwerfen kann.

Die einzelnen Anforderungen werden in Form von User-Stories formuliert „(als [ROLLE] will ich, dass ich [FUNKTIONALITÄT], damit ich [NUTZEN])“. Ein Eintrag im Product-Backlog wird „Product-Backlog Item“ genannt, verfügt über einen im Product-Backlog eindeutigen Prioritätswert (wobei höhere Werte einer höheren Priorität entsprechen) und wird vom Product-Owner stets absteigend nach Priorität der Product-Backlog Items sortiert.

Das Product-Backlog wird vom Product-Owner permanent um neue Anforderungen, d.h. um Product-Backlog Items, erweitert, aktualisiert und sortiert.  [mehr]

Selected-Backlog  ^

Bei dem Selected-Backlog handelt es sich um eine Auswahl der höchstpriorisierten Einträge des Product-Backlog, die vom Product-Owner für die Realisation im aktuellen Sprint vorgeschlagen werden. Die einzelnen Einträge des Selected-Backlog, die Selected-Backlog Items, werden dem Entwicklungsteam vom Product-Owner im Sprint-Planning, Phase 1, präsentiert und sind die Basis für die Anforderungsliste der Iteration (Sprint-Backlog).  [mehr]

Sprint-Backlog  ^

Das Sprint-Backlog ist die Liste von Selected-Backlog Items, die vom Entwicklungsteam für die Realisierung im aktuellen Sprint akzeptiert wurden und als Sprint-Backlog Items in das Sprint-Backlog übernommen wurden. Sie bilden die Basis für die im Sprint zu realisierenden Anforderungen. Das Entwicklungsteam verpflichtet sich dazu, am Ende des Sprint-Planning, Phase 1, alle Einträge des Sprint-Backlog im Laufe des Sprints vollständig zu realisieren (Commitment).

Das Sprint-Backlog darf im laufenden Sprint nur im Dialog und mit ausdrücklicher Einwilligung des Entwicklungsteams geändert werden.  [mehr]

Task  ^

Bei den Tasks handelt es sich um einzelne Arbeitspakete, in die die Sprint-Backlog-Items des Sprint-Backlogs im Sprint-Planning, Phase 2 zerlegt wurden. Sind alle Tasks eines Sprint-Backlog Items vollständig gemäß der „Definition of Done“ realisiert, ist die Anforderung vollständig realisiert. Der Aufwand eines Tasks wird in Arbeitsstunden geschätzt und sollte innerhalb eines Tages realisierbar sein. Ist ein Task aufwändiger, als in einem Tag realisierbar ist, muss der Task weiter aufgeteilt werden, bis die Teile in jeweils einem Tag realisierbar sind.  [mehr]

Sprint-Vision  ^

Das Thema / das Ziel des Sprints in einer textuelle, bildhaften Formulierung, um den Entwicklern ein gemeinsames Bild des Zieles zu geben.  [mehr]

Impediment-Backlog  ^

Das Impediment-Backlog ist eine Liste, die wird vom Scrum-Master gepflegt und bearbeitet wird, die während des Sprints aufgetretenen Hindernisse (Impediments), die die Produktivität des Entwicklungsteams behinderten, enthält.  [mehr]

Sprint-Burndown-Chart  ^

Das Sprint-Burndown-Chart ist eine Grafik, aus der der Fortschritt und der aktuelle Zustand der aktuellen Iteration hervorgehen. Sie zeigt eine Kurve, die sich, ausgehend von einem höheren Wert (Summe der geschätzten Aufwände der Anforderungen in Storypoints), gegen Null („alle Anforderungen realisiert“) bewegt, bzw. die Nulllinie schneidet.

Werte über der Nulllinie sind noch offene Aufwände, Werte auf der Nulllinie selbst ist die Grenze der vereinbarten Aufwände, Werte unterhalb der Nulllinie bedeuten eine Übererfüllung durch zusätzlich geleistete Aufwände.  [mehr]

Commitment  ^

Das Commitment ist das Versprechen, bzw. die Anerkennung der Verpflichtung durch das Entwicklungsteam, die aus dem Selected-Backlog in das Sprint-Backlog übernommenen Anforderungen vollständig zu realisieren.

Man kann das Commitment auch als einen mündlich geschlossenen Vertrag zwischen dem Entwicklungsteam und dem Product-Owner ansehen, in dem sich das Entwicklungsteam verpflichtet, die akzeptierten Anforderungen vollständig zu realisieren und sich der Product-Owner im Gegenzug dazu verpflichtet, das Entwicklungsteam vorbehaltlos soweit wie möglich darin zu unterstützen.  [mehr]

Velocity  ^

Die Velocity ist die sich aus der Erfahrung ergebene Entwicklungsgeschwindigkeit des Entwicklungsteams in Storypoints pro Sprint. Sie wird ermittelt, indem der Durchschnitt der Summe der in den Sprints abgearbeiteten Storypoints über die Anzahl der Sprints gemittelt wird. Es braucht im Allgemeinen 3 oder mehr Sprints, bis sich die Velocity auf einen Entwicklungsteam-spezifischen Wert stabilisiert. In den ersten Sprints, bis sich die Velocity stabilisiert hat, wird die Velocity geschätzt und akzeptiert, dass in dieser Zeit das Commitment nicht immer eingehalten werden kann.  [mehr]

Resultat(e)  ^

Product-Increment  ^

Das Product-Increment ist eine potentiell auslieferbare Produktversion („potentially shippable product-increment“), das lauffähig und — zumindest theoretisch — für sich allein einsetz- und nutzbar ist. Es handelt sich (bis auf die letzte und endgültige Auslieferung) nicht um eine Endversion, sondern um einen gegenüber der Version des vorangegangenen Sprints weiterentwickelten Zwischenstand.  [mehr]

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE