アジャイルモデル
柔軟な (アジャイル) 方法論は、ワークフローをいくつかの小さなサイクルに移行することで、ソフトウェア開発のリスクを軽減します。これらのサイクルは反復と呼ばれ、通常は 2 ～ 3 週間続きます。
イテレーションは、タスクごとに機能を向上させる、複数のタスクで構成される小さなソフトウェア プロジェクトのようなものです。これらには、計画の作成、要件の評価、プロジェクトへの同意、コードの作成、テスト、技術文書の作成が含まれます。
通常、本格的なソフトウェア リリースには 1 回の反復では十分ではありません。ただし、アジャイルの良い点は、各反復の終了時にプロジェクトの小さな部分が評価できる状態になっているということです。これにより、チーム メンバーは最終リリースを待たずに、さらなる作業の優先順位を変更できます。
「アジャイル」開発手法を適用すると、各反復後に具体的な結果を確認できます。つまり、開発者は自分の作業の結果が要件を満たしているかどうかを理解できます。これは、フレキシブル モデルの重要な利点の 1 つです。
デメリットとしては、アジャイルを利用する場合、人件費やプロジェクトの予算の見積もりが難しい場合があります。柔軟なモデルを実際に適用するためのオプションを選択すると、その中で最も有名なのはエクストリーム プログラミング (XP) です。
XP は、毎日行われるチーム メンバーの簡単なミーティングと、定期的なミーティング (週に 1 回以下) に基づいています。毎日の集会（デイリースタンドアップ）では、通常次のことが議論されます。
- 現在の仕事の結果。
- 各チームメンバーが完了すべきタスクのリスト。
- 遭遇した困難とその解決方法。
マニフェスト
アジャイルは開発における全体的な方向性であるため、それに取り組むためのルールは特別な文書であるアジャイルマニフェストで宣言されます。これには、チームが取り組むべき実践と原則の両方が含まれます。
アジャイルマニフェストは4つの基本的な考え方と12の原則で構成されています。
主要なアイデア:
- 開発者間のコラボレーションはツールよりも重要です。
- 製品の動作バージョンはドキュメントより優先されます。
- チームと顧客の間の相互理解は契約条件よりも重要です。
- 元の計画は、必要に応じていつでも変更できます。
アジャイルの 12 原則については次のとおりです。
- 主な優先事項は、完成したプログラムが顧客の期待に準拠することです。
- 条件の変更は、開発の最終段階であっても（ソフトウェアの品質と競争力を向上させることができる場合には）どの段階でも許可されます。
- ソフトウェア製品の動作バージョンの定期的な配信 (14 日ごと、月ごと、または四半期ごと)。
- 成功の鍵は、顧客と開発者との間の定期的な対話 (できれば毎日) です。
- プロジェクトはそれに興味を持つ人々の間で構築されるべきであり、そのような人々には仕事に必要な条件とあらゆる種類のサポートが提供されるべきである。
- チーム内で情報を共有する最良の方法は個人的な会議です。
- ソフトウェアの動作バージョンは、進捗状況を示す最良の指標です。
- すべての利害関係者は、ソフトウェア開発プロセス全体を通じて望ましい作業ペースを維持できなければなりません。
- 技術の向上と優れた設計により柔軟性が向上します。
- シンプルさを保ち、過度に作りすぎないことが重要です。
- 最良の結果は、自己組織化できるチームから得られます。
- チームメンバーは、ワークフローを変更して効率を向上させる方法を定期的に考える必要があります。
アジャイル マニフェストによれば、優れたソフトウェア開発プロセスは、このプロセスに携わる人々に直接依存します。これを行うには、彼らのやり取りをできるだけ効率的に整理し、最も組織化されたチームを作成する必要があります。
方法論
アジャイル宣言には、価値と原則を説明するいくつかの方法論もあります。
- アジャイルモデリング。
- アジャイルな統合プロセス。
- アジャイルなデータ手法
- 迅速なアプリケーション開発 (DSDM);
- 不可欠な統一プロセス。
- 極端なプログラミング。
- 機能主導の開発。
- 現実になる;
- オープンアップ;
- スクラム。
アジャイル モデリングは、ソフトウェア モデルとドキュメントの開発を高速化し、簡素化するための原則、用語、実践方法をまとめたものです。
アジャイル モデリングの目標は、モデリングとドキュメントを改善することです。これには、コーディング、テスト、またはプロジェクトの管理、展開、サポートに関連する問題は含まれないことに注意することが重要です。ただし、この方法論にはコードレビューが含まれます。
Agile Unified Process は、ユーザーが簡単に近似 (モデル化) できる方法論です。通常、商用ソフトウェアの開発に使用されます。
アジャイル データ手法 - 複数のチームの協力を通じて顧客の条件を達成する、いくつかの同様の方法論。
DSDM - このアプローチは、開発者とともに将来の製品のユーザーが積極的に参加するという点で他のアプローチとは異なります。
機能駆動開発は、「各機能は 2 週間以内に実装する必要がある」という期限付きの開発方法論です。
ユースケースが小さい場合は、機能として考慮する価値があります。それが重要な場合は、いくつかの機能に分割する必要があります。
Getting Real は、最初にプログラム インターフェイスを開発し、その後でその機能を開発するという反復的な方法論です。
OpenUP は、プロジェクト サイクルを開始、改良、構築、引き継ぎの 4 つの段階に分割する開発手法です。
アジャイルの原則によれば、作業期間に関係なく、すべての関係者とチームメンバーに知り合いになって意思決定を行う方法を提供する必要があります。このおかげで、状況を効果的に制御し、中間結果を時間内に評価することが可能になります。プロジェクト計画はライフサイクルを定義し、最終結果はアプリケーションの安定リリースとみなされる必要があります。
スクラムに関しては、開発プロセスを管理するためのルールを規定し、条件を調整したり変更を加えたりする可能性を備えた既存のコーディング手法を適用できるようにします。この方法論を使用すると、開発の初期段階で期待される結果からの逸脱を確認して排除することができます。
これをもう少し詳しく見てみましょう...