ISO/IEC TR 24587:2021 ソフトウェアおよびシステムエンジニアリング—アジャイル開発—アジャイル導入の考慮事項 | ページ 2

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

序文

ISO (国際標準化機構) と IEC (国際電気標準会議) は、世界標準化のための専門システムを形成しています。 ISO または IEC のメンバーである国家機関は、技術活動の特定の分野を扱うために、それぞれの組織によって設立された技術委員会を通じて、国際規格の開発に参加しています。 ISO と IEC の技術委員会は、相互に関心のある分野で協力しています。 ISO および IEC と連携して、政府および非政府の他の国際機関もこの作業に参加しています。

この文書の開発に使用された手順と、今後の維持のために意図された手順は、ISO/IEC 指令で説明されています。 1. 特に、さまざまなタイプの文書に必要なさまざまな承認基準に注意する必要があります。この文書は、ISO/IEC 指令の編集規則に従って作成されました。 2 ( www.iso.org/directives or www.iec.ch/members_experts/refdocs を参照)

このドキュメントの要素の一部が特許権の対象となる可能性があることに注意してください。 ISO および IEC は、そのような特許権の一部またはすべてを特定する責任を負わないものとします。ドキュメントの開発中に特定された特許権の詳細は、序論および/または受信した特許宣言の ISO リスト ( www.iso.org/patents を参照) または受信した特許宣言の IEC リスト ( https://patents.iec.ch )

このドキュメントで使用されている商号は、ユーザーの便宜のために提供された情報であり、保証を構成するものではありません。

規格の自主的な性質の説明、適合性評価に関連する ISO 固有の用語と表現の意味、および技術的貿易障壁 (TBT) における世界貿易機関 (WTO) の原則に対する ISO の遵守に関する情報については、 www を参照してください。 .iso.org/iso/foreword.html . IEC については、 www.iec.ch/understanding-standards を参照してください。

この文書は、合同技術委員会 ISO/IEC JTC 1, 情報技術、小委員会 SC 7, ソフトウェアおよびシステム工学によって作成されました。

序章

アジャイル開発は、反復開発、頻繁な検査と適応、段階的デリバリーに基づく開発アプローチであり、機能横断的なチームでのコラボレーションと継続的な利害関係者のフィードバックを通じて要件とソリューションが進化します (ISO/IEC/IEEE 26515:2018 を参照)

多くの組織は、システムおよびソフトウェア開発へのアジャイル アプローチへの移行の利点を認識しています。ただし、組織によっては、移行が早すぎる場合があります。組織の準備が整う前に。このドキュメントでは、ソフトウェアおよびシステム開発にアジャイル アプローチを採用する際の適切な考慮事項についての洞察を提供します。このドキュメントでは、これらの考慮事項の焦点は、そのような動きを行う前に考慮できるアジャイルの準備要因です。この情報を使用して組織とチームの準備を整えることは、アジャイルへの移行の成功と、組織がアジャイル アプローチのメリットを数年間引き出すことができなくなる失敗との違いを生む可能性があります。このドキュメントは主に、アジャイルへの移行が可能かどうかの決定を担当するマネージャーと、そのような移行を行うための組織の準備を担当するマネージャーによって使用されることを意図しています。ドキュメントで考慮されているアジャイル準備の要素は、組織レベルで、組織内のプロジェクトまたはチームに適用できます。

テクニカル レポートとして、このドキュメントには、「最新技術」に関するデータなど、国際標準または技術仕様として通常公開されているものとは異なる種類のデータが含まれています。

1 スコープ

このドキュメントでは、組織、プロジェクト、製品、またはチームが、システムおよびソフトウェアの開発と保守活動にアジャイル アプローチを使用するための移行を開始する準備ができているかどうかを決定する可能性が高いアジャイル準備要因の概要を説明します。

このドキュメントは、すべてのアジャイル方法論に適用できる一般的なアプローチを提供し、スクラム、SAFe, エクストリーム プログラミング (XP) などの特定のアジャイル方法論は対象としません。

2 参考文献

このドキュメントには規範的な参照はありません。

3 用語と定義

このドキュメントでは、次の用語と定義が適用されます。

ISO および IEC は、次のアドレスで標準化に使用する用語データベースを維持しています。

3.1

アジャイル開発

反復開発 (3.10) 、頻繁な検査と適応、および機能横断的なチームでのコラボレーションと継続的な 利害関係者 (3.16) フィードバックを通じて要件とソリューションが進化する漸進的デリバリーに基づく開発アプローチ

注記 1:このドキュメントで使用されている「アジャイル」という言葉は、方法論を指しています。

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.1, modified — 外部附属書への参照が削除されました。]

3.2

アジャイルな成熟度

組織、部門、プロジェクト、またはチームが、ビジネスニーズの達成に貢献するアジャイルの価値と原則を一貫して適用する程度

3.3

アジャイルチーム

アジャイル方法論の範囲内で、製品の開発に協力する機能横断的な小さなグループ

1 年生から初級:一般的なアジャイル チームの規模は 3 人から 10 人です。

3.4

アジャイルチームリーダー

アジャイルチーム (3.3) が組織のアジャイルの原則、実践、価値、およびプロセスを遵守することを保証する責任を負う個人

1 年生から初級:アジャイル チーム リーダーは、マネージャーではなくファシリテーターです。

3.5

合意

作業関係が行われる条件の相互承認

例:

契約書、合意書。

[出典:ISO/IEC/IEEE 12207:2017, 3.1.5]

3.6

お客様

製品またはサービスを受け取る組織または人

[SOURCE:ISO/IEC/IEEE 12207:2017, 3.1.16, modified — エントリの例と注記は削除されました。]

3.7

毎日立ち上がる

アジャイル チーム (3.3) の各メンバーと、進行状況、計画、および障害となる問題について話し合うために使用される、毎日の短いタイムボックス ミーティング。

注記 1:所要時間は 15 分を超えるとは予想されない。

3.8

インクリメント

新しい機能または変更された機能を提供する、ソフトウェア製品のテスト済みの提供可能なバージョン

[出典:ISO/IEC/IEEE 24765:2017, 3.1913]

3.9

反復

一連の ソフトウェア機能 (3.15) が開発され、 利害関係者 (3.16) にデモンストレーションできる実用的な製品につながる短い時間枠

注記 1:アジャイル方法論が異なれば、反復に使用される用語も異なります。

注記 2:一部のアジャイル方法論は、反復に基づいていません。

注記 3:通常の反復期間は 2 週間から 4 週間です。

[出典:ISO/IEC/IEEE 26515:2018, 3.10, modified — エントリに注 3 が追加されました。]

3.10

反復開発

計画、開発、およびテスト活動を並行して繰り返し使用する

[出典:ISO/IEC/IEEE 26515:2018, 3.11]

3.11

ペルソナ

研究に基づいて定義された特性を持つユーザーのモデル

[出典:ISO/IEC/IEEE 26513:2017, 3.29]

3.12

プロダクトオーナー

利害関係者(3.16) 製品の機能、受け入れ、および使用に責任を負う

注記 1:製品の所有者は、製品のビジョン、必要な機能とその優先順位、および承認基準を共有します。

3.13

リリース

顧客(3.6) またはユーザーへの製品 増分(3.8) の配布

3.14

ソフトウェア機能

要件文書によって指定または暗示されたソフトウェアの特性。

例:

機能性、性能、属性、設計上の制約。

[出典:ISO/IEC/IEEE 24765:2017, 3.3814]

3.15

スポンサー

プロジェクト、プログラム、またはポートフォリオにリソースとサポートを提供し、成功を可能にする責任がある個人またはグループ

[出典:ISO/IEC/IEEE 24765:2017, 3.3908]

3.16

利害関係者

システムに対する権利、共有、主張、または関心を持っている個人または組織、または自分のニーズと期待を満たす特性を所有している個人または組織

[SOURCE:ISO/IEC/IEEE 15288:2015, 4.1.44, modified — エントリの例と注記は削除されました。]

3.17

タスクボード

アジャイル チーム (3.3) が完了するタスクとチームの最近の進捗状況の視覚的表示

3.18

ユーザーストーリー

ペルソナ (3.11) の観点からユーザー要件を説明する簡単な説明

[出典:ISO/IEC/IEEE 26515:2018, 3.16]

参考文献

[1]ISO/IEC/IEEE 12207:2017, システムおよびソフトウェア工学 — ソフトウェア ライフ サイクル プロセス
[2]ISO/IEC/IEEE 15288:2015, システムおよびソフトウェア工学 - システム ライフ サイクル プロセス
[3]ISO/IEC/IEEE 24765:2017, システムおよびソフトウェア工学 - 語彙
[4]ISO/IEC/IEEE 26513:2017, システムおよびソフトウェア工学 - ユーザー向け情報のテスターおよびレビュー担当者の要件
[5]ISO/IEC/IEEE 26515:2018, システムおよびソフトウェア エンジニアリング — アジャイル環境でのユーザー向け情報の開発
[6]14th Annual State of Agile Report, 2020 [2020 年 6 月閲覧 https://explore.digital.ai/state-of-agile/14th-annual-state-of-agile-report から入手可能
[7]KPMG Global Agile Survey 2019 [2020 年 6 月閲覧 https://assets.kpmg/content/dam/kpmg/be/pdf/2019/11/agile-transformation.pdf から入手可能
[8]ベックKら。アジャイルマニフェスト。アジャイル アライアンス、2001 年 [2020 年 6 月閲覧入手先: http://agilemanifesto.org/
[9]ベックKら。アジャイル マニフェストの背後にある原則。アジャイル アライアンス、2001 年 [2020 年 6 月閲覧入手先: http://agilemanifesto.org/
[10]Williams L, Kessler RR, Cunningham W, Jeffries R. ペア プログラミングのケースを強化します。 IEEE ソフトウェア. 2000 年、17, (4)、19 ~ 25 ページ。ドイ: 10.1109/52.854064

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs ).

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents ) or the IEC list of patent declarations received (see https://patents.iec.ch ).

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html . In the IEC, see www.iec.ch/understanding-standards .

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering.

Introduction

Agile development is a development approach based on iterative development, frequent inspection and adaptation, and incremental deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and through continuous stakeholder feedback (see ISO/IEC/IEEE 26515:2018).

Many organizations recognize the benefits of moving to an agile approach to systems and software development. However, for some organizations the move can be taken too early; before the organization is ready for it. This document provides insight into appropriate considerations when adopting an agile approach to software and systems development. In this document, the focus of these considerations is the agile readiness factors that can be considered before making such a move. Using this information to increase organizational and team readiness can make the difference between a successful move to agile and a failure that prevents the organization from deriving the benefits of an agile approach for several years. This document is primarily intended to be used by those managers responsible for deciding on whether a move to agile can be made and those managers who are tasked with preparing an organization for making such a move. The agile readiness factors considered in the document can be applied at the organizational level and to projects or teams within organizations.

As a Technical Report, this document contains data of a different kind from that normally published as an International Standard or Technical Specification, such as data on the “state of the art”.

1 Scope

This document provides an overview of agile readiness factors that are likely to determine whether an organization, project, product or team is ready to start the transition to using an agile approach to their system and software development and maintenance activities.

This document provides a general approach that is applicable to all agile methodologies and does not cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).

2 Normative references

There are no normative references in this document.

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

3.1

agile development

development approach based on iterative development (3.10) , frequent inspection and adaptation, and incremental deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and through continuous stakeholder (3.16) feedback

Note 1 to entry: Any use of the word “agile” in this document refers to methodology.

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.1, modified — The reference to an external annex has been removed.]

3.2

agile maturity

extent to which an organization, department, project or team consistently applies agile values and principles that contribute to the achievement of its business needs

3.3

agile team

small cross-functional group of people who collaborate on the development of a product, within an agile methodology

Note 1 to entry: A common agile team size is 3 to 10 people.

3.4

agile team lead

individual responsible for ensuring an agile team (3.3) adheres to the organization’s agile principles, practices, values and processes

Note 1 to entry: The agile team lead is a facilitator rather than a manager.

3.5

agreement

mutual acknowledgement of terms and conditions under which a working relationship is conducted

EXAMPLE:

Contract, memorandum of agreement.

[SOURCE:ISO/IEC/IEEE 12207:2017, 3.1.5]

3.6

customer

organization or person that receives a product or service

[SOURCE:ISO/IEC/IEEE 12207:2017, 3.1.16, modified — The example and note to entry have been deleted.]

3.7

daily stand-up

short, daily, time-boxed meeting used to discuss progress, plans and any blocking issues with each member of an agile team (3.3)

Note 1 to entry: Duration is not expected to exceed 15 min.

3.8

increment

tested, deliverable version of a software product that provides new or modified capabilities

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.1913]

3.9

iteration

short time frame in which a set of software features (3.15) is developed, leading to a working product that can be demonstrated to stakeholders (3.16)

Note 1 to entry: Different agile methodologies use different terms for an iteration.

Note 2 to entry: Some agile methodologies are not based on iterations.

Note 3 to entry: Typical iteration length is two to four weeks.

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.10, modified — Note 3 to entry has been added.]

3.10

iterative development

repeated use of concurrent planning, developing, and testing activities

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.11]

3.11

persona

model of a user with defined characteristics, based on research

[SOURCE:ISO/IEC/IEEE 26513:2017, 3.29]

3.12

product owner

stakeholder (3.16) responsible for the capabilities, acceptance and use of a product

Note 1 to entry: The product owner shares the product vision, required features and their priorities, and acceptance criteria.

3.13

release

distribution of a product increment (3.8) to a customer (3.6) or users

3.14

software feature

software characteristic specified or implied by requirements documentation

EXAMPLE:

Functionality, performance, attributes, design constraints.

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.3814]

3.15

sponsor

person or group who provides resources and support for the project, program, or portfolio and is accountable for enabling success

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.3908]

3.16

stakeholder

individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations

[SOURCE:ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The example and note to entry have been deleted.]

3.17

taskboard

visual display of tasks to be completed by an agile team (3.3) and recent progress made by the team

3.18

user story

simple narrative illustrating a user requirement from the perspective of a persona (3.11)

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.16]

Bibliography

[1]ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes
[2]ISO/IEC/IEEE 15288:2015, Systems and software engineering — System life cycle processes
[3]ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary
[4]ISO/IEC/IEEE 26513:2017, Systems and software engineering — Requirements for testers and reviewers of information for users
[5]ISO/IEC/IEEE 26515:2018, Systems and software engineering — Developing information for users in an agile environment
[6]14th Annual State of Agile Report, 2020 [viewed June 2020]. Available from: https://explore.digital.ai/state-of-agile/14th-annual-state-of-agile-report
[7]KPMG Global Agile Survey 2019 [viewed June 2020]. Available from: https://assets.kpmg/content/dam/kpmg/be/pdf/2019/11/agile-transformation.pdf
[8]Beck K. et al. The Agile Manifesto. Agile Alliance, 2001 [viewed June 2020]. Available from: http://agilemanifesto.org/
[9]Beck K. et al. Principles behind the Agile Manifesto. Agile Alliance, 2001[viewed June 2020]. Available from: http://agilemanifesto.org/
[10]Williams, L., Kessler, R.R., Cunningham, W., Jeffries, R. Strengthening the case for pair programming. IEEE Software. 2000, 17(4), pp. 19–25. doi: 10.1109/52.854064