|
アジャイル開発 |
IT TERMS INFORMATION
2019-No.4 |
|
|
|
|
|
|
まず、アジャイルとは、プログラム開発手法ではありません。アジャイルはマインドセット、価値観であり、方法論というわけではありません。2001年に、従来のソフトウェア開発手法とは違う開発手法を実践していた17名の開発者が集まり、議論が行われ、結果「アジャイルソフトウェア開発宣言」が生まれました。
下記がアジャイルソフトウェア開発宣言です。これがアジャイルの始まりになるとても重要な文章です。
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、より良い開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
|
宣言内にある「左記のことがら」とは、プロセスやツール、包括的なドキュメントなどを指します。一見すると、左記のことがらは重要視されないと思われがちですが、左記が不要という話ではなく、より右記の方が大事であるという発想です。
アジャイル開発で求められているのは、スピードです。そのスピードを保つためにもドキュメントは最小限にとどめ、動くソフトウェアを対話しながら素早くリリースして顧客に届けようという考え方です。
では、実際にアジャイル開発は従来の開発手法と比べてどのような特徴があるか、親しみが多いと思われるウォーターフォールモデルと比較します。
ウォーターフォールモデルは、工程ごとに作業を順番に完了していく手法で、非常に簡潔で分かりやすいメリットがあります。しかしながら、前工程へ立ち戻れないために、開発途中で顧客のニーズに変化が合った際、納品が難しくなるというデメリットがあります。
アジャイル開発は、開発項目を分割し、優先順位の高い順に開発を進めていく手法です。そのため、小さな機能が一つ完成した時点で、顧客のニーズに合っているかどうか確認することができるというメリットがありますが、一方で、仕様を変更しやすいからといって、何でも変更できるような状態としてしまうと、システム自体が完成しないということもあり得るため、変更できない前提条件を明確にしておくことが大切です。また、複数のチームに分かれて短期的な開発を繰り返すため、プロジェクト全体の進捗管理が難しくなります。よって、開発者の経験値に依存してしまい、習得が難しいということがアジャイルのデメリットと言えます。
|
▲ウォーターフォールモデルとアジャイル開発 |
アジャイル開発には、様々な手法があります。このうち、今回は、スクラムについて説明致します。スクラムは、軽量なアジャイルプロジェクト管理メソッドで、進め方は以下の通りです。
- 役割を決める(プロダクトオーナー、スクラムマスター、開発チーム)
- プロダクトオーナーにより、プロダクトバックログを決める
- 一定の周期(スプリント)で開発を行い、納品を行うことを繰り返す
スクラムは、上記の通り、プロジェクト管理の手法であり、プログラムの書き方に関する手法はありません。そこで、XPも行うよう推奨されます。XPには、テスト駆動開発、リファクタリングなど、欠陥のないプログラムの作成手法が定められていますが、その全ての手法を取り入れるのではなく、その時に必要だと思われる手法を取り入れれば良いとされています。
|
▲スクラム・プロセス |
アジャイルはやることが目的ではなく、アジャイルな状態にして生産性を向上させようとするものです。一日のタスク分解、一日の振り返りから始めてみてはいかがでしょうか。
|