Agile - Versionsgeschichte

Ctreber am 31. Januar 2023 um 11:52 Uhr

2023-01-31T11:52:28Z

← Nächstältere Version		Version vom 31. Januar 2023, 12:52 Uhr
Zeile 1:		Zeile 1:
	[[~~Hauptseite~~\|Home]]		[[Christian Treber\|Home]]

	=Agile (Scrum, Kanban)=		=Agile (Scrum, Kanban)=
Zeile 20:		Zeile 20:
	* Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.		* Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.

	[[~~Hauptseite~~\|Home]]		[[Christian Treber\|Home]]
	[[Category:Notizen]]		[[Category:Notizen]]

Ctreber am 21. Oktober 2018 um 20:10 Uhr

2018-10-21T20:10:04Z

← Nächstältere Version		Version vom 21. Oktober 2018, 21:10 Uhr
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.
	* ~~Handwerkliche~~ Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.		* Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.

	[[Hauptseite\|Home]]		[[Hauptseite\|Home]]
	[[Category:Notizen]]		[[Category:Notizen]]

Ctreber am 19. Juni 2018 um 10:20 Uhr

2018-06-19T10:20:10Z

← Nächstältere Version		Version vom 19. Juni 2018, 11:20 Uhr
Zeile 21:		Zeile 21:

	[[Hauptseite\|Home]]		[[Hauptseite\|Home]]
			[[Category:Notizen]]

Ctreber am 14. Juni 2018 um 22:21 Uhr

2018-06-14T22:21:42Z

Ctreber: 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…“

2018-06-14T22:15:34Z

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…“

Neue Seite

=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. In jedem Sprint können die Prioritäten aufs Neue festgelegt werden.
* Sprint Plannings: Das Business entscheidet und verhandelt direkt mit der Realisierung. Kurze Wege statt stiller Post.
* 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.
* 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.

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.
* Dokumentation: Das Projekt geht, das Team macht etwas anderes, das Produkt bleibt. Nicht mehr Doku als nötig, aber ganz sicher auch nicht weniger.

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.

← Nächstältere Version		Version vom 14. Juni 2018, 23:21 Uhr
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]]