カイゼン・ジャーニーなどのスクラムの流れを把握できる本アジャイルを初めて勉強するためには向かなさそう。先に別の本を読んでおきたい。再読するなら第22章:なぜアジャイルな計画づくりがうまくいくのかアジャイル計画試したけど何かの壁に当たったとき。計画づくりのためのガイドラインが載ってて9ページ。内容メモ第7部・ケーススタディから逆算する結局の所、~の手法がわからないから読み返したいはずなので、ケーススタディの流れに沿って再読するのが良さそう。ユーザーストーリーの洗い出しP273:「プレイヤーとしてxxしたい」をベースにユーザーストーリーを探し出す。見積もりのスケールフィボナッチ数列(1,2,3,5,8...)を利用する。スケール値をバケツと見なし、若干多く入れることもできるが、多すぎるとあふれる、程度の感覚でスケールする対比・分割ストーリーごとの見積もり結果が同じ程度の単位までに収まるようにする。1~8であれば、作業間の規模を読み取れるが、1:100では100の規模を読み違える。第12章:ユーザーストーリーの分割ストーリーが大きすぎて1つのイテレーションに収まらない場合は分割を考慮する。タスク単位への分割は行わない。各人にスケール値のカードを配り、ストーリーに対する見積もりを同時に出す・同時に出すので、他人の意見に引きずられない・値に差が出たときにそう感じた理由を説明してもらう。チーム全員が話すことになるため、団結感が出やすい・説明により、全員が同意して平均化された値になる。・フィーチャの開発によって低減できるリスクP106:図9.2の「リスクと価値の四象分類」がある。フィーチャごとにこの図に載せて決定するのもあり。15章:イテレーションの長さを決めるリリースまでの長さを考慮して決める。大体1~2週間がオススメ。イテレーションの計画を作成P288:第1イテレーションの計画づくりこの段階までで、ユーザーストーリーはあくまで「プレイヤーとして新しいゲームを開始したい」の単位から変更していない。ユーザーストーリーの優先順位が付けられ、優先度の上位から改めてユーザーストーリーをタスクに分割する。第14章:イテレーション計画づくりユーザーストーリーをタスク(+作業時間)に昇華する。この時点では担当者は決めない。ストーリー割当の基準ベロシティ駆動1イテレーションごとの目標ベロシティを決定し、それに収まる量のユーザーストーリーをそのイテレーションの目標に定める。定めた分のユーザーストーリーをタスクに見積もる。コミットメント駆動ユーザーストーリーを一つ選びタスクを見積もる。それのコミットがイテレーション内で確約できるなら対応し、次のユーザーストーリーを見積もる。確約できないなら、それまでの確約分がそのイテレーションの目標になる。大きくても1営業日=1タスク程度の粒度で有るべき。タスクが見積もれないときP170:調査をする・修正するの2タスクに分ける。第16章:ベロシティの見積もり下手に予想するよりは実際にやってみるほうが良し。個人レベルの作業可能時間も見積もり、1イテレーションあたりの作業可能時間も見積もることで、進捗の把握がしやすくなる(バーンダウンチャート)。第17章:不確実性に備えるバッファの計画1タスクごとにバッファをつけるとパーキンソンの法則により、いっぱいまで時間を使ってしまいがちになる。プロジェクトバッファを別枠で確保する。・先を見越した計画づくりチームAのデータがなければチームBの作業が進まないケースなど。その場合、チームAの作業がイテレーション0.5分だったとしても、チームBは次イテレーションからの作業開始とする。(チームAの作業が完全完了できなかったとき、イテレーション中での待ち時間を避ける、合流バッファの考え方リリースプランニングP296:プロダクトリサーチの結果などを用いて、リリース時点での製品状態を確定する。タスクボードP239:タスクボードを用意し、ストーリーごとにタスク・作業中・確認待ち(+その他)を貼り出すことで、視覚的にわかりやすくなる。イテレーション終了時点で行うことP251の報告書の内容を確認していく。ダウンチャートリリースまでの残り作業の理想グラフに対して、実際の残り作業量グラフを書き込む。理想に対する作業の進み具合・停滞具合が視覚化されるので、大きく問題が起きていたときに気づきやすい。作業進捗+作業が溢れてることを確認できる。メモバグの扱いP168そのイテレーションで発生したバグであれば、そのイテレーション内で直すべきである。前イテレーションのバグ・着手できなかったバグは次以降のイテレーションのバグタスクとして積まれる。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。Themeisle.。