LeSS Study [2015/Dec./16] 資料(公開版)

Less Study 2015/12/16 今給黎 隆 注：この後のページでの赤字や太字がscrumと違うところです

Sprint • プロダクトに1つのスプリント – 同時に行われる • 全てのチームのためのスプリントプランニング • スプリントレビュー とスプリントのふりかえり – 同時に行う必要はない！ • チームレベルのプロダクトバックログ・リファインメント

• http://lessstudy.github.io/works/mechanics/sprint.jp/sprint-planning-one.jp.html
• http://lessstudy.github.io/works/mechanics/sprint.jp/sprint-review.jp.html
• http://lessstudy.github.io/works/mechanics/sprint.jp/retrospective.jp.html
• http://lessstudy.github.io/works/mechanics/sprint.jp/product-backlog-refinement.jp.html

スプリントプランニング • 2つの部分からなる • スプリントプランニング1(What) – どのチームがどの項目を行うかを決める、すべてのチー ムが集まって行う会議体 – プロダクトオーナーから与えられた準備が整った項目の 選択や、手間取っている問題の決着のつけ方、スプリント ゴールの定義に焦点を当てる • スプリントプランニング2(How) – チームごとに分かれたミーティングで、各チームはスプリ ントの間にアイテムを「完了」させる計画を創造する – 各アイテムを「完了」させるために行う仕事の計画の創造 に焦点を当てる。各アイテムとアクションプランやタスクは、 スプリントバックログを構成する。

スプリントプランニング1における秘訣 比較的シンプルでしばしば短い会議となる よく機能させるためのいくつかの秘訣： • 参加者を制限する。 – 2つのチーム：チーム全体が参加できる。 – 2つ以上のチーム：チームごとに1人か2人の代表者を送る – スクラムマスターは、代表者となるべきではない。 • プロダクトオーナーは、プロダクトバックログの優先順位の最 も高い項目をチームに提示する。 • チームは自分たちで項目を配分する。 • 項目に関する（以前のプロダクトバックログ・リファインメン ト で解決されていない）未解決の問題があれば何でも議論 する。 • 必要に応じて、これから行うスプリントでのチーム間の調整 の必要性を議論し、マルチチームスプリントプランニング2 の 計画を立てる。

• http://lessstudy.github.io/works/mechanics/sprint-planning-one.jp/product-backlog-refinement.jp.html
• http://lessstudy.github.io/works/mechanics/sprint-planning-one.jp/sprint-planning-two.jp.html

マルチチームスプリントプランニング2 よくあること：2つのチームが似たような関連するフィー チャーに取り組んだり、異なるフィーチャーだけれども 同じコンポーネントに影響を与えるものに取り組む – 有効な対策：マルチチームスプリントプランニング2の開催 • マルチチームスプリントプランニング2 – 複数チームのスプリントプランニング2を物理的に同じ場 所で開く – チームができること • • • • 共有設計セッションを持つ いつでも他のチームに質問をする 共同の仕事を調整する 一緒に作業する他の機会を見つけ、他のチームから学ぶ – 例えば、クロスチームでのペアプログラミング

デイリースクラム (1/2) • チームごとに実施され、1チームでのスクラムと変わりはない – チームに対して、彼らがスプリントゴールを達成するために、共同責 任を持ち自己管理するための必要な情報を提供する。 – チームのための会議体であって、スクラムマスターや管理者のため のものではない。 • チームは15分間を共に過ごして、その間に各メンバーは3つの質 問に答える – 昨日、何をしたか? – 今日、何をするつもりなのか? – やろうしていることに立ちふさがるものは何か? • デイリースクラムで学んだ情報から、チームメンバーは、フォロー アップのディスカッションをデイリースクラム外にするか決めるであ ろう

デイリースクラム (2/2) • 他のチームのメンバーが観察するために加わるこ とで、デイリースクラムをチーム間の調整に使うこ とができる。 • それ以外のデイリースクラムに関係した調整技術: – スクラム・オブ・スクラム • 週に3回開催される傾向がある。 • 各チームの代表者（実際に仕事に関与しているチームメン バーであって、スクラムマスターではない）が、どのようなチー ムをまたがった調整が必要かを決めるために集まる。 • 通常、チーム間の意思疎通に関連することに焦点を当てるこ とを除いて、単一のチームでのデイリースクラムと同様の フォーマットに従う。

連携 & 統合 Coordination & Integration • スクラムの価値： 分権化を行い、中央集権化を超えて連携と統合 を自己組織化し、伝統的なプロジェクトマネジメントに見られた調 整を制御した。 • LeSSの連携と統合： 十分に混乱を回避するための境界と構造を 提供しながら、分散型の連携をサポートする方法に集中します。 – – – – – – – – まずは話す コードで会話する デイリースクラムに観察者を送り込む コミュニティとメンターを構成する スクラム・オブ・スクラム 複数チームミーティング 開拓しボトルネックを打ち破りスキルを生み出す旅行者 リーディングチーム

とりあえず話す • おそらく、チーム間で連携するための最良の方 法は、単純にチーム間で調整すること – 自己管理チームならば、どんなメンバーでも、議論す べき問題があるならば別のチームにのりこむでしょう し、それを期待する – 連携の必要があれば、他のチームに行くか電話を持 ち上げて「まずは話す」のです。 • 最悪でも、電子メールをおくりましょう。 • 調整するのに、形式だった、公式で、通常はゆっくりな、調 整メカニズムは必要ありません。立ちあがってみんなのとこ ろに話しに行きなさい。

