アジャイル ソフトウェア開発と ウォーターフォール ソフトウェア開発
すべてのプロジェクトに適用できる単一の手法はありません。 しかし、多くのチームは、ソフトウェアを開発する際、予測的なウォーターフォール手法からアジャイルなどの適応型手法に移行しています。 従来のウォーターフォール型開発手法は、プロジェクトの開始時に作成された本来の要件と設計計画に沿って、厳格なフェーズに従います。 プロジェクト マネージャーは、マイルストーン、機能、リソースの交渉に時間を費やして、プロジェクトの計画段階からじっくりと取り組み、通常、作業が完了するまでに多くのゲートを通ってどのように移動するかを詳細に説明する本格的なプロジェクト プランを作成します。
顧客は開発が始まる前に要件を確定し、その後、長期的な開発プロセスが発生します。プロジェクト マネージャーはこの開発プロセスにおいて、各ハンドオフから納品までプロジェクトのすべての動きを追跡します。 すべてがうまくいけば、このプロセスは予定通りかつ予算内のリリースになります。 このアプローチの主なデメリットは有名でしょう。 変化に対応することができず、動作するソフトウェアを提供するまで長い時間がかかります。 テクノロジーが競争の場を形成し、あらゆる変化が促される場合、要件が石碑に刻まれているような 6 か月以上のリリース サイクルでは、ビジネスのニーズを満たすことができません。
アジャイル ソフトウェア開発の歴史は、従来のウォーターフォール手法に対するフラストレーションによるものです。 アジャイルは変化と迅速なソフトウェア開発のニーズに対応するために設計されています (アジャイル マニフェストの価値と原則で説明されています)。 プロジェクト リーダーは通常、開発チームの作業を促進し、ボトルネックを排除し、ソフトウェアのイテレーションを定期的に実施するためにチームが集中力を維持できるように支援します。 マイルストーンよりも、時間、機能の選択、優先順位付け、会議が重要です。
ウォーターフォール モデルとは異なり、開発チームは最終的に、スプリント (またはイテレーション) の開始時に期間内で達成できるものを判断し、一連の機能の構築に着手し、スプリントの終了時に本番環境にインストールできるソフトウェアを提供します。 DSDM (動的システム開発手法) などのアジャイル ソフトウェア開発手法は柔軟性があるため、開発チームが製品のニーズに合わせてフローを調整できます。
アジャイル ライフサイクル
アジャイル ソフトウェア開発 (またはシステム開発) 手法には、以下が含まれますが、これらに限定されません:
- ディシプリンド アジャイル デリバリー (DAD)
- 適応型ソフトウェア開発
- アジャイル モデリング
- かんばん
- スクラム
- スクラムバン
- エクストリーム プログラミング (XP)
- 動的システム開発 (DSDM)
- ユーザー機能駆動開発
- リーン ソフトウェア開発
各アジャイル手法の全体的な目標は、変化に適応し、動作するソフトウェアを可能な限り迅速に提供することです。 しかし、各手法ではソフトウェア開発のフェーズを定義する方法に若干の違いがあります。 さらに、目標は同じでも、各チームのプロセス フローは、プロジェクトや状況によって異なる場合があります。 たとえば、アジャイル ソフトウェア開発のライフサイクル全体には、概念設計、開始、構築、リリース、本番、撤退の各フェーズが含まれます。
アジャイル プロセス フロー
- 概念設計 - プロジェクトが構想され、優先順位付けされます
- 開始 - チーム メンバーが決定され、資金が提供され、初期環境と要件が議論されます
- イテレーション/構築 - 開発チームはイテレーションの要件とフィードバックに基づいて、動作するソフトウェアの提供に取り組みます
- リリース - QA (品質保証) テスト、社内外のトレーニング、ドキュメント開発、本番環境へのイテレーションの最終リリース
- 本番 - ソフトウェアの継続的なサポート
- 撤退 - 顧客への通知や移行を含む終了活動
この図は、企業のアジャイル ライフサイクル モデル全体を示しています。 どの企業でも、プロジェクトは同時に進行し、異なる製品ラインで複数のスプリント/イテレーションが記録され、さまざまなビジネス ニーズを持つ社内外のさまざまな顧客が存在する可能性があります。
アジャイル ソフトウェア開発ライフサイクル
Agile Software Development Workflow
The Agile software development lifecycle is dominated by the iterative process. Each iteration delivers the next piece of the development puzzle: software and supporting elements (e.g. documentation) available for use by customers, until the final product is complete. Each iteration is usually two to four weeks in length and has a fixed completion time. The iteration process is methodical and the scope of each iteration is only as broad as the allotted time allows.
Multiple iterations will take place during the Agile software development lifecycle and each follows its own workflow. During an iteration, customers and business stakeholders provide feedback to ensure that the features meet their needs.
A typical iteration process flow can be visualized as follows:
- Requirements: Define the requirements for the iteration based on the product backlog, sprint backlog, and customer and stakeholder feedback.
- Development: Design and develop software based on defined requirements.
- Testing: Quality assurance (QA) testing, internal and external training, documentation development.
- Delivery: Integrate and deliver the working iteration into production.
- Feedback: Review customer and stakeholder feedback and work it into the requirements of the next iteration.
Agile Software Development Workflow Diagram
While you may feed additional features into the product backlog throughout the project, the rest of the process repeats until the product backlog has been cleared. As a result, the Agile software development process flow is a loop rather than a linear process.
Agile Scrum Workflow
The flow of work in Scrum is directed via a series of meetings, as described below:
Sprint planning is used to choose the work that will be incorporated into an upcoming Sprint based on the product backlog.
A daily Scrum is a short meeting where each participant answers the following questions:
- What work did you do yesterday?
- What work will you do today?
- What obstacles are in your way?
The Scrum master, who manages the meetings, uses the data gathered to update the burndown chart and look for ways to remove the obstacles that were identified.
A sprint review is a meeting at the end of each Sprint to evaluate what was completed and to review the product backlog and determine what still needs to be done. Reviews focus on the product.
Finally, the sprint retrospective meeting at the end of each Sprint which covers what worked well and what can be improved. Retrospectives focus on the process.
You can read more about Scrum in our comprehensive guide.
Making the Agile Process Work for You
As with any methodology, there are advantages and disadvantages (Read about the advantages and disadvantages of Agile). The Agile method is more suitable in situations where customers and project stakeholders are available to provide input, functional portions of software are needed quickly, flexibility is desired to accommodate changing requirements, and the team is co-located and able to collaborate effectively.
As with any change, integrating Agile processes into your business can be overwhelming. Here are four activities that will help support the adoption of Agile workflow:
- Daily Meetings: Host consistent or daily stand-up meetings to maintain open communication, hold workers accountable, and keep each iteration moving forward.
- Live Demonstrations: Deliver live demonstrations of each iteration’s final product to show progress.
- Share Feedback: Receive feedback from stakeholders and customers and share it with the entire team before the next iteration begins.
- Remain Agile: Make changes to your process based on feedback to ensure each iteration improves the last.
Streamline the Agile Software Lifecycle with Smartsheet for Project Management
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。