第20章 より効果的なアジャイル : 予測可能性
適切なプラクティスが選択されていれば、アジャイルプラクティスは予測可能性も大きく後押しする。(p230上部)
「アジャイルは予測ができないからダメだ」という人に読ませたい一文
図20-1が結構新鮮な気がする。スクラム現場ガイドでもこういった回答はしていない。これはマコネル視点なのか、議論をしていった末なのか、気になるな。
機能コストスケジュールの大まかな組み合わせ(中略)パラメータはどれも厳密に固定されず、少なくとも僅かな柔軟性がある
鉄の三角形(機能コストスケジュール)の話しているんやな
それは品質、コスト、デリバリー(スケジュール)じゃないかな?
CDSで鉄の三角形、品質を足して荒ぶる四天王と覚えていた記憶が…
予測可能性がものいうのはそのフィーチャーセットを厳密に定義した後であり、通常はリリースサイクルの10~30%に差し掛かった辺りである
ちなみに、基本設計の中央値は20%なので、30%っていうと基本設計がほぼおわったところみたいなイメージなんだろうな。
なるほど・・・
作業量での直接的な見積もりは、先入観と主観性の問題をはらんでいる。(p232中部)
ありそうすぎる。先入観は意図的、主観性は無意識的だと定義されているという前提において、無意識的な主観性のを補正するのは正しい知識が必要そう
個人やチームの見積りは総じて甘くなりがちだ。(p232中部)
確かにそう。自分のチームでも、時間が足りなくなることはあったけど、時間が余ることはなかった。
「早く終わらせろ」というプレッシャをかけるほど見積が甘くなる傾向にはあるなーと感じてました
実際にその状況になったことはないけれど、想像するとそうなりそうだと感じますね
ベロシティ(p233小見出しより)
もう少しこれについて学びたいのでいい本をこっそり教えて欲しいです…!
DoD(厳密な完成の定義)
チームでコントローラブルではないものがリリースまでに挟まっているとマジで死ぬ
リリースされなければ顧客にバリューを提供できていない=完成とは認めんみたいなアレとバッティングする
QAフェーズが必要だが、QAは別チームリソースなので……
DoD(Difinition of Done)
チームが技術的負債を溜め込むことがあってはならない。(p233中部)
リファクタリングが必要とかそんな感じかな…?TDDはそれにも効果的だと認識しているけど、実際どんな負債が生まれやすくて、どんな方法で解決しやすいんだろう?
従来のシーケンシャルプロジェクトの見積りとは対照的に、チームがその生産性をリリースサイクルの早い段階に実証的に調整できるようになる。(p233下部)
「実証的に」が大事そう。これば僕の解釈だけど、アジャイルは、むしろシーケンシャルよりも、実証的な面から言えば予測の精度が高い故に、予測可能性が高いとも言えそう。
図20-2
チームの平均ベロシティのバラツキと90%の信頼区間で計算すると、のあれ
やはりある程度厳密に予想できるんだな
たった数回のスプリント(今回だと5回)でここまで計算できるの、十分早い気がする(気がする)ので、ますますアジャイルでも予測はできるんだぞ!と言いたくなる
現実にはもっと凸凹していて予測できねーってよくなってましたね。
スプリントとブッ込まれるユーザーストーリーのサイズ感や、いい感じのサイズにバラせること大事
大抵は、優先順位の付け方と、Readyにできていない問題が多いと思うけど、どうなんでしょうね。Readyにできていないよねっていうのをチーム全員で無視していることは往々にしてあるなーっていう。
大反省のかたまり
1,2,1,1,2,3とあと13と8と21みたいな感じだと凸凹がなおらない
だからユーザーストーリーは大きめのポイントの方がいいのか?
1200ストーリーポイント(p235下部)
全体で幾つのストーリーポイントがあるとかってどうやって厳密に決めるんだ…?(別の章で述べられてるかもと思いつつ)
プロダクトバックログに乗っている数字の合計ですね。
乗せているならそれは合計にハネます(というぼくの認識)
アナログ管理だと頑張って手計算で集計します(そして大体間違える。計算苦手)
アジャイルコーチによっては(中略)大きなストーリーポイントや、(中略)大きなフィボナッチ数列の利用を推奨することがある。(p237中部)
単純な興味だけどkyonさんはどうしているんだろう…?(答えるのが難しければスキップで全然大丈夫です!)
1年分くらいの量かなっておもうやつなら13以下くらいで見積もってます。全部エピックで見積もる感じ。見積もり期間で30hくらいもらうけど。 kyon_mm.icon
おおさすが。。。
予測可能性が必要なときにエピックを予算として扱う(p238小見出しより)
かしこい…(感想)
わかりみ
ジャストインタイムの機能を提供する余力も残している(p239上部)
余力、本当に大事だと身に染みていろんなところで感じる。大事。
わかりみのかたまり
(前略)計画を変更することがある。それは何も悪いことではない。
ここに太字あるの、良さみを感じる…アジャイルだ…
アジャイルだー
リリースサイクルの初期にプロダクトバックログを完全に定義するには、その作業のほとんどがCynefinフレームワークの #煩雑系 に分類されることが前提となる。作業のほとんどが #複雑系 に分類されるとしたら、その作業が完了するまで推敲を完全かつ確実に行うことは不可能となる。 p18を見よう!
(前略)そのプロジェクトの予測が(たとえ理論的にであっても)可能かどうかについてよく考えてみよう。
必ずしも予測はできるものじゃないんだぞ、って言いたそう。たしかに。そりゃそうだけど、たしかに。(感想)
大納言わかりみのかまたり
検査
■柔軟性と予測可能性に関してどのようなビジネスニーズがあるだろうか。
予測可能性 : 予算承認の合意形成のために使いたい, 柔軟性 : 顧客のニーズ、セキュリティ問題、致命的なバグにクイックに対応したい
柔軟性にはニーズがあるかな、予測可能性はあんまりかも、学生だからってのがやっぱり大きい…?
事業の施策の開始時期につながるので、予測可能性はニーズがある(内製なので多少のずれが許されることが多いけど…外向けに時期を発表しているようなケースは厳しいですね。)
■あなたのビジネスには厳密な予測可能性が必要だろうか。それとも大まかな予測可能性で十分だろうか。
どちらの場合もあった。前者で規模が大きいとうまく機能しているのをみたことはない。
前者は「計画に現実を合わせる」形で対応されている気がしますねー(よくないパターン)
大まかで十分だなあ、でも、授業中はある程度厳密であってほしかったかも?
■アジャイル開発の目的がビジネスニーズをサポートすることであり、ビジネスが予測可能性を必要とする場合があることをチームは理解しているだろうか。
理解していない人はいまのチームにはいない。
基礎的なレベルが低いとやりたくてもできない、できないから考えても無駄無駄。完了直前にはいつ終わるか分かるよ、的な学習性無気力になっちゃう気がしてますね(前いたチームだと)。
そもそもアジャイルの基礎知識がない人はなぜかアジャイル=計画しない、計画しないから予測できないみたいなトンチキ見解を言い出しがちな気が(どこでその話聞いたんだろ)
これは全員が理解している(と信じたい)
理解したい
(シーケンシャル開発ですが)理解してるはず…(社外から来ていただいているメンバーにまで理解してもらえているかどうかは若干不安が残りますが。)
■エピックを予算として扱うプラクティスについて検討する。このアプローチはあなたのチームにどのような効果をもたらすだろうか。
これはすごい「ヘウレーカ!」みたいな発見があった
暗黙的にほとんどの組織はこれをやっているとおもうけど、現場の人?が認識していないことがあるなっておもう。
言語化されて「たしかにそうだわ!」と思いました。
ただ言語化した方が調整はしやすい気がしますね。マネージャー間の「握り」みたいなあやふやな言葉にしないほうがいいと思ってます
すごいアイデアに思えたけど、たしかに冷静に考えると絶対やっている
エピックがないので大して効果ない…?エピック作った方がいい…?エピックの代わりになる何かがある…?誰か教えて…!
エピックは大事ですよ。でないとどのユーザーストーリーを落としていいのかわからなくなる
■ポートフォリオに含まれているプロジェクトのそれぞれをCynefinフレームワークに従って評価する。チームが見積もりを要求されている作業は本質的に複雑系に分類されるものだろうか。
Cynefinのどの位置に該当するのかいつも曖昧だなってなっているので、あまり確信をもてていない。
↑に全く同じ
PBI単位でやってみると大体煩雑か単純かなあ
適応
■予測可能性に対するビジネスニーズについてチームと話し合い、(それがビジネス側にとって重要な場合は)なぜ重要なのかを説明する。
そこそこした記憶が蘇るけど、各メンバーと2回ずつくらいな気がする。
したことがなかった。。
よくやるんですが
マネージャー「だいじなんだよー」部下「予測できないよー」ぼく「今はそれ以前の段階っすねー」
で終わる気がしてます(高い精度で予測できる段階まで進められたことがない)
ビジネスニーズはうーん…とりあえず一回話を出してみるか
■複雑系に分類されるプロジェクトをそれぞれ煩雑系のプロジェクトに変換できるかどうかについて評価する。複雑系に分類されたままのプロジェクトについては、予測から調査に焦点を切り替える。
有用な視点ではあるけど、議論が自転車置き場問題みたいになってしまうこともあるので、そのときには「これはこうできないっていう話ですね」って誰かが話を打ち切る必要があるんだが、そういうハンドリングできないチームとかマネージャー達で構成されていると大変。
わかりみのかまたり
複雑系だと信じ込んでいてただスキルが足りないだけな場合がかなりあったので、この戦略を取るといいのか悩ましい。。
わかりみのおおきいかたまり
これは大丈夫そう…?
■アジャイルプラクティスの使い方を改善し、エピックを予算として扱うなど、予測可能性に対するビジネスニーズをうまくサポートすることをチームに要請する。
安定的にプログラミングする、デザインする、テストをし、徐々に改善していくということが最も優先順位が高いことをPOやスポンサーが示すことって大事だなって思う。ただ、最初の一歩を間違うとレガシー環境(マイナス環境)からスタートになってしまうような場面もあるので、そこそこできるアーキテクトとか、デザイナーとか、コーチって重要だなっておもう。なので、社内?でSME(Subject Matter Expert)に手伝ってもらえる環境って大事なんだなーっていう。
コーチがいるといないとで全然違いますねー。
技術的にやってみせてくれるアジャイルコーチが非常に欲しい
腕のいいアジャイルコーチがいても実は受け入れ側のチームの受容可能な能力がキャップになってしまうケースが多々あり……
本当に入門編で終わってしまって導入した=完了のチームはよくみます
ジョニーさんがコーチだったのになー
要請してみよう!