amazon.co.jp
[2013-01-10-1] から約1年半。アジャイル開発をそこそこ経験したので、再読しました。
気になったところをざっと引用。
P70
弟子: もしも、そうした方々にインセプションデッキを作るための時間を割いてもらえないとか、質問にも答えられないほど忙しい場合、私はどうすべきでしょうか？センセイ: まずはそのことを喜ぶがよい。なぜならお前はプロジェクトの最初の重大なリスクを発見したのだから。
難しい問題だよね。
P94
プロジェクトの今の段階で、誰が決断を下すのかということを確認しておけば、後で起きることになるであろうさまざまな混乱を防ぐことが出来る。
重要。
P131
「相対サイズで見積もる」というシンプルな原則がアジャイルな見積りと計画づくりの真髄だ。
無意識にやってて忘れてたけど、改めて認識。
P161
個人の生産性を測るのは、プロジェクトマネジメントのダークサイドへの道だ。個人の生産性を測ると、バグと手戻りと思い違いが増える。一方、強調しようとかスキルを伸ばそうとか知見を共有しようとかいった態度は薄れていく。各人がなんとしてでも自分自身の生産性を確保しようと躍起になるからだ。
ケースバイケースだけど、そういう傾向にはなりやすくなると思う。
P170
プロジェクトが既に始まっているのなら、インセプションデッキのすべての課題をこなす必要はないかもしれないが、少なくとも次の５つの質問にはチーム全員が答えられなきゃまずい。
- このプロジェクトにいるのはなぜ？
- 成し遂げようとしていることは何？
- 顧客は誰？
- 解決すべき主要な課題は何？
- 最終決断を下すのは誰？
このへんは使えそう
P214
つまり私からのアドバイスはこうだ。毎日、チームのみんなに「今日、私はこれをやります」とコミットメントを表明するんだ。これを続けていけば、自分でもびっくりするぐらい実際に仕事をやり遂げられるようになっていくはずだ。
これは明日からやる。
P216
アジャイルサムライには、ストーリーが半分終わったとか、４分の３終わらせたとか、８割完了したなどいったことは無いのだ。ストーリーは完了したか、していないか。そのどちらかだ。
そうね。
P291
アジャイルソフトウェア開発宣言プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
改めて。