tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

トラベラー

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

チーム名をつける

f:id:tune:20180629083122p:plain

概要

開発対象でチームを呼んでいると、チーム名に仕事が引っ張られるようになる。

詳細

機能・コンポーネント・ライブラリ名をチーム名としていると、開発対象が変化・拡大した時に混乱が生じます。 酷い場合はチーム名から類推される仕事をマネージャーが渡すようになり、仕事を用意できなくなるとチーム構成の見直しを管理職が言ってくることになります。

またフィーチャーチームを構成していると機能・コンポーネント・ライブラリでは呼ぶことが難しいです。

そこでチームメンバに考えてもらい、チーム名をつけてもらいましょう。 はじめは気恥ずかしいかもしれませんがすぐに慣れ、チームに独自の文化が根付くようになります。

参考

qiita.com

バグを毎日配る

f:id:tune:20180622155643p:plain

概要

スクラムでスプリント区切りの開発をしているとスプリント期間中に見つかったバグの扱いに悩むことになる。 スプリント期間内で直す、プロダクトバックログにバグ修正をストーリーとして積み直すことが定石だが、各チームにあらかじめ割り振るという手もある。

詳細

背景

スプリント期間中に埋め込んだバグはスプリント期間中に修正することが大原則だが、以前のスプリントで埋め込んだバグやスクラム開始前のバグ、他の開発チームが埋め込んだバグについてはコントロールできない。 またリリース前の「リリーススプリント」では積み直す次のスプリントがないこともある。

バグの早期対処を促す方法として「バグをチームに配る」ことをして「カンバンで別管理する」ことを試してみた。

実施手順

デイリースクラム後にスクラムマスターとプロダクトオーナーが集まり、新たに見つかったバグ報告を全員で眺める。原因を想像し、適切と思われる担当チームを割りふる。担当したチームはカンバンボードにバグを追加し、メンバの手が空いたのち、最も優先順位が高いバグに着手する。バグの担当チーム割り振りは絶対のものではなく、各チームの余力やバグについて新たにわかった事象を考慮に入れて適宜再割り当てを行う。

効果

チームが対処すべきバグ総数が可視化され、チームが負荷を自分たちでコントロールするようになった。

またバグ報告から調査に入るまでの期間が短くなり、バグが発生してから修正までの期間が短く改善された。

参考