Agiles Vorgehen zu Hause anwenden

Taskboard at homeWer die Vorzüge eines agilen Vorgehens im Berufsleben kennen und schätzen gelernt hat, möchte mitunter auch zu Hause nicht darauf verzichten. Viele Aufgaben und zu wenig Zeit, um alle abzuarbeiten, ist für viele Agilisten nicht nur im beruflichen, sondern auch im privaten Umfeld eine Herausforderung. Also heißt es, bewusst zu entscheiden, was „ausgeliefert“ wird und was vorerst nicht umgesetzt wird.

Besonders häufig findet ein einfaches Kanban-Board Anwendung, das dabei hilft, den vollen Überblick über die anliegenden Aufgaben und den Stand der Bearbeitung zu behalten. Es wird dann von „Personal Kanban“ gesprochen. In einem priorisierten Backlog wird festgehalten, welche Arbeiten in welcher Reihenfolge anfallen. In regelmäßigen Standups wird gemeinsam besprochen, was als nächstes angegangen wird. Etwa nach dem gemeinsamen Abendessen. Ein WiP-Limit begrenzt die Anzahl der parallel bearbeiteten Items. Teilweise wird das WiP-Limit am Wochentag ausgerichtet, da z.B. am Wochenende mehr Zeit für die Erledigung privater Aufgaben zur Verfügung steht als unter der Woche.
Damit eine Aufgabe tatsächlich als abgeschlossen gilt, sollte sie entsprechend einer formulierten Definition of Done abgeschlossen sein.
Abweichend von einer solchen Einteilung des Boards in „Backlog“, „Doing“ und „Done“ wird teils auch mit einem Board, das nach den Wochentagen eingeteilt ist, gearbeitet.

Ausgangspunkt für viele Personal Kanban-Anwender ist eine Situation, in der sie durch besonders viele Aufgaben überwältigt werden. Dies kann z.B. durch eine anstehende Hochzeit, einen Hausbau, Umzug oder ähnliches bedingt sein. Genau unter solchen Umständen ist es besonders wertvoll, sich die Zeit zu nehmen, um einen vollständigen Überblick der noch ausstehenden Arbeiten zu erhalten. Ein persönliches Kanban-Board aufzusetzen und initial zu befüllen ist mit weniger als einer Stunde Zeiteinsatz locker machbar. Ausprobieren lohnt. Durch regelmäßiges Reflektieren über den Prozess können nach und nach Optimierungen vorgenommen und so ein passendes persönliches Set gefunden werden.

Vereinzelt wird auch vom Einsatz von Scrum in der Familie gelesen, hier ist allerdings bereits die Rolleneinteilung in ScrumMaster und Product Owner unter Umständen eine kleine Herausforderung. Aber warum nicht mal selbst probieren?

Erfahrungsberichte zur Agile-Anwendung im privaten Umfeld:

Foto: orcmid

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Werbeanzeigen

25 Blogs zu Scrum und agiler Softwareentwicklung

