Wie arbeitet eVolpe in Scrum?
An die andere Seite (hier) haben wir schon über Scrum geschrieben. Dort erklären wir was bedeutet Scrum genau und wie ist es organisiert. Im folgenden Absatz sprechen wir mehr über der praktischen Seite. Wie arbeiten wir in eVolpe übereinstimmend mit den Regeln von Agile Software-Entwicklung? Die Antwort darunter.
Produkt Backlog
Die Software-Entwicklung startet in eVolpe nach der Beratungsphase, der Systemauswahl und nach den Handelsvereinbarungen. Für unsere Kunden führen wir Workshops wie System Overview (System Überblick) und Produkt Discovery (Produkt Entdeckung). Sie sind sehr kreative Aktivitäten, die der Blick auf Customer-Relationship-Management in spezifischen Unternehmen ermöglichen. Bemerkenswert ist dass, solche praktischer Unterrichten hoher Engagement-Ebene an Kunden erfordern. Durch diese Workshops, um die Fragen besser zu visualisieren, benutzen wir kreativen Techniken mit Verwendung von mehrfarbigen Haftnotizen, Kugelschreibern, Whiteboard oder antistatische Folien.
Das Ergebnis der Workshops ist das Produkt Backlog.
Das Produkt Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Das Produkt Backlog ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss ihren Ursprung im Produkt Backlog haben. Der Produkt Owner ist für die Pflege des Produkt Backlogs verantwortlich. Er verantwortet die Reihenfolge bzw. Priorisierung der Einträge.
Die Anforderungen im Produkt Backlog sollten nicht technisch, sondern fachlich und anwenderorientiert sein. Eine Möglichkeit, um diese Sichtweise zu unterstützen, ist die Formulierung der Produkteigenschaften als User Stories.
Das Produkt Backlog ist nicht vollständig und erhebt auch nicht diesen Anspruch. Zu Beginn eines Projektes enthält es die bekannten und am besten verstandenen Anforderungen. Die Priorisierung der Eintragungen erfolgt unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Eintragungen mit der höchsten Priorität werden als erste im Sprint umgesetzt.
In einigen Fällen, vorbereiten wir auf der Grundlage von Produkt Backlog eine Abschätzung. Wir machen das nur um die Größenordnung des Projekts zu erhalten. Dieser Ansatz wird am häufigsten verwendet, wenn die Bestellung von dem Projektbudget abhängig ist. Beachten Sie jedoch, dass Scrum alle Änderungen ermöglicht und sogar unterstützt. So diese Schätzung ist hauptsächlich illustrativ.
Während Sprints
In Scrum spricht man von Ereignissen oder Aktivitäten statt von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Alle Aktivitäten von Scrum haben feste Zeitfenster, die nicht überschritten werden sollen.
Die Umsetzung des Projekts läuft in 2-wöchigen Iterationen. Nach jeder Stufe muss man eine neue Funktionalität oder Änderung vorstellen. Jede Iteration – so genannte Sprint, beginnt mit einem Treffen: Sprint Planung. Während Sprint Planung bestimmen wir das Ziel für das bevorstehend Spint. Auf dieser Grundlage werden auch die User Stories aus Backlog ausgewählt. Der zweite Teil des Treffens besteht aus einer exakten Planung der Entwicklungsteam-Arbeit.
Jeden Tag halten wir ein maximal 15 Minuten lang, tägliches Stand-up-Treffen bei unserer Scrum-Tafel. Jedes Mal tritt es eine Fortschritts-Inspektion und notfalls eine Anpassung des Plans dazu. Wir setzten dann auch was am letzten Tag erreicht wurde, was ist der Plan jetzt und ob haben wir solche Probleme getroffen.
Während Sprints halten wir auch ein Treffen genannt Refinement.
Refeinment widmen wir um neuen Anforderungen durchdiskutieren, so alles richtig geklärt und geschätzt werden kann. Wir vorbereiten neue Ausgaben und schicken die nach Produkt Backlog. Später wählen wir was möchten wir in bevorstehend Sprint bearbeiten.
Mit was endet ein Sprint?
Am Ende des Sprints treffen wir uns mit dem Kunden (über Skype oder per Telefon) durch Sprint Review. Das Team gibt dem Kunden die resultierende Erhöhung, zusammen mit einer kurzen Präsentation, was getan wurde. Es ist auch die richtige Zeit für die Diskussion über die neuen Anforderungen, die durch die aktuelle Form des Produkts inspiriert werden könnten. Wir führen auch die Inspektion von geleisteter Arbeit und sprechen über Anpassung an die neuen Anforderungen.
Nach jedem Sprint ist es möglich, die Pakete, die Erhöhung der Produktionsumgebung bilden zu installieren. Natürlich muss man nicht jeder Sprint mit diesem Release beenden. Es ist völlig abhängig von der Entscheidung des Kunden.
Zuvor können Kunden mit neuen Funktionalitäten in die Testumgebung sich bekannt machen. Auf dieser Grundlage akzeptiert die Kunde das Ergebnis des früheren Sprints.
Das letzte Treffen, mit Entwicklungsteam, Proxy-Produkt Owner und Scrum Master (verantwortlich für den Prozess) ist die Sprint-Retrospektive.
Retrospektive ist eine hervorragende Möglichkeit, die Art und Weise in denen wir als Team zusammenarbeiten untersuchen. Sowie die zwischenmenschliche Beziehungen. Wir diskutieren über was wir haben gemacht und auf was sind wir stolz. Es ist auch wichtig über was wir noch effektiver als Team machen brauchen zu sprechen.
Jedes Projekt kann aus mehreren folgenden Sprints zu bestehen. Sonst von ein paar bis zu zehn und mehr solcher Iterationen. Wenn der Kunde es festgestellt hat, dass das Produkt bereits fertig ist, gehen wir weiter und starten mit Wartungsmodus (das im Servicevertrag festgelegt ist).
