Agile: Unterschied zwischen den Versionen

Aus Christian Treber
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. In jedem Sprint können die Prioritäten aufs Neue festgelegt werden.
* 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 Transparenz über den Stand der Dinge.
* 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. Nicht als Post Mortem, sondern während das Projekt läuft.
* 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 möchte.
* 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

Home

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.

Home