アジャイル開発 Advent Calendar 2016 の1日目の記事になります。
アジャイル概念の背景
この宣言に凝縮されています。
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
個人的な理解ですが、人を重視し、柔軟性を軸とすると理解しています。
その理由ですが、
ソフトウェアは作っている間にも市場や環境は変化し、必要なものが変わること。
作っていくことによって、より十分な理解が進みよりよい方法や正しい方法が見えること。
ここで計画を重視してしまうと、最終的に良い物が完成しないこと、環境にマッチしきれていないものが出来る確率が高いことは明白です。
これを実現するためにアジャイルという開発手法を実践するのだと思っています。
そして、そのアジャイル開発宣言の背景には以下の考えがあります。
アジャイル宣言の背後にある原則
アジャイル手法
では、その概念を実行するためにはどうすればよいか?というものをまとめたものが手法になります。
それがスクラム
やXP
などいくつかの手法あります。
これらは学ばなければならないものです。
名前だけ真似ても出来るようになりません。
アジャイルチームを作るためには、知識があった上で取捨選択して導入しなければならないです。
一番メジャーな2つの手法についてざっくりと説明すると
XP (エクストリームプログラミング)
アジャイルソフトウェア開発宣言の考え方を中心に
プラクティスが中心のアジャイル手法になります。
スクラム開発
プロセス中心のプラクティスが多く
登場人物の中心概念はスクラムマスタ、プロダクトオーナー、開発チームという3つの役割を中心に定義されています
プラクティス
開発手法にはいくつかのプラクティスがあります。
プラクティスとは朝会やペアプログラミング、スプリントなど具体的な実践方法のことです。
これらは個別に難易度が違うため、これからのアドベントカレンダーでも語るものが多くあると思います。
最後に
よく比較されますがウォーターフォールが悪いというものではありません。
導入すれば必ず良くなるわけでもありません。
正しい知識を身につけることは必ず必要であり
チーム導入方法については最新の注意を払いながら導入する必要があります。
運用するさいに発生した問題やノウハウをこれからAdventCalendarに書いていきたいと思いますのでよろしくお願いします。