Embedded Files
３章 アジャイル手法
３章 アジャイル手法
人は交換可能な歯車？
→交換できないとするとリスクが大きい
→一人をエースにしない・チームで
・トラックナンバー（ハネムーンナンバー）
→何人トラックに轢かれても継続できるか？を表す数値
-->まさ加筆
たしか継続できない最小数だったと思います (if ( 被害者数 >= トラックナンバー ) 継続困難; )
（不確かなソース（念のため調べてみました）：
http://d.hatena.ne.jp/keyword/%A5%C8%A5%E9%A5%C3%A5%AF%A5%CA%A5%F3%A5%D0%A1%BC
http://c2.com/cgi/wiki?TruckNumber
）
<--
1.プロジェクトへのアジャイルなアプローチ
1.1 ひとつのチーム
・ロールと稼働率 相反しないか？
→相反しない場（体制）作りを志向せよということか？
→スケールとの関連があるね。
→多能工になれということか？
・プロダクトオーナーは今後よく出てくる言葉なので押さえておくべき。
プロダクトオーナーの責務
*チーム全員がビジョンを共有し、そこを目指せるようにすること。
*優先順位付け
*最終的な意思決定をする
1.2 短いイテレーション
・タイムボックスの期間中は変えない
・タイムボックスに入らないフィーチャを削るのはいつ？だれ？
→リリースプランとして→手前で交渉→見積もりをやり直していく
→いつでもふつうに
1.3 イテレーション毎の成果
・ユーザーストーリーをマジカで作ってみては？
・ユーザーストーリーは書きすぎないことも大事
⇒厳密に詳細さを求める前に、要件の網羅性を確保するのが大事。 (doubledispatch加筆。ここは考えさせられました）
※受け入れ時に初めて、携帯で閲覧する要件があることが発覚する等、
根本的に要求項目がスッポリ抜けるトラブルは実プロジェクトとしてある。
・要件はだれが作る？
（ユーザーストーリーはだれが作る？）(doubledispatch)
→ユーザー（本質的に）
→開発者と一緒に
1.5 検査と適用
・イテレーション中は仕様を変えない
・再見積もりとフィードバック
・経営判断
・慣性がつくと急な変更できない。イテレーション終了後に仕様変更。
⇒ウォーターフォールで大人数でも同様。いったんトランザクションとして作業を完遂するか全キャンセル
してからでないと、変更は難しい。誤りなく変更を受け入れて完遂させるのが困難。(doubledispatch)
2.アジャイルな計画づくり
・ナレッジを得ることを計画する？
→全てを知っていることを前提にしない
⇒コア部分使ってみたら満足して、残りのフィーチャ不要と判断するかもしれない。
最初に長期計画したフィーチャを計画駆動でリリース仕切るのでなく、フィード
バックタイミングを設けて要否を判断する（doubledispatch加筆)
→ベロシティの成長を意識する？
⇒ベロシティの実測値のフィードバックに基づいて、リリースを見直す(doubledispatch加筆）
2.1 複数レベルの計画づくり
・受託だと内側のみ？
⇒リリース計画と、イタレーション計画と、毎日の作業のTodoのみ。（受託側で意識する範囲）
⇒上位のポートフォリオ（投資配分）や、長期の計画は発注・内製側の決定事項(doubledispatch加筆）
2.2 満足条件
・リリースプランニングはイテレーションに含まれる？
⇒イテレーションの間にやるべきでしょう。
⇒リリースプランニングとイテレーションプランニングを階層的な状態遷移図風に表した図が分かりにくい。
→の遷移のトリガーのイベントが記載されていないから。(doubledispatch)
※足りないとこは、補足をお願いします。
Page updated
Google Sites
Report abuse