Embedded Files
第20章 イテレーション計画のモニタリング P.238～
この章の章末の「話し合ってみよう」は特に重要に思える。ぜひちゃんと時間を取って話し合いましょう。
（やまもと）
1. タスクボード P.238～
タスクボード楽しそう．
(いじゅういん)
「目につきやすいリマインダー」（P240 4行目)これだ！
（やまもと）
P240の23行目あたり「開発者は作業を完了させたと思っているが、実装タスクに対応するテストタスクが用意されていない場合には、タスクカードを「確認待ち」の列に移動させる運用にしている」について。
- 「実装タスク」と「テストタスク」は別タスクにするの？ひとつのタスクにすれば簡単だろうに？
- テストタスクのテストはテストタスクに含まれる？（それともまた別のタスク？）それは具体的にどんな作業？
（やまもと）
コラム：タスクボードを使ったバグトラッキング P.241
「プロダクトオーナーはイテレーションの計画時に「『重要』なバグを10個、修正する」という作業を含める」
この「10」という数字がおもしろい。重要なバグがいくつ発生するか分からないが、予測できないものをハンドリングしている例だ。
（やまもと）
2. イテレーションバーンダウンチャート P.241～
ウォーターフォール開発の場合、開発スパンが長いので、タスクボート運用も難しい側面がありますね。この項を読んで如何に運用しやすい単位で見える化するかというのも重要なのかという事を考えさせられました。
（You&I）
P242の図20.2 イテレーションバーンダウンチャートについて。バーンダウンチャートの縦軸は残タスク量で単位は理想時間。イテレーション中のタスク増減や再見積りによる残量の変化と、タスクの消化による残量の変化を、イテレーションバーンダウンチャートは区別していない。前章のリリースバーンダウン棒グラフでは区別していたけど。なぜイテレーションバーンダウンチャートでは区別しようとしないのでしょうか？
（やまもと）
3. 投入工数のトラッキング P.242～
見積もりと実績の比較は実際に行われている．
常時それが確認できるようになっているのでとてもプレッシャーを感じている．
仕事を怠けていないかを監視するために比較されている気がして，すごく仕事がしにくい．
しかも，そういったものが賞与に影響する場合もあるのでとてもストレスフルになってる．
(いじゅういん)
この本では、見積りと実績の比較は、見積り精度向上のためだけに行いなさい、でもそれにしてもリスキーだよ、と言っている。
涙がでそう。僕らのリアルワールドでは、見積りと実績の比較は、工程の遅れとしてすぐに現れ突きつけられる。
（やまもと）
4. 個人のベロシティ P.243～
P.243 「警告する。個人のベロシティをトラッキングしてはならない。」なるほど、個人の事を考える暇があるならチームの事を考えろという事ですか。
（You&I）
P.244 「ストーリーのユーザーストーリーが、1人で完了させられるような内容ばかりなのであれば、ストーリーの書き方を見直した方がよい。」
この注意事項は以前の章では書かれていなかった事かと思います。
（You&I）
まとめ P.244～
Page updated
Google Sites
Report abuse