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

0. アジャイル手法

マニフェストの解説に「それなのに、この業界は随分と長い間、人々を交換可能な歯車として扱う開発プロセスを模索し続けている」とあるけど、その通りだと思う。というか、そのような前提で契約をしているよねえ。（yama__moto）

アジャイルマニフェスト（アジャイルソフトウェア開発宣言）（Ｙｏｕ＆Ｉ）

http://www.agilemanifesto.org/

http://www.agilemanifesto.org/iso/ja/

1. プロジェクトへのアジャイルなアプローチ

1-1. 1つのチームとして働く

1 つのチームとして動くとした場合、テスター・デザイナーといった役割の人員の稼働率が低くなる（作業がない時間ができる）ように思われるが、どうだろう か？また稼働率が低くなる結果として複数の作業を掛け持ちする事になり、２章にある通り作業のマルチタスク化は作業効率を落とす（P.40）ことになった り、チーム一丸で動く事の妨げにならないだろうか？（Ｙｏｕ＆Ｉ）

MEMO：チーム内の役割：「プロダクトオーナー」「顧客」「ユーザー」「開発者」「プロジェクトオーナー」（Ｙｏｕ＆Ｉ）

一人の人が複数の帽子を被り分けるのはあり（だが、マルチタスクはなし）、ということでは、と想像しますがどうでしょうか。(yama__moto)

1-2. 短いイテレーションで作業する

「イテレーションの長さは固定されていることが多いが、各イテレーションの開始時にイテレーションの長さを決めるチームもある」！これは驚き。固定でなくても、決めてそれを守ればいいの？（yama__moto）

P.48 「実装する予定だったフィーチャを削ってでも期日を守る、それがタイムボックスの考え方」一度実際にそんな風にやってみたいですね。ただフィーチャを削る 判断を、いつ・だれがするのでしょうか？開発者？プロジェクトオーナー？またP.55には「プロダクトオーナー」と「チーム」が対話して議論を重ねるとの 記述があります。（Ｙｏｕ＆Ｉ）

1-3. イテレーションごとに成果をあげる

1-4. ビジネス上の優先度を重視する

P.50 「ユーザーストーリーは、システムについてユーザーまたは顧客の視点からフィーチャの概要を記述したもの」「ユーザーストーリーには形式が定められておら ず、標準的な記法もない」「＜ユーザーの種類＞として＜機能や性能＞が欲しい。それは＜ビジネス価値＞のためだ」を読んで、マジカ！（http://www.magicaland.org/）をふと思い出しました。本当にストーリーが書きやすくなるものなのか一度本会の方でやってみても面白いかも知れませんね。（Ｙｏｕ＆Ｉ）

ユーザーストーリーについては、「ユーザーストーリービギンズナイト」 http://www.slideshare.net/SukusukuScrum/no01101suc3rum20100225 が必見です！(yama__moto)

2. アジャイルな計画づくり

P.52 「私たちはこうした新しい知識（プロダクトナレッジ・プロジェクトナレッジ）を得ることを計画に組み入れ忘れてしまうことが多い。」とあり、本書の後ろの 章で組み入れ方は説明されているのでしょうか？第９章のテーマの優先順位付けでプロダクトナレッジ・プロジェクトナレッジに関する項目が出てきます が・・・。（Ｙｏｕ＆Ｉ）

2-2. 満足条件

P.55 「プロダクトオーナー」と「チーム」が対話して議論を重ねるとの記述がありますが、この議論はイテレーションに内包されるもの？それともイテレーションの開始前に行うもの？（Ｙｏｕ＆Ｉ）

個人的見解：イテレーション中は目標に集中して作業させてあげたいので、開始と終了のタイミングかな？と思いました(doubledispatch)

話しあってみよう

P.57 「3.予算とスケジュールはリリースプランニングの満足条件となっている。なぜイテレーションプランニングの満足条件に予算とスケジュールを含めないのだろうか？」

イテレーションプランニング段階では、予算とスケジュールは固定されているためか？意見を聞いてみたい。(kaku_kaku)