カンプラン: バックログとカンバンのミックス方式

アジャイル チームのためのアジャイル フレームワークを選択する上で、常に確実な解決策はありません。カンバン、スクラム、またはその 2 つを組み合わせたスクラムバンやカンプランのどれを使用するかにかかわらず、アジャイルはチーム プロセスです。各チームが、優れたソフトウェアを計画、追跡、リリースする方法の基盤として、どのフレームワークが最も効果的かを判断する必要があります。

カンバンの目的は、チームが全力で作業できるように適切な作業量をチーム メンバーに割り当てることです。カンバンではボードの内容が最優先事項になるため、チームにとっては計画の柔軟性、明確な焦点、完全な透明性というメリットがあります。ボードの内容が、開発者の作業事項です。カンバンは、優先事項が変化する継続的なデリバリーが重視されるオペレーション チームに適しています。

一方、スクラムでは、スプリントと呼ばれる長さが決まった一連のイテレーションに作業が分割されます。スプリントで計画された事項が、チームの最優先事項になります (特定の機能や機能グループなど)。通常、明確なロードマップや優先作業がある製品チームにはスクラムが最も適しています。

ただし、スクラムとカンバンを組み合わせることで最も大きな効果が上がるチームや、スクラムからカンバンに移行しようとしているチームもあるかもしれません。そのようなチームに最適な手法が、スクラムバンです。このミックス方式はさまざまな方式で実践されますが、スクラムバン チームで最も一般的なトレンドとなっているのが、スクラムのスプリントとバックログ、およびカンバンの WIP 制限とサイクル期間を使用する方式です(注: サイクル期間とはチームのワークフローにおけるタスクの所要時間です)。

反復的な作業を希望しないものの、バックログ グルーミング機能を必要とするチームはどうすればよいでしょうか? Jira のカンプラン (またはカンバン バックログ機能の有効化) が答えかもしれません。

カンプランは、アジャイルソフトウェア開発のミックス手法の 1 つです。スクラムバンと同様に、スクラムとカンバンの両方の機能が組み合わされます。カンプランは、バックロググルーミングが必要であるものの、スプリントでの作業を望まないチームに最適です。

Atlassian のビルド エンジニアリング チームは、Atlassian ソフトウェアのビルド、テスト、デリバリーに使用されるプラットフォームを担当しています。開発者は、信頼性の高いインフラストラクチャとスピードに優れた継続的インテグレーション (CI) を採用しています。4 年前には 1 か月のビルド数はおよそ 21,000 でしたが、現在は 150,000 を超えています。

この増加を可能にした要因として、チームの拡大、Subversion から Git への移行、自動テストと、それほど目立ちませんがスクラムからカンバンへの移行が挙げられます。ビルド エンジニアリング作業の特性 (随時行われるリクエスト、インシデント、イノベーション作業) とスクラム フレームワークは相性が良くなかったため、チームはスクラムバンの導入を決定しましたが、スプリントでの作業が好まれなかったため、すぐにカンバンへと移行しました。しかし結局、カンバンもチームが望んでいた特効薬ではないことが明らかになりました。多くのチームと同様に、このチームもカンバンを成功させようと試みました。1 つのボードから複数のボードに切り替え、サポート エンジニア ボードやプロジェクト作業ボードなども使用し、それぞれ異なるワークフローを導入しました。しかし、どのようなボードを使用した場合でも、共通する最も大きな問題がありました。それは、あるチーム メンバーが「不毛地帯」と呼んだ、作業可能モードに移行する必要があるものの、優先度が決定されていない課題です。「進行中」列にある課題にはチームが対処できますが、不毛地帯の「To Do」列にある課題は放置されてしまうのです。

ビルド エンジニアリング チームは、毎日のスタンドアップと週次計画ミーティングで、中身が膨大で整理されていない To Do リストに対処しようとしました。しかし、本当に必要なのはミーティングを増やすことではなく、バックログでした。

従来、カンバン ボードにバックログ機能はないため、プロダクト マネージャー、開発マネージャー、チーム リーダーは 1 列目の課題を計画に使用します。このリストの中身が増えるにつれ、課題を把握し、優先順位を付けることが難しくなります。ビルド エンジニアリング チームは作業領域に基づいてボードを分割しましたが、それでも統合されたチーム ボードは大きすぎるままでした (何度もスクロールしなければいけない)。

そこで Jira チームは、チームやボードを再編成するさまざまな手法を考えたり、ゼロからやり直したりするのではなく、カンバンにバックログを導入することを決定しました。カンプラン機能により、課題がリストビューで表示され、列の幅が広いバックログが導入されました。これにより、カンバン ボードが 2 つの異なる画面に分割されます。1 つはバックログ グルーミング用のバックログで、もう 1 つはエンジニアリング チームがタスクの選択や移動をして、ワークフローを進めるカンバン ボードです。

この機能は、Jira におけるスクラム ボードのバックログと変わりません。たとえば、サイドバー内のバックログ アイコンをクリックすると、幅の広いバックログ課題の列が表示されます。バックログ グルーミングを実行した後、課題をワークフローの次のステップにドラッグ & ドロップできます。

このように、スクラムのバックログ画面とカンバン ボードを組み合わせると、スクラム ボード バックログのように 1 つのアジャイル ボードとして機能します。課題をクリックすると課題の詳細ビューが表示されます。課題の詳細ビューなどの目的を絞ったビューにより、各チーム メンバーが集中してより迅速にタスクを実行できます。

最後に、エピックや割り当て済みバージョンを使用してリリースを整理する非スクラム チームは、課題の表示やクイック編集など、スクラム ボード内のツールを利用できます。このシンプルかつすばやい編集により、プロダクト マネージャーや開発マネージャーなど、計画モードで作業するすべてのユーザーがエピックとバージョンを効率的に管理できます。

カンプランは、あるお客様が述べたように「2 つの手法の長所を組み合わせた」手法です。進行中のスプリントなしでカードを移動させ、バックログにタスクを入力して計画を改善できます。これによってアトラシアンのビルド エンジニアリング チームを悩ませてきた「不毛地帯」は排除され、カンバン チームはこれまでのカンバンには存在しなかった計画モードで作業できるようになりました。また、必要な作業に求められる基盤としてカンバン、スクラム、スクラムバンのいずれにもピンとこなかったチームにとって、カンプランは新たな作業手法となります。

カンバン ボードで計画モードを使用することで、カンバンに慣れていないチームも、慣れているチームも、自分のチームには適していない可能性があるベスト プラクティスに従う代わりに、このアジャイル フレームワークを利用する方法を見つけ出せます。アジャイル開発の目的は、ベスト プラクティスの先を行く継続的な改善であることを思い出してください。