www.projectwizards.net/

Projekt-Praktikum: Aufwand schätzen oder nicht?

am 3. Juni 2009

Bärbel de BouvierSeit meinem Aufwandsschätzungs-Faux-pax vor ein paar Tagen beschäftigt mich das Schätzungs-Thema. Dabei bin ich auf verschiedene Postings von – vorwiegend amerikanischen – Bloggern gestossen, die darüber diskutieren, ob man eine Aufwandsschätzung überhaupt braucht. Ein Gedanke, der mit bislang noch gar nicht in den Sinn kam. Die Argumente sind aber nur zu schön:

  • Aufwandsschätzung sind nie wirklich genau und schaffen daher keinen Mehrwert.
  • Selbst wenn sie hinreichend genau sind, die Arbeit muss trotzdem erledigt werden. Warum also Zeit mit Schätzungen vergeuden?
  • Das Schätzen des Aufwands sorgt für schlechte Stimmung, da jeder gezwungen ist mitzumachen und einem Konsens zuzustimmen, auch wenn er tief im Inneren anderer Meinung ist.
  • Die Aufwandschätzungen beeinflussen das Verhalten der Teammitglieder in negativer Weise. Entweder, indem sie sie unter Druck setzen den Termin einzuhalten und damit schlechtere Qualität zu liefern oder, wenn sie dem Termin voraus sind, in ihren Anstrengungen nachzulassen und damit Zeit zu verschwenden.

Dem stehen natürlich die bekannten “Vorteile” entgegen:

  • Der Wert eines Projektes lässt sich nicht ohne Aufwandsschätzung ermitteln.
  • Ein Sprint lässt sich nicht planen, ohne den Aufwand zu kennen.
  • Ohne Aufwandsschätzung geht die Disziplin im Team flöten und es wird Zeit verschwendet.

Die Frage ist jetzt natürlich, was uns die Autoren damit sagen wollen. Wird da ein endlich etabliertes, in unzähligen Projekten bewährtes Verfahren schon wieder in Frage gestellt? Ein bischen schon. Meine Erkenntnis: Nicht beirren lassen und weiter machen! Trotzdem bleibe ich an dem Thema dran. Mehr dazu im nächsten Posting.

Tags: , , ,

Projekt-Praktikum: Aufwandsschätzung

am 26. Mai 2009

Bärbel de BouvierOh je! In meinem letzten Blog-Post zum Thema Aufwandsschätzung habe ich ein wenig daneben gehauen. Aber es gibt ja nichts, was man nicht auf Youtube finden und daraus seine Lehren ziehen kann. Beispielsweise eine zweiteilige Session von Mike Cohn, einem der Gründer der Scrum-Alliance, zum Thema Agile Estimation. Der Vortrag dauert insgesamt gute eineinhalb Stunden. Zeit, die sich auf jeden Fall lohnt.

(weiterlesen …)

Tags: , , ,

Projekt-Praktikum: Karten-Nachschlag (Update)

am 25. Mai 2009

Bärbel de BouvierUpdate: Wer sagt denn, dass man im Internet nichts lernen würde? Kommentator Markus Hippeli macht darauf aufmerksam, dass ich bei der Aufwandsschätzung einem Mißverständnis aufgesessen bin. Mehr dazu in seinem Kommentar unter diesem Beitrag. Danke für diesen Hinweis (und sorry Chef!). Ich habe die entsprechenden Passagen nun geändert.

Im letzten Beitrag habe ich kurz das Thema Zeitplanung in Scrum-Projekten mittels eines Kartenspiels angesprochen. Die Frage ist natürlich, warum die Zeitplanung per Kartenspiel besser funktionieren sollte, als ohne. Die Antwort ist ganz einfach: Die Schätzungen werden genauer!

In einer perfekten Welt mit perfekten Menschen wären solche Karten natürlich nicht notwendig. Aber Menschen sind halt Menschen und deshalb brauchen sie Hilfsmittel, die eine Diskussion zum einen schnell auf den Punkt bringen, zum anderen jeden dazu zwingen mitzumachen und über ein gegebenes Thema mit gegebener Ernsthaftigkeit nachzudenken. Für die Aufwandsschätzung in agilen Projekten helfen eben die Planning-Poker-Karten. Und so funktioniert es:

Im Sprint-Planning-Meeting stellt der Product-Owner die einzuschätzende User-Story vor. Danach zückt jedes Team-Mitglied die Karte, deren Wert seiner Meinung nach dem entsprechenden Aufwand entspricht. Ist also ein Team-Mitglied der Meinung, die Userstory erfordert einen Aufwand von “5″, zückt er die entsprechende Karte.

