Embedded Files
（１）doubledispatch：
P36の「１．フィーチャでなく作業で計画している」というのが問題であることが
書かれていますが、よくわからないです。
・この意図は、先のイタレーションまで、作業に分解したタスクでガントチャートを
引くことがまずいと言っていると思えばいい？
・後続の先のイタレーションの計画では、イタレーションごとの目標をどのフィーチャ
の実装完了とするか、程度の粒度に留めて計画しろと言っている？
・現在のイタレーションでの日々のToDoを分解してリストアップして未済を把握
して作業すすめると思うけど、、、、こういう至近の作業の段取りはこの文脈で
は「計画」と読んでいないということでいいのかな？
・問題点として作業は早く終わらないとか、スケジュールの遅延は先に伝搬する
とか、作業は独立していない、等々述べてるけど、フィーチャの粒度で計画する
とこれらを改善できるのかな？（これの疑問は先の章で解決？）
【当日の議論】
フィーチャーをまたがって作業を独立の並行して実施するのがまずい。遅れたり
中断すると、フィーチャが全く実装されないこともある。ひとつひとつフィーチャ
単位に終わらしていけば、中断したり遅れてもやった分だけフィーチャがリリース
される(bleis)
(2)doubledispatch：
P42で不確実性を考慮に入れない計画は問題だとして、当初は5,6か月で終了しま
す等の幅を持たせた計画にしろと言ってます。確かにその通りなんだけど、、、どう
やって契約してるのかな？実践にどうやって移せばいいのか？（答えを急ぎすぎ？）
【当日の議論】
急ぎすぎ。先々の章のお楽しみ。
(3)kaku_kaku:
P37の「作業は早く終わらない」について
学生症候群：『学生の夏休みの宿題と同じで、「与えられた期限間近まで、仕事を本気には始めない」という、人間の傾向をいうもの。』って
のも早く終わらない要因になりますね。
【当日の議論】
ドワンゴはニコニコ動画のリリースを早くしたかったら、期限を切らなかった。期限を設定すると間に合うように
逆算してスタートしないから。可及的速やかにを要求。(daxanya)
(4)Ｙｏｕ＆Ｉ:
P.33の「計画づくりでは、作業ではなくフィーチャを単位にすべきなのである。」
ここで急に「作業」という表現が出てきて、読んでいて自分はちょっと混乱しました。
1章のコメントでの自分の発言と矛盾するようですが、フィーチャ＝機能の集まりと考えた場合、
フィーチャの実装状況は、とどのつまり機能の実装状況になってしまうのではないか？と。
Ｔｗｉｔｔｅｒで話が出ていましたが、P.44の章末の「話し合ってみよう」を皆で話し合ってみよう！
(5)bleis-tift:
P.39の結論には同意できるけど、「作業が早く終わることがめったにない」という前提がない場合は、
「一連の作業が順調に終わったときのみ早く着手できる」という結論にはならないのでは？
遅れた作業より前の作業や後の作業が早く終われば、早く着手できるはず。
【当日の議論】
問題点を列挙する章のため。ちょっと書き方が下手かもしれないが、目を瞑ろう(daxanya)
■話あってみよう
【スタッフが多い年配テーブル】
２．あなたのまわりでは、見積もりとコミットメントは一緒だろうか。どうすればこの誤解は解けるのだろうか？
そうに決まってるじゃん。苦笑い(yama__moto,kaku_kaku,doubledispatch)
見積もりが単なる作業計画の場合はコミットメントではないが、金額（契約）が絡むとコミットメントとなる(daxanya)
お客さんや上司って、「言い切って（コミットメントして）もらいたがってる」のだよね。(doubledispatch)
※誤解を解く方法まで議論が進みませんでした。
３．マルチタスク化は何が問題だろう。どうすれば軽減できるか。
マルチタスクは、プロジェクト複数かけもち等、リスクヘッジ上必要(daxanya)
マルチタスクそのものではなくて、リソースの枯渇する状況の方が問題(daxanya)
クリティカルチェーンではないが、マルチタスクしているタスクが全て誰かのボトルネックになっている場合がある。
すべてを遅らしてしまう。(doubledispatch)
※軽減する方法は時間なくて丁寧に議論できませんでした。
【若者テーブル】
誰か書いてください。
Page updated
Google Sites
Report abuse