Agile: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(Die Seite wurde neu angelegt: „=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…“) |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
[[Hauptseite|Home]] | |||
=Agile (Scrum, Kanban)= | =Agile (Scrum, Kanban)= | ||
Was mir an Agilität seit 2003 gefällt: | 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. | * 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. | * 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. Frühe Verfügbarkeit von Features, vielleicht schon ab dem ersten Sprint. Volle | * 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 was Anschub braucht. | * 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: | 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 | * 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. | * 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: | Was ich weiter für wichtig halte: | ||
| Zeile 17: | Zeile 19: | ||
* 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. | ||
* Handwerkliche Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung. | * Handwerkliche Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung. | ||
[[Hauptseite|Home]] | |||
Version vom 14. Juni 2018, 23:21 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.
- Handwerkliche Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.