スプリントレビューでデモしにくい時 → 551メソッド

概要

youtu.be

「UIが無い」などスプリントレビューの参加者にスプリントの成果が見せにくいときのやり方。 成果が「あるとき」と「ないとき」を明確にすることで、何が変わってどのくらい価値が生まれたのかわかりやすくする。

ネタ元

t-and-p.hatenablog.com

プロダクトオーナーはどこにいる?

f:id:tune:20181111093336p:plain

概要

適切なプロダクトオーナーを見つけることはアジャイル開発の成功のために欠かせない。 自分たちの開発形態を踏まえ、正しいプロダクトオーナーを探す努力を続けること。

詳細

3つの開発形態とプロダクトオーナーがどこにいるか

f:id:tune:20181111092418p:plain

プロダクト開発(Product development)

製品・サービスを開発し、社外の顧客へ提供する形式。多くの製品開発はこれに属する。 適切なプロダクトオーナーは社内にある事業企画を検討する部門などビジネスサイドにいることが多いが、アジャイル開発に巻き込めず開発サイドの窓口を代理のプロダクトオーナーとして立てることが多いと思われる。

社内(プロダクト)開発(Internal (product) development)

社内で使われるシステム・ツールの開発を行う。 社内システム・ツールの取りまとめ部門にプロダクトオーナーの適任者がいる。

顧客も社内の人間であり、プロダクトオーナー含めてアジャイル開発に巻き込みやすい。

プロジェクト開発(Project development)

社外から委託を受けて開発を行う。委託元の開発形態はプロダクト開発かもしれないし、社内開発かもしれない。 いずれの場合もプロダクトオーナーは開発者が所属する会社ではなく、委託元の会社にいる。

プロダクトオーナーを探す

適切なプロダクトオーナーをビジネスサイドから立てることが望ましいが、開発の最初からアジャイル開発に巻き込むことが難しいことが多々ある。この場合、主に開発サイドから、代理のプロダクトオーナーを立てて開発を開始することになる。

しかし適切なプロダクトオーナーをアジャイル開発に巻き込む努力を止めてはならない。 下記の違いに留意し、現在のプロダクトオーナーがどの位置付けなのか開発メンバが認識しておくようにする。

  • 代理プロダクトオーナー(Proxy Product Owner)
    • 適切なプロダクトオーナーは見つかっているが、多忙のためアジャイル開発に割く時間がなかったり、拠点が離れていて開発チームと密なコミュニケーションが持てない場合に立てる。代理プロダクトオーナーは本物のプロダクトオーナーと開発チームの間を行き来して開発が滞らないように協力する。
  • 偽プロダクトオーナー(Fake Product Owner)
  • 適切なプロダクトオーナーが見つかっておらず、開発サイドから立てた代理の場合こう呼ぶ。「偽」とつけることで、ビジネスサイドから本来開発を主導するべき適切な人材を探す努力を忘れないようにする。

プロダクトオーナーを育てる

プロダクトオーナーを立てるべき適切な部門を見つけることは難しくないが、プロダクトオーナーとなるべき適切な人材は見つからないことが多い。製品についてビジョンと情熱を持ち、優先順位を明確化して決断することが求められるが、全てを最初から備えた人物がいることはまずない。

その場合はスクラムマスター/アジャイルコーチがプロダクトオーナーを育てる必要がある。

ネタ元

LeSS実践者研修で学んだ。下記サイトでも紹介されている。

Product Owner - Large Scale Scrum (LeSS)

トラベラー

f:id:tune:20181110192420p:plain

概要

開発者が他のチームへ移動、または複数のチームを渡り歩き、スプリントでの困りごとを解決したり、特定の技術や知識についてチームに伝える役割を果たす。。

LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。

詳細

アジャイル開発では頻繁にチームメンバーを変えないことを良しとしている。これはメンバ構成を変えてしまうと下記のようなマイナス効果があるためである。

  1. ベロシティが測りにくくなる/振り返りの施策効果がわかりにくくなる
  2. 人が変わったことが原因なのか、開発を妨げる別の要因があったのか、たまたまなのか…
  3. チームとしての成長・成熟を妨げてしまう : 人となりの理解、どうチームに貢献するかなど互いの関係性構築がリセットされる。

一方で固定メンバで長くスプリントを続けていると問題も生じるようになる。

  1. チームがマンネリ化を感じる
  2. 特定のスーパーエンジニアにチームが頼るようになる
  3. 特定の技術・知識が特定チームに偏ってしまう。

そこで特定の開発者が別のチームへ移動し、上記の解決を図る。例えば元のチームのよかった文化や取り組みを伝えたり、別チームに不足している技術・知識の教育を行う。 一方で開発者が抜ける側のチームもどれだけその開発者に依存していたのかはっきりするため、頑張り・やる気を引き出す効果がある。

トラベラーは誰がやっても良いが、高スキルのエンジニアが担うことが多い。

ネタ元

LeSS実践者研修で教えてもらった。

スカウト

f:id:tune:20181106212753p:plain

概要

複数チームで開発を行なっていると他のチームが何しているのかわからなくなることが多い。 そこで偵察員(スカウト)を送り、情報を集めチーム間で必要な情報が共有されるようにする。

LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。

詳細

開発時に関連するチームの打ち合わせにチームを代表してメンバを派遣する。デイリースクラムや、チーム内の打ち合わせなど。 代表メンバは得た情報をチームに持ち帰り、共有する。逆に自チームの動向を聞かれる立場になるかもしれない。

関連する人全員に声をかけると打ち合わせの参加人数が増え、議論がしにくくなってしまう。 リーダー/代表者が集まって情報交換を行うとそこがボトルネックになりやすい。

スカウトを受け入れることで興味のある、手の空いている人を介して情報の共有を緩やかに行うことができる。

ネタ元

LeSS実践者研修で教えてもらった。

LeSS Conference 2018 New Yorkの発表資料

f:id:tune:20181020181708p:plain

はじめに

9月にNYで行われたLeSS(Large Scale Scrum)のカンファレンス資料がどこかで見れないか、SlideshareやSpeakerDeckをずっと探していたけど、公式サイトで公開されていた。

LeSS Conference 2018 New York - Large Scale Scrum (LeSS)

左のサイドバーにある"Program"をクリックすると、基調講演(Keynotes)と下記5種のジャンル別ページにアクセスできる。

  • Experience - Experience reports by people in LeSS adoptions
  • Experiments - Practices to improve your LeSS adoption
  • Games - Games to learn about LeSS
  • Training Snippets - Snippets of LeSS Training and reflection on them
  • Open Space

気になった資料公開されている公演

LeSS Huge at Nokia

基調講演の1つ。NokiaでLeSS/Less Hugeを導入したお話。公式サイトのCase Studyでも公開されている事例だが、時系列の組織変化が記載されている。大規模導入は年単位で変化し続けなければならず大変だというのがよくわかる。

LeSS Huge at BMW

BMWの自動運転開発でLeSS/LeSS Hugeを導入したお話。導入途中のワークショップの写真がたくさん紹介されており、当時の臨場感が伝わってくるよう。またワークショップの写真からかなり準備して移行を計画していたのかと想像できる。

Large group Product Backlog Refinement in LeSS & LeSS Huge

LeSSでのバックログリファインメントの実際をドローンでのピザ配達を手がけるスタートアップの事例を参考に紹介している。大きな事業目的から重要な最初のバックログアイテムを見つける流れが面白い。

What is our Product?

LeSSでは有期のプロジェクトではなく、プロダクトとして開発に取り組み、プロダクトの定義を大きく捉えることを推奨している。この公演では良いプロダクトの定義の見つけ方について話されている。途中紹介されている手法は講演者が考案したDiscover to Deliverというものらしい。

The LeSS Scrum Master

LeSSでのスクラムマスターのあり方を説明している。プロダクトの方向性を決めるプロダクトオーナー、プロダクトの作り方を決めるチームメンバーに対し、チームの代表がスクラムマスターではなく、チームの生産性を高く保つために組織・体制に責任を持つというのがLeSSにおける役割としてしっくりきた。

おわりに

2019年は9月にドイツ ミュンヘンで行われるらしい。公式サイトの画像にビールアイコン貼ってあって行きたい気持ちが駆り立てられる。

バックログアイテムの分割

f:id:tune:20180818100208p:plain

概要

チームのアウトプットを安定させるには、取り組むバックログアイテムが適度な大きさになっていることが望ましい。しかし新機能の実装など長い時間・大きな工数を要する開発項目が出てくることは避けられず、分割して複数スプリントにまたがって開発を行うことになる。

アジャイル開発に不慣れなチームが分割を行うと「設計・実装・テスト」や「コンポーネント1の開発・コンポーネント2の開発…・結合」のように分割してしまう。しかしこれではスプリント毎に価値を提供できる形になっていない。

分割のコツ

CRUDで分ける

ユーザ管理画面を開発するとして、作成(Create)・表示(Read)と、更新(Update)と削除(Delete)を別のバックログアイテムにする。 さらに作成と表示を別のバックログアイテムにしてもよい。

ダミーデータを使う

最初はあらかじめ用意したダミーデータを表示して、実際の読み込み部は別のバックログアイテムにする。

インターフェースを分ける

最初はCLIの開発者用ツールまでを開発し、実際の顧客が使用するGUIアプリは別のバックログアイテムにする。

非機能で分ける

最初は素朴な実装を行い、高負荷時に必要な処理(バッチ処理、キャッシュなど)を別のバックログアイテムにする。

テスト自動化のバックログを作る

f:id:tune:20180803190017p:plain

概要

通常のバックログにテスト拡充を含めると優先順位付で新機能追加に負けてしまいがちである。そこでバックログそのものをわけ、並び替えの基準も「手動テストの工数を踏まえて自動化した時のメリットが大きいもの」を優先すると良い。

詳細

塹壕より ScrumとXP」の著者Henrik Knibergが執筆当時に戻れるなら「次はこうするかな」という施策に含まれているひとつ。

単体テストを書くこと」はDONEの定義に含めることが多いが、「結合テストを用意すること」や「結合テストツールを改善すること」まで考慮したスプリント計画を立てられるチームは少ない…はず。テスト自動化に関するバックログは本来のバックログを分けることで、スプリントごとに一定の工数を割きやすくなる。(より正しくは、工数を割くことを忘れないようになる)

並び替えの基準もPOの気持ちで並び替えるのではなく、「手動テストの工数を踏まえて自動化した時のメリットが大きいもの」を優先すると費用対効果が高くなる。

ネタ元

www.ryuzee.com