実践と価値を行き来して理解を深めるXP
〜ストーリー・計画づくり篇〜
- Event:
XP祭り2022
- Presented:
2022/10/01 nikkie
お前、誰よ
Pythonとアニメが好き
Py thon Con ference Japan 2021 座長
国内外のPyConで定期的に（リモート）登壇（2020〜）
最近のアニメはリコリコ、スーパースター🌟💫などなど楽しんでます😆
XPするデータサイエンティスト
株式会社ユーザベース （Python、自然言語処理）
We're hiring!! (Engineers, Data scientists, Researchers)
XPとnikkie
2019年、ユーザベースにJoinしてXPの実践スタート
XP未経験 から開発チーム（先輩XPer）のプラクティスを見様見真似で実践
3年経った頃「このやり方でいい？」と思うように
今回話す、私のこのやり方でいいんだっけ？
ストーリー（＝ユーザーストーリー User story）
計画づくり（planning、計画を作る過程）
アプローチ
『エクストリームプログラミング』には簡潔な説明がある
「私のこのやり方でいいんだっけ？」（本質をわかっている達人（例：ケント・ベック）は同じやり方をする？）
👉 他の書籍 にあたっていく
実践と価値を行き来
実践と価値を行き来
プラクティスの実践➡️価値の理解
価値を体現するプラクティスを探す
これでいい？＝「価値の理解を更新したい」
書籍（この発表のメイン）
社外の読書会（Special thanks agile_devs ）
日々チームでの実践（Special thanks チームメンバー）
思うに、誰しもアジャイルの 旅の途中 にいる
キーノートでも「旅」出ましたね
現時点での私の理解を共有します
ちょっとしたことでもフィードバックいただけるととても嬉しいです🙌
実践と価値を行き来して理解を深めるXP
ストーリー
計画づくり
原点📚ケント・ベック曰く
ストーリー（ユーザーストーリー）とは
顧客に見える機能の単位を使って計画すること
『エクストリームプログラミング（第2版）』7.6
ストーリー、これでいいんだっけ？
確証が持てなかったポイント「ストーリーはどこまで詳細にする？」
機能の単位で計画する中で、ストーリーにメモが増えていく📝
『Clean Agile』📘 曰く
ユーザーストーリーとは、システムの機能をユーザーの視点から簡潔に記述したもの
第3章「ストーリーとポイント」
ここで注目：簡潔に記述
詳細化を避けるのは鍛錬である。
第3章「ATMのストーリー」📘
なぜ詳細化を避ける？
ストーリーをマネジメント可能、スケジュール可能、見積り可能にするためには、「一時的な詳細の欠如」が必要である
第3章「ストーリーとポイント」📘
ストーリーは 会話のプレースホルダー 📘
Webページ作成中のLorem Ipsumや「ああああ」と同じということ
実際のコンテンツは後から挿入される
タイトルタイトルタイトル
ああああ
ああああ
ああああ
※プレースホルダーの例のスライドです
ストーリーは「あとで会話する」を表す
詳細な仕様を決めるのは、ストーリーを開発するときまで可能な限り遅らせたい。
第3章「ストーリーとポイント」📘
『Clean Agile』📘を読んで
当初の疑問「ストーリーはどこまで詳細にする？」
ストーリーは 会話のプレースホルダー
💡詳細化はあまり効果的ではない（「ああああ」を「あいうえ」に凝っても・・・）
もう1冊『The Art of Agile Development, 2nd Edition』📖
英語で読んでます
初版は日本語 で入手できます（2009）
AoAD2eより
Stories are for planning. They’re the playing pieces of the planning game. That’s it!
8.Planning > Stories
AoAD2e ストーリーとはnikkie訳
ストーリーとは計画のためのものです。ストーリーは 計画ゲームをプレーするための駒 で、それだけです！
規模により分類できればいい📖
計画段階（プラクティス The planning game）においての話
ストーリーがちょうどいい大きさ・大きすぎる・小さすぎるが分かる状態
『Clean Agile』📘の 詳細化を避けると重なる
計画とは別にストーリーをタスクに分解する📖
Use task planning to break the first few stories into development tasks.
8.Planning > Adaptive Planning > How to Create Your Plan
『AoAD 2e』を読んで
当初の疑問「ストーリーはどこまで詳細にする？」
（やはり）ストーリーは詳細化しない
計画とは別にタスクに分解
ストーリーについての考察
裏にある考え方はなんだろう？
実践を踏まえるとどのようにとらえられるだろう？
再掲：『エクストリームプログラミング（第2版）』
ストーリー（ユーザーストーリー）とは
顧客に見える機能の単位を使って計画すること
ポイントは「計画 すること」
ストーリーは 状況 によって詳細化の程度が変わる！
計画時は 詳細化を避ける
計画とは別にタスクに変える
詳細化を避ける
XPの価値の1つ「シンプルさ」
計画時は簡潔な記述に留める
コミュニケーションのリマインダー
XPの価値の1つ「コミュニケーション」
「会話のプレースホルダー」
取り組む際にコミュニケーション して、詳細化する
詳細化は遅らせたい
XPの価値の1つ「フィードバック」
チームの 学びを反映 して詳細化したい
計画時に話した詳細は信用していない（『Clean Agile』📘）
計画する中でストーリーにメモを増やしていた私へ
📣「詳細化したい衝動に抵抗するんだ！」
計画段階では規模で分類できればいい。詳細化は後で
💡ストーリーのプラクティスの鍵は どこまで詳細化するかチーム内の認識合わせ
小まとめ🥟：ストーリー
見積もって 計画 するために、 一時的に詳細化を避ける
「会話のプレースホルダー」、開発して学びを得た上で直前で詳細化
ストーリーから計画づくりへ橋渡し（2点）
ストーリーポイント
規模を見積もり、期間を導出
1)ストーリーポイント
ストーリーを ポイント で見積もっている（1pt、2pt）
ストーリーポイントとは
フィーチャを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったもの
『アジャイルな見積りと計画づくり』（4章 p.62）
ストーリーポイントとは
ポイントの数字はあいまいで、ファジーで、精度の低いものであり、実時間と直接 関連しているわけではない
『Clean Agile』（第3章 ATMのストーリー 強調ママ）📘
ポイントの考え方：バケツと砂
5 ポイントのバケツに 5 ポイント 分よりも少し多めに砂を入れたとしても、砂がバケツからあふれることはない
『アジャイルな見積りと計画づくり』（6章 p.75）
比較して見積もる
ストーリーどうしを比較
平均的な規模のゴールデンストーリー
『アジャイルな見積りと計画づくり』より
見積りは短時間で
少ない労力で大きな効果 が得られる状態（図の左寄り）（『アジャイルな見積りと計画づくり』6章）
精度が低い（ブレる）からこそ短時間（『Clean Agile』📘 第3章）
フィードバックで調整して精度を上げていく
ストーリーから計画づくりへ橋渡し（2点）
ストーリーポイント✅
規模を見積もり、期間を導出
2)規模を見積もり、期間を導出
『アジャイルな見積りと計画づくり』（4章）
2つの道具🛠
ストーリーポイント（既出）：規模の見積り
ベロシティ
ベロシティ
ベロシティとは、チームの進む速度をあらわす数値
『アジャイルな見積りと計画づくり』（4章 p.63）
ベロシティ
チームが 1 回のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値
『アジャイルな見積りと計画づくり』（4章 p.63）
スケジュールの求め方
プロジェクト全体の規模を見積もる（ストーリーポイントの合計）
規模をベロシティで割る ＝ 必要なイテレーション回数 の見積り
『アジャイルな見積りと計画づくり』（4章）
ベロシティの推測
ベロシティが分かっている場合はイテレーション回数はすぐ求まる
ベロシティが不明な場合（例：新規チーム）、ベロシティを見積もる（後述）
実践と価値を行き来して理解を深めるXP
ストーリー
計画づくり
計画づくり、これでいいんだっけ？
（ちょっと長いですが）「これでいいんだっけ」を共有します
「何をいつまでに作ればいいのか」に答えた
ここでは、1イテレーションの期間は1週間とする
全体の規模 \(\div\) ベロシティ
1回1回のイテレーションに入っていく
イテレーションプランニング
優先度の高いストーリーを採る
ポイントの合計がベロシティになるまで
比喩：予算を賢く使って買い物
ストーリー＝食料品
ストーリーポイント＝値札
ベロシティ＝予算
ref: 『エクストリームプログラミング（第2版）』第12章
ベロシティは確約ではなく見積もり
完成させようと 試みる ことを約束しているわけでもない
『Clean Agile』第3章 ATMのストーリー（強調ママ）📘
"確約ではない"が、これでいい？
「採ったストーリー、今週は全部できませんでした」
翌週もこれが繰り返される
コミットの強度が低くなってる？（信頼目減りしてない？）
昨日の天気 ☀️🌤☁️
ちょっと話題を変えて
昨日の天気（Yesterday's Weather）
今日の天気は昨日の天気と同じだろう
今回のイテレーションのベロシティは 前回のイテレーションのベロシティと同じ だろう
昨日の天気により、ベロシティは自己調整される
ベロシティを 過剰 に見積りすぎた（overestimate）
見積もったベロシティに満たない
昨日の天気により、次のイテレーションはベロシティを 小さく できる（達成はより現実的）📉
昨日の天気により、ベロシティは自己調整される
ベロシティを 過小 に見積りすぎた（underestimate）
見積もったベロシティを上回る
昨日の天気により、次のイテレーションはベロシティを 大きく できる📈
話を戻して、これでいいんだっけ？
今回はストーリー全部できませんでした（の繰り返し）
IMO：全体の規模 \(\div\) ベロシティ の裏側
分母のベロシティは 昨日の天気
今回のベロシティは前回のイテレーションと同じ
イテレーションを通して 同じベロシティという前提 でスケジュールが算出されている！
IMO：フィードバック！
「今回はストーリー全部できませんでした」はフィードバックのトリガー！
同じベロシティという前提が崩れている👉 スケジュールに影響 する（結構重要な事態！🚨）
期間の導出に使ったベロシティが過大と分かった
昨日の天気により、小さい値に調整された
全体の規模 \(\div\) ベロシティ により、所要する イテレーション回数は増える
この懸念はステークホルダーに共有されるべきと考える
まずい事態に対策はないのか？
発生した場合はスコープの調整（全体の規模を減らす）が有力（ref: 荒ぶる四天王『アジャイルサムライ』）
そもそも今回は全部できませんでした（の繰り返し）に ならないようにする 方法はある？
計画に意志を乗せる
有力と考えている対策（実践中）
「そのプランニングに意思、乗せていますか?」
「そのプランニングに意思、乗せていますか?」
各イテレーションのイメージ
各イテレーションで必ず達成すること
各イテレーションで完全Doneしようとする
IMO：主導権を握りに行く
意志を乗せていなかった私、状況に翻弄されている
前回も今回もストーリー全部できなかった（あわわわ）
意志を乗せることで、 主導権を取った 状態
裏付け：3段階の計画（プランニング・オニオン）
リリースプランニング
イテレーションプランニング
「今日」のプランニング
『アジャイルな見積りと計画づくり』（3章 図3.1）
意思を乗せるとの対応
リリースプランニング
各イテレーションのイメージ
各イテレーションで必ず達成すること
意思を乗せるとの対応
イテレーションプランニング & 「今日」のプランニング
各イテレーションで完全Doneしようとする
計画づくりについての考察
裏にある考え方はなんだろう？
実践を踏まえるとどのようにとらえられるだろう？
規模を見積もり、期間を導出
昨日の天気 が採用されている！
＝同一のベロシティという前提
上回るのに比べて 下回るのはかなりまずい
ベロシティが同一前提にもかかわらず下回った
XPの価値の1つ「フィードバック」
いつまでに作る（何イテレーション分か）への回答がズレる（多くの期間が必要）とわかる
ステークホルダーとコミュニケーションを！
「ベロシティは確約ではない」
ベロシティが 分からない場合 の見積もり（『Clean Agile』📘）
見積もったベロシティ（と導出される期間）の精度は低い（ブレうる）
ベロシティのデータが蓄積されるとベロシティも期間も精度が高く（ブレずに）見積もれる
WE WILL🎶
各イテレーションをイメージし「ストーリーを完了させるんだ」という 意志 を乗せる
ただし、それでもすべてを完了させるのは至難の業
「やるんだ」のスタンスであれば、状況に対して主導権は取れている（と考える）
小まとめ🥟：計画づくり
ベロシティが見積った値を下回ったという結果は、 期間を導出した際の前提（同一ベロシティ）を 大きく 揺るがし ている
WE WILL：「毎イテレーション、すべてのストーリーを完了させるんだ」という意志を乗せる
まとめ：実践と価値を行き来して理解を深めるXP
ストーリー：「どこまで詳細にする？」
計画づくり：「ストーリー全部できませんでした」
まとめ：実践と価値を行き来して理解を深めるXP
ストーリー：「どこまで詳細にする？」
計画時点では 詳細化を避ける
計画づくり：「ストーリー全部できませんでした」
まとめ：実践と価値を行き来して理解を深めるXP
ストーリー：「どこまで詳細にする？」
計画づくり：「ストーリー全部できませんでした」
同一ベロシティが前提 にされているので即フィードバックを回す
意志 を乗せる
この旅はどんな旅だった？
守破離とは、Alistair Cockburn曰く (4:30〜)
守：1つの技法をコピー、質問しない
破：技法を集める
💡「このやり方でいいんだっけ？」は破の段階に差し掛かっていたということか！
ご清聴ありがとうございました
Enjoy your journey!❤️
References が続きます
References 1/3
『エクストリームプログラミング（第2版）』（2015）
『Clean Agile』（2020）
『アジャイルな見積りと計画づくり』（2009）
References 2/3
『アート・オブ・アジャイル デベロップメント』（2009）
『アジャイルサムライ』（2011）