CSM研修初日メモ
ちゃんとした感想は２日間通してからしっかり書きたいと思いますが、帰ってから調べ物をしたので備忘録的にブログに残します。
今日はCSM研修に行ってきました。スクラムアライアンスのページ
ちなみに、調べてみるとCSM研修は東京だけでなく、今日だけでもコロンビア（米国メリーランド）、コロンバス（米国オハイオ）、ミュンヘン（ドイツ）、ヘルシンキ（フィンランド）、ルクセンブルク（ルクセンブルク）、サンデー（米国ユタ）、ボストン（米国マサチューセッツ）、サンパウロ（ブラジル）、マーカム（カナダ）でも開催されているようです。
心に残ったことはいっぱいあったのですが、
「バグは開発ラインを止めて、今すぐ直せ！っていうけど、そんな時間なかったらどうするの？」
的な質問が参加者から出た際に、講師がいろいろと回答された中に「Illegitimus Non Interruptus」を調べてみてくれと言っていたので調べてみました。
恐らく、このページのことだと思うので、自分的メモ（超意訳）を残します。
「Illigitimus non interruptus」（不法に中断させない）
これ、意訳難しいですね。。英語じゃないし。個人的には「不法介入に負けない！」が可愛いかなと思ったり。。ｗ
■背景
1968年にサイエンスジャーナルで発表された「The Tragedy of the Commons,（コモンズの悲劇／共有地の悲劇）」、このジレンマは、誰にとっても明らかに長期的な利益（感心）じゃない場合でも、複数の個人が各々の利益のために合理的かつ独立して自らをコンサルティングしていると、最終的には共有リソースの消費を始めてしまう、といったものです。
■問題
スクラムチームはまれに優先順位の変化や様々な障害でスプリントを中断されてしまいます。要因は、経営の干渉、市場の変化、チームの慢性的機能障害、繰り返される失敗スプリントなど様々です。
■フォース
スクラムチームとは何かについては割愛します。
未熟なプロダクトオーナーシップにさらされたチームは、競合する優先順位やプロダクトバックログ外のものが届けられます。
そんなプアな組織（会社？）で、既にリリースされているにも関わらず緊急な修正を要する欠陥を作り続けている場合、ほとんどすべてのケースにおいて、特別なメンテナンスチームを組むことは、杜撰なコードとより多くのバグを生むだけなので、ドッグフーディングをするスクラムチームを有するべきである。
■解決
延長（増加、再割り当て）を許さない「割り込み用時間」を設ける。
例えば、自己組織化のために３つの簡単なルールを設けて生産の中断を抑止します。
- チームは過去の実績に基づいてバッファ（割り込み枠）を設ける。例えば予期しない作業が平均30％の場合、ベロシティが60グミのチームなら20グミを割り当てます。
- すべての要求（割り込み要求も）は優先順位付けのためにPOを通します。POはビジネス価値の低いいくつかのPBIの優先順位を下げます。
- 例えばバッファオーバーフローの脆弱性が発見されたなどで割り込まれたものが、割り込み枠を超える場合（上の例なら20グミ以上）、チームはその受け入れを拒否しスプリントの再計画をします。
ちなみに、この割り込み枠はバグ修正や緊急割り込みに充てるだけでなく、スプリントの一環として技術的負債の返済などにも充てられます。ただし、この枠にベロシティの50％以上充てることは常識的に考えてもあり得ません。
また、POは将来の収益創出と顧客満足向上を考慮してこの枠の大きさを調整していきます。
■結果として得られる背景
これらのルールのおかげで、チームは失敗スプリントを避けるために自己組織化されるようになります。さらに良いことに、結局割り込み枠を使わなくなった場合に、計画を前倒しにできたり障害リストの除去ができたりします。
以上。
上記のことは、幸いにもコーチに教わっていたので親切でない意訳になっているかも知れませんし、そもそも間違った訳かも知れませんが、一日研修を受けてぼーっとしている状態で書いたものなのでご容赦ください。ｗ
