健全なエンジニアリング チームになるためには、自己組織型チームであることも重要です。つまり、役割と責任が明確であり、よく練られた計画を使用してプロジェクトの遂行に取り組んでいるチームです。
昨年、私たちは Micros Scale という新しいチームを結成しました。このチームは、アトラシアン社内の開発者エクスペリエンス プラットフォームであるサービスとしてのプラットフォーム (PaaS) の構築を担当しました。作業スコープが固定されており、タイムラインが明確であったため、私たちは段階的に作業を遂行するよう努め、焦点を絞り、目標志向で、積極的に取り組むようになりました。
しかし、以前のチームでは、臨時のオペレーション作業が多く、スプリントを適切に計画できませんでした。チームのキャパシティの少なくとも 55 パーセントが、現状を維持するためのローテーション (KTLO) に割り当てられていました。そのため、当時は、カンバンが私たちにとって最も適した手法でした。
タックマン モデルによると、Micros Scale チームは形成期にあり、キャパシティ計画、スプリント計画、目標設定、チームのふりかえり、グルーミングとストーリーの精緻化、見積もり、プロジェクトの内訳など、いくつかの改善すべき点があったことは注目に値します。
私たちに適していたアジャイル手法
Micros Scale には、非常に複雑で、お客様に期限が公表されている 2 つの主要なプロジェクトがあります。つまり、迅速にリリースすることが非常に重要です。私たちはデリバリー アプローチに自信を持ち、アジャイルのプロとして計画に取り組みたいと考えていました。そして、チームが自己組織化し、共通の目標を達成し、経験に基づいて行動して欲しいと考えていました。
アジャイル アプローチを再評価するために、次の質問をしました。
- イテレーションごとに目標を設定して、独自のテーマを持つ目的を達成することはできるか?
- 1、2 週間、成果物のスコープに取り組むことはできるか?
- 取り組む必要のある要件を精緻化して固めることはできるか?
- タスクの優先度を変える必要がある臨時リクエストの頻度は低いか? また、大きな変化が起こる可能性は低いか?
- チームは新設されたばかりで、まだアジャイル プロセスに慣れていなか?
これらの質問に対する答えが「はい」だったため、私たちのチームにとって最適なアジャイル手法はスクラムであることが分かりました。決断の参考にした、その他の詳細は以下のとおりです。
| | | | |
|---|---|---|---|
| アジャイル手法 | 内容 | 有効ですか? | それはなぜですか? |
| スクラム | スクラムは明確なロードマップの作成と作業の優先順位付けを行うもので、カンバンはチームに対して臨時に提起される作業を視覚化するものです。 | はい | 事前定義された明確なバックログがあり、それらの改善と優先順位付けが必要です。以前のチームでは、優先度が高い想定外の作業が数多くありましたが、今は予測可能になりました。 |
| スプリント中にストーリーを変更すべきではありません。 | はい | より柔軟なアプローチが取れます。この場合は、スクラムバン (スクラムとカンバンのハイブリッド) です。 | |
| スクラムは、まだ機能主導型を学習中であるアジャイル チームにとって採用しやすい手法です。ルールが細かく決められており、脱線を防ぐための日課やタイムボックスがあります。 | はい | 新しいメンバーで編成された私たちのチームはまだ形成期から混乱期にあり、スクラムを採用することでさらに成熟できます。タックマン モデルをご覧ください。 | |
| カンバン | 進行中の作業を制限し、プロジェクトのサイクル期間を短縮することに重点を置きます。チームに作業の時間制限がなく、確約されたタイムラインがない場合に適しています。チームが受け取ったリクエストは、できるだけ早く処理されます (サービス デスク チームの SLA と同様)。 | いいえ | 他のチームが私たちに依存しているため、推定タイムラインを作成し、それに応じて他のチームが計画を立てられるよう支援する必要があります。一部の取り組みについてはアトラシアンのお客様に公表されているため、それを念頭に置いて計画を立てる必要があります。サービス デスクのような短時間のリクエストはあまりありません。 |
| 優先度や規模が異なる運用上のリクエストが大量に寄せられるチームに最適です。 | はい | 私たちには KTLO の負荷があまりなく、そのワークストリームはチーム内の 1 人の役割によってローテーションで管理されています。必要であれば、その面倒な役割をカンバンとして実行できます。 |
スクラムの採用
私は、エンジニアリング マネージャーの主な特徴の 1 つは指揮者のように振る舞うこと、さらに、コネクター、コンパス、コーチとなることであると十分に認識しています。ですから、指揮者としての能力を嫌でも鍛える必要がありました。以下に、私がどのようにしてこの目標を達成したかを説明します。
アジャイルについて詳しく学ぶ
アトラシアンの社内学習リソースは、アジャイル プラクティスのスキルを向上させるのに役立ちました。私は広範囲にわたるアジャイル コースを受講し、アジャイル コーチに指導を求めました。数人のエンジニアリング マネージャーから話を聞いて、他の組織やチームでの経験について学びました。
DACI を使う
DACI 意思決定フレームワークを採用して (DACI は「推進者、承認者、貢献者、報告先」を表す)、グループの意思決定を効果的かつ効率的に行いました。DACI の変更提案をチームに説明することで、チームからのコメント、同意、サポートが確実に受けられました。
スプリント テンプレートを使う
スプリントを管理するプロセスを考え、各スプリントのテンプレートを作成して、より合理的な計画に役立てました。スプリント計画テンプレートには次の内容を含めました。
- 達成したことを明確にし、それを祝うために、前回のスプリントを見直す方法。
- 前回のスプリントをふりかえり、学んだことを次のスプリントに適用する方法。
- スプリントの期間、名前、目標、目的。
- 完了することを確約しているストーリーの数。スプリントのスコープ。
- メンバーの空き状況に基づいてキャパシティ計画を行う方法。
- 次のスプリントに向けて十分に準備するためにスプリント中に実行が必要なアクティビティ。
- ストーリーの書き方、要件の精緻化の仕方、そしてそれに取り組むための解決策。
- 取り組んでいるストーリーの状態を追跡する方法と、未完成のストーリーをどうするか。
スクラムへの移行には価値があった
スクラムに移行したことで改善された点は、以下のとおりです。
ベロシティの向上
アジャイルでは、チームの生産性を測定する要素の 1 つがベロシティです。ベロシティは、スクラム チームがスプリント中に完了する平均的な作業量です。私たちは、ベロシティ チャートを使って、チームが何に取り組み、何を完了したかを把握しています。下のベロシティ チャートのグレーの列は、キャパシティに基づいてチームが取り組んだストーリー ポイントの数を示しています。グレーの列を青い列と比較します。青い列は、実際に完了したストーリー ポイントの数です。このチャートを使って、チームは将来のスプリントの予測を調整できます。
リスクの早期特定
リスクを早期に特定し、解決策を考案することが、プロジェクトの成功の鍵です。
私たちは目標とスプリントのテーマを定義することで、目標達成に密接に関連するストーリーを選択しました。スプリント中のセッションでは、チームでストーリーを整理し、改良し、精緻化しました。精緻化を行うときは、次のように質問しました。
- 実行するべきタスク
- なぜこの作業を実行するのか?
- それはどのようなビジネス価値をもたらすのか?
これにより、依存関係を特定して、影響の大きいチケットを優先することで、障害を排除できました。また、プロジェクトごとに働き方を変え、チームのフォーカスを向上させることができました。
祝! リリース
キャパシティ計画と目標設定は、大きなモチベーションをもたらした一方で、取り組みに対する透明性を保つという課題を投げかけました。私たちは、アトラシアンの PaaS アカウント シャーディングの重要なフェーズを 1 つ正常にリリースしました。また、信頼性、耐障害性、コンプライアンスを高めるために、より多くの AWS リージョンを対象とするデータ レジデンシー プロジェクトのフェーズ 1 がもうすぐ完了しそうです。
形成期から統一期へ
上で述べたように、Micros Scale チームは比較的新しく、タックマン モデルでいう形成期にあります。
チームの統一された目標を定義したことで、その目標を達成し、モチベーションを高めるために、全員が足並みを揃え、支え合うようになりました。私たちは失敗し、ふりかえり、学び、そして改善していきました。3 か月半後、Micros Scale のメンバーの数は 50% 増えましたが、私は今でもこのチームは統一期にあると考えています。
コミュニケーションの改善
スプリントごとに計画を立てて献身的に取り組むことで、チーム全体を念頭に置いた計画に対する可視性が高まり、互いに分かり合えるようになりました。エンジニアリング マネージャーや関係者は、プロジェクトの障害や進捗状況をずっと簡単に追跡できるようになりました。
アジャイル手法の選択方法
- 問題を見つけたら、ためらわずにプロセスを見直しましょう。人、プロセス、ツールなどについて、アジャイルに考えましょう。
- チームのプロジェクトと責任を評価して、チームに最適なアジャイル手法を見つけましょう。アジャイル手法の詳細については、カンバンとスクラムの比較ページをご確認ください。
- スクラムに移行する場合は、Jira スクラム ボードを使用するか、Confluence またはお気に入りのツールでテンプレートを作成することをお勧めします。
スプリントごとにスプリント計画ページを作成して、前回のスプリントをふりかえり、チームのキャパシティとスプリント目標に基づいて次のスプリントを計画しましょう。以下は、私個人の Confluence テンプレートです。
以下は、全体的なスクラム テンプレートに含まれている私のキャパシティ計画テンプレートです。
また、以下は、私のスプリント目標とスコープ テンプレートです。
スプリント中は、別のページを用意して、過去 1 週間のチーム パフォーマンスを追跡したり、スプリントの現在の進行状況を考慮して次のスプリントにどのストーリーをロール オーバーする必要があるかを追跡したり (グルーミングと呼ばれる)、グルーミングしたストーリーを精緻化したり (ストーリーのリファインメント) すると便利です。以下は、私がスプリント中に使用しているバックログ グルーミングとリファインメントのテンプレートです。
チームはそれぞれ異なるため、私たちにはうまくいったことが他のチームでもうまくいくとは限りません。スクラム、カンバン、またはスクラムバンやカンプランのように両方を組み合わせたものの方が適しているかもしれません。チーム固有のニーズを評価し、どのような手法がチームにとって有効かを理解することが重要です。
