less
agile
scrum
スクラム

認定LeSS実践者研修を受けてきた

More than 1 year has passed since last update.

Odd-e社主催の認定LeSS実践者研修を11/29~12/1に受けてきたので、簡単に報告します。以下の内容は研修中にもらった資料、講義中の話をベースにしています。


LeSSとは?(概要)


  • 大規模開発用のアジャイル開発フレームワーク


    • Large-Scale Scrumの略



  • 基本はスクラムで、大規模用に拡張を行っている

  • 適用範囲は2〜数百チーム(3000人規模の開発チームに導入したとか・・・)


    • 2~7チームはLeSS、8チーム~はLeSS Hugeを使う


      • LessとLeSS Hugeの違いは追加の役割とか、プロダクトバックログの作り方ぐらい(後述)





less_mind_map.jpg


認定LeSS実践者研修とは?


  • 3日間の研修

  • 講師はOdd-e代表 Bas Vodde氏(同時通訳あり)


    • LeSSの考案者の1人



  • 20人弱の参加者、3チームに分かれて1日3~4回のワークあり


    • アジャイルコーチをやっている方やアジャイル本の訳者も複数人参加



  • やったワークは以下の通り


    • 自己紹介

    • LeSSの原理原則/ルールについて疑問点の洗い出し、ディスカッション

    • 講義で学んだことをマインドマップにまとめ、アップデート

    • 開発者の能力、約束させられたfeatureの数と実際に出来たアウトプットの差に関する考察のための、システムモデルの作成

    • 実プロダクトにおける、doneの定義と技術的スコープ軸のfeature適応マップの作成

    • LeSSに関する試験問題作成



less_system.jpg


LeSSの内容


テイラーの思想


  • "単純労働者には計画やクリエイティブな仕事をさせない方が効率的であることは疑いの余地がない"


    • 教育されていない人を効率良く働かせるために、改善と計画を業務から切り離した


      • best practiceとして広まったが、開発プロセスはこうではない

      • 開発プロセスにbest practiceは存在しない






LeSSは大規模開発においてbest practiceなのか?


  • LeSSはbest practiceではない

  • 実はLeSSというフレームワークを作りたくなかった


    • フレームワークを使って何も考えずにルールに従ってほしくなかった



  • LeSSという名前が付く前に、色々な事例を紹介する本を出したが、それは経験のある人向けで、初心者向けではなかった


    • ルールを教えないと始まらないし、ルールがあると何も考えられなくなるジレンマ


      • 結果的に、事例の中で最低限共通していることを抽出してそれをLeSSと名付けた






LeSSの原理・原則


LeSSはスクラム


  • 大規模開発用のものだが基本はスクラム


経験ベースのプロセス管理


  • 既に記載した通り、これまでの大規模開発への適用を基に最低限共通した内容を抽出している


透明性


  • スクラムと同様


More with LeSS


  • LeSSを適用して多くを学び、改善を続け、スケールさせていく


製品全体思考


  • 1回のスプリントで1つの製品に向けて全力で作り上げる

  • コンポーネントチームにもつながる(後述)


顧客中心


  • 顧客の視点で価値を最大化する

  • コンポーネントチームにもつながる(後述)


完璧を目指しての継続的改善


  • ここでいう完璧とは、1つのマイルストーン的な意味合い

  • 完璧な状態になると、次のまた完璧な状態を目指す


システム思考


  • システムの全体最適化する


    • 個人や1チームの最適だけに集中しない




リーン思考


  • マネージャーは現地現物を基に改善を促進する

  • "選手を見るのではなく、ボールを見る"


    • 提供した価値に意味があり、稼働率に固執しない



  • ムダを排除する


    • 人から人への情報の受け渡しが一番ムダ



  • リーンを導入すること、LeSSを導入することを目標にするのではなく、良い製品を作る

  • 改善用チームを作るのではなく、チームが改善する


待ち行列理論


  • どこにqueueがたまっているかを知ることが大事

  • LeSSでは3つのqueueがある


    • プロダクトバックログ(着手前)

    • スプリントバックログ

    • プロダクトバックログ(新しいもの)




LeSSにおける役割


PO


  • 1プロダクトに1人


    • チームごとにいない



  • 開発の優先順位を決定する

  • バックログアイテムの詳細化は行わない


    • 大規模開発でこれをPOがやるのは無理ゲー

    • プロダクトバックログリファインメントも参加必須ではない



  • 自動化の取り組みの責務がある

  • 決して一人で働かず、助けてもらう

  • イイ人にならない


    • スプリントで完成出来なかったのなら、なぜそれが出来なかったのか振り返らせる




チーム


  • SM + 開発メンバー

  • スクラムではスクラムチームと開発チームという呼び方があるが、LeSSでは単にチームと呼ぶ

  • 長期間維持


    • 1つのチームがうまくいっているからといって、チームメンバーをバラバラにして他のチームにいってうまくいくとは限らない




SM


  • 最大3チームまで見る

  • 役割としてはスクラムと一緒


マネージャー(管理職)


  • LeSSにおいて役割として必須ではない


    • が、やらなきゃいけないことはあるw




  • 本質的な課題を知るために開発現場に行き、組織的な判断をして、開発体制の変更などを行う


    • チームへ開発内容の指示をしちゃらめええ



  • doneの定義の拡張は組織的な変更を伴う可能性があるので、マネージャーの責務

  • 組織構造が文化を変え、文化が組織構造を変える


LeSSのセレモニー


スプリントプランニング1


  • 複数チームが参加し、どのプロダクトバックログアイテムをどのチームがやるかを決定


    • 人数が多すぎる場合は、チームの代表が参加



  • プロダクトバックログアイテムの詳細化


    • バックログリファインメントで詳細化しきれなかった場合

    • バックログリファインメント~スプリントプランニングまでの間に変更があった場合




スプリントプランニング2


  • スプリントプランニング1の後に、チームごとに並列で実施

  • 複数のチームで関係のあるバックログアイテムに取り組む場合は複数チームで実施

  • スプリントプランニング2->1とは普通ならない


スプリントレビュー


  • 全チームで合同で実施


    • スクラムのスプリントレビューのようにやると、時間もかかりすぎるし、参加意識が低くなるので広い部屋でバザール形式でやるのがオススメ




スプリントレトロスペクティブ


  • 全チームで同じ時間に実施、ただしチームごと


オーバーオールレトロスペクティブ


  • システム上の問題ついての話合い

  • 複数チームに対する改善

  • PO、SM、チーム代表が参加


    • チーム代表は議題があるときのみ参加



  • スプリント中に実施するプロダクトが多い


プロダクトバックログリファインメント


  • 1つのプロダクトバックログに対し、バックログアイテムの詳細化・分割

  • 見積り

  • 参加者はチームとユーザーorステークホルダー


    • POは必須ではない



  • 4チーム以上ある場合は、オーバーオールプロダクトバックログリファインメントを実施


    • 参加者はPOとチームorチーム代表




componentチームとfeatureチーム


  • LeSSではfeatureチームを構成しなければならず、ここではなぜfeatureチームであるべきかを考える


componentチーム


  • 一般的な組織だとcomponentチームになりがち


    • Androidアプリチーム、iOSアプリチーム、サーバーチーム、インフラチームのような



  • 前提として、プロダクトバックログは価値の順になっている


    • componentチームになっていると、バックログが全体のpriorityとして何かがわからなくなる



  • どこかのチームが楽になると、作業を作ることになり、製品全体思考・顧客中心という原則から外れる


    • 事業領域への理解も少なくなる



  • 1つの機能がチームに依存してしまい、スケーリングに問題が出る


    • チーム間の調整にXXXマネージャーが必要になり、そこにqueueが溜まる




featureチーム


  • 機能単位でチームに渡すことが出来るようになるため、チームの成果がそのまま顧客価値のための成果につながる

  • チーム間で機能の関係性は無くなったが、コードの関係性は出るようになる(が、これはコミュニケーションを取れば良いだけ)


    • チームごとにブランチを作らずに、1レポジトリに対して作業する



  • チームごとにスペシャリティを持っているのが良いが、大抵チームにそのスキルが無い場合があるが、それは学習で補う


    • 必要となるスキルを速く習熟出来る人を雇うのも手



  • 顧客/ユーザーと同じ用語で会話しているか、でそのチームが顧客中心になっているか知る良い判断材料になる

  • 設計がぐちゃぐちゃになるのでは、という懸念はよくあるが、経験上featureチームの方がこの問題は少ない


LeSS Huge


  • LeSSとの大きな違いはエリアPO(APO)という存在がいるということ

  • プロダクトオーナーがバックログを作成し、要件エリアもバックログ内に定義してエリア毎に分割する


    • APOはそのエリアのバックログだけ着目する



  • タイミングによっては、エリア間で優先度問題が出る場合がある


    • 例えばエリアAに優先度の高い要件の方が多いのに、エリアAのはやり切れず、優先度の低いエリアBの方が先に完成するなど

    • その場合はチームごとエリアを移動し、そのエリアの機能を作る


      • そういう意味でエリアは固定ではなく、変動する





  • エリアの中はLeSSと同じ


LeSS導入時の注意点


  • 導入時は最初から一気に入れる


    • ただし、LeSS Hugeは関係者が多すぎるので徐々に入れていくべき



  • 1チームを複数拠点で構成するのはNG

  • チーム間のコミュニケーションは推奨する


所感


  • 実践者研修という名だけあって、認定スクラムマスターの研修と比較してより現場に近い印象を持った


    • POが忙しくなりすぎるのでバックログを整理しきれないとか、組織を変えるためにマネージャーの役割が必要だとか




  • 前のプロダクトで適用したものがかなりLeSSと近いものだったので、いろいろ悩みながら組織作りをした方向性は間違っていなかったことが認識出来たのは良かった

  • 今関わっているプロダクトが大規模化していて、スケールの問題を抱えているので、今回学んだLeSSを適用して新たな知見を得たい

  • LeSS以外のやり方はそこまで知らないので、他のフレームワークも知りたい欲が高まった