Agile: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
[[ | [[Christian Treber|Home]] | ||
=Agile (Scrum, Kanban)= | =Agile (Scrum, Kanban)= | ||
Zeile 18: | Zeile 18: | ||
* Requirements Engineering: Das Problem zu verstehen ist die Basis für erfolgreiche Software-Vorhaben. Dem Produkt Owner und dem Team werden von Scrum implizit eine Menge Fähigkeiten und Aktivitäten zugedacht, die aus guten Gründen Gegenstand einer eigenen Disziplin sind. | * Requirements Engineering: Das Problem zu verstehen ist die Basis für erfolgreiche Software-Vorhaben. Dem Produkt Owner und dem Team werden von Scrum implizit eine Menge Fähigkeiten und Aktivitäten zugedacht, die aus guten Gründen Gegenstand einer eigenen Disziplin sind. | ||
* | * Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung. | ||
[[ | [[Christian Treber|Home]] | ||
[[Category:Notizen]] | [[Category:Notizen]] |
Aktuelle Version vom 31. Januar 2023, 12:52 Uhr
Agile (Scrum, Kanban)
Was mir an Agilität seit 2003 gefällt:
- Business-getriebenes Backlog: Das, was für das Geschäft das Wichtigste ist, kommt zuerst dran. Die Welt dreht sich auch im Projekt weiter - in jedem Sprint können die Prioritäten aufs Neue festgelegt werden. Das Geld wird dort investiert, wo es das Meiste bringt.
- Sprint Plannings: Das Business entscheidet und verhandelt direkt mit der Realisierung. Kurze Wege statt stiller Post. Ich halte viel davon, auch die Nutzer im Planning zu haben - schneller und sicherer kann man alternative Lösungsmöglichkeiten nicht verhandeln.
- Iterationen: Regelmäßige ehrliche Konfrontation mit dem eigenen Tun. Volle Transparenz über den Stand der Dinge. Frühe Verfügbarkeit von Features, vielleicht schon ab dem ersten Sprint. Volle Konzentration auf wenige Dinge.
- Eingebaute Retrospektiven: Regelmäßige Reflexion über das, was gut läuft und das, was Anschub braucht. Während das Projekt läuft und ihm nützt, nicht als Post Mortem.
Was ich dabei nicht über Bord werfe:
- Architektur: Zu einem gewissen Grad lohnt es sich vorab zu überdenken, wohin die Reise geht. Und festzulegen, was einem wichtig ist, und nach welchen Kriterien man verschiedene mögliche Lösungen bewerten will.
- Dokumentation: Das Projekt geht, das Team macht etwas anderes, das Produkt bleibt. Nicht mehr Doku als nötig, aber ganz sicher auch nicht weniger als erforderlich.
Was ich weiter für wichtig halte:
- Requirements Engineering: Das Problem zu verstehen ist die Basis für erfolgreiche Software-Vorhaben. Dem Produkt Owner und dem Team werden von Scrum implizit eine Menge Fähigkeiten und Aktivitäten zugedacht, die aus guten Gründen Gegenstand einer eigenen Disziplin sind.
- Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.