Welche Blogs zu Scrum und agile Softwareentwicklung solltet ihr nicht verpassen? Vor einiger Zeit habe ich meine persönlichen Top 5 Scrum-Blogs vorgestellt. Agile Office fragte in einem Kommentar, welche weiteren Blogs ich zu dem Thema lese.
Nachfolgend daher eine umfangreichere Liste von 25 Blogs zu Scrum und agiler Softwareentwicklung:

  1. „Scrum Log“ von Jeff Sutherland: Der „Vater von Scrum“ schreibt seit 2002 über alles rund um Scrum, von „Dealing with Bugs in a Sprint“ bis zu „Hackathons – How it’s done at Facebook“
  2. „Telling It Like It Is“ von Ken Schwaber: Der Mitbegründer von Scrum und Gründer von Scrum.org schreibt regelmäßig über seine Sicht auf die Entwicklungen in der Scrum Community.
  3. ScrumAlliance Articles: Hier gibt es Artikel von vielen erfahrenen Scrum Trainern und Professionals.
  4. „bor!sgloger — leading Scrum with passion“ von Boris Gloger: Einer der bekanntesten Scrum-Trainer aus Deutschland versorgt uns regelmäßig mit aktuellen Tipps und Tricks rund um agile Softwareentwicklung.
  5. „All Things Product Owner“ von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board.
  6. „Lean und Kanban“ von Arne Roock: Der Prokurist bei it-agile und Träger eines schwarzen Gürtels in Karate schreibt einen der wenigen deutschen Blogs über Kanban in der Softwareentwicklung.
  7. „Dayley Agile“ von Alan Dayley: Ein Softwareentwickler, der seit vielen Jahren auf agile Softwareentwicklung schwört und seine Erfahrungen mit uns teilt.
  8. Implementing Scrum von Michael Vizdos: Der Scrum-Trainer berichtet von seinen Erlebnissen, Tony Clark liefert ihm herausragende Illustrationen dazu. Sehr sehenswert.
  9. „inside-scrum“ von Jean-Pierre: Ein Anwenderbericht vom Start und der Durchführung eines Scrum-Projekts.
  10. Agile Product Design: Agile Softwareentwicklung betrachtet aus dem Blickwinkel des Product Designs, eine längere Zeit schon still, aber mit sehr interessanten Artikeln.
  11. Peter Beck: Scrum-Trainer von DasScrumTeam. Zuletzt leider etwas ruhig geworden.
  12. „scrum breakfast“: Die Selbstbeschreibung drückt es am besten aus: „Blog about Scrum: getting started, crisis project management and transforming into a lean organization.“
  13. ScrumEdge: Ein weiteres Scrum-Blog, das durch eine hohe Frequenz von guten Artikeln überzeugt.
  14. „Agile Product Owner“ von Jennifer: Die Eigenbeschreibung „Sharing the Art of Agile Product Ownership“ trifft es auf den Punkt. Zuletzt ist es in dem Blog leider eher ruhig geworden.
  15. ScrumCenter: Der Corporate Blog eines agilen Beratungsunternehmens. Viele Inhalte von Präsentationen werden behandelt, aber auch auf interessante Artikel verwiesen.
  16. Scrumology von David Bland: Entgegen dem Namen geht es nicht nur um Scrum, sondern auch um Kanban und „schlanke“ Softwareentwicklung. David teilt seine Erfahrungen aus der Praxis.
  17. Stefan Roock: Der Trainer für agile Softwareentwicklung berichtet über seine Erlebnisse und Erfahrungen aus seiner Beratungstätigkeit.
  18. The Agile Executive von Israel Gat: Dieser Blog beschäftigt sich mit dem Rollout von „Agile“ auf Unternehmensebene, also über einzelne Teams hinweg.
  19. The Agilista PM von Donna Reed: Mit Fachartikeln, Webinaren und Webcasts werden hier Aspekte des agilen Projektmanagements behandelt.
  20. Scaling software agility: Wie lässt sich agile Softwareentwicklung in großen Projekten einsetzen? Hier gibt es Antworten.
  21. PM-Blog von Stefan Hagen: Obwohl sein Blog nicht ausdrücklich auf agile und schlanke Vorgehensweisen fokussiert, ist ihm dieses Faible von Stefan anzumerken.
  22. „ScrumTools – agiles Projektmanagement“: Neben einer Liste von Scrum-Tools gibt es von Zeit zu Zeit Artikel im zugehörigen Blog.
  23. agileoffice: Agile, Lean und Scrum sind die Themen, mit denen sich dieses Blog beschäftigt.
  24. „Systems Thinking, Lean and Kanban“ von David Joyce: David teilt seine langjährigen Erfahrungen als Coach und Teammember und verweist regelmäßig auf spannende Artikel.
  25. „Lean Software Engineering“ von Corey Ladas und Bernie Thompson: Die beiden teilen ihre Erfahrungen aus Teams von u.a. Microsoft und IBM. Ihre Artikel bekommen hohe Aufmerksamkeit und sorgen regelmäßig für umfangreiche Diskussionen.
Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.
Foto: Von Rafa[EU]

Card, Conversation, Confirmation: Die drei C’s einer User Story

Was gibt es bei der Erstellung von User Stories zu beachten? Drei C’s können dabei helfen: Card, Conversation, Confirmation. Die drei C’s gehen auf Ron Jeffries zurück, der sie schon 2001 in einem Blogpost beschrieb: Essential XP: Card, Conversation, Confirmation.
Noch heute gelten sie neben den INVEST-Kriterien als wichtige Grundregel bei der Erstellung von User Stories.

Card
User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Team vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten. Es sollte damit nicht mehr Platz als der auf der Karte verfügbare benötigt werden, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Reicht der Platz nicht aus, ist die Story in der Regel zu groß oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über den Wunsch in Form der Konversation mit dem Team abgestimmt.

Conversation
Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story wird als sehr wichtig erachtet. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und dem Team „durch einen Türschlitz“ zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während einem Anforderungsworkshop, in einer Schätzklausur und während der Sprint-Planung. Die mündlichen Absprachen werden manchmal begleitet durch zusätzliche Dokumente, wie etwa Vorlagen in einem Projektwiki oder Mockups.

Confirmation
Um einen Nachweis zu haben, ob die Stories in der gewünschten Form implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Der Kunde hält dafür vor Beginn der Umsetzung einer Story die zentralen Kriterien fest, nach denen die Abnahme der Story später erfolgen soll. Durch die Implementierung von Akzeptanztests kann die Erfüllung der Akzeptanzkriterien sichergestellt werden.

Mit den drei C hat uns Ron Jeffries eine gute Merkhilfe für die Grundregeln einer User Story an die Hand gegeben.

Weitere gute Lektüre zu User Stories:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von jakuza

Vorteile von Scrum für den Auftraggeber

Für viele Unternehmen, die Software-Entwicklungsprojekte vergeben, ist immer noch ein fixierter Funktionsumfang zu einem fixierten Preis das präferierte Vertragsmodell. Das bietet ein Projekt, das nach agilen Vorgehensweisen wie Scrum durchgeführt wird in der Regel nicht! Ein Scrum-Projekt bietet aber eine Reihe anderer Vorteile und auch abgewandelte Vertragsmodelle, die Unternehmen die gewünschte Sicherheit bei der Vergabe von Entwicklungsprojekten bieten.

Zu den Vorteilen der Anwendung von Scrum gehören die Ausrichtung auf eine hohe Qualität, eine hohe Flexibilität für den Auftraggeber und die frühe Möglichkeit, einen ersten Stand der beauftragten Anwendung einzusehen und testen zu können. Eine Reihe von Vorteilen für die Kunden habe ich in einem aktuellen Artikel für das Blog von //SEIBERT/MEDIA zusammengefasst: „Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?“

Foto: Von marcobuonvino

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

User Stories schreiben ist wie Fahrrad fahren


Schon einmal versucht, jemandem zu erklären, wie man Fahrrad fährt? Macht nicht wirklich Sinn, oder? Man muss einfach üben, üben, hinfallen, weiter üben.

So ähnlich ist das auch mit dem Schreiben von User Stories. Diese Form der Anforderungsbeschreibung lässt sich natürlich grundlegend auch rein verbal erklären. Eine User Story besteht aus einem Namen, einem beschreibenden Satz und einer Reihe von Akzeptanzkriterien. Aber gute Stories schreiben lernt man nicht durch eine Erklärung. Das ist genau so ein Balanceakt wie Fahrrad fahren. Die Stories sollen weder zu ungenau, noch zu detailliert, weder zu groß, noch zu klein sein. Übung im Schreiben von User Stories an sich und der Austausch mit dem Team ist dabei unerlässlich. Das Team wird in der Regel sehr deutlich kommunizieren, welcher Detaillierungsgrad einer Story ausreichend ist und insbesondere, wenn er es einmal nicht ist. Ein Anforderungsworkshop mit dem gesamten Team zum Start des Projektes kann helfen, sich aufeinander einzuspielen.

Im Laufe des Projekts entwickelt sich eine gemeinsame Sprache zwischen den Beteiligten, die zu einer Vereinfachung der Zusammenarbeit führt und es damit gerade auch jenen leichter macht, die in dem Projekt einen großen Teil der Stories schreiben.

Aber am Anfang steht: der Anfang. Wie beim Fahrrad fahren. Der Mut wird belohnt.

Weitere Informationen zu User Stories:

Foto: Von Bruce McAdam

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Die agile Revolution: Was bringt die Umstellung von einem klassischen auf ein agiles Vorgehensmodell?

RevolutionWas bringt die Umstellung von einem klassischen Wasserfallmodell in der Softwareentwicklung auf agile Prinzipien? Sie kann bei konsequenter Durchführung geradezu einer Revolution gleichen, wie ich mit zwei Fallbeispielen zeigen möchte.

So berichtet der Mit-Unterzeichner des agilen Manifests Mike Beedle von seinem ersten Projekt, bei dem er die Umstellung von klassischer zu agiler Vorgehensweise mit Scrum begleitet hat:

„Eighty consultants; hundreds of employees; thousands of pages of documentation that included processes, procedures, requirements, design, testing; and hundreds of failed project plans, could not deliver what Scrum and Org Patterns delivered in 4 months with 10 people. It was amazing. It was magical.“
[Auszug aus „Mike Beedle on the Early History of Scrum„]

Auch bei Salesforce.com wurde die Umstellung von einem klassischen Vorgehen auf die „Adaptive Development Methodology“, einer von Salesforce.com eingesetzten Mischung aus Scrum und eXtreme Programming, wie eine Revolution wahrgenommen.
Mehr von diesem Beitrag lesen

Veranstaltungtipp: Agile Softwareentwicklung bei SAP

Die Scrum User Group Rhein-Main lädt am kommenden Donnerstag, 19.8.2010, zu einem interessanten Vortrag nach Mainz ein: „Agile Softwareprodukt-Entwicklung bei SAP im Kontext von Lean“. Referent ist Christian Schmidkonz, bei der SAP AG Leiter des Agile Center of Expertise.
Es ist ein spannender Erfahrungsbericht zur internationalen agilen Softwareproduktentwicklung der SAP zu erwarten. Im Anschluss bleibt genug Zeit, um das Thema weiterzudiskutieren und eigene Erfahrung auszutauschen.

Der Abend soll der Einstieg für ähnliche Veranstaltungen der Scrum User Group sein. Treffen finden jeden 3. Donnerstag im Monat an wechselnden Orten im Rhein-Main Gebiet statt. Die Einladung erfolgt immer via XING-Gruppe „agile Rhein-Main„.

Weitere Informationen und eine Möglichkeit zur Anmeldung gibt es auf der XING-Eventseite.

Erfordert agile Softwareentwicklung keine Disziplin?

Agile Software-Entwicklung hat noch häufig mit einem Vorurteil zu kämpfen. Bei vielen Managern scheint im Kopf verankert zu sein, dass nur ein Vorgehen nach dem Wasserfall-Modell, bei dem vor dem Start eines Projektes jeder einzelne Schritt in Anforderungslisten festgehalten wird, ein sauberes, strukturiertes Vorgehen ist.

Agile Methoden der Softwareentwicklung werden dann oft als „Durchwurschteln“ bezeichnet. Aber ist es wirklich so, dass die Vorgehensmodelle der agilen Softwareentwicklung weniger Disziplin erfordern als klassische Vorgehensmodelle?
Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: