Kundenrezensionen


5 Rezensionen
5 Sterne:
 (1)
4 Sterne:
 (1)
3 Sterne:
 (1)
2 Sterne:
 (1)
1 Sterne:
 (1)
 
 
 
 
 
Durchschnittliche Kundenbewertung
Sagen Sie Ihre Meinung zu diesem Artikel
Eigene Rezension erstellen
 
 

Die hilfreichste positive Rezension
Die hilfreichste kritische Rezension


4.0 von 5 Sternen Planen und Schätzen für agile Produktentwicklung – Lesenswert
Das Buch "Wie schätzt man in agilen Projekten" von Boris Gloger bietet einen verständlichen Einstieg in moderne Produktentwicklung mit Scrum und liefert Schätzmethoden für die Größe von Produkt-Funktionalitäten.

In einem sehr angenehm zu lesenden Stil werden dem Leser die Prinzipien der agilen Produktentwicklung, die...
Vor 4 Monaten von Martin Dungs veröffentlicht

versus
2 von 2 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Unter "Schätzen" verstehe ich etwas anderes!
Nachdem Gloger zusammen mit anderen in deren Buch „Der agile Festpreis“ im Jahr 2012 erklärt hat, dass ein agiler Festpreis in gewissen Grenzen vereinbart werden kann, habe ich erwartet, dass das Schätzen in diesem Buch detailliert wird. Das ist aber nicht der Fall (S. 121 ff). Denn Schätzen eines Festpreises geht laut Gloger gar nicht:...
Vor 4 Monaten von Zahrnt veröffentlicht


Hilfreichste Bewertungen zuerst | Neueste Bewertungen zuerst

2 von 2 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Unter "Schätzen" verstehe ich etwas anderes!, 8. Juli 2014
Rezension bezieht sich auf: Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind (Gebundene Ausgabe)
Nachdem Gloger zusammen mit anderen in deren Buch „Der agile Festpreis“ im Jahr 2012 erklärt hat, dass ein agiler Festpreis in gewissen Grenzen vereinbart werden kann, habe ich erwartet, dass das Schätzen in diesem Buch detailliert wird. Das ist aber nicht der Fall (S. 121 ff). Denn Schätzen eines Festpreises geht laut Gloger gar nicht: „Zum Festpreis die gesamte Leistung zu bekommen, obwohl der Umfang der Leistung noch nicht feststeht, das ist absurd!“ (Seite 32). „Man kann unmöglich schätzen, wie oft man während eines Projekts über das Gleiche nachdenkt, oder wie oft man einen Testfall wiederholen muss, bis das Ergebnis befriedigend ist, oder wie lange man braucht, um die zündende Idee zu haben.“ (Seite 85).

Gloger bezeichnet seine Aussage zur Schätzung als „frohe Botschaft“, auf Seite X Scrum als „neue Wunderwaffe“. Dementsprechend ist sein Porträt auf Seite VIII mit einem Kranz von Strahlen umgeben, ähnlich wie bei Heiligenbildern. Etwas Bescheidenheit wäre passender.

Zu diesem Thema erläutert die Rückseite, dass nicht in Aufwänden, sondern in Funktionalität zu schätzen ist „und genau deshalb gehen agil geschätzte Projekte pünktlicher und im Kostenrahmen durchs Ziel, ohne Kunde oder Lieferant zu übervorteilen.“ Wie es zu einem Kostenrahmen kommt, wird allerdings nicht abgehandelt.

Der Wert des Buches liegt hingegen darin, dass der Autor „die Instrumente für die erfolgreiche Projektplanung und Produktentwicklung“ erklärt (Satz auf der Rückseite). Jessner geht darauf in der vorhergehenden Rezension (also nachstehenden) ein. Das ist hilfreich, hat aber nur beschränkt etwas mit dem viel gepriesenen Scrum zu tun.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


2 von 2 Kunden fanden die folgende Rezension hilfreich
1.0 von 5 Sternen Wenig konkreter Inhalt auf 145 Seiten, 12. September 2014
Rezension bezieht sich auf: Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind (Gebundene Ausgabe)
Mal abgesehen von nur wenigen Seiten über konkrete Schätztechniken bleibt das Buch in den meisten Passagen vage und "geschwätzig". Der Versuch, agiles Schätzen aus dem agilen Kosmos selbst abzuleiten bleibt herrlich unkonkret und bietet nur wenige praxisrelevante Tools oder Techniken. Anstelle des Titelthemas wird ausführlich aber wenig konkret über Produktentwicklung als solche philosophiert (Rolle Product Owner, Design Thinking,...). Und dann wird tatsächlich Steve Jobs als Prototyp des Project Owners stilisiert. Haben wir alles in verschiedenen Variationen schon mal gehört (z. B. Steve Jobs als der idele charismatische Leader in einem Leadership-Seminar) und schon damals nicht hilfreich gefunden.
Bei mir ist der Eindruck entstanden, als hätte der Autor selbst den roten Faden seines Buches bis zum Ende gesucht und leider nicht gefunden. Vielleicht hätte er die im Buch angedeuteten Ideen zur Produktdefinition, einmal auf selbiges anwenden sollen um so den Kern und den "Business Value" für den Leser klarer zu sehen ;-)
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


2 von 2 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen "Schätzen" ist leider nicht das Thema dieses Buches, 22. August 2014
Verifizierter Kauf(Was ist das?)
Rezension bezieht sich auf: Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind (Gebundene Ausgabe)
Hallo,
ich habe mir dieses Buch gekauft, weil ich in meinen Projekten unbedingt mehr über das Schätzen erfahren wollte. Dies wollte ich gleich in die Praxis umsetzen. Szenarien wie schwierig das Schätzen sein kann gibt es genug, z.B. wie kann man Optimierungsaufgaben, also wiederkehrende Aufgaben mit Storypoints bewerten. Ich hatte die Erwartung, dass "Schätzen" der Hauptbestandteil dieses Buches darstellt. Gefunden habe ich ein paar Absätze, aber deutlich zu wenig als dass es die Überschrift dieses Buches rechtfertigt. Wer allerdings einen kleinen Überblick über Scrum haben möchte kann sich das Buch holen. Es gibt auch ein sehr gutes Buch von Gloger (ja genau der gleiche Autor!, "Scrum: Produkte zuverlässig und schnell entwickeln"). Vielleicht hatte ich daher so "hohe" Erwartungen.
Gruß,
Christian
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


4.0 von 5 Sternen Planen und Schätzen für agile Produktentwicklung – Lesenswert, 28. Juli 2014
Verifizierter Kauf(Was ist das?)
Rezension bezieht sich auf: Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind (Gebundene Ausgabe)
Das Buch "Wie schätzt man in agilen Projekten" von Boris Gloger bietet einen verständlichen Einstieg in moderne Produktentwicklung mit Scrum und liefert Schätzmethoden für die Größe von Produkt-Funktionalitäten.

In einem sehr angenehm zu lesenden Stil werden dem Leser die Prinzipien der agilen Produktentwicklung, die Scrum-Methodik und die Produkt-Owner-Rolle dargestellt. Dabei geht es nicht nur um die Softwareentwicklungs-Methode, sondern um ein teambasiertes Management-Framework. Auch die Unterschiede agiler und traditioneller Organisationen werden deutlich. Das größte Kapitel beschäftigt sich ausführlich mit den frühen Projektphasen innovativer Produktentwicklung gemäß Design Thinking. Der Inhalt reicht von der Erarbeitung der Produktvision, über Methoden zur Klärung von Kontext und Herausforderungen bis zu den Kriterien für User Stories im Backlog.

Wer in dem Buch klassische aufwandsbasierte Schätzverfahren sucht, wird enttäuscht. Geschätzt werden hier nicht mehr Aufwände von Aufgaben, sondern die Produktgröße, d.h. der Umfang von Funktionalitäten der User Stories. Dafür werden 4 Schätzmethoden vorgestellt (Magic Estimation, Estimation Meeting, Planning Poker, Team Estimation Game).

Als besonders wertvoll und hilfreich sind zu erwähnen:
- Probleme klassischer Projektorganisationen
- Tipps zum Management großer Scrum-Projekte (viele Teams)
- Reaktionsmöglichkeiten durch Scope-Anpassung (change for free)
- Kennzahlen wie Velocity (Team-Kapazität) und Cost-of-Delay (Projektverzugs-Kosten)
- Hervorgehobene Tipps, Warnungen, Beispiele und Zusammenfassungen

Auch wenn ich mir für die Durchführung der Schätzmethoden noch ausführlichere Beispiele gewünscht hätte, liefert das kompakte Buch (142 Seiten ohne Anhang) viele Anregungen und Ideen Scrum-Projekte erfolgreicher zu machen.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


0 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Schätzen ist ordnen im Kopf, oder doch im Bauch? und Estimation without estimate., 14. Juni 2014
Rezension bezieht sich auf: Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind (Gebundene Ausgabe)
Schätzen Projekten zeigt für mich den Grad für die Reife der Organisation und der Teams für agiles Vorgehen.
Sag mir wie Du schätzt und ich sag die wie agil Du bist. Ich hatte ich eine Diskussion mit einem Geschäftsführer und ich fragte ihm wie er in seinen Projekten, wo Kunden eingebunden sind geschätzt wird und er antwortete mir: "Egal wie die Kunden schätzen, Hauptsache nicht nach Aufwand".
Im Grunde genommen ist es sehr einfach: Das Produkt in kleine Teile splitten. Die Teile nach Größenverhältnissen ordnen (schätzen) und Aufwand messen. Aus dem gemessenen Aufwand wird geplant (Fertigstellung, Releases). Das ganze wird dann Velocity genannt (Wie viele Ordnungseinheiten pro definierter Zeiteinheit im Mittel von einem Team umgesetzt werden).
In oft großen und erst auf den Pfaden zur Agilen befindlichen Organisation und Teams stößt diese Ansicht auf enormen Widerstand.

Doch warum polarisiert dieses Thema so?

Vor kurzem bin ich auf Boris Glogers Buch zum Thema Schätzen gestossen.
Viele dieser Fragen werden beantwortet, überraschend neu beantwortet, oder sie sind mit diesem Buch gar obsolet geworden.

Darin werden Antworten gegeben auf: Warum das so polarisierend ist, wie man dem begegnet und vor allem liefert es Argumente in diesen oft heftig geführten Diskussionen.
Boris Gloger zeigt, dass Agiles schätzen nicht nur schneller ist, sondern auch mit ein bedeutender Faktor in der Veränderung von Projekten weg von beispielsweise Projektmanagement hin zu Produktmanagement ist.

"den Kunden in den Mittelpunkt zu stellen, bedeutet erst einmal: Den Kunden verstehen." Deshalb soll alles, auch das Schätzen auf das Produkt, den Kunden, die Vision bewertet und ausgerichtet sein. So schafft Agiles schätzen einen Teil zum Wandel zum Agilen Unternehmen bei. Teammitglieder werden beim agilen Schätzen angehalten nicht mehr über Aufwand zu diskutieren, sondern über das Produkt nachzudenken. Schätzen in Aufwand bindet die Entwickler erstens an gegebene Schätzung und auch an die Person per se und Commitments werden dadurch ungenauer. Oder Refactorings werden schwer durchsetzbar, wenn eine Aufgabe mal doch länger dauert. Im Agilen Umfeld wird immer der Sprint betrachtet und wenn eine Aufgabe länger dauert wird das durch Aufgaben ausgeglichen, die kürzer dauern. Und das kuriose dabei: Es geht gar nicht darum wie lange die Aufgabe dauert, sondern mit der Aussage wie groß ist eine Aufgabe im Verhältnis zu anderen Aufgaben ist lässt sich viel genauer und schneller Planen.

"Die agile Organisation agiert stets mit dem Blick nach außen, statt sich in überbordendem Maß mit internen Prozessen zu beschäftigen."

Im Mittelpunkt steht auch für das Entwicklungsteam, so Boris Gloger: "Das Commitment wird aus der maximal in einem Sprint möglichen" und "optimiert nicht lokale interne Prozesse, sondern optimiert aus der Sicht des Kunden und hat dabei die gesamte Wertschöpfung im Blick".

Das Buch gibt weiters viele nützliche Tipps, z.B. für den Product Owner: "Schreiben Sie bitte nicht selbst alle diese User Storys , auch nicht, wenn das Entwicklungsteam das von Ihnen erwarten sollte. Diese User Storys schreiben Sie als Product Owner mit dem Entwicklungsteam."
Also gemeinsames Arbeiten und schätzen ist auch Arbeit, gemeinsames Verständnis immer auf den Kunden ausgerichtet. Das soll Leidenschaft für Produkt und Kunden fördern und auch über Umwege z.b. wieder mehr Firmenzugehörigkeit und Motivation schaffen.

Boris Gloger geht aber auch auf das klassische Vorgehen in Projekten ein und zeigt deren Schwächen auf. Entscheidungen wie Projekte zustande kommen sind meist intransparent genau vordefiniert und die Personen, die Schätzungen abgeben, sind oft nicht in das Projekt involviert.
"Schreiben Sie bitte nicht selbst alle diese User Storys , auch nicht, wenn das Entwicklungsteam das von Ihnen erwarten sollte.1 Diese User Storys schreiben Sie als Product Owner mit dem Entwicklungsteam." ... Diese Menschen sind nun im wahrsten Sinne des Wortes ohnmächtig, denn sie sind einer Instanz ausgeliefert, die anhand unbekannter Kriterien entscheidet, ob das Projekt genehmigt wird."

Boris Gloger geht dann genauer in einem langen Kapitel "Exploration" darauf ein und gibt Lösungsansätze für "Sie lassen Komplexität von Anfang an zu, statt sie durch voreilige Entscheidungen abzuwürgen. Sie laden dazu ein, alle Elemente miteinander agieren zulassen. Sie inkludieren, statt exkludieren. Diese Komplexität wird dadurch gemanagt, dass alle Beteiligten von Anfang an mit im Boot sind und indem die Projektleitung für das Arbeiten Prozesse nutzt, die sprunghaft und zirkulär sein dürfen."

Verkürzt dargestellt funktioniert das über Geschichten, Bedeutungen, Sinn, Bildern, Experimenten, Prototypen und mehrfaches Feedback und Integration von Feedback. Eine Ausformung dessen ist Scrum mit der Idee Fast Feedback Fail Fast für schnelles Lernen und das am besten mit kleinen Teilen den User Stories mit dem „Wer, was und wozu?“ mit der Ausformulierung also wieder in kleine Geschichten.

Und da ist Boris Gloger schon wieder beim Schätzen und bei der Größe der User Story: Es gibt kleine und große davon und Abstufungen. Diese werden ins Backlog gegeben. Stories die früher kommen, sollen kleiner und genauer formuliert sein, Stories die erst spät kommen können ruhig größer und wage sein. "Früherere" Stories haben dabei größeren Kundennutzen.

Jetzt ins Detail: „Wir schätzen also noch nicht, wie lange es dauern wird, das Produkt zu liefern? Wir schätzen die Produktgröße und nicht die Aufwände? Möglicherweise sind Sie genauso verwirrt, wenn Sie diese Zeilen lesen, wie es meine Trainingsteilnehmer immer sind. Jedes Mal dreht sich alles um die Frage „Wie lange dauert es?“

Dann kommt eine ausführliche Argumentation warum das so ist. Die führt über "Oder anders ausgedrückt: Wie viel Funktionalität hat Ihr Produkt?"
und kommt dann im wesentlichen auf meine oben angeführte Definition: "Große der Funktionalität schätzen, Aufwand messen".

Dabei stellt Boris Gloger mehere Schätzverfahren vor. Das Good old "Planning Poker" präfereriert er nicht mehr, weil es zu viel Zeit braucht. Auch hier: Schätzen wie Implementieren, wie formulieren im Agilen "NUR SOVIEL WIE UNBEDINGT NOTWENDIG". Eine Weiter Gefahr so Gloger: "Die Gefahr ist aber, dass sich das Entwicklungsteam über Implementierungsdetails und nicht über die Funktionalitäten austauscht."

Präfertiert wrid "Magic Estimation". Dabei können 100 User Stories in 20 Minuten geschätzt werden und das mit einer sehr hohen und ausreichenden Genauigkeit. Ein Team ordnet ohne miteinamder zu sprechen dabei die vor Ihnen liegenden User Stories Kathegorien von (0,1,2,3,5,8,13,20,40,100) zu. Diese Kathegorien symbolisieren die Größen. Bewegt sich eine Story ötern zwischen mehre Kathegorien, soll darüber im Anschluss diskutiert werden warum.

Das und die Anderen Verfahren werden auch anhand ihrer zugehörigen Meetings genau beschrieben.

Weiter beschriebenes und vielleicht weniger bekanntes Verfahren ist "Team Estimation". Das ist wieder etwas kommunikativer und kommt sogar ohne Skala aus. Ohne auf die Details hier einzugehen die Vorteile die Gloger benennt: Die Teammitglieder haben die Chance, ihre Einschätzung
zu erklären, wenn sie eine User Story umhängen. Dieses Verfahren zwingt im Gegensatz zum Magic Estimation indirekt alle Teammitglieder, sich aktiv zu beteiligen. Was ebenfalls nicht zu unterschätzen ist: Die Teammitglieder können sich untereinander über die Art und Weise austauschen, wie sie schätzen. Wir finden hier also eine sich selbst-kalibrierende Schätzmethode vor.

Weiter Methoden werden kurz unter Mini Schätzspiele erklärt: "Relativer Vergleich", "Knobeln" und "Talking Board". Knobeln gefällt mir: "Sie
funktioniert als Variante zum Planning Poker: Die User Story wird vorgelesen. Dann zählt der ScrumMaster bis drei und alle Mitglieder des Entwicklungsteams zeigen entweder die Faust (zählt als 0) oder einen bis fünf Finger der Hand. Die Anzahl der gezeigten Finger steht wiederum für „1, 2, 3, 5, 8“.""

Dann das geniale Kapitel "Warum schätzen wir in Funktionalität ?" und darauffolgend "Wir wollen aber in Aufwänden schätzen!" und "Schätzen von Komplexität".
Boris Glogerers Argument gegen Komplexitätsbetrachtungen: "was „schwierig“ denn eigentlich heißt. Etwas, das mir leicht fällt, muss meinem Kollegen noch lange nicht leicht fallen. Wenn ich ein ScrumMaster-Training halten soll, würde ich diesem eine Komplexität von 1 geben.Meinen Mitarbeitern fällt es wesentlich schwerer, das gleiche Training zu geben. Das ist auch logisch. Aber wird das Training deshalb komplexer? Oder ist meine Einschätzung falsch: Ist das Training vom Standpunkt der Komplexität6 betrachtet eigentlich eine 20 und meine Velocity nur viel besser, äh . . . ein Training dauert immer zwei Tage . . . also ist meine Velocity immer 20 pro zwei Tage?" und weiter: "Ganz ehrlich: Ich will mich als Scrum Consultant nicht mit Fragen beschä! igen, die nicht lösbar sind. Ich habe als Physiker, Philosoph und Soziologe schon während meines Studiums gelernt, dass es unter anderem auf die richtigen Fragen ankommt, wenn man Erkenntnisse gewinnen will. Der Physiker in mir sagt: „Eine physikalische Größe ist eine quantitativ bestimmbare Eigenschaft eines physikalischen Objektes, Vorgangs oder Zustands.“ Daher gilt: Größen müssen zweifelsfrei definiert werden können. Sie dürfen nicht mit anderen Größen vermischt werden, es sei denn, sie können abgeleitet werden. Weder die Aufwandschätzung noch die Komplexitätsschätzung erfüllt diese Akzeptanzkriterien für das Definieren von Größen. Die Idee, Funktionalitätsumfänge zu schätzen, ist sicherlich auch nicht perfekt, sie kommt aber doch der Forderung nach Quantität am nächsten."

Dann noch ein sehr interessantes Kapitel mit den Idee Schätzungen überflüssig zu machen mit der vorgestellten Methode
Ein Verfahren wird als Cycle-Time-Estimation bezeichnet verzichtet ganz auf Schäzen unter dem Motto: Lassen wir das Aufwandschätzen weg, beschäftigen wir uns lieber mit dem Produkt, und trotzdem die notwendigen "Zahlen" zu haben. Boris Gloger: "Die traditionelle Denkschule will
wissen, wie lange ein bestimmtes Element benötigt, um verarbeitet zu werden. Die posttraditionelle Denkweise will nur wissen, wie lange das Erarbeiten einer Funktionalität dauert."

Boris Gloger stützt sich dabei auf die Erfahrung die Empirie - der Cycle-Time Methode als Ausweg.
Bei dieser Methode ist es nach einer gewissen Zeit (z.B. 3 Monaten) übrigens sogar unerheblich, ob ein Teil klein, oder groß ist. Dabei wird über einen längeren Zeitraum von beispielsweise ein paar Monaten mit Storypoints estimated und gleichzeitig eine Tabelle aufgebaut. Jede Story wird bei Eintritt in das Backlog, welches nur wirklich benötigte Stories für minimale Produkterfüllung haben soll, notiert und auch wie viele Stories sich zu diesem Zeitpunkt im Backlog befinden. Wird eine Story fertig, so wird auch dieses Datum notiert. Die längste Verweildauer wird ermittelt und dabei auch notiert wieviele Stories zu diesem Zeitpunkt im Backlog waren. Boris Golger: "Geht der Füllstand des Committed Product Backlogs nicht über den Wert der letzten drei Monate, können wir annehmen, dass jede weitere User Story, die wir ins Committed Product Backlog legen, auch innerhalb der Durchlaufzeit unserer längsten User Story erzeugt werden wird."
voilà: Estimation ohne Estimation :-)

Abschliessend gibt es noch Kapitel über Skalierung und Monitoring. Monitoring über den Realease Burndown Chart agbeildet - hier handelt es sich wiederum um eine gratis Messung.

Zusammenfassung:
Boris Gloger motiviert aber auch auf Bauchgefühl zu hören, ohne das er das explizit ausspricht. Schätzen IST in Relation setzen PLUS Bauchgefühl MINUS "die nicht immer zielführende Ratio" geschickt angewandt. Das führt zu genaue und schnelle Grundlage für die Planung mit Mut und Leidenschaft für das Produkt.Wobei nicht Beliebigkeit gemeint ist, sondern, dass kollektive Intuition zielführender ist als einzelne Ratio (meine Interpretation).

Alles in allem ein sehr gelungenes Buch bei dem man nach dem Lesen von nur 160 Seiten den Kopf voller neuer hilfreicher Ideen und bekanntes hintergründiger erklärbar hat. Das Buch ist Zündstoff, nicht im Sinne von zündeln, sondern von zündenen Ideen und neues probieren.

Boris Gloger zieht systemisch am roten Faden Schätzen und behandelt damit faszinierend das agile Thema.

Keine Kritikpunkte, alles sehr verständlich und übersichtlich, lediglich die Lockheed Story im Kapitel 2 finde ich etwas old-fashioned tradiert.
Von mir gibt es ein klares 5 von 5.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


Hilfreichste Bewertungen zuerst | Neueste Bewertungen zuerst

Dieses Produkt

Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte erfolgreicher sind
EUR 29,99
Auf Lager.
In den Einkaufswagen Auf meinen Wunschzettel
Nur in den Rezensionen zu diesem Produkt suchen