There’s innovation in Linux. There are some really good technical features that I’m proud of. There are capabilities in Linux that aren’t in other operating systems.

—Linus Torvalds, creator of Linux

フィーチャーとケイパビリティ

フィーチャーとは、ビジネスバリューを提供し、ステークホルダーのニーズを満たし、ひとつのPIでアジャイルリリーストレインによってデリバリーできるサイズのソリューション機能を表します。

各フィーチャーにはベネフィット仮説と受け入れ基準が含まれており、単一のアジャイルリリーストレイン (ART) によってPIでデリバリーできるよう必要に応じてサイズ変更または分割されます。

ケイパビリティは、大規模ソリューションの機能を表し、その実装はしばしば複数のARTにまたがり、ひとつのPIでデリバリーできるサイズになっています。

フィーチャーは、リーンUXプロセスモデルにも適しており、これには市場に出せる最小限のフィーチャー (MMF)、ベネフィット仮説、および受け入れ基準の定義が含まれます。 MMFはスコープと投資を制限し、アジリティを強化し、迅速なフィードバックを提供します。ケイパビリティは、フィーチャーと同じように動作しますが、より抽象度が高く、大規模なソリューションの定義と開発をサポートします。

詳細

フィーチャーとケイパビリティは、ソリューションのバリューを定義し、プランニングし、実装する上で重要です。図1は、これらの作業項目の広範なコンテキストを示します。

図1 SAFeコンテキストにおけるフィーチャーとケイパビリティ

図1は、フィーチャーを使用してソリューションが開発されることを示しています。それぞれが、ステークホルダーの重要なニーズを満たすシステムによって提供されるサービスを反映します。それらはARTバックログで維持され、それぞれが新しいバリューを提供するようにPIに収まるようにサイズが調整されます。フィーチャーは、アジャイルリリーストレイン (ART) のローカルコンテキストから、またはエピックまたはケイパビリティを分割することからも生まれます。

ARTおよびソリューショントレインカンバンシステムは、フィーチャーとケイパビリティのフローをサポートします。そこではファネルを通過して分析、バックログ、実装、検証、デプロイ、リリースの状態を進みます。このプロセスは、合理的な経済分析、技術的影響、およびインクリメンタルな実装のための戦略を提供します。

プロダクトマネジメントとシステムアーキテクトは、それぞれフィーチャーとイネーブラーを定義します。非機能要件 (NFR) は、セキュリティ、信頼性、パフォーマンス、保守性、拡張性、およびユーザビリティなどのシステム属性を定義します。 NFRは、異なるバックログを通じてシステムの設計の制約または制限として機能します。フィーチャーはWeighted Shortest Job First (WSJF)を使用して優先順位をつけられ、PIの境界で計画され、レビューされます。それらはストーリーに分割され、機能が利用可能になると実装、統合、テスト、デモが行われます。

フィーチャーの発見と記述

デザイン思考は、魅力的で持続可能なプロダクトを作り出すための顧客中心のアプローチを取ります。デザイン思考のツール、ペルソナ、共感マップ、顧客ジャーニーマップを含む、顧客やユーザーに対する共感と深い理解を提供します。それらが一緒になることで、フィーチャーとその潜在的なベネフィットをより理解するための豊かなコンテキストを提供します。

フィーチャーは、フィーチャーとベネフィットの形式で定義されます。

フィーチャー - 名前とコンテキストを与える短いフレーズ
ベネフィット仮説 - エンドユーザーまたはビジネスに対する提案された測定可能なベネフィット

一つのユーザーの役割をサポートするために設計された「ユーザーストーリーボイス」形式でフィーチャーを定義するのは避けてください。通常、フィーチャーは複数のユーザーの役割に対して機能を提供します。さらに、ユーザーストーリーとフィーチャーを説明するために同じ方法を使用すると混乱を招く可能性があります。

図2は、ベネフィット仮説を持つフィーチャーの一例を示しています。

図2 フィーチャーとベネフィット仮説

フィーチャーの作成と管理

プロダクトオーナーや他の主要なステークホルダーとのコラボレーションにより、プロダクトマネージャーはARTのローカルなコンテキストでフィーチャーを定義します。エピックを分割する結果として、一部のフィーチャーが生じます。

システムアーキテクトは通常、イネーブラーフィーチャーを作成します。 ARTバックログは、ビジネスフィーチャーと並行してイネーブラーを維持するために使用されます。イネーブラーはアーキテクチャランウェイを進み、探索を支援するか、ソリューションを開発、テスト、統合するために必要なインフラストラクチャを提供します。

ビジネスフィーチャーと同様に、イネーブラーフィーチャーはエピックから派生するか、またはARTレベルでローカルに現れることがあります。カンバンシステムを通過するイネーブラーは、ソリューションをさらに進め、アーキテクチャランウェイを拡張することを重視するため、ARTバックログでのキャパシティ割り当ての対象となります。各PIの境界で、新しいフィーチャー（またはケイパビリティ）とイネーブラーに割り当てられるリソースの割合が見積られ、トレインをガイドします。

フィーチャーの優先順位付け

WSJF優先順位付けモデルは、プロダクト開発フローの経済性に基づいて仕事（例：フィーチャー、ケイパビリティ）を優先順位を付けるために使用されます。「正しい仕事」を「正しい順序」で実装することが最大の経済的ベネフィットを生むため、この決定的なプロセスの重要性をいくら強調してもしすぎることはありません。

プロダクトおよびソリューションマネジメントは、フィーチャーの優先順位をつけるためにWSJFを使用し、システムおよびソリューションアーキテクトもまた、イネーブラーフィーチャーに優先順位をつけるためにWSJFを使用します。ビジネスフィーチャーとイネーブラーフィーチャーが同じバックログに存在するため、プロダクトおよびソリューションマネジメントは、システムおよびソリューションアーキテクトと協力して優先順位の違いを調整しなければなりません。優先事項を戦略テーマとキャパシティ配分に合わせることは、バックログにおけるベクトル合わせとバランスを取るための2つのアプローチです。

フィーチャーの見積り

フィーチャーの見積りは、バリューのデリバリーの予測、WSJFの優先順位付けの適用、そしてエピックをフィーチャーに分割してその見積りを合計することによるエピックのサイズ調整をサポートします。フィーチャーの見積りは通常、ARTカンバンの分析状態で行われます。それは正規化された見積りテクニックに依存しており、アジャイルチームが使用する方法と似ています（詳細はイテレーションプランニングの記事を参照してください）。分析中に、ARTから特定分野のエキスパートを選択し、探索アクティビティと予備的なサイズ調整に取り組みます。

フィーチャーの承認

フィーチャーの受け入れ基準は、実装が正しいもので、ビジネスのベネフィットを提供するかどうかを決定します。図3では例を提供します。

図3 受け入れ基準を持つフィーチャー

受け入れ基準は、プロダクトマネジメント、ステークホルダー、開発者間でベクトルを合わせることにより、実装のリスクを軽減し、ベネフィット仮説の早期検証を可能にします。受け入れ基準は、ストーリーのソースとしても使用できます。ストーリーと同様に、受け入れ基準はしばしばビヘイビア駆動開発 (BDD) を用いた受け入れテストに変換されます。

プロダクトマネジメントは、フィーチャーを受け入れる責任があります。機能が正しく実装されているか、非機能要件が満たされているかを判断するために受け入れ基準を使用します。

ケイパビリティ

この記事の大部分は、システム動作を最も一般的に詳述するフィーチャーの定義と実装に関する説明を扱っています。ケイパビリティは、フィーチャーと同じ特性とプラクティスを示します。例えば、

フレーズとベネフィット仮説を使用して説明されています
ひとつのPIに収まるようにサイズ設定されていますが、多くの場合、実装するのに複数のARTが必要です
ソリューショントレインカンバンを使用して理論的に考えられ、承認されます。ソリューショントレインバックログは、承認されたケイパビリティを保持します
ビジネスケイパビリティの効率的な開発とデリバリーをサポートするために必要なすべての技術的な仕事を説明し、可視化するために関連するイネーブラーを持ちます
ソリューションマネージャーによって承認され、機能が目的に適しているかどうかを判断するために受け入れ基準を使用します

ケイパビリティは、ソリューションのローカルコンテキストで発生するか、または複数のバリューストリームを横断する可能性のあるポートフォリオエピックの分割の結果として発生する可能性があります。ケイパビリティの別の潜在的なソースは、ソリューションコンテキストで、環境の一部の側面が追加のソリューション機能を必要とする場合があります。