2017.04.21Mendixで課題解決 , アジャイル

私たちはアジャイルに向かっていけるのだろうか?

  • このエントリーをはてなブックマークに追加


寒い2月のある日、米ユタ州に17人の開発者が会し、我々が今日アジャイルとして知っている基本原則に同意(2001年の「アジャイルソフトウェア開発宣言」)した時から、ソフトウェア開発は大幅に変わってきました。多くの開発チームはこれらの基本原則を採用し、誰が彼らの作成したアプリケーションを使用するのか、また、ユーザーと開発チームがお互いに、ユーザーが望むソフトウェアにしてしていくものだと認識しました。

 

これらの原則は、ユーザーが本当に望むソフトウェアを手に入れることができるので素晴らしいものです。表面上の計画の変化への対応という考え方は、原則としてはとてもいいものですが、アジャイルソフトウェア開発宣言には困ったことになることがあります。

 

この「変化への対応」に対する私の解釈は、「役に立つソフトウェア」を作成するためには、達成する必要がある基本的な要件のリストから始めることです。開発プロセスに入ると、あなたが必要だと思っていたもののいくつかが何らかの形で修正され、開発者がこれに備えなければならないと予想されます。彼らはより小さく繰り返すことで(従来のビッグバンリリースと比較して)ソフトウェアを生産しており、ビジネスとより密接にコラボレーションして、彼らが正しい方向に向かっていることを定期的に確認しています。

ここまではよく聞こえますーーーさて、何が問題なのでしょう?

 

問題は、変更を受け入れることによって、すでに完成されたと思われるものが初めから再作成される場合に何が起こるかです。

それは少し抜本的かもしれませんが、前回の完成に対してこれまでの開発に要した期間をまた必要とするような再作業が必要な場合はどうでしょうか?

 

それには、いくつかのオプションがあります:

  • ひとつはこれを受け入れることで、開発期間を少なくとももう一度初めから確保する必要があると考えること。
  • もう一つはこの原則によって、開発サイクルが完全に終わるまでの期間に、ユーザが最初に要求した機能をすべて必要としない、と理解できることです。

 

元々のユーザは、最初に求めていたことを必要としないということは滅多にありません。私たちはその中でよく、仕掛けをしておきます。つまり、最初に求めてきたことほど洗練されたものは必要がないとして、必要なものだけをより少ない労力でつくっていくのです。

これはうまくいきましたが、通常はサービス開始する為に予定していた充分な時間を与えてもらえません。

 

そうです。私たちは開発期間が終わった時にサービスを開始しています。しかし、正直に言えばこれはサービスであり、私たちは期間が終わるまではやりません。

 

という訳で、原点に戻ってみましょう。私たちはアジャイルに向かっていくことが出来るのでしょうか?
アジャイル方法論に基づくプロジェクトは想定よりも少々長くなるかもしれませんが、結果としてユーザーが本当に必要とするソフトウェアになります。このほんの少しの開発期間の延長は、的を外したソフトウェアを開発することよりも上回った効果を生み、アジャイルのコストについて考えることができます。

すべてのソフトウェアプロダクト(アジャイルもそうであるように)で避けられない変更を考えると、この原則を使うことには本質的な価値があります。

 

 

翻訳元:https://www.mendix.com/blog/can-afford-go-agile/

 

  • このエントリーをはてなブックマークに追加

このエントリーにコメントする

必須項目は全て入力してください。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)