このページについて
Scrum Allianceの公認研修である認定スクラムマスター研修に行ってきました。
全3日制。その2日目で得た学びをまとめたものです。
※3日通しての総括編はこちら
※以下は全て個人の理解/感想であり、内容に誤りを含む可能性があります。悪しからず。
アジェンダ
- スクラムガイドの読み込み
- 個人ワークで問題作成⇒グループ内で問題を出し合う
- 良問と思うものを選抜し、他チームと問題を出し合う
- 大規模アジャイル開発（の前に）
- 局所最適のバイアス
- 依存関係の幻想
- LeSSフレームワーク説明＆ワーク
以下、個別のメモ
スクラムガイドの読み込み
読みながらガイド内の記述を答えとしたクイズを書き、皆で出し合う形式で実施。
述べ1時間半くらい使った。基本は大事。
当チームで良問と判定されたものは以下。
- スクラムチームが取るべき人数規模の範囲は？
- プロダクトバックログアイテムには「詳細」「並び順」「見積り」「（穴埋め）」の属性が含まれている。
- スプリントバックログにはスプリントゴール達成に必要な作業全てと、「（穴埋め）」が含まれているべきである。
- プロダクトバックログを作業に分解する際、適切な粒度は？
- スプリントレトロスペクティブで検査すべき４つの観点とは何か？
【回答】
- 開発チーム 3～9人＋プロダクトオーナー1人、スクラムマスター1人＝5～11人
- 価値
- （前回のレトロスペクティブで特定した優先度の高い）プロセスの改善点
- 1日以下
- 人、関係、プロセス、ツール
局所最適化のバイアス
ワークではチョコレート工場で働く人（コメディビデオ）を題材に、局所最適化している点を最低13個挙げた。
- 作業前、監督者が作業者へ「ひとつでもチョコレートの包装に失敗したらクビだ」と宣告する
- 始めて見ると、前のラインと後のラインで生産量があっておらず、後のラインの作業が詰んで行く
- 困った後のラインの人が、上司に怒られない様に処理できなかったチョコを服の中に隠し出す
- 一つもミスが無いと思い込んでいる上司は満足げな表情を浮かべる
【学び】
- 人は複雑な環境に慣れておらず、見える範囲で最適な行動を取ろうとしてしまう
- 自分のとった行動が、思わぬ時に思わぬ所であまり関わりの無い人や物事に影響を及ぼしている
- この様な盲点を局所最適化バイアスと定義している
- そのため、「何に対して」最適化をするのか？ということを考えなくてはならない
知識創造における依存関係に対する幻想
- 従来開発において、チーム間のタスクには依存関係が発生することがある
- しかし、ソフトウェア開発の様な知識創造の場において、依存関係は幻想である事に気づくべきである
【依存関係が発生する原因】
- 「コンポーネントチーム」かつ「各コンポーネント間で発生する専門的知識の差」によって発生する
- 「Bチームの認証機能の開発が終わらないから、うちのEmailパスワード機能の開発に入れません」
- 「フィーチャーチーム」がINVESTなプロダクトバックログアイテムに取り組む場合、これらの依存関係はひとつのストーリー「ユーザとしてEmail＆パスワードによる認証が出来る」という単位で扱うため、チーム間の依存関係は発生しない
ワーク中、依存関係と優先順位を勘違いした話
- ワークでプロダクトバックログを作成する中で、フィーチャー間に作成順序（＝依存関係）が存在している様に見えた
- 「①Aという機能を使える」というアイテムが出来上がらないと、「②A機能でBオプションを選択する」というアイテムが消化できないよね？という具合
- これは依存関係ではなくて、①の提供が②よりも優先されているだけだった
- ①と②が依存関係であるならば、それらはひとつのアイテムになっているべきである
1スプリントで取るべきプロダクトバックログの目安
- 4つが目安と言われている
- ひとつだと、予期せぬ不確実性によって沼にはまる危険があるため
複数チームによるアジャイル開発の基本イメージ
- 本研修ではLeSSというフレームワークを用いた
- 「集中」と「分散」を呼吸する様に繰り返すイメージで取り組むこと
- 例えばバックログリファイメントでは、POと各チームの代表がバックログを作成
- 各チームがそれぞれいくつかのバックログを持ち帰り、チーム内で細分化
- またPO+代表で細分化を並べ替え ⇒ 一旦できたネ！
LeSSにおけるスプリントプランニング
- 1チームでのスクラムと比べて、第1部と第2部をより明確に分けて取り組むことが重要
- 第1部では、「何をつくるか？」をPOと各チームの代表で議論して決定
- 第2部では、「どうやってつくるか？」を各チーム内で詳細化
あるチームではどうにもならないタスクに出会ったら
- 何とかする方法をチーム内で考える
- 他のチームから助けられそうな人を見つけ出す
- 合言葉は「まずは会話」
- 次に、具体的な対応のとり方を検討する
- 例えば、「トラベラー」「コンポーネントメンター」というアイディアが用意されている
【気を付けよう】
- スクラムマスターが「外部障害」と認識して、他チームからのヘルプを阻害してしまう可能性がある
- それはSMが部分最適に陥っていることを指す（考えを改めてもらおう）
チーム間のワークシェアを円滑にするために
- デイリースクラムに偵察に行くのも良い
- 偵察の基本スタンスは、輪の外から見る（余計な口出しは無用）
目指すべき「継続的インテグレーション」
- LeSSではブランチやPRはコミュニケーション機会の減少要素として推奨していない
- 全チームが全部マスターマージする様な環境を是とする
- 大きな1回のコンフリクトよりも、小さな複数回のコンフリクトを好ましいと考える
- この様な常に常に統合してテストしていくことを継続的インテグレーションと捉える
【「でも怖い」を乗り越えよう】
- PRによる複眼ではなく、ペアプログラミングやモブプログラミングによる複眼を推奨している
- マスターマージによるデグレやエンバグを嫌うのではなく、テストコードによる品質担保を推奨している
TDD（テスト駆動開発）
- 実装から書くのではなく、テストから書く
- 少しテストコードを書いて、少し実装を書いて・・・を繰り返す
- リファクタリングまで終わって完了である（ボーイスカウトルール！）
- まとめ：「テスト失敗」→「テスト成功」→「リファクタリング」
【心】
- 「コードを通じて他人と対話する」という表現を用いていた
- 他人が読めるようなコードを書く手心（プロセス）を忘れないことが大事
チーム間で共通のコンポーネントを開発する場合
【やってはいけないこと】
- 共通部分を抽出して「共通チーム」を結成し、集約的に開発する
- これには大きな計画や設計が必要となり、無駄な開発を伴うリスクがある
- また、フィーチャーとの依存関係が発生し、ウォータフォールへ流れて行ってしまう
【取るべき対応】
- 基本、先に手を付けたチームが先に開発すれば良い
- アーキテクチャをどうするか？ということは課題としてチーム横断的に対話していけばよい
- コンポーネントメンターという役割がその一助となる
- リファクタリングを含めた結果、最終的な姿は共通チームがやりたい姿に近い筈
テレワークとアジャイル開発
- ぶっちゃけ推奨していない（同じ拠点の方が確実に効率的という姿勢）
- 「出来る限り」同じ部屋に集まること
- 「出来る限り」同じ部屋に集まっていることと同等な環境になる様に工夫すること
- 電話やチャットツールなど言語だけでは間が詰まない（又は非効率である）ことを認識すること
- この「出来る限り」を諦めない姿勢が重要だと思った（今の自分の案件もそうだ）
質疑応答タイム
複数チームで重複したロジックをコーディングしてしまうリスクをどう考えればよいか
- LeSSにおいても「コンポーネント戦略」という概念はある
- アーキテクトにかかる約束事などはチーム間で認識合わせて進めるもの、とのこと
- 例えばAsIs勉強会を開く、メンター同士で集まって議論する、など
開発チームにおいて、どこまで個の役割を無くしていけるものか
- 先ずは隣り合うスキルセット間でタスクをシェアしていく
- デザイナとUI、UIとサーバといったコンビ間ではシェアできる部分が多い筈
- 中期的には、継続的な学習によりシェア出来る範囲を広げていく
スクラムを部分的に適用する事の是非
- スクラムイベントの目的とチームの状況を理解した上で「やらない」という選択肢を取ることは可能
- スクラムイベントを実施しなかった場合に、どんな影響が出るかをよく考えてみよう