A | B | C | D | E | F | H | I | L | M | N | O | P | R | S | T | U | V | W

A

Agile Release Train (ART)
アジャイルリリース列車(ART)

SAFeでは、アジャイルリリース列車は複数のアジャイルチームに基づき、長期に渡り存続する自己組織化されたチームである。アジャイルリリース列車は、プログラムレベルの価値を提供するメカニズムとして、一般的に50-125人のメンバーで構成される。共通のリズムを用いて、各列車は、継続的に定義し、構築し、テストし、1つの企業の価値のストリームに価値を提供する専任のリソースを持つ。各列車は8-12週間のプログラムインクリメントマイルストンではもちろん、2週間毎に価値のある、評価可能なシステムレベルのインクリメントを作成する。ARTは市場のニーズに応じ任意の時点でリリースできる。

Agile Teams
アジャイルチーム

アジャイルチームはSAFeの最小のソフトウェア開発組織単位である。アジャイルチームはクロスファンクションナルグループであり、価値を定義、構築及びテストのための能力と権限を持つ。アジャイルチームに通常7名 +/- 2名のメンバーからなり、1つのアジャイルリリース列車に専属する。チームに複数名の開発者やテスト担当者、専門分野のリソース、1名のスクラムマスターと1名のプロダクトオーナーを含む。チームはスクラムプロジェクトマネジメントプラクティス、XPから由来するコード品質プラクティスを適用し、リーン思考、フロー、仕掛作業(WIP)を理解する。列車における役割によっては一部のチームがスクラムバンやカンバンを利用する。

Architectural Epic Kanban
アーキテクチャーエピックカンバン

ポートフォリオレベルのアーキテクチャーエピックに対し、アーキテクチャーエピックカンバンシステムは可視性、仕掛作業(WIP)の制限及び継続的なフローをもたらす。アーキテクチャーエピックカンバンシステムは通常企業やシステムアーキテクトを含むCTO/技術オフィスの管理下にある。

Architectural Epics
アーキテクチャーエピック

アーキテクチャーエピックは、現在と今後のビジネスニーズをサポートするために、ポートフォリオソリューションを進化させるために必要な大きな技術取り組みである。アーキテクチャーエピックはアーキテクチャーエピックカンバンシステムに捉えられ、分析される。承認されたアーキテクチャーエピックは、実装のためのリソースが用意されるまでにポートフォリオバックログに保管される。

Architectural Feature
アーキテクチャーフィーチャー

アーキテクチャーフィーチャーは開発者が必要な技術システムサービス、インフラ、コンポーネントと他の基礎要素である。これらの基礎要素は、エンドユーザーや企業にソリューション価値を提供するビジネスフィーチャーを実装するためのものである。

Architectural Runway
アーキテクチャー滑走路

アーキテクチャー滑走路は、既存の技術的インフラであり、コードでインスタンス化されている。アーキテクチャー滑走路は過度的な、遅延を招く再設計を行うことなく、今後のフィーチャーの実装を支援するために必要である。直近の1-2個のプログラムインクリメントにおけるフィーチャー実装の成功を十分に支えるため、各リリース列車はアーキテクチャー滑走路の継続的な拡張に努力する。

ART Metrics
ARTメトリックス

ARTメトリックスは、各アジャイルリリース列車とアジャイルチームの組織健全度を評価するために利用できる自己評価、チームが構築したソフトウェアの資産健全度を測定できるように設計した反復及びプログラムインクリメントメトリックス、すべての利害関係者が1リリースにおける各フィーチャーの進捗を理解するために役に立つ進捗レポートを含む。

B

Budgets
予算

予算は、1つのアジャイルリリース列車に要員、支出及びその他のリソースにおける投資のための運営枠を提供する。SAFeのリーン-アジャイル予算付けアプローチは、プロジェクトに基づく原価計算のオーバーヘッドや摩擦を低減する。また、このアプローチは複数のチームがまとまった長く存続するチームにリソースを割り当て、そして各チームは価値のストリームの実装に専念する。

Business Epic Kanban
ビジネスエピックカンバン

ポートフォリオレベルのビジネスエピックに対し、ビジネスエピックカンバンシステムは可視化、フローと仕掛作業の制限をもたらす。通常、ビジネスエピックカンバンシステムはビジネス戦略の実現に責任を持つ経営者やビジネス責任者からなるプログラムポートフォリオ管理下にある。

Business Epics
ビジネスエピック

ビジネスエピックは大きな、顧客向けの取り組みであり、新しいビジネス機会のメリットを実現するために必要な新しい開発をまとめたものである。ビジネスエピックはビジネスエピックカンバンシステムに捉えられ、分析される。承認されたビジネスエピックは実装のためのリソースが用意されるまでにポートフォリオバックログに保管される。

Business Owners
ビジネス責任者

ビジネス責任者は、特定のリリース列車が提供する価値に関して、主要な効力、統制及びROI責務を持つ管理層の利害関係者の小さなグループである。ビジネス責任者は価値のフロー全体で重要な役割を果たし、リリース計画策定時に、とりわけ重要な役割を持つ。リリース計画策定時に、ビジネス責任者は上役のレビューや問題解決打ち合わせを参加したり、計画を承認したり、チームPI目標のビジネス価値を評価する。

C

Code Quality
コード品質

コード品質は、チームがより高いシステム品質を納品し、高いベロシティと俊敏性を提供し、強化されたイノベーションの機会を増加するために役に立つマインドセットであり、文化であり、プラクティス集である。コード品質はソフトウェア開発の専門家の本質的なモチベーションと誇りをサポートするのに役に立つ。コード品質はSAFeの4つの中心的価値の1つで、SAFeの中で説明したように、概ねテストファースト法、アジャイルアーキテクチャー、継続的インテグレーションとリファクタリング、また、ペアワークや共同共有の利用により達成できる。

Coordination
連携

価値のストリームが1つのARTに大きすぎる場合、価値を納品するために複数のARTが必要となる。通常、これらのARTは機能上、技術上、要員面に至るまで日常的に管理しなければならない依存性が生じる。この場合、エンドユーザー価値の納品は内容の管理、統合とリリースの連携に依存する。

D

Developers & Testers
開発者とテスト担当者

アジャイルチームは主に開発者とテスト担当者からなる。開発者はユーザーストーリーのためにコードを書いて、スパイクストーリーを用いて、調査、設計、プロタイピングを実施する。開発者の責務はプロダクトオーナーとテスト担当者と協力し、正しいコードが開発されることを保証する。毎日、ペアワークをし、コードや単体テスト、自動化された受け入れテストを書いて、新しいコードを共有されたリポジトリに入れる。テスト担当者は協力的に開発者とプロダクトオーナーと並行で作業を実施する。受け入れテストを定義し、作成し、実行し、共有されたリポジトリでテストケースの保守を行う。

DevOps
DevOps

DevOpsはソフトウェア開発へのアプローチの哲学であり、アジャイル開発チームとソフトウェアシステムを配置し、維持する責任を持つ情報技術(IT)専門家の間のコミュニケーション、協力、および緊密な連携を強調するプラクティス集である。これは、アジャイルリリース列車のメンバーとしてIT/配置/運用担当者を含めることにより、また、DevOpsガイダンスプラクティスに従うことにり、部分的には達成される。

E

Enterprise Architect
エンタープライズアーキテクト

プログラムをわたった全体的な技術実現を促進するため、エンタプライズアーキテクトはビジネス利害関係者やシステムアーキテクトと一緒に作業を行う。エンタプライズアーキテクトは継続的顧客とチームのフィードバックを力にし、適応的設計とエンジニアリングプラクティスを育み、共通の技術ビジョンに巡って、プログラムやチームの協力を促進する。

Epic Owner
エピックオーナー

エピックオーナーの責務は、1つのエピックの識別から、カンバンシステムや分析プロセスを経由し、進めるか/止めるかについての意思決定プロセスを推進することである。エピックが実装に受け入れられる場合、エピックオーナーはリリース列車と一緒に作業をし、エピックのビジネス利益を実現するために必要な開発活動を着手させる。

Epics
エピック

エピックは、潜在的なROIの分析と理解を保証するようにスコープが十分に充実した企業の取り組みである。エピックは、通常、ビジネスや技術のインパクトと実装の戦略を発展させるための軽量なビジネス企画を必要とする。エピックは通常横断的で、複数の組織、予算、リリース列車に影響を与え、複数のPIを介する。ポートフォリオエピックは複数のリリース列車に影響を与える。プログラムエピックは1つの列車に含まれる。

F

Feature
フィーチャー

フィーチャーは、1人もしくは複数の利害関係者のニーズを満たすため、システムによって提供されるサービスである。フィーチャーはプログラムバックログに維持され、プログラムインクリメントに収まるようにサイズを調整する。このように、各PIは概念的に一貫したものを納品する。フィーチャーはユーザーストーリー(反復に適するようにサイズを調整する)とエピック(PI期間中)の間のギャップを橋わたしする。主要な経済的プログラム利益は、フィーチャーに対する賢明な優先順位付と順序調整により駆動されるので、SAFeでは、継続的優先順位付けには重みづけされた最短作業から着手(WSJF)のリーン経済アルゴリズムを採用する。

I

Innovation and Planning (IP)
イノベーションと計画策定(IP)

SAFeでは、定期的なイノベーションと計画策定スプリントがある。このスプリントは、目標を達成するために見込んだバファーとして、検査と適応やリリース計画を実施するための時間として、イノベーションのためのリズムに基づく機会として、継続的な教育の時間として、技術的なインフラ、ツールやほかの障害のための作業時間として、バックログの手入れの時間として、さまざまな目的で利用できる。さらに、PIマイルストーンにリリースもする場合、IP反復は最終的なシステムの妥当性検証時間や必要かもしれないドキュメント作りの時間を提供する。

Inspect & Adapt
検査と適応

検査と適応 (I&A) ワークショップは定例的な儀式である。各PIの終了時に行うが、チームはこの時間を利用して振り返り、問題解決、改善活動の識別を行う。チームは、適切な利害関係者にソリューションの現在の状態をデモし、それによって、正しいコースを向けるために必要となる迅速なフィードバックを得る。パフォーマンス測定が収集され、分析される。続いて振り返りと問題解決ワークショップを実施する。このワークショップでは、すぐにリリース計画に組み込まれる改善ストーリーや他のプロセスからの教訓を洗い出す。

Iteration
反復

反復(スプリントと同じ意味)は厳格な時間枠(タイムボックス)である。時間枠内で、チームはテストされ、動作するソフトウェアの形式で、インクリメンタルな価値を提供する。各反復は1つ標準的なパターンに従う。それは反復の計画、目標への確約、実行、主要な利害関係者へのデモ、最後に、振り返りの開催というパターンである。振り返りでは、チームはパフォーマンスを改善するために必要な変化を分析し決定する。

Iteration Planning
反復計画

反復計画はチームが次の反復を計画するための作業である。反復計画ミーティングのアウトプットは、スプリントに確約するストーリーと受け入れ基準からなるスプリントバックログ、スプリントのビジネス目標であるスプリント目標、目標を達成するために必要な作業に関するチームの確約である。

Iteration Retrospective
反復振り返り

反復振り返りは各反復の終盤で開催する短いミーティングである。チームのメンバーはプライベートで、安心できる環境で集まり、自分達のプラクティスの有効性を議論し、今後の改善を定義する。定量的な部分ではチームが使用するメトリックスをレビューする。定性的な部分では、チームの様々なプラクティスを議論し、直面した特定な課題について議論する。問題が識別された後、チームはこれらの問題を解決するための是正活動を洗い出す。

L

Lean
リーン

リーン思考は、無駄を最小にし、市場への投入時間を低減し、顧客の価値を最大にする原則とプラクティス群である。リーンの目標は、持続可能な最短のリードタイムで人や社会に最高の価値を提供することである。リーン思考は5つの要素を含む:目標改善プロダクト開発フロー人を尊敬するリーン思考リーダー/管理者/講師。リーン思考はアジャイルプラクティスを企業レベルへスケールアップするため不可欠なものであるため、SAFeの土台である。

Lean-Agile Leaders
リーン-アジャイルリーダー

リーン-アジャイルリーダーは生涯の学習者、管理者、先生、コーチである。リーン-アジャイルリーダーはリーン、システム思考とアジャイルソフトウェア開発の価値、原則とプラクティスを理解し、示すことを介して、チームがより良いソフトウェアシステムを構築するために支援する。リーン-アジャイルリーダーはリーン・アジャイルリーダーシップの4つの原則に従う。

N

Nonfunctional Requirements (NFR)
非機能要求(NFR)

非機能要求(NFR)はセキュリティー、信頼性、保守性、拡張性、使いやすさなど(よく「品質」や「…性」を指す)を含むシステムの特徴を記述する。また、システムの設計に関する制約や制限でもある。非機能要求は、長く残る品質と制約であり、機能要求と異なり、一般的に「完了の定義」の一部として再検討されている。NFRはチーム、プログラム及びポートフォリオレベルに存在する。

P

Portfolio Backlog
ポートフォリオバックログ

ポートフォリオバックログはSAFeの最上位のバックログであり、これからカンバンシステムを通過し実装を待つエピックの保持場所として機能する。このバックログに、市場の差別化、業務の効率化や、競争力のあるソリューションを達成するために必要な優先順位が付けられた横断的なビジネスエピックとアーキテクチャーエピックが含まれている。

Portfolio Level
ポートフォリオレベル

SAFe全体像(ビッグピクチャー)の最上位レベルはポートフォリオレベルであり、ここでプログラムは価値のストリームの線に沿ってエンタープライズビジネス戦略との整合がはかられる。より大きな企業では、複数のプログラムポートフォリオがあるかもしれない。それぞれに戦略と資金が決まっている。

Portfolio Metrics
ポートフォリオメトリックス

ポートフォリオメトリックスは、プログラムポートフォリオ管理機能自身の状態や進捗をよりよく理解するために利用できる自己評価、ポートフォリオエピックがカンバンシステムから実装へ移動時にそれを追跡するためのメトリックス、全体プログラムポートフォリオの健全度を評価するために利用できるリーンなメトリックス群を含む。

Portfolio Vision
ポートフォリオビジョン

ポートフォリオビジョンは戦略的な意図を捉え、プログラムポートフォリオ目標を達成するために目的のある時間、資金およびリソースの投資のガイダンスを提供する。価値のストリーム、戦略テーマ、ビジネスとアーキテクチャーエピックカンバンとポートフォリオバックログで構成され、ポートフォリオビジョンは企業のビジネス戦略向けの活動に対する詳細化と確約を反映する。

Product Management
プロダクト管理

プロダクト管理者はリリース列車の内容の責任者として務める。プログラムバックログを定義したり、優先順位を付けたり、そしてPIやリリースにどのフィーチャーを入れるのかを決定したりなど、プロダクト管理者が責任を持つ。プロダクト管理者はプロダクトオーナーを含む内部や外部の利害関係者と一緒に作業をし、企業の技術的、機能的、経済的な目標とのバランスを取りながら、フィーチャーの提供を最適化する。

Product Owner
プロダクトオーナー

プロダクトオーナーはアジャイルチームのメンバーである。チームが担当しているフィーチャーやコンポーネントの概念的、技術的な一貫性を維持しながら、プログラムの優先順位の実行を効率化するために、プロダクトオーナーはチームバックログの定義や優先順位付けに責務を持つ。プロダクトオーナーは拡張されたプロダクト管理層–プロダクトオーナーチームの一員でもある。プロダクトオーナーチームは開発する内容について権限を持つ。その上、プロダクトオーナーは、ユーザー価値およびソリューション品質の保証における重要な役割を持っている。また、システムベースラインに新しいストーリーを受け入れる権限を与えられた唯一のチームメンバーである。

Program Backlog
プログラムバックログ

プログラムバックログは、アジャイルリリース列車の目標を満たすために、今後予想されるすべての作業を唯一の決定的に保管する場所である。バックログは主に今後完成していくフィーチャーからなる。これらのフィーチャーによってユーザーのニーズを対応し、ビジネスのメリットを提供する。また、今後のフィーチャーバックログを対応するため、アーキテクチャー滑走路を構築しなければならないので、バックログにアーキテクチャー滑走路を構築するために必要なアーキテクチャーフィーチャーも備えている。

Program Epics
プログラムエピック

プログラムエピックは単一の列車で実装されるエピックである。これらのエピックはスコープ、影響度とコストにより、カンバンシステムを通してポートフォリオバックログに入れられるか、あるいは局所で取り上げられる。いずれの場合、実装する前に、分析や影響度の評価、及びプログラムポートフォリオ管理との議論をしなければならない。

Program Increment (PI)
プログラムインクリメント(PI)

プログラムインクリメント(PI)は、システム状態の評価、フィードバックの獲得、プロセスの改善、計画の再策定、また、ポートフォリオレベルのレビューやロードマップの策定に適したリズムに基づく時間枠と価値単位である。チームのスプリントと類似し、PIはARTに対するものである。

Program Level
プログラムレベル

プログラムレベルでは、重要な、長く存続するエンタープライズのミッションに対し、要員やその他のリソースに関する資金提供が適用される。SAFeのエンタープライズでは、ほとんどのプログラムは1つのアジャイルリリース列車に1対1の関係を持つ。価値のストリームを納品するために、各ARTは資金提供、統制とインクリメンタル開発パターンに従う。このように、従来のより伝統的な開始と終了日を持つ「プログラム」と比べ、一般的にARTは非常に長く存続し、より永続的な構造とミッションを持つ。

Program Portfolio Management (PPM)
プログラムポートフォリオ管理(PPM)

プログラムポートフォリオ管理(PPM)は最上位の信頼と内容責任を表す。これらの責任は、各価値のストリームに必要な知識を持ち、内部の財政的制約と外部の市場の状況をよく理解しているビジネス側の役員によって担われる。

Program PI Objectives
プログラムPI目標

プログラムPI目標は、今後のいくつかのPIのためにまとめられた特定な目標とビジネス価値の説明である。リリース計画策定時に作成した各チームPI目標を集約したものが、プログラムの目標となる。

R

Refactors
リファクタリング

リファクタリングは外から見たシステムの振る舞いを変更せずにコードベースを改善する体系的なアプローチである。特定のリファクタリング作業は、処理速度の増加、異なる由来の内部データ、セキュリティーの強化、コードをより効率的、より保守可能、より可読性向上をするためのいくつかの側面を改善する作業を達成するために、必要なバックログ項目として現れる。

Release
リリース

リリースはプロダクトソリューション全体を表す。リリースすることによって、エンドユーザが開発された動作するソフトウェアの完全な恩恵を受け、顧客の環境でソリューションの有効性を保証するために必要なすべての要素が検証され、パッケージ化され、文書化され、サポートされる。

Release Management
リリース管理

リリース管理は、1つ以上のリリース列車を横断し、リリースを統制する責任を持つ権威者である。一般向けのソフトウェアの提供、内部や本番稼動のソリューションの納品のための調整と促進はこのチームの主要な責務である。

Release Planning
リリース計画

リリース計画はアジャイルリリース列車の重要な、リズムに基づく同期ポイントである。リリース計画は、標準のアジェンダを用いた、定期的な、プログラム規模の、顔を突き合わせたイベントである。アジェンダにビジョンの発表、チーム計画に分かれての検討、次のPIに向けた目標への確約を含む。

Release Train Engineer (RTE)
リリース列車エンジニア(RTE)

リリース列車エンジニアは「上位スクラムマスター」である。RTEはプログラムレベルのプロセスとプログラムの実行を促進し、障害をエスカレートし、リスクを管理する。また、プログラムレベルの継続的な改善を推進することを支援する。リリース計画策定、検査と適用ワークショップ、スクラム・オブ・スクラムズなどプログラムイベントの開催に関して、RTEは責任を持つ。

Roadmap
ロードマップ

ロードマップには、約3-6ヶ月の時間軸に渡って、フィーチャーやエピック、リリース及びその他のマイルストンのような意図した納品物を提供する。ロードマップは通常、次回のプログラムインクリメント(PI)に対しては高い確信度のフィーチャーの見通し、その次のPIに対しては中ぐらいの確信度のフィーチャーの見通し、それより先は相対的に低い確信度のフィーチャーの見通しを含む。

S

Scrum Master
スクラムマスター

スクラムマスターの主要な責務は自己組織化され、自己管理されたチームが目標と確約を達成し、継続的にパフォマンスを改善することを支援することである。スクラムマスターはスクラムやアジャイル、リーンのプラクティスを理解し、教え、XPから取り入れた技術プラクティスの利用を促進する。また、障害の識別と排除、弛まないパフォーマンス改善を支援するために必要な協力を育む。

Shared Resources
共有されたリソース

プログラムレベルでは、リリース列車の対象となる特定の価値のストリームに専任するほとんどの役割とチームを説明している。しかしながら、プログラムは専門家が必要である。つまり、セキュリティー専門家、情報アーキテクト、DBA、ドキュメント作成者、IT専門家などのような共有されたリソースである。組織やリリース列車のスコープによるが、一定的な期間内で、これらのリソースがプログラムに専有されるかもしれないが、他の機能部署からの兼務の可能性が高い。

Spikes
スパイク

スパイクは調査、設計、探索とプロトタイプのような作業のためのストーリーである。技術的アプローチのリスクを軽減したり、要求をよりよく理解したり、また、ストーリーの見積もり信頼性を高めるために必要な知識を得ることはスパイクの目的である。スパイクは技術的と機能的という2つの形式がある。他のストーリーと同じ、スパイクは見積もられ、チームメンバーが担当し、反復の終了時にデモされる。

Sprint Goals
スプリント目標

スプリント目標は、チームとプロダクトオーナーがスプリント内で完成するものを合意した高いレベルのまとめられたビジネスと技術の目標である。SAFeの中では、自己組織化され、自己管理の複数のチームのまとまりとするアジャイルリリース列車が効果的な連携を図るため、スプリント目標は不可欠である。スプリント目標は以下の3点で価値を提供する。1)スプリントのため、個々のチームメンバーとプロダクトオーナーは共通なミッションにベクトル合わせる。2)個々のチームが継続的にPI目標にベクトル合わせる。3)チーム、上役とビジネス責任者間のシンプルなコミュニケーションプロトコルを提供し、そして、列車に乗っている各チームの現在の意図や仕掛作業が上役に継続的に知らせられる。

Stories
ストーリー

ストーリーは要求仕様の従来の形式のアジャイル的な代替物である。ストーリーは小さくて独立した振る舞いであり、インクリメンタルに実装できる。各ストーリーはビジネスに価値をもたらす。ストーリーは要求ではない。一般的に交渉可能であり、そして、契約上求められる振る舞いではなく、むしろ1種の意図の声明を表している。しかしながら、受け入れ基準を通じ、システムコンプライアンス及び回帰テストを保証するために必要な詳細を提供し、実装とともにストーリーはより詳細化されていく。1つの反復内で完成できるようにストーリーは必要に応じ分割される。

Strategic Themes
戦略テーマ

戦略テーマはポートフォリオビジョンを進化するエンタープライズビジネス戦略に結びつけ、具体的箇条書きされたビジネス目標や新たなビジネス差別化要素である。戦略テーマはポートフォリオ内の意思決定にビジネス背景を提供し、価値のストリームやリリース列車における投資に影響を及ぼす。また、ポートフォリオバックログ及びプログラムバックログの入力にもなる。

System Architect
システムアーキテクト

システムアーキテクトは、リリース列車のためにユーザーのニーズ、システム要件とビジネス上のメリットに関する高レベルの理解を維持する責任がある。システムアーキテクトはアジャイル、意図的な設計、システムレベルのリファクタリングと再設計、非機能要求のガイダンスを提供し、創発的な設計、アーキテクチャーフローを促進し、インタフェースや依存関係の理解に手伝い、チームレベルの設計判断を促進する。

System Demo
システムデモ

システムデモは2週間ごとに行い、プログラムにおけるすべてのチームによって提供されたすべての新しいソフトウェアの、その時点で集約され統合されたシステムインクリメントの姿を提供する。システムデモはシステムチームが主催する。開発中のシステムの有効性と使いやすさに関して、プロダクト管理、上役、顧客(もしくは顧客代理)を含む主要な利害関係者からフィードバックをもらうことがシステムデモの目的である。

System Team
システムチーム

多くの場合、システムチームの責務は、開発環境のインフラの利用と構築に支援を提供し、システムインクリメントを評価することである。これは、継続的インテグレーション、ビルド環境、テストプラットフォーム、テスト自動化フレームワークの開発と保守、各アジャイルチームからのコードの結合を含み得ることができる。システムチームはエンドツーエンドのシステムテストの実施に必要なスキルとツールを持ち、利害関係者にソリューションをデモし、非機能システムテストを支援する。

T

Task
タスク

SAFeでは、タスクは一番低いレベルでの作業単位である。反復計画時に、チームはストーリーをタスクに分解する。個々のタスクはストーリーを完成するために必要な個別の活動となる。通常、1つのタスクの見積もりは時間単位で、おおよそ2-4-8時間である。タスクは誰か1人に割り当てられし、1つの反復内で完成させなければならない。もし、タスクが大きくて、1つの反復内で完成できない場合、ストーリーが大きすぎ、処理する前に分割しなければならない。タスクは、ストーリーを完成させるために厳密に誰が何をするかについて、チームが合意するための方法を提供する。タスクはチーム内の依存性だけではなく、ボトルネック、個人やリソースが空いているかどうかなども明らかにする。

Team Backlog
チームバックログ

チームのバックログは、チームがプログラムソリューションの一部を進めるために行う必要があるすべてのものを表す。ユーザーと技術ストーリー、今後のフィーチャー、不具合、インフラ作業、スパイク、リファクタリング、及びその他チームが行わなければならない作業を含む。ストーリーの種類毎の容量の割り当ては、多くの場合、チームが行わなければならない様々なタイプの作業に対する投資を手引きするために使用される。

Team Demo
チームデモ

チームデモは、チームが反復で完成した作業の結果をデモするという伝統的な、スクラム所定の儀式である。チームデモは、プロダクトオーナー、他のチームメンバー、他の関係する利害関係者に動作するソフトウェアを示すことにより、チームの進捗を測定することである。スプリントが計画時に、デモの準備も始まる。つまり、スプリント計画時に、チームがストーリーをどのようにデモするかを考え始める。各ストーリー、スパイク、リファクタリング作業、新しいNFRのすべてを、チームがデモできなければならない。

Team Level
チームレベル

アジャイルチームは、いくつかの固定長の反復(スプリント)でチームのバックログからストーリーを定義/構築/テストする責任を持ち、ソフトウェア開発に固有のバラツキを管理するためにリズムと同期を使用する。さらに、アジャイルリリース列車での大規模な、より価値の高いソリューションのフィーチャーコンポーネントを構築するために、複数のアジャイルチームが他のチームのコードと自分のコードを統合することにより協力する。基本的なアジャイルプロジェクト管理のプラクティス(主にスクラムから)、アジャイル技術的プラクティス(主にXPから)を実装と実施すること、高品質のソフトウェアを生み出すために必要に応じて他のチームと協力することについて、アジャイルチームは、個人と、集団として責任がある。

Team PI Objectives
チームPI目標

チームPI目標は、今後のPIのためにチームが達成しようとする具体的なビジネスと技術目標の要約である。リリース計画策定時に、各チームはビジョンやほかのインプットされた目標をレビューし、初期のユーザーストーリーを定義し、反復におけるチームのキャパシティがいっぱいになるまでにユーザーストーリーを計画する。その後、チームはこれらの結果を用いて、計画に反映し、PIにおけるチームの具体的な技術とビジネス目標にまとめて、要約する。各チームの目標を集約し、プログラムPI目標となる。

U

User Experience (UX)
ユーザーエクスペリエンス(UX)

ユーザインタフェース(UI)要素を含むコードの実装は完全にアジャイルチームの責務である。一方、ソリューションのコンポーネントとシステム全体で一貫したユーザーエクスペリエンス(UX)を提供するように、UX設計者はプログラムレベルで作業し、コンポーネントや、プログラムを横断する設計ガイダンスを提供する。

V

Value Streams
価値のストリーム

ソフトウェアの価値のストリームは、システムの定義、開発、配置という長期にわたる一連のステップであり、これによって、会社や顧客に対して継続的な価値のフローがもたらされる。価値のストリームは、プログラムを駆動し、企業を最終的に競合他社と差別化できる、説得力のあるより長期的な取組でなければならない。

Vision
ビジョン

ビジョンは、利害関係者のニーズと提案されたフィーチャーに関して、開発されるソリューションを利害関係者の視点で説明する。ビジョンは、高レベルのフィーチャー、非機能要件および設計制約の形式で想定されたソリューションの本質を捉え、開発されるシステムの概観を提供する。プログラムに対する目的を説明し、今後のフィーチャー、ストーリー、判断の基となる境界を提供する。足並みを揃えるため、プログラムの目標や目的に関する共通の理解を創出するため、継続的にすべてのチームメンバーにビジョンを伝えることは重要である。

W

Weighted Shortest Job First (WSJF)
重みづけされた最短作業から着手(WSJF)

WSJFは遅延のコストと残作業の規模を用いて、バックログの優先順位を決めるためのリーンの方法である。このアルゴリズムはPIの区切りで適用され、現時点のビジネス背景、価値、開発実状、リスクと考慮する労力に基づいて、絶えずにプログラムの優先順位を更新する。

Last update: 4 April, 2014

c 2010-2014 Leffingwell, LLC. All rights reserved.