スプリントに割り込ませるとき
いつスプリントで実施する PBI を変更するのか
そもそもスプリント期間中は追加でやることを増やさない。とされている。気がする。なんとなく。
スプリント計画でやる PBI を決め、スプリント期間中はその達成に集中する、ってどこかで聞いた気がする。
だから、スプリント中に実施する PBI は変えない、というのが答えな気がする。
----
そもそもスプリントの目的ってなんだっけ？
スクラムガイドに書いてある通り、スプリントゴール がそのスプリントの目的になる。
スプリントで着手する PBI は、スプリントゴールを達成するために必要となるものを実施することになる。
逆に言えば、スプリントゴールに関係ない PBI は、そこまで頑張らなくてもいいかもしれない（本当か？）
（むしろゴールに集中できなくなるし入れない方がマシかもしれない。YAGNI だ YAGNI。）
スプリントゴールに向かって進む中で、スプリントゴールを達成するために、今やっている PBI だけじゃ足りない、とか、この PBI なくてもスプリントゴールは達成できるな、と分かったときは、どうしたら良いだろうか。
そんなときに、スプリントで予定していた PBI を追加したり、やめたりすればいい。
----
本当にそうだろうか？例えば PBI でいえば。
PBI にも達成する内容が決まっていて、Done の定義がそれに該当する。
PBI を完成させるために何をすればいいか、作業内容を計画時点で洗い出す。
ところである PBI に着手したときに、予定外の作業をやらないと、Done にならないことがわかった。
そんなときにどうするか、となると、当たり前だが、計画外の作業をやらずに完成させない、、、のではなく、計画外の作業を実施して完成させることになる。当たり前すぎる。
PBI を完成させるのに作業が不足しているなら、追加してやればいい。
スプリントゴールについても同じで、スプリントゴールを達成すのに PBI が不足しているなら、追加してやればいい。
プロダクトゴールについても同じで、プロダクトゴールを達成するのにスプリントゴールが不足しているなら、追加してやればいい。
無駄ならやるつもりだったとしてもやめればいい。作業も PBI も一緒。
----
いつ PBI を追加するとか、やめるとか考えるといいのか？
要は、いつスプリントゴールに向かっているかを確認すればいいのか。
結局のところ、Daily Scrum がそれに当たることになる。
Daily Scrum でなにを話すと良いのか。要は進捗。
何に対する進捗を見ればいいのか？となると、お察しの通り、スプリントゴールに対する進捗であって、スプリント計画でやると決めたスコープが終わっているかどうかではない。
日々完成させた PBI を通じて、スプリントゴールを達成できるかを検査する。
となると、スプリントバーンダウンチャートなんて見てても、進捗なんて追えないってことがわかってくる。
バーンダウンチャートで進捗が追えると思っているということは、スプリントゴールが見えていないことの裏返しになる。
「計画したことが終わるかどうかが進捗であり、その過程での変化を拒絶する」
これって計画駆動の忌避したかったウォーターフォール脳じゃないの？
----
そもそもスプリントゴールは何で記載すべきか？
スプリントゴールは、スプリントで予定していた PBI の総量という訳ではないはず。
プロダクトゴールに進む上で、どういうステップで進んでいくかという作戦目標がスプリントゴールになる。
ゴールなので、「〜〜をやる」という表現ではなく、検査可能な “状態“ で記載されることが望ましくなる。
----
というわけで、
ゴールに向かって進むのであって、与えられた PBI をチームで仲良くやっていればいい訳じゃないよね、っていう話。（終わり）
見積もりを振り返らない
やってみたら大きかったので、ストーリーポイントを見直してもいいですか？
見積もりの精度を上げるにはどうしたらいいですか？
いい加減飽きたんやそのやりとり。
例えば、通勤にかかる時間は？って聞かれると、
各工程を積み上げて計算→誤差多い
昨日とどれくらい違う？→たぶん一緒
じゃあ毎日ずっと一緒？→たぶんね。でもたまに遅れる。早くなることより遅れることの方が多い。
っていうのはなんとなくわかる気がする。
個別のアイテムは誤差が出る。開発は複雑度が高いのでたまに地雷を踏むのでハマる？すると想定よりも時間がかかる。山手線が止まるのと一緒。
これを誤差がなくなるには？とか、地雷を全て見つけてから見積もりをしては？とやりたがる人がいるが、おすすめしない
なぜなら、完璧な見積もりなんて存在しないし、意味がない。なんならネガティヴな効果さえ生んでしまう
ネガティヴな効果＝コブラ効果、グッドハートの法則に代表されるような観察者効果。 見積もりと合うことが求められるなら、死ぬほどサバ読んで使い切るのが関の山。それを求める阿呆はいないけど、結果そうなる。
見積もりは完璧にいかない。上振れもあるし下ぶれもある。
これは確率密度分布で理解すると手っ取り早い。
確率密度関数は、どの値になる可能性がどの程度の確率か、の分布を示したもの。
よく言われる？のは↓の正規分布のもの。
どのあたりに分布するかはわかるが、実際にどこの値をとるかは蓋を開けるまでわからない。シュレーディンガーの見積もり。
ソフトウェアの見積もりは Putnam モデルから言われるとレイリー分布に従うとか言われる。要はロングテールがあるよね（課題が見つかったりしてどハマりしたら割と無限に時間が溶けるよね）って話。
レイリー分布はこんな形
ここで見積もりが実績と必ず乖離する理由が現れる
電車で何時間かかる？と聞かれたときには、"いつも"何時間くらいかかるか、を返すことが多いと思う。
それは統計で言えば 最頻値 になる。
この絵でいえばピーク部分が最頻値。
ところでじゃあその確率次第（見積もりだしね）の結果、やってみた結果を見てみるとどうなるかというと、それぞれの工程は最頻値を取りながらもトータルとしては 期待値 に落ち着く。
レイリー分布の期待値は、
一方、最頻値は
なので、期待値は常に最頻値、これくらいかかると見積もった値に対して、 と、25％上振れする。
僕らは、最頻値で見積もり、現実は平均値でやってくる
この2割の上振れを踏まえてキャパシティに組んでおく必要が出てくる。（積み上げ見積もりの場合）
ちなみに、この不思議な2割という数値は、ウォーターフォールのPMだろうがスクラムマスターだろうがだいたい取っておかないといけないと思うという直感の数値と一致する。なんとも不思議というか必然というか。
積み上げるとバッファが必要とは書いたが、アイテムによっては山の左側、つまり予想より早く終わることも起こりうる いくつかのアイテムの実績を集めると、上振れしたものと下振れしたものが合わさって出てくる。 全てのアイテムの合計を行うと、これらの見積もりとの乖離が相殺する。意外とこの数値はブレない。 （期待値同士の比較になるため。）
（まあ実際には、確率密度関数の最頻値＝見積もりより低くなることは少ないことが多いのでより高く上振れする。パーキンソンの法則が働くので）
要はアイテムの見積もりはそこそこダイナミックにブレるが、それらを足し合わせたベロシティはそんなにブレない、ということになる。
じゃあ手取り早くやるにはどうしたらいいか、って考えると、ベロシティで見積もるのが手取り早そう。
例：段ボールにMサイズのみかんが何個入りますか？
っていう問題に対して、
みかんのサイズを分析し、充填率を分析し、何個入るか考える
何箱か実際に詰めてみて、どれくらい実際に入るのか確かめて、平均値採用する
という2つのアプローチのどちらが効率が良いかと言われると、間違いなく後者でしょう。
なお前者のアプローチを採用した場合、待っているのは予実の乖離の分析なぜなぜ祭りと完璧な精度を求める箱詰め予測のプロフェッショナルの道。いいからコードを書けこの管理屋が。
というわけで、積み上げてどれくらいできるよね、って見積もるよりも、実績をベースに見積もった方がまだマシそう。理性主義は現実見てから唱えてくださいね、ってなる。
そもそも見積もりなんて、作る価値があるかを判断するために、価値に見合うだけのコストで収まるかが知りたいから必要とされる。
無駄なコストを抑えるための見積もりに無駄なコストを掛けてたら本末転倒以外の何物でもない。
ましてや本質的にブレるのが見積もりであるのに、見積もりがなぜブレたのか、を考えるのは考えるのは大した意味が無い。
マネジメントしているつもりになっていてやることがなくなる人ほどそういうことをし始める。
サイコロを振ってなぜ１が出なかったのか？って考えてるのと同じで正直アホだと思う。
当然実績ベースで見積もったところで結果はブレるかもしれないが、そこを気にしていてもしょうがない。
唯一精度を上げる方法があるとしたら、全ての見積もりサイズを同程度にしておく。小さくしておく。くらいしかない。（唯一のまともなアドバイス）
そもそもスプリントの精度ってなんのために必要なのか、っていうと答えられないことが多いんじゃ無いかなって気はする。
スプリントが達成できたかどうかは、計画したアイテムが終わったかどうか、ではなく、計画したアイテム（と、計画していなかったけど必要だとわかったアイテム）を通じて、インクリメントが結果としてスプリントゴールを満たしているかどうかしかない。
スプリントゴールは各 PBI とは別に、それらの PBI を通じて ”どんな状態を実現したいのか” で表現されているとわかりやすいのだと思う。
作戦目標をスプリントゴールだとすれば、各 PBI はそれぞれの作戦過程における戦術目標に相当する。
戦術目標を全て満たしたとしても、作戦目標を達成するかどうかは怪しい。
なぜなら作戦立案時から状況が変わっているかもしれないし、立てた作戦が間違っているかもしれないから。
なので、戦術目標(PBI) をクリアーしながら、作戦目標を達成できるかを評価し続けないと危ない。これはデイリースクラムでやればいいと思う。
これは長そうだしいつか別に書く。多分。知らんけど。
ふりかえりのマンネリ感に向けて
ふりかえりにマンネリ感がある
っていう話を聞いた。
確かに感じるところもある気がする。
これに対してどうしたらいいのか。
なぜそうなるのか。
----
どういう状態なのか？
----
そもそもまずいことなのか？
ふりかえりの目的、というかレトロスペクティブの目的。
プロセスなどを検査し、適応する。
なんかこれ自体はできている気はする。でもイマイチらしい。
----
似たような話題がスプリントにもあった気がする
スクラムガイド2020 版で導入された、「プロダクトゴール」
ともすれば毎スプリントごとに何かを作る野菜切り係となってしまうスクラム。
短期的な目標だけではなく、長期的な達成目標を設定しましょう、っていうやつ。
XP だと四半期サイクル、みたいな
日々の目の前のことだけじゃなく、長期的な目標が見えていることで、何に目を向ければわかるようになる。
ビジョンとかダイレクションとかで仕事の内容については語られることが多い気はする。
これがあるので森羅万象から自分たちが向かう方向が見えて、何を見て何を対応するのか日々判断できるようになる
----
これと同じことがチームにもあればいいんじゃないだろうか
要は、チームとしても、チームの長期的な目標を掲げる
要はミッションステートメントでしょ？はいそうです。
チームに名前をつけて、どういうチームになるのかを明確にする。
（あとはもちろん、人をコロコロ入れ替えない。）
自分たちがどういうチームになるのか。具体的に書いても面白いかもしれない。
小さいことから始めるなら、テックブログ書いて PV 何件、とかでも。
GitHub 年収予測でチーム総額がいくらになるとかだとちょっとアレかも。
----
これをやるとどうなるのか
自分の見ているチームでは、これをやることを提案してみよう。
（失敗したらひっこめよ）
観測範囲では、きちんとこういった目標を設定しているチームは士気が高い。
というか、やっていて士気が低いとか、戦闘力が低いチームは見たことがない。
あ、作りっぱなしでふりかえることのないチームはそうじゃないかも。
これはプロダクトゴールでも一緒なんだろうけど。
反復型開発とアジャイルは違う
反復型開発 イコール アジャイル開発ではないよね、という話
顧客価値の最大化を狙うとすると、思い込みで開発するよりも、より顧客について学習した状態で何を作るかを判断した方がいい。
そうなると、「何を作ればいいか」を継続的に探す必要が出てくる。
とはいえ仕様書で何を作ればいいかがわかるかというと、それも無理ゲーな話（できると思っているアタマユルイ人はいる）
となると、動くソフトウェアで触って確かめないといけない。
となると、動くソフトウェアを継続的に作る必要がある。継続的にドメインを学習するために。
＃継続的にソフトウェアを作る上で、小さいタイムボックス＆バッチで作るか、フローで作るかは選択の余地があり
そのため、アジャイル開発ではあるが、反復型開発ではない、というパターンは上記が実現できないので、おそらくない。
結果として、アジャイル開発であるなら、反復的に開発することが必要になる。
一方で、反復的に開発するというのは、コストがかかる。
ビルドの手間、リグレッションテスト、デプロイの手間、手戻りの際の管理の煩雑さ、漸進的な設計、、、
これらのものが意外とコンピュータリソースやクラウドやツールで何とかなってきたので、反復型開発が「ペイしやすく」なってきたので、反復型開発がしやすくなって気はする。
反復型開発のメリットは、アジャイル開発が実現できるだけではない。
スコープでコントロールするスタイルでトカゲの尻尾切りでプロジェクトをローンチできる。
いらない機能を作り込む代わりにコストと納期が伸びるのと、いらない機能を作らない代わりにコストと納期を約束できます、というのでは後者が望まれる場面も多い。
この場合は「要件定義」とかいうフェーズを済ませてしまう人も多い。
ヒアリングした結果のうち、優先度が高いものから反復的に作っていきましょう。
最悪の場合、作った結果を見てもらうこともない。
見てもらわないとなると、何のために反復型開発をしているのか、となるが、PJ をコントロールしやすくするため、となる。
金と納期は決まったから、最初に聞いた内容からできることだけ作ろうぜ。と。
それのどこが顧客の方を向いているのか、全く理解できない。ただのコントロール力不足じゃないですかね。
で、どうなるかというと、３割くらいは、検収・ユーザーテストで要件不足に気がつき炎上する。
こういうケースをアジャイル開発と呼んでいるケースが多く、「やっぱりアジャイルってさ〜」っていう人が割といる。いいかげんアジャイルアジャイル言われて久しいし。
いやアジャイルじゃなくてただの劣化スパイラルじゃないのそれ、と。RUP ですらないだろと。
反復型開発がアジャイル開発だ、と思っている人には、アジャイル開発がダメに見える。
アジャイル開発をしている人には、それってアジャイル開発じゃないよね、と見える。
側から見ると、アジャイルをやっている人は成功している物だけをアジャイル開発と呼んでいる、ように見えてしまう。
反復型開発はアジャイル開発の一側面であって全てではない、というのを理解していない人が多いので、名前も悪いよな、とか思いながらコーヒー飲んでいます。
漸進的探索とか目的に近い名前をつけておいた方が良いんだろうな、という気持ち。
