海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

脱「ちゃんと」病

何かを改善するときに、

「ちゃんと○○できるようにするには」

みたいな方向にどうしても行きがちになる気がする。

ex1. 本番障害が発生した → テストをちゃんとやる ex2. デモで手戻りが発生した → ちゃんと要件・仕様を詰める

みたいな。


この「ちゃんと」病に取り憑かれるのは、Waterfall 時代の癖なのかもしれない。

もちろん、事前に抑えられるなら事前に抑えたほうが良いのは絶対にある。が、限度もある。

100% をちゃんと事前に抑えるのは無理だと諦めたほうが良くて、せいぜい8割が事前に抑えられれば良い方だと思う。(要出典)

で、残りの2割に対して、「ちゃんと○○しよう」というアプローチでやっても、無駄なコストがかかるばかりになってしまう。

そもそも、「ちゃんと要件を事前に決めるなんて無理でしょ」みたいな事実から継続的に検査と適応をしないといけないよね、というのがアジャイル開発のモチベーションの大きな一つなはず。


じゃあ、どうするか。

MTTR vs MTBF を両輪で使い分けるのが大事な気がする。

問題を起こさないことと、問題が起きたときにその影響を極小化したりすることで問題の影響を抑制する方向を考える。

ex.社内でインフルエンザが流行って作業が進まず、遅延が発生する  → インフルエンザが流行らないようにする ← そのために、注意喚起、手洗いうがい、アルコール消毒機器を置く  → インフルエンザが流行っても問題が大きくならないようにする ←タスクを属人化させない、バッファを確保する、休みやすい環境にする、Plan B を決めておく

ex. メモリが貼りついて本番障害が発生し、売り上げ機会を逸した  → メモリが貼りつかないようにする ← スタックした部分を修正する  → メモリが貼りついても問題が大きくならないようにする ← 構成を冗長化する、スケーラブルな設計にしておく、定期的に再起動する

どっちも重要だし、どっちもやったほうがよさそう。

どちらかだけで何とかしようとするのは割と悪手な気がする。


どちらがいいというわけではなく、「ちゃんと○○しましょう」という言葉が出てきたら、ちょっと待てよ?無理スジなのでは?って考えるようにしたい。

Daily Scrum が終わったらホイッスルを吹かれても大丈夫か

昨日、Scrum Master's Night に参加してきました。

smn.connpass.com

 

その中で、ファシリテーション難しいよね、ってテーマに参加させていただきました。同じテーブルの皆さま、ありがとうございました。

f:id:Bashiko:20211209235026j:plain

その中で、デイリースクラムファシリテーションをどうやってもらうか、っていう話題になりました。

アジェンダや何を話すかを明確にしておくことで、安心してファシリテーションをやってもらえるんじゃないか、といった話もあり、一方で、デイリースクラムの目的というかゴールだけ伝えておけば、自分たちでどうやるかは考えられるんじゃないか、みたいな話になりました。

で、デイリースクラムのゴールってなんじゃらほい、みたいな話になり、そこで話したのが、表題に書いたことに関係する、「ホイッスル吹かれても大丈夫か」っていう話でした。(なんのこっちゃ)

続きを読む

スプリントに割り込ませるとき

いつスプリントで実施する PBI を変更するのか

 

そもそもスプリント期間中は追加でやることを増やさない。とされている。気がする。なんとなく。

 

スプリント計画でやる PBI を決め、スプリント期間中はその達成に集中する、ってどこかで聞いた気がする。

 

だから、スプリント中に実施する PBI は変えない、というのが答えな気がする。

 

 

----

 

そもそもスプリントの目的ってなんだっけ?

 

スクラムガイドに書いてある通り、スプリントゴール がそのスプリントの目的になる。

 

スプリントで着手する PBI は、スプリントゴールを達成するために必要となるものを実施することになる。

 

逆に言えば、スプリントゴールに関係ない PBI は、そこまで頑張らなくてもいいかもしれない(本当か?)

 

(むしろゴールに集中できなくなるし入れない方がマシかもしれない。YAGNIYAGNI。)

 

スプリントゴールに向かって進む中で、スプリントゴールを達成するために、今やっている PBI だけじゃ足りない、とか、この PBI なくてもスプリントゴールは達成できるな、と分かったときは、どうしたら良いだろうか。

 

そんなときに、スプリントで予定していた PBI を追加したり、やめたりすればいい。

 

f:id:Bashiko:20210604015232p:image

 

----

 

本当にそうだろうか?例えば PBI でいえば。

 

PBI にも達成する内容が決まっていて、Done の定義がそれに該当する。

 

PBI を完成させるために何をすればいいか、作業内容を計画時点で洗い出す。

 

ところである PBI に着手したときに、予定外の作業をやらないと、Done にならないことがわかった。

 

そんなときにどうするか、となると、当たり前だが、計画外の作業をやらずに完成させない、、、のではなく、計画外の作業を実施して完成させることになる。当たり前すぎる。

 

PBI を完成させるのに作業が不足しているなら、追加してやればいい。

 

スプリントゴールについても同じで、スプリントゴールを達成すのに PBI が不足しているなら、追加してやればいい。

 

プロダクトゴールについても同じで、プロダクトゴールを達成するのにスプリントゴールが不足しているなら、追加してやればいい。

 

無駄ならやるつもりだったとしてもやめればいい。作業も PBI も一緒。

 

----

 

いつ PBI を追加するとか、やめるとか考えるといいのか?

 

要は、いつスプリントゴールに向かっているかを確認すればいいのか。

 

結局のところ、Daily Scrum がそれに当たることになる。

 

Daily Scrum でなにを話すと良いのか。要は進捗。

 

何に対する進捗を見ればいいのか?となると、お察しの通り、スプリントゴールに対する進捗であって、スプリント計画でやると決めたスコープが終わっているかどうかではない。

 

日々完成させた PBI を通じて、スプリントゴールを達成できるかを検査する。

 

となると、スプリントバーンダウンチャートなんて見てても、進捗なんて追えないってことがわかってくる。

 

バーンダウンチャートで進捗が追えると思っているということは、スプリントゴールが見えていないことの裏返しになる。

 

「計画したことが終わるかどうかが進捗であり、その過程での変化を拒絶する」

 

これって計画駆動の忌避したかったウォーターフォール脳じゃないの?

 

----

 

そもそもスプリントゴールは何で記載すべきか?

 

スプリントゴールは、スプリントで予定していた PBI の総量という訳ではないはず。

 

プロダクトゴールに進む上で、どういうステップで進んでいくかという作戦目標がスプリントゴールになる。

 

ゴールなので、「〜〜をやる」という表現ではなく、検査可能な “状態“ で記載されることが望ましくなる。

 

----

 

というわけで、

 

ゴールに向かって進むのであって、与えられた PBI をチームで仲良くやっていればいい訳じゃないよね、っていう話。(終わり)

 

見積もりを振り返らない

やってみたら大きかったので、ストーリーポイントを見直してもいいですか?

見積もりの精度を上げるにはどうしたらいいですか?

いい加減飽きたんやそのやりとり。


例えば、通勤にかかる時間は?って聞かれると、

各工程を積み上げて計算→誤差多い

昨日とどれくらい違う?→たぶん一緒

じゃあ毎日ずっと一緒?→たぶんね。でもたまに遅れる。早くなることより遅れることの方が多い。

っていうのはなんとなくわかる気がする。

個別のアイテムは誤差が出る。開発は複雑度が高いのでたまに地雷を踏むのでハマる?すると想定よりも時間がかかる。山手線が止まるのと一緒。

これを誤差がなくなるには?とか、地雷を全て見つけてから見積もりをしては?とやりたがる人がいるが、おすすめしない

なぜなら、完璧な見積もりなんて存在しないし、意味がない。なんならネガティヴな効果さえ生んでしまう

ネガティヴな効果=コブラ効果、グッドハートの法則に代表されるような観察者効果。 見積もりと合うことが求められるなら、死ぬほどサバ読んで使い切るのが関の山。それを求める阿呆はいないけど、結果そうなる。

測りすぎ――なぜパフォーマンス評価は失敗するのか?


見積もりは完璧にいかない。上振れもあるし下ぶれもある。

これは確率密度分布で理解すると手っ取り早い。

確率密度関数は、どの値になる可能性がどの程度の確率か、の分布を示したもの。

よく言われる?のは↓の正規分布のもの。

f:id:Bashiko:20210210020036p:plain:w300

どのあたりに分布するかはわかるが、実際にどこの値をとるかは蓋を開けるまでわからない。シュレーディンガーの見積もり。

ソフトウェアの見積もりは Putnam モデルから言われるとレイリー分布に従うとか言われる。要はロングテールがあるよね(課題が見つかったりしてどハマりしたら割と無限に時間が溶けるよね)って話。

Putnam model - Wikipedia

レイリー分布はこんな形 f:id:Bashiko:20210602041546p:plain

ここで見積もりが実績と必ず乖離する理由が現れる

電車で何時間かかる?と聞かれたときには、"いつも"何時間くらいかかるか、を返すことが多いと思う。

それは統計で言えば 最頻値 になる。

この絵でいえばピーク部分が最頻値。

ところでじゃあその確率次第(見積もりだしね)の結果、やってみた結果を見てみるとどうなるかというと、それぞれの工程は最頻値を取りながらもトータルとしては 期待値 に落ち着く。

レイリー分布の期待値は、\sigma\sqrt{\pi/2}

一方、最頻値は \sigma

なので、期待値は常に最頻値、これくらいかかると見積もった値に対して、 \sigma\sqrt{\pi/2}/\sigma = \sqrt{\pi/2} \approx 1.25 と、25%上振れする。

f:id:Bashiko:20210602044349p:plain

僕らは、最頻値で見積もり、現実は平均値でやってくる

この2割の上振れを踏まえてキャパシティに組んでおく必要が出てくる。(積み上げ見積もりの場合)

ちなみに、この不思議な2割という数値は、ウォーターフォールのPMだろうがスクラムマスターだろうがだいたい取っておかないといけないと思うという直感の数値と一致する。なんとも不思議というか必然というか。

積み上げるとバッファが必要とは書いたが、アイテムによっては山の左側、つまり予想より早く終わることも起こりうる いくつかのアイテムの実績を集めると、上振れしたものと下振れしたものが合わさって出てくる。 全てのアイテムの合計を行うと、これらの見積もりとの乖離が相殺する。意外とこの数値はブレない。 (期待値同士の比較になるため。)

(まあ実際には、確率密度関数の最頻値=見積もりより低くなることは少ないことが多いのでより高く上振れする。パーキンソンの法則が働くので)

要はアイテムの見積もりはそこそこダイナミックにブレるが、それらを足し合わせたベロシティはそんなにブレない、ということになる。


じゃあ手取り早くやるにはどうしたらいいか、って考えると、ベロシティで見積もるのが手取り早そう。

例:段ボールにMサイズのみかんが何個入りますか?

っていう問題に対して、

  1. みかんのサイズを分析し、充填率を分析し、何個入るか考える

  2. 何箱か実際に詰めてみて、どれくらい実際に入るのか確かめて、平均値採用する

という2つのアプローチのどちらが効率が良いかと言われると、間違いなく後者でしょう。

なお前者のアプローチを採用した場合、待っているのは予実の乖離の分析なぜなぜ祭りと完璧な精度を求める箱詰め予測のプロフェッショナルの道。いいからコードを書けこの管理屋が。

というわけで、積み上げてどれくらいできるよね、って見積もるよりも、実績をベースに見積もった方がまだマシそう。理性主義は現実見てから唱えてくださいね、ってなる。


そもそも見積もりなんて、作る価値があるかを判断するために、価値に見合うだけのコストで収まるかが知りたいから必要とされる。

無駄なコストを抑えるための見積もりに無駄なコストを掛けてたら本末転倒以外の何物でもない。

ましてや本質的にブレるのが見積もりであるのに、見積もりがなぜブレたのか、を考えるのは考えるのは大した意味が無い。

マネジメントしているつもりになっていてやることがなくなる人ほどそういうことをし始める。

サイコロを振ってなぜ1が出なかったのか?って考えてるのと同じで正直アホだと思う。


当然実績ベースで見積もったところで結果はブレるかもしれないが、そこを気にしていてもしょうがない。

唯一精度を上げる方法があるとしたら、全ての見積もりサイズを同程度にしておく。小さくしておく。くらいしかない。(唯一のまともなアドバイス


そもそもスプリントの精度ってなんのために必要なのか、っていうと答えられないことが多いんじゃ無いかなって気はする。

スプリントが達成できたかどうかは、計画したアイテムが終わったかどうか、ではなく、計画したアイテム(と、計画していなかったけど必要だとわかったアイテム)を通じて、インクリメントが結果としてスプリントゴールを満たしているかどうかしかない。

スプリントゴールは各 PBI とは別に、それらの PBI を通じて ”どんな状態を実現したいのか” で表現されているとわかりやすいのだと思う。

作戦目標をスプリントゴールだとすれば、各 PBI はそれぞれの作戦過程における戦術目標に相当する。

戦術目標を全て満たしたとしても、作戦目標を達成するかどうかは怪しい。

なぜなら作戦立案時から状況が変わっているかもしれないし、立てた作戦が間違っているかもしれないから。

なので、戦術目標(PBI) をクリアーしながら、作戦目標を達成できるかを評価し続けないと危ない。これはデイリースクラムでやればいいと思う。

これは長そうだしいつか別に書く。多分。知らんけど。