This book presents what the authors believe is an improved variant of agile software development, based on what they have been practicing.
While the authors clearly understand the fundamental principles of agile, and apparently have used their variation successfully, I recommend that readers approach this version with caution.
I'm not quite sure who this book is for, despite an introductory section that attempts to answer that question. If you are new to agile, this book doesn't provide a primer on the subject but assumes you have at least some familiarity with it. Thus it appears that the book is intended for people who have basic familiarity with agile but who have not perfected it and thus are looking for ideas to improve their game. However, if that is correct, the authors spend far too much time justifying agile and going over things that the reader would already be very familiar with.
Having managed large software development groups myself for several decades, I share the authors' belief that agile development is the best known way to develop software. Even though my development groups consistently produce great results with agile, I am constantly looking for ways to improve, and thus was interested in this book. While I agree with the authors about agile in general, I am not convinced of the key elements of the variant of agile presented here, specifically:
* A centerpiece of the authors' method is to pay developers a bonus at the end of each iteration if successful. C'mon, that is a method that works with pets but is demeaning to humans. The authors even tell us (correctly) that pay is not at the top of the list of developer motivations, so why put SO much emphasis on this? And with money riding on each iteration, it is human nature to game the system. Developers are powerfully motivated by pride (as this book points out), so why not make that goal of each iteration?
* This book is pretty adamant about 6 weeks as the iteration length, yet that is generally thought to be at the very long end of what most successfully agile practitioner think is useful. I have found shorter cycles (2 - 4 weeks) to be much better, ironically for reasons that the authors feel are important: faster feedback, quicker discovery of whether you are on the right path, less distance to backtrack if wrong. The closer people are to their goal, the greater the sense of urgency people have, thus I think 6 weeks is too long.
* While not a core tenet of this method, the authors discuss team size and seating arrangements. Co-location of teams is clearly a good practice, but they suggest that teams should contain roughly 12 people seated in a bullpen, which I think is far too large for cohesion and not necessarily the best layout, even if it were available. Even Baden-Powell (whom they quote) recommends "six to eight". And it's not made clear who is on the team, e.g. just engineers, probably QA and writers, but what about architects, etc? What is the job of the leader - head programmer, business leader, project manager, or HR manager? This whole area is pretty vague.
One way I judge the return on investment for the time I spent reading a book is whether it contained any idea or insight that I will be likely to remember a year from now. In that regard, this book DID provide some value. The highlight for me was their assertion that "Software reflects the group the produced the software; if the company is dyfunctional, then the software is dysfunctional." While the rest of the book was generally a disappointment, this idea is a gem. I just wished the authors had followed up and elaborated on it, instead of making this statement at the end of a section and leaving it hanging.
My advice:
- If you are new to agile, don't use this as your introduction. Be sure to read something that gives you a firm understanding of agile principles first, then read this book - and THEN read some others.
- If you are already practicing agile, you might find some food for thought here, but the key ideas of this variant of agile are not ones that I would recommend or adopt myself.
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
何か問題が発生しました。後で再度リクエストしてください。
他の国からのトップレビュー
J. Peterson
One opinion of what Agile should be, but approach with caution
2010年9月25日にアメリカ合衆国でレビュー済み
Likes to eat Pi
Everything you need to start agile
2010年10月28日にアメリカ合衆国でレビュー済み