(weiterlesen …)

Tags: , ,

Projekt Praktikum: Zeigt her eure Karten!

am 19. Mai 2009

Bärbel de BouvierHeute habe ich das folgende, sehr stimmungsvolle Video über den Einsatz von Scrum in der Praxis gefunden. Man sieht darin vor allem drei Dinge:

  1. Offenbar macht die Arbeit mit Scrum Spaß.
  2. Scrum ist alles andere als planlos und erfordert einiges an Papierkram.
  3. Kartenspielen ist Arbeit.

Letzter Punkt ist besonders interessant, denn es geht hier um das so genannte Scrum Planning-Poker. Hierbei benutzt man ein Kartenspiel als Diskussionshilfe bei der Schätzung des Aufwands einzelner User-Stories. Anstatt dass die Team-Mitglieder wild spekulierend ihre Aufwandsschätzungen in den Raum schreien, zeigen sie statt dessen Spielkarten, die je nach ihrem Wert, einer bestimmten Zeitspanne entsprechen.

(weiterlesen …)

Tags: , , ,

ScrumDay2009 in München

am 8. Mai 2009

Bärbel de BouvierBoris Gloger hat auf seinem Blog eine kurze Zusammenfassung zum Scrum-Tag in München geschrieben. Ein Zitat aus seinem Beitrag macht Mut für alle, die noch mit Scrum und anderen agilen Techniken kämpfen. Man muss nicht sofort komplett umschalten:

Keiner hat gesagt, er macht Scrum vollkommen. Für die meisten war aber klar, dass sie sich auf den Weg begeben hatten und das sie diesen Weg nicht mehr verlassen wollen.

Sehenswert ist die Präsentation von Oliver Zeiler (ImmobilienScout24.de) und Boris Gloger, die sie auf dem ScrumDay gehalten haben:
(weiterlesen …)

Tags: , , ,

Ein wenig Meditation über Scrum

am 28. April 2009

Bärbel de BouvierWir hatten auf diesem Blog schon einmal eine schöne Präsentation von Jurgen Appelo vorgestellt. Jetzt ist mir beim Stöbern auf Slideshare eine weitere über den Weg gelaufen. Wer wissen will, was Scrum ist und wie es funktioniert, findet in der kurzweiligen Slidehow mit dem schönen Titel “The Zen of Scrum” alles, was er wissen muss. Wer tiefer einsteigen will, findet hingegen bei uns jede Menge wissenswertes zu Scrum.

Übrigens: Zen steht für einen “Zustand meditativer Versenkung”. Wenn’s hilft, dann bitte sehr…


        

Tags: , ,

Projekt-Praktikum: Die Dauer eines Sprints

am 6. April 2009

Bärbel de BouvierNach dem Product-Backlog-Meeting steht das erste Sprint-Planning-Meeting auf der Agenda. Erster Punkt dort ist die Definition der Dauer eines Sprints. Auf den ersten Blick scheint die Sache ganz klar zu sein: Ein Sprint in Scrum dauert in der Regel 30 Tage. Doch das ist logischerweise nur eine Empfehlung. Abhängig vom Projekt und vom Team kann die Sprintlänge variieren. Es gibt Teams, die mit Sprints von ein oder zwei Wochen Länge arbeiten, andere wiederum bevorzugen bis zu sechs Wochen.

Wonach richtet sich also die Sprintlänge? Ganz einfach: Am Ende jedes Sprints muss ein „shipable Product“, also ein auslieferungsfähiges Produkt stehen. Das wiederum ist aber nicht zu verwechseln mit dem „fertigen“ Produkt. Es geht nur darum, dass ein bestimmtes, funktionierendes Featureset einsatzbereit ist. Egal, wie grundlegend seine Funktionalität ist.

Dementsprechend hängt die Sprintlänge also von der Größe und den Fähigkeiten des Teams ab, sowie von den User-Stories, sprich den zu verwirklichenden Features. Eine Website wird beispielsweise eher in kürzeren Sprints zu bewerkstelligen sein. Ein komplexes Produkt, bei dem komplizierte Entwicklungsprozesse und umfangreiche Vorarbeiten und Learnings nötig sind, wird eher in längeren Sprints angegangen werden.

Ein weiterer, nicht zu vernachlässigender Aspekt der Sprintlänge ist der damit verbundene Overhead. Je kürzer der Sprint, desto häufiger fallen beispielsweise die obligatorischen Sprint-Planning- und Sprint-Review-Meetings an. Gerade bei größeren Teams ist der damit zusätzlich verbundene Aufwand nicht zu unterschätzen.

Grundsätzlich aber gilt: Die Länge des Sprints wird weder vom Management, noch vom Product-Owner vorgegeben. Vielmehr bestimmt sie das Team selbst. Schließlich ist das ja einer der Scrum-Grundgedanken: Das Team weiß am besten, wie es die gestellten Aufgaben bewerkstelligen kann. Bei meinem kleinen und übersichtlichen Projekt hat sich das Team für einwöchige Sprints entschieden.

Tags: , , ,

Projekt-Praktikum: Scrum-Fehler vermeiden

am 24. März 2009

Bärbel de BouvierHeute bin ich über eine schöne Video-Präsentation von Henrik Kniberg gestolpert. Henrik ist Schwede und Coach für agile und schlanke Softwareentwicklung. Auf der Java-Konferenz Jfokus 2008  hat er einen sehens- und hörenswerten Vortrag mit dem viel sagenden Titel “10 ways to screw up with despite Scrum and XP” gehalten. Ein unterhaltsames und lehrreiches Video für alle, die sich für agile Methoden interessieren.

 

10 ways to screw up with Scrum and XP

Tags: , , , , ,

Projekt-Praktikum: Story-Cards

am 23. März 2009

Bärbel de BouvierIch stecke mitten in meinem ersten Projekt, bei dem wir mit Hilfe von Scrum eine Community-Website entwickeln. Im letzten Blog-Posting habe ich beschrieben, wie wir zu unserem ersten Product Backlog gekommen sind. Dieser Prozess war wegen der Überschaubarkeit des Projektes und dem winzigen Team von nur drei Leuten einfach zu handlen: Wir haben uns an meinen Schreibtisch gesetzt, ein wenig diskutiert und die User-Stories in ein Merlin-Dokument eingetragen.

Der Normalfall in größeren Projekten und mit größeren Teams sieht allerdings anders aus. Zumeist wird hier mit so genannten Story-Cards und einer Pinnwand bzw. einem Whitboard und Magneten gearbeitet. Dazu erhält jeder Teilnehmer des Backlog-Meetings einen Stapel Karteikarten und einen Filzstift oder Kugelschreiber. Optimal sind linierte, nicht zu kleine Karteikarten. Postkartengröße ist optimal.

Im einfachsten Fall schreiben die Teilnehmer auf jede Karte ihre User-Story, sowie die Priorität und eine Zeiteinschätzung. Es gibt allerdings auch Fälle, in denen man auch mehr auf der Karte eintragen kann. Vor allem dann, wenn im Verlauf des Projektes mit den Karten gearbeitet wird, statt deren Inhalte in den Computer zu übertragen, so wie wir das hier tun.

Der Vorteil der Story-Cards ist, dass man damit an der Pinnwand „herumspielen“ kann. Beispielsweise, wenn sich deren Priorität ändert. Und das tut sie im Verlauf des Meetings, denn Scrum ist ja auch eine kollaborative Projektmanagement-Methode. Vor allem ist aber das gemeinsame Schreiben der User-Stories und das Diskutieren ein kreativer und damit gewollter Prozess innerhalb von Scrum.

Tags: , , ,

Projekt-Praktikum: Product-Backlog-Meeting

am 11. März 2009

Bärbel de BouvierNach dem die CeBIT-Woche endlich rum ist und alle an meinem Projekt beteiligten Mitarbeiter wieder verfügbar sind, konnte ich letztens mein erstes Product Backlog Meeting abhalten. Zuvor hatte ich einen initialen Backlog mit den Anforderungen des Kunden zusammengestellt, der als Arbeitsgrundlage gedient hat. Die Aufgabe in diesem Meeting: Zusammen mit den Entwicklern eine erste Zeiteinschätzung, sowie generell eine Präzisierung der notwendigen Arbeitsschritte auszuarbeiten.

Da mein Projekt relativ überschaubar und das Team  recht klein ist, haben wir das Meeting an meinem Schreibtisch abgehalten. Den Input des Teams habe ich gleich in ein Merlin-Dokument eingetragen (siehe Bild). Bei größeren Projekten und Teams sind unter Umständen ausgefeiltere Techniken ratsam, etwas das Brainstorming mit Ideenkarten und einem Whiteboard. Doch dazu werde ich später ein eigenes Posting machen.

Wichtig ist, dass ich jetzt eine Grundlage für meine Arbeit habe. Ich habe schon während des Meetings eine Priorisierung durchgeführt und die Aufgaben entsprechend geordnet. Damit ist die Grundlage für das erste Sprint-Planning-Meeting schon mal geschafft.

Product Backlog

Tags: , , , ,