『アジャイルな見積りと計画づくり』第14章のコメント・疑問

第14章イテレーション計画作り (P.159～180)

1. イテレーションのプランニングではタスクの担当者を決めない (P.161～)

P.159 「イテレーションプランニングの最中にタスクをシステムに入力するには誰かがキーボードで入力を担当することになる。この場合、キーボードの入力者に権力が集中してしまう。」

これは、ファシグラするときにも気をつけたいな。ファシグラする人に権力が集中しないように。（角谷）

P.161 「プロジェクトが最もうまくいくのは、チームに『全員が一丸となって取り組む』という態度が備わっているときだ。」こんな理想的なシチュエーションは経験 した事がありません。また、この状態を維持し続けるのも至難の業なのではないか？と思います。（You&I）

担当者を決めざるを得ない状況ではどうするのか？ 実質PGが一人しかいない状況とか（あな）

2. イテレーション計画とリリース計画の違い (P.162～)

3. ベロシティ駆動イテレーションプランニング (P.163～)

3-1. 優先順位を調整する

3-2. 目標ベロシティを決める

3-3. イテレーションのゴールを決める

イテレーションのゴールを明確な詳細にしない理由は?

確な詳細すると弊害があるから?

3-4. ユーザーストーリーを選ぶ

3-5. ユーザーストーリーをタスクに分割する

■3-5-1. プロジェクトに価値を与える作業のみを含める

■3-5-2. 慣れるまでは詳細に

■3-5-3. ミーティングはタスクに含める（それも多めに）

朝会で情報共有したり、プランニングポーカーを使って短時間での見積もりを出したりするのに、ミーティングの時間は多くとるのは何故でしょう？本文ではあまり言及されていないようです。（You&I）

■3-5-4. バグ

■3-5-5. 依存関係の扱い

■3-5-6. タスクへの分割が難しい場合

P.170 「スパイクとはイテレーション計画に含めるタスクの一種で、何らかの知見を得たり、疑問を解消することを目的に取り組む作業のことだ。」 事前調査としてこの手のことをやることはありますが、確かに開発中やることもありますね。スパイクって名前は知りませんでした。（You&I）

3-6. タスクを見積もる

ストーリはストーリポイントで、タスクは理想時間で見積もるってこと？（角谷）

3-7. 多少の設計はOK.

P.172 「私の経験ではイテレーションプランニングでクラス図が必要になったことはない。」 クラス図の書きっぷりにもよりますが確かに普通は見積もりの段階ではクラス図は細かすぎるかも。（You&I）

3-8. タスクの適切なサイズ

4. コミットメント駆動のイテレーションプランニング (P.173～)

4-1. チームにコミットできるかたずねる

イテレーションの計画で、リリースのコミットを尋ねるのはアジャイル精神と反するのでは？ そうでないなら、アジャイル精神とは何？（あな）

→ では逆に質問ですが、あなさんの仰る「アジャイル精神」とは何でしょうか？期日までに決めた機能を実装していく方法を取った場合アジャイル開発できないと の意味合いにも取れてしまいますが。本文中にもある通り、期限までにリリース可能なフィーチャーをイテレーション中に新しいタスクが発生することを見越し た上で、チーム内での合意にてコミットするのではないでしょうか？（You&I）

■4-1-1. 見積りを合計する

「ここで鍵となるのは、チームメンバーひとりひとりが、自分の得意分野以外でもやれることを探してチームに貢献することである。」とてもいい言葉です。(kei10in)

■4-1-2. 保守とコミットメント

5. 私のおすすめ (P.177～)

著者のお薦めは「コミットメント駆動」。（You&I）

6. タスクの見積りとストーリーポイントの関係 (P.178～)

まとめ (P.180～)