現在、ソフトウェア プロジェクトにおいて、特にプロジェクトでは、最初から適切に計画するために製品要件を完全かつ正確に収集することは多くの困難に直面しています。ソフトウェア開発に影響を与える問題は、予想もつかないほどたくさんあります。たとえば、ビジネス、テクノロジー、人、起動時間などの要因から問題が発生する可能性があります。

当時に、アジャイルは柔軟なソフトウェア開発方法として知られ、ソフトウェア プロジェクト管理への特定のアプローチです。

これは、できるだけ早く製品をユーザーの手に届けるための統合されたインタラクティブな作業プロセスで構成されています.従来のソフトウェア開発方法は、ますます不利な点にさらされ、業界における失敗したプロジェクトの率が増加しています.新しい状況に適応するために、より現代的で異なるソフトウェア開発方法を考え出しました。

1. アジャイルソフトウェア開発プロセス

1.1 コンセプト

アジャイルは、ソフトウェア開発への反復的かつ漸進的なアプローチであり、プロジェクトチーム全体で非常にスムーズかつ高度に協調的な方法で行われ、コスト効率が高くタイムリーな高品質の生産ソリューションを支援するニーズの優先順位付けを行い、利害関係者のニーズを満たします。

チームがアジャイル プロセス アプローチを使用しているかどうかを判断するには:

• 品質：回帰開発モデルに従った実験です。
• 利害関係者の関与：プロジェクトの開発に積極的に関与している主要な関係者です。
• 消費ソリューション: 定期的に消費可能なソリューションを提供する高品質の生産チームです。
• 自己組織化：フレームワーク内で自己組織化および協力する能力が高く評価されています。
• 改善：プロジェクト全体で自己改善が可能です。

1.2 アジャイルシッピングライフサイクル

アジャイル テストと品質戦略を本当に理解するためには、それらがアジャイル システム開発ライフサイクル (SDLC) 全体にどのように適合するかを理解する必要があります。

図 1 は、アジャイル開発ライフサイクルの高レベルのビューを示しており、アジャイル プロジェクトのビルド フェーズがイテレーションと呼ばれる一連の時間ボックスに編成されていることを示しています (スクラムの方法では、それらは「スプリント」と呼ばれ、一部の人々はサイクルを呼びれます。反復的なアジャイルのライフサイクルのは真実にないと多くの人が言いますが、そのライフサイクルは大きくは連続的で、小さくは反復的であると見なすことができます。順序に向かってのは、運送ライフサイクルの少なくとも一部の要素 (コンセプト、ビルド、運送) が変更される可能性があります。

これは、ライフサイクルのどのフェーズにいるかに基づいて検証/テストが行​​われるという意味です。

したがって、このライフサイクルで発生する高レベルのアクティビティのコンポーネントを理解することが重要です。

• アイディア:このフェーズの目標は、プロジェクトチームを発足させることです。最初の要件の視覚化を行い、システム構造を視覚化し、開発チームの定義と編成を開始して、プロジェクトの競争上の目標、サポート、および資金を設定します。テスト/検証には、テスト環境とツールのセットアップの開始と、初期モデル、計画、ドキュメント、ビジョンの目標または利害関係者をレビューする能力が含まれます。

• 構築の反復: 各ビルドの反復 (図 1 に示すように 1 から  回繰り返す) の目標は、ソフトウェアの生産をより効率的にすることです。アジャイル チームは優先順位に従って、各イテレーションでは、キュー リスト (スクラムがバックログと呼ばれるもの) から最も重要な要件を実行します。アジャイルチームはチーム全体に手を差し伸べ、テストが開発とシステム構築に点在しています。
• 効果的なテストの焦点は、回帰テストとテスト駆動開発 (TDD) を使用することです。
• 運送: この段階(図 1 の濃い緑色) の目標は、システムを正常にデプロイできることです。これは実際には非常に複雑になる可能性があり、エンド ユーザー トレーニング、ユーザー サポート、使用操作、コミュニケーション、製品マーケティング、潜在的なバックアップ、リカバリ、組織のパイロットなどを含みます。リリース プロセス中にもテストを使用して、システムが本番環境に対応できる状態にあることを確認します。

図 2: ディシプリンド アジャイル デリバリー (DAD) を使用した基本的なアジャイル/ライフサイクルの簡単な説明します。DAD はルールではないくて、1 つのライフサイクルをサポートするものです。図 2 は、アジャイル シッピング ライフサイクルであるスクラムの DAD に基づいていますが、一部のリーン/カバン タイプの継続シッピング ライフサイクルも非常によくサポートしています。

 1.3 従来のシステム開発ライフサイクル

図 から V 字型ソフトウェア開発モデルの説明し、これは、本質的に従来のウォーターフォール モデルの洗練された形式です。V パターンでは、ダイアグラムの左側のジョブがライフサイクルの後半で検証され、アクティビティがそれぞれ渡されます (たとえば、要件は受け入れテストによって確認され、構成要素はパススルーされます。）この方法はテストされていないよりも優れていますが、体系的な問題があるため、実際には非常に高価であることが証明されています。

• 間違った機能を提供すること

Vモデルは、プロジェクトの早い段階で詳細な要件アプローチを促進します。これは良い方法かもしれませんが、実際には非常に貧弱な方法です。先の大きな要求、BRUF、プロジェクト チームは、利害関係者が本当に必要とするものではなく、仕様に合わせて何かを構築するから、そのアプローチはかなりの無駄を生みます。　壊れやすい設計に構築する:上記と同じですが、理論的にはアーキテクチャ/設計の詳細を検討することは良い考えですが、実際には、利用可能な情報がほとんどない場合、技術的な決定はあまりにも早く行われます。

• 引き継ぎによって欠陥が注入されること

2 つのグループの人々の間で衝突がある時に、製品に含まれる問題につながります。 この問題は、評価によって部分的に軽減できますが。

• 欠陥の修正には費用がかかること

V モデルはフィードバック サイクルを長くすることが多く、欠陥修理が長期化し、修理コストが増加します。

• 価値実現までの時間の増加
• V モデルは、官僚主義と生産待ち時間の増加により、タイムスケールを延長しました。これにより、機会のメリットと正味現在価値 (NPV) が減少します。

2. アジャイルのメリットとデメリットのは

2.1 アジャイルはどう違うこと

アジャイル開発スタイルに移行するプロのテスターは、これまでとは大きく異なる多くの開発特性に気付くかもしれません。

• 良い協力:アジャイル開発者は密接に連携し、ドキュメントのやり取りを介して直接通信します。彼らは、文書を人々の間の最も効果的なコミュニケーション方法として認識しています。
• 作業サイクルの短縮:特定の要求から現在の請求の確認までの時間は、数か月や数年ではなく、数分のオーダーです。これは、テスト駆動開発 (TDD) アプローチの採用、コラボレーションの向上、中間ドキュメントへの依存の減少によるものです。
• アジリストは変化を受け入れる:

アジャイル開発プロセスでは、ライフサイクル全体で変更が許可される優先順位として要件を修正することを選択します。

• 柔軟性の向上:ソフトウェア開発の後、各フェーズがテストに与えられ、アジャイル プロジェクト チームは、一日の終わりにミーティングを行って作業を交換するため、要件は常に継続的に更新され、バグは早期に検出され、早期に修正されます。

• IT には、より厳しい規律が求められる：利害関係者と緊密に協力し、自分の決定を尊重し、定期的に変更される可能性のあり、完全なテスト スクリプトを作成する前に簡単なテスト スクリプトを作成する必要がありますが、実際に実行するのははるかに困難です。アジャイル開発は、従来の開発よりもはるかに規律を必要とします。
• 利害関係者には、より大きな説明責任が求められる：アジャイルでは、利害関係者が互いにより緊密に通信し、ソフトウェアの生産を確実にするために、関係者が彼らの行う要件と決定に対してより責任を負う必要があります。
• 必要なスキルの以上：ただのテスターでも、プログラマでも、アナリストでも、ただのアナリストでもなく、アジリストは人々をより専門的にさせ、より応答性が高くまとまりのあるアプローチに向かう従来の開発アプローチから脱却します。

2.2 アジャイルと従来のアプローチを比較すること

アジャイル アプローチには、従来の V モデルに多くのより利点があります。

• 必要な機能を提供する能力の向上:アジャイル チームは利害関係者と緊密に連携し、利害関係者が積極的に参加した直後にアイデアが開始されます。実際、当事者間の絶え間ない協力と交換により、機能要件は常に拡張され、継続的に更新されます。
• 品質の向上: 調査によると、アジャイルを開発に適用すると、従来の開発よりも品質が高くなることがわかっています。ここでの理由は、チームの結束、早期の対応、および段階的な頻繁なテストです。
• 改善されたデザイン:アジャイルアーキテクチャとアジャイルデザイン戦術は大きな改善です。そして、これをアジャイルチームによるコラボレーションと組み合わせることで、従来の開発よりも優れたデザインを齎します。アーキテクチャと設計は、アジャイルチームにとって非常に重要であり、初期段階だけでなく、開発プロセス全体でこれを行います。　
• 経済的改善:成功事例を調査すると、アジャイルチームは通常のチームよりも高い収入をもたらすことがわかりました。その理由は、フィードバックの時間が短いほど、コストが削減されるからです。さらに、アジャイルチームはよりスマートに作業するため (連続的な OT...)、提供する機能が高速になり、その結果、より多くの収入が得られます。

3. アジャイル戦略

3.1 ステークホルダーの積極的な参加

アジャイル モデルでは、利害関係者の関与が非常に重要です。利害関係者は密接に関連しているため、次のことが増えることでプロジェクトの成功の可能性が増やすことによって：

• 開発者は利害関係者のニーズを現実的に理解できます。
• 多くの利害関係者の受け入れテストに参加するため、プロジェクトの品質が向上します。
• 利害関係者は、開発チームと協力しながら、指示、戦略の変更、要求を行うことができます。

3.2 機能要件管理

• アジャイル モデルの基礎は、スタック (キュー) モデルの優先順位付けであり、要件は優先順位に従って実行され、プロジェクト開発全体で利害関係者が要件を開発できるようになります。このチャートは、アジャイルのいくつかの高度な概念も示しています。
• 高優先度では、機能および再現性の要件も、中および低優先度の要件よりも詳細に指定されます。

3.3 最初のリクエストを視覚化すること

論理的な問題と、妥当な時間内に決定を下す組織力に応じて、アイデアは数日から数か月続く場合がありますが、モデリングには初期要件が必要で、数日しかかかりません。 アイデアは、アイデアの短縮と優先順位付けに基づいて、より迅速に生成されます。

4. 結論

アジャイル モデルを適用するプロジェクトは、多くの場合、要件を絶えず変更および更新する必要があり、知識とテクノロジーのトレンドの両方を迅速かつタイムリーに把握する必要があります。

さらに、優先度に焦点を当てた開発と生産のおかげで、アジャイルは複数のフェーズとコンポーネントで開発されたプロジェクトに適用されます。アジャイル ソフトウェア開発は、組織と機能グループ間のコラボレーションを通じて要件とソリューションを開発するソフトウェア開発手法のグループです。適応、進化的開発、早期の製品提供、継続的な改善を促進し、変化への機敏で柔軟な対応を促進します。

オフショア開発をご検討されている方々はぜひ一度ご相談ください。

※以下通り弊社の連絡先

アカウントマネージャー: クアン(日本語・英語対応可)

電話番号:　(+84)2462 900 388

メール:  konnichiwa@hachinet.jp

お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。

Tags

ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。