チーム名をつける
概要
開発対象でチームを呼んでいると、チーム名に仕事が引っ張られるようになる。
詳細
機能・コンポーネント・ライブラリ名をチーム名としていると、開発対象が変化・拡大した時に混乱が生じます。 酷い場合はチーム名から類推される仕事をマネージャーが渡すようになり、仕事を用意できなくなるとチーム構成の見直しを管理職が言ってくることになります。
またフィーチャーチームを構成していると機能・コンポーネント・ライブラリでは呼ぶことが難しいです。
そこでチームメンバに考えてもらい、チーム名をつけてもらいましょう。 はじめは気恥ずかしいかもしれませんがすぐに慣れ、チームに独自の文化が根付くようになります。
参考
バグを毎日配る
概要
スクラムでスプリント区切りの開発をしているとスプリント期間中に見つかったバグの扱いに悩むことになる。 スプリント期間内で直す、プロダクトバックログにバグ修正をストーリーとして積み直すことが定石だが、各チームにあらかじめ割り振るという手もある。
詳細
背景
スプリント期間中に埋め込んだバグはスプリント期間中に修正することが大原則だが、以前のスプリントで埋め込んだバグやスクラム開始前のバグ、他の開発チームが埋め込んだバグについてはコントロールできない。 またリリース前の「リリーススプリント」では積み直す次のスプリントがないこともある。
バグの早期対処を促す方法として「バグをチームに配る」ことをして「カンバンで別管理する」ことを試してみた。
実施手順
デイリースクラム後にスクラムマスターとプロダクトオーナーが集まり、新たに見つかったバグ報告を全員で眺める。原因を想像し、適切と思われる担当チームを割りふる。担当したチームはカンバンボードにバグを追加し、メンバの手が空いたのち、最も優先順位が高いバグに着手する。バグの担当チーム割り振りは絶対のものではなく、各チームの余力やバグについて新たにわかった事象を考慮に入れて適宜再割り当てを行う。
効果
チームが対処すべきバグ総数が可視化され、チームが負荷を自分たちでコントロールするようになった。
またバグ報告から調査に入るまでの期間が短くなり、バグが発生してから修正までの期間が短く改善された。
参考
コンポーネントコミュニティー & コンポーネントメンター
概要
複数チームで1つのプロダクトを開発していると、あるコンポーネントが特定の所有者を持たないことになる。 「事前に設計をやりすぎない」というアジャイル開発の進め方と合わさるとコンポーネントの設計がぐちゃぐちゃになる。 開発チームをフィーチャーチームで構成するとコードはチームで共同所有されるため、より責任の不在が顕著に問題となる。
詳細
特定コンポーネントの設計に関する相談役を任命する。または開発に関与する各チームからメンバを選出してコンポーネントコミュニティーを設ける。あくまでメンター(指導者・助言者)であって、品質管理の門番ではないことに注意すること。
LeSS発案者のBas Vodde氏は当初「コードガーディアン」と呼んでいたらしいが、テストの不足やカバレッジの不足などコミットを阻害する品質の門番化してしまう例が発生し、呼び名を再考したとのこと。 組織やチームによって品質管理基準の達成が求められることがあるかもしれないが、コンポーネントコミュニティ・コンポーネントメンターに基準設定の役目を持たせるのであれば、関連する全チームからメンバーを選出し、担当者が不在のまま規則が決定するのを避けなければならない。
個人的には開発チームが十分に自立しているならばメンター呼びでも良いが、経験者による十分な注視が必要ならば「コードオーナー」のような呼び方も有効かもしれない。
ネタ元
複数チームでのスプリント計画
概要
LeSS(Large Scale Scrum)で行う、複数チームで1つのバックログに基づいてスプリント計画を立てる時のやり方。
詳細
第1部
プロダクトオーナー、チームの代表者1〜2名(スクラムマスターでなくてもよい)が参加し、どのチームが何のストーリーを担当するのかを決定する。やりかたは特に定められていないが、紙や付箋にストーリーをあらかじめ書いておき、早い者勝ちでチームに選んでもらうのでよい。
プロダクトオーナーやスクラムマスターは事前にストーリーをチームに割り振ることはしない。あらかじめ割り振ってしまうとチームが割り当てられたストーリーのみに注目するようになり、全体でのより良いやり方(ストーリーXはチームYがやった方が早く終わる)を考える力が弱まる。
第1部は短く終える。各チームで担当するストーリーが決まったらプロダクトオーナーが確認し、問題なければ第2部を始める。優先順に担当されてないと感じたら再度割り振りを見直してもらう。
第2部
通常のスクラムでのスプリント計画と同じ。 他チームの作業に影響があるストーリーがあるかもしれないため、全チームが近くの場所でスプリント計画を検討し、必要があれば気軽に声を掛け合えるのが良い。
FAQ
チームによってストーリーの難易度が違うので、見積もりが変わってしまうのでは?
見積もりはプロジェクト全体のスケジュールを見積もるためのものではなく、担当を決めるための参考(どのくらい時間がかかるか、スプリント期間内に終えられるか)に使うものである。チームに割り当てられた後に見積もりを正す行為は意味がない。
ネタ元
ワントランク開発 / トランクベース開発
概要
開発者が1つだけ存在する最新版(trunk/master)に直接コミットをし、ブランチを切らずに開発を行う。 ブランチを切るという誘惑に打ち勝ち、長い間最新版と離れることで発生するマージに時間がかかる問題や、コードの衝突問題が発生しないようにする。
最新版が常に統合された状態になり、マージや衝突の問題を早期に気づくことができるメリットがある。
FAQ
いつコミットするの?
良いタイミングでいつでも。1日に複数回が理想。
特定の機能追加・不具合の修正を100%完了させてからコミットする必要はなく、他の人の作業や検証を止めなければ複数の修正に分割してコミットすれば良い。
いつコードレビューするの?
コミットしてからレビューすることもできる。 コードに未レビューの修正が入ることと、ブランチの生存期間が長くなってマージ工数が膨らむことを天秤にかけて判断すればよい。
Pull Request / Merge Requestを使っているからうちは1トランク開発だよ
厳密にはブランチを切っているからワントランク開発になっていない。
開発中の機能は動かないようにしたいんだけど
フィーチャートグルのようなソフトウェアスイッチ(設定ファイルで有効化するとか)を使うとよい。
せっかくGit使っているのになんでブランチ使わないの?
必要ないなら使う必要はない。
こんなの上手くいきっこないよ
ためしにやってみて、上手くいかなかったらやめれば良い。
ネタ元
スプリントレビューに定型質問を用意する
解説
スプリントレビューに招待された人がフムフム聞いてうなづくだけだったり、大人数で質問が活発が出ないときにあらかじめ汎用的に質問を考えておき見えるところに掲示しておく。レビュー後のディスカッションが盛り上がらなかった時にそれを持ち出して話題を転換してみる。
例
- デモの内容を理解できましたか
- 10段階で評価するならどれくらいでしたか
- もっとも重要な課題を解決できましたか
- プロジェクトとして望ましい方向に進んでいますか
ネタ元
LEGOにおけるアジャイル開発のスケールアウト(Planning as a Social Event)
概要
LEGOのデジタルソリューション部門における複数のスクラムチームの方向性を揃えるための2日間のイベント開催事例の紹介。 ネタ元はPlanning as a Social Event - Scaling Agile@LEGO。
詳細
2014年のLEGOでは会社トップの施策として年単位の計画や予算配分の枠組みを策定していた。 またボトムの施策として開発チームはスクラムを適用して開発をそれぞれ進めていた。 しかし中間層(プロダクトオーナー、プロジェクトマネージャーなど)では開発の優先順位が揃わず、たくさんの打ち合わせ、メール、ドキュメント、ストレス、混乱が発生していた。
そこでチーム間での足並みを揃えるため、2015年から2日間の全体合宿(Social Event)を8週間おきに開催するようになった。
全体合宿の内訳
体育館や広い会議室、食堂のような全員が一堂に集まれるスペースを用意して開催する。 全員参加でオフショアのように普段の拠点が離れているチームは代表者のみが参加することもある。
1日目
デモ
5分間のビデオを上映し、直近2ヶ月間でリリースされた内容のハイライトを紹介する。 毎回のスプリントレビューのフィードバックとは異なる視点で、インスピレーションを与え、全体概要を把握しやすくし、自分たちがどこに向かおうとしているのかを思い出させる効果がある。
ライトニングトーク
マネージャーがいくつかの話題を紹介する。例えば「Digital Child Safety(? なんのことだろう)」、「近々開催予定のハッカソン」、「プラットフォーム戦略」など。
フィードバックを書くボードが用意してあり、次回より改善する方法を休憩時間に議論できるようになっている。
計画(Team breakouts)
普段のチームごとにホワイトボードの近くに集まり、次の数ヶ月の計画を立てる。8週間の間に予期しないことがたくさん発生するため詳細を詰めるのではなく、高レベルの計画を話し合う。 オープンスペースのように今話し合っていることから学びがなかったり、貢献できていなかったり、楽しめていないと感じた時は別の場所に移動することが奨励されている。
チームは開発項目をバックログから自発的に取得する(=Pull)。誰かが開発項目をチームに割り振る(=Push)ことはしない。過去の実績を踏まえてどれくらいできるかを元に決定する。バックログは複数チームで共有のものもあるし、専門チームは個別のバックログを持つこともある。
チームごとの計画ボードの他に、全チームで共有するリスクボードと依存性ボードがある。リスクボードは各チームの計画で見つかったリスクを付箋に書いて貼り出すもので、適切な解決の話し相手を見つけて計画中に解決したり、解決できないものは上位の管理職にエスカレーションする。
依存性ボードはチームが取り組む開発項目の依存性を可視化するものである。横軸にチームごとのレーンを作り、縦軸はスプリントごとに行を分ける。依存される開発項目(先に行うもの)は赤色、依存する開発項目(後に行うもの)は青色の付箋を使い、両者を線(紐とかマスキングテープ)で繋いで可視化する。例えば赤色の付箋が多く貼られているチームは少しの遅延が他チームに大きな影響を与え、遅延が拡大するリスクを抱えていると考えられる。チームが十分に自立していると、自然と依存性ボードの前に集まり、計画を阻害する要因について議論し、解決を促す役割を果たす。依存性ボードは全体合宿での議論だけでなく、普段の開発現場に持ち帰り、定例(Scrum of Scrumsなど)の場でリスクを再確認するためにも使うことができる。
計画の相互紹介(Draft plan fair)
計画がひと段落したらバザー形式で相互に計画を紹介し合う。時間を決め、好きな場所に移動し、計画を聞き、ディスカッションを行う。LEGOでは7.5分を4ラウンド行なっている。以前は全チーム持ち回りで発表するようにしてたが、聞いている人が飽きてしまい、ほとんどの人にとっては全チームの計画を知る必要がないと判断し、4ラウンドに落ち着いたそう。
管理職のレビューと問題解決
開発チームのメンバは帰宅し、管理職やリーダーだけが残る。 リスクボードと依存性ボードを並べた前に全員が集まり、現状課題の認識と解決策を議論する。
リスクボードにあげられた項目はROAMフレームワークを使ってすべて処理してから帰る。これは各項目をResolved(解決した)、Owned(担当を決めた)、Accepted(リスクを受け入れた)、Mitigated(軽減策を検討した)のいずれかに分類するものである。
2日目
計画の相互紹介、管理職のレビュー結果を踏まえて再度チームで計画を見直す。 LEGOでは全体合宿の進行を見直し、現在では1日で終わるようになったらしい。
ふりかえり
全体合宿の振り返りをチームごとに行う。前回よりも改善されたこと、次回改善すべきこと、全体合宿の点数を5点満点で評価する。
チームの振り返りが終わった後、スクラムマスター、ファシリテーターだけ残り、チームの振り返りさまりを改善ボードの前で共有していく。
