Running agile programs (without losing your mind)

アジャイルへ移行すると全体像が見えなくなると考える人々がいます。これにはまったく同意できません。

Dan Radigan Dan Radigan

アジャイル開発の早期導入者は、小規模な、自己完結型のプロジェクトで作業する小規模な、自己完結型のチームでした。これらの人々によって、アジャイルモデルが実用的で、世界中のソフトウェアメーカーに喜びと改善をもたらすことが証明されました。最近では、大規模な組織が単一のチームやプロジェクトを越えてアジャイルを拡大しており、全プログラムに適用する方法を探しています。 

これには課題がないわけではありません。ただし、それは行うことができないという意味ではありません。しかし、まず、オンライン ファッション小売業者の Gilt がアジャイルを使用してビジネスをどのように変えたか聞いてみましょう。

ウォーターフォール対アジャイル

アジャイルの特長など、基本的なところから始めましょう。 

従来のプロジェクトマネジメントのスタイルは、ウォーターフォール型のようにフェーズで構成されています。以下は、標準的なウォーターフォール型プロジェクトの図です。この製品開発のスタイルは、あらゆるものを同時に一括して単一の製品に盛り込む「ビッグバン」アプローチで、リスクの高いリリースとなります。プロジェクトが1つのフェーズを終えると、チームは必ず次のステージに押しやられるため、戻るには手間がかかります。

Waterfall release example | Atlassian agile coach

従来のプロジェクトマネジメントのスタイルでは、「クリティカルパス」を作成することがよくあります。この場合、プロジェクトは進行を妨げている問題が解決するまで先に進めません。さらに言えば、エンドカスタマーは製品が完全に完成してからでないと製品に触れることができません。このため、製品の設計上の重要な問題とコードは、リリースされるまで明らかになりません。

Let's contrast that with an agile project management style, which takes an iterative approach to development with regular feedback intervals. These iterations allow for the team to be diverted to (and productive in) another area of the project while a blocking issue is resolved.

Agile project management example | Atlassian agile coach

イテレーションによりクリティカルパスを取り除き、開発中の製品に触れることができる。

その結果、チームは持続的にビルド、デリバリー、学習、調整を行う機会を得ます。市場の変化に足をすくわれることなく、チームは新しい要件に迅速に適応できます。

An even greater benefit is shared skill sets among the software team. The team's overlapping skill sets add flexibility to the work in all parts of the team's code base. This way, work and time isn't wasted if the project direction changes. (For more on that, see our article on building great agile teams.)

優れたアジャイルプログラムを作成する方法

When a program transitions from traditional project management to agile, the team and the stakeholders must embrace two important concepts:

  • プロダクトオーナーは、開発チームの成果の価値を最適化することに集中します。開発チームは、最も重要な作業を最優先に位置付けるプロダクトオーナーを信頼します。
  • 開発チームは余裕がある場合にのみ作業を受け入れることができます。プロダクトオーナーがチームに作業を強いたり、独断的な締め切りを課すことはありません。開発チームは、新しい作業の受け入れが可能になったとき、プログラムのバックログから作業を取り出します。

アジャイルプログラムが反復して作業の編成、実行、構成を行う仕組みを調べてみましょう。

ロードマップ

roadmap outlines how a product or solution develops over time. Roadmaps are composed of initiatives, which are large areas of functionality, and include timelines that communicate when a feature will be available. As the program develops, it's accepted that the roadmap will change–sometimes subtly, sometimes broadly. The goal is to keep the roadmap focused on current market conditions and long-term goals. 

製品要件

Each initiative in the roadmap breaks down into a set of requirements. Agile requirements are lightweight descriptions of required functionality, rather than the 100-page documents associated with traditional projects. They evolve over time and capitalize on the team's shared understanding of the customer and the desired product. Agile requirements remain lean while everyone on the team develops a shared understanding via ongoing conversation and collaboration. Only when implementation is about to begin are they are fleshed out with full details. 

バックログ

The backlog sets the priorities for the agile program. The team includes all work items in the backlog: new features, bugs, enhancements, technical or architectural tasks, etc. The product owner prioritizes the work on the backlog for the engineering team. The development team then uses the prioritized backlog as its single source of truth for what work needs to be done. 

アジャイルのデリバリー原動力

Agile can be implemented using various frameworks (like scrum and kanban) to deliver software. Scrum teams use sprints to guide development, and kanban teams often work without fixed work intervals. Both frameworks, however, use large delivery vehicles like epics and versions to structure development for a synchronized release cadence out to production.

Agile metrics

Agile teams thrive on metricsWork in progress (WIP) limits keep the team, and the business, focused on delivering the highest priority work. Graphs like burndown and control charts help the team predict their delivery cadence, and continuous flow diagrams help identify bottlenecks. These metrics and artifacts keep everyone focused on the big goals and boost confidence in the team's ability to deliver future work. 

信頼で進行するアジャイル

アジャイルプログラムは、チームメンバー間にハイレベルの信頼がなければ機能しません。特定のプログラムと製品にとって何が適切なのかという難しい話し合いをするには、率直さが必要です。会話は一定の間隔で生じるので、アイデアと懸念は定期的に示されます。つまり、こうした会話の間に行われた意思決定を実行するためには、チームメンバーがお互いの能力 (と意欲) も信頼している必要があります。

In summary, agile development is a structured and iterative approach to making software. It gives you the ability to respond to change without going off the rails. And that's good news for any program.