コードで会話する • 継続的インテグレーションを採用 – 誰もが中央リポジトリのメインラインにチェックインさ れた全てのコードを持つ。 • ブランチは避けるべき不要な複雑化 – プロダクトチームの誰もが一日に数回リポジトリと同 期して、他の人のすべての変更を取得します。 – （他の人とあなたの仕事を同期するために）立ち上が り、「まずは話す」ことに遠慮する気がなくなるには！ • リポジトリを更新 • 2分ほど他の人の更新を調べる • 今の仕事と関連した部分を見る

デイリースクラムに観察者を送り込む • チームのための簡単な調整方法 – 関連の仕事をする他のチームのデイリースクラム にサイレントオブザーバーとして代表を送る • 代表はスクラムマスターでない – デイリースクラムの後、観察者がチームに報告を 戻せば、チームメンバーは、さらなる行動を取る ことができる

コミュニティとメンターを構成する • 同じ時間に同じコンポーネントで働いている人々は、質問をし たり、互いのコー​​ドをレビューするので、お互いに知っている 必要があります。 • コンポーネント実践コミュニティ（CoPs: Communities of Practice）で対応 – メーリングリスト、チャット、不定期会議、もしくは他のリモートコラボ レーション手法で交流 • コミュニティは、多くの場合、いくつかの追加の役割を持つ普 段は機能チームのメンバーである「コンポーネントメンター」が 主催 – 各コンポーネントに作業を共有する複数のメンターがいることで、 キーパーソンへの依存を減らすことができる。 • 重要！...連携を支援する以外にも、このプラクティスはコン ポーネントのコード/設計の品質を維持または向上させ、学習 を進めます。

コンポーネントメンターの役割の例 （1）コンポーネントが機能のさせ方の先生になる （2）コンポーネントの長期的な健康を観察する （3）コンポーネントコミュニティを組織する （4）設計ワークショップを組織する （5）コードをレビューする – コンポーネントのメンターは、コミット前に承認と称し てコードをレビューしてはいけない • メンターは、コンポーネントの教師と執事であって、関門で はない

スクラム・オブ・スクラム スクラム・オブ・スクラムミーティング：チーム間のデイリー・スクラムのような会議 – 典型的には週に2 〜3回開催 – すべてのチームが関与する必要はありますか？いいえ。 • 調整すべきやむにやまれぬ必要があるときにチームのサブセットで開催します。 – スクラムマスターやプロダクトオーナーでない実際の開発作業を行うチームメンバーが参加 • スクラム・オブ・スクラムの人々は、チーム間の実際の作業を調整する唯一の目的のために集まる • 通常、フォーマットは、デイリースクラムに似た3つの質問 – 他のチームに関連する、私のチームがしたことは何ですか？ – 関連することで私のチームが行うことは何ですか？ – 他のチームが知っておくべきか助けて欲しい、私のチームの障害物は何ですか？ • 当然ですが、グループが見つけた有意義な質問へと進化させて使います。 • 注意： – スクラム・オブ・スクラムを開催したいという要望は、機能横断的でないグループやコンポー ネントのチーム、でなければ、意気投合することや共有作業を行うことができなかったり望ん でいないチームによる不必要な依存関係や協調問題の徴候である可能性があります。 – また、実際のチームのリードまたはマネジャーのスクラムマスターが、「リーダーシップ会議」 と称して集まる徴候の可能性がある。それは誰かがコマンドコントロールのリーダーシップを 引き継ぐことを感じさせるように関わり、チームの自己組織化を減少する傾向があるので、 起こらないようにしてください。

複数チームミーティング • 密接に連携するチームでは、マルチチームのLeSS ミーティングを実施するのが一般的 – 他のチームが必要性を感じなくても、いくつかのチーム が密接に協力する必要があることが一般的 • いくつかの例 – – – – マルチチームのプロダクトバックログリファインメント マルチチームのスプリントバックログ2 マルチチームの設計ワークショップ デイリースクラムに観察者を送り込む

ボトルネックを突破し、打ち破り スキルを生み出す旅行者 • 旅行者：何人かの経験豊富な技術専門家 – （希少な）専門家の知識を全てチームで利用可能にする ための方法 • 各スプリントで、彼らが別のチームに参加 – ペアを組んでコーチング – ワークショップ – 教育のためのセッション開催 • 旅行者は厳密に言えば、調整のために作られたわけ ではありませんが、別のチームに参加することで、彼 らは幅広いネットワークを作成または強化します。こ れは、正に非公式の調整チャンネルに必要とされるも のです。そして、彼らはチーム横断的な知識や実践の 一貫性を高め、連携している目標を実現します。

リーダーチーム • 関連しあう大きな機能を項目に分割するために一緒に作業するチー ムを調整するための別の技術 – 一部のドメインでは、機能はものすごく大きい（巨人） • これらの巨人を小さなプロダクトバックログ項目に分割する際は、一つのモンス ターの機能を作成するために、多くのチームが緊密に協力し、それぞれのPBIに 別々に切り離すことが必要 • 巨大な全体の機能の主導的な役割をになうだけの通常の機能チーム – 開発作業を行うことに加えて、他のチームが何をしているかを追跡し、そ れらを同期する手助けを担当します。 • 要するに、開発をしている自分自身に加えて、巨人に関連するクロスチームの連 携を整理する • 開発初期 – いくつかのチームが同時に巨人の実装を開始する場合がある – それ以外は、リーダーチームは、初期知識の移転に集中し、凝集デザイ ンの作成を簡素化することを始める • いくつかのスプリントの後：より多くのチームが参加 – リーディングチームは、入ってくるチームに、リーダーチームがすでに知っ ていることを学ぶのを助けるための教育の責任も負う