Embedded Files
「アジャイルな見積りと計画づくり」を読んだ感想コメント・疑問を、以下に記入ください。読書会では、ここに書かれたコメント・疑問を中心にディスカッションを行います。
名古屋アジャイル勉強会で使ったワークショップの資料があるので、それを使って本の概要を確認しようかなと思います。（やまもと）
以下、当日のディスカッションのメモです。
規模の見積りと期間の見積りを分離すると、なぜうまくいくのでしょう？
再見積りがしやすいから、ベロシティの変化を反映しやすい
アジャイルな開発では、見積りと計画づくりをし続けていく、だからうまくいく
それを可能とするために、規模と期間を分離しておく
最小フィーチャーがイテレーションに入らないアンチパターン
イテレーションはフィードバックサイクルだから長くはしたくない
分割するのが一般解だけどやりなおしはきつい
ハイセイフティ用途はアジャイルできない？
そんなことはないだろ
メディカル アジャイルで検索すると結構ヒットする
フィーチャーはエンドツーエンドでなくてはならない？
そうであることが好ましいが、イテレーション内にdoneしてフィードバックを得られることの方が優先
形式的なことに囚われ過ぎないようにしよう
完了条件(doneの定義)が重要
ゴールを明確にする
中間状態にこだわっても
プランニングポーカー
やってみると個人毎の傾向が浮き彫りになる
他人の意見に引きずられやすい人も明かになる
感覚が共有され、そろっていく
テストに関心がある人が入るといい
どうやってテストするのか、どんなテストをすべきなのか、みんなが意識するようになる
アジャイルとミニウォーターフォールとの違い
たとえば、実装やテストのことを考えずに設計はできないはず
考えずに設計だけして壁越しに投げつけるのがウォーターフォール
考えて必要なことは平行して行うのがアジャイル
ウォーターフォールはビッグバン過ぎるのが問題
納品してから直させられたり
どうしてもっと早くすり合わせできないのか
変更はないものだと思い込むから、変更が起こったときに対応できない
変更ありきで考えれば、変更コストは下がる
アジャイルはフィーチャー単位の開発が肝
だから順次リリースできる
ウォーターフォールだと途中での変更や追加に非常に弱いが
Page updated
Google Sites
Report abuse