#agilesamurai アジャイル開発に向き不向きのプロダクトはあるのか？
#agilesamurai の方々に質問です。アジャイル開発に向き不向きのプロダクトってあるんでしょうか？C++で開発しクライアントパッケージソフトウェアには向いてないんじゃないか？という意見があがったもので…どうなんでしょう
— 植木宏さん (@hirocueki) 3月 30, 2012このつぶやきに対し、アジャイルサムライの1人である、西村さんから、
@hirocueki なぜ向いてないと考えたかがすごく興味があります
— Nishimura Naotoさん (@nawoto) 3月 30, 2012とのリプライがあったので、「どの部分が向いてない」と考えられたのかを自分なりにまとめてみたい。
私が勤務する会社では、Windows向けのパッケージソフトウェアを開発している。言語は主にC++で、サーバーサイドの処理にPHPを使ったり、ライブラリをC#で書いたりもする。
自社開発なのでつくるものはすべて自分たちで決定している。
成果物として、exeファイルができあがる。他の製品からも使われる機能はdllとして切り分けし、すべての製品で使われる処理はlibファイルとして再利用可能な形にまとめる。
要件定義、仕様作成、開発、テスト、という４つのフェーズを大きなかたまりのなかで、仕様作成の部分である程度のきりわけが必要なのではないか？ということで、向いてないのではないかと言われた。
具体例を挙げる。
docファイルの読み込み機能を実装するとした場合に、docファイルのデータのうち、どこまで互換性をもつのか？という仕様作成が入るのだが、doc以外にもxlsファイルの読み込み機能もほしいからローダークラスはこういうインターフェイスにしよう、他のクラスから同じ呼び出し方ができるように、外部公開関数は共通のインターフェイスを持たせよう。まてまて、他の製品からもこの機能を使いたいぞ、と考えてdllとして設計をしたり…。
もし、アジャイルに則って、docファイルを読み込んで表示するというユーザーストーリーを完了した場合、データの持ち方や、クラス間のインターフェイスが決定される。その後、xlsファイルを読み込んで表示するというユーザーストーリーが出た場合に、共通のインターフェイスを持たせるための変更が大きくなってしまうのではないか？
しかも、doc、xlsファイルの読み込みをdllにするというユーザーストーリーが出たら、本体側の処理をdllに切り分けるという手戻りが発生する危険があるのでは？
ということで、はじめにある程度の大きさの仕様設計がされていなければならない部分は、アジャイル的な開発サイクルに当てはめられないのではないかという疑問がでて、私は回答できませんでした。
この場合は、はじめに取りかかった、docファイルを読み込んで表示するというユーザーストーリーの時点で、他形式のファイルはどうする、dllとして設計する必要はないか、といった話し合いがされるべきなのでしょうか？
