基本はフィードバック
アジャイルな開発プロセスで大事なのは、フィードバックすることです。
フィードバックする・されるということは、自分以外の何か（人や設計）とシンクロしながら進むということです。
XPで言うと、
- ペアプログラミングではナビゲーターとドライバーが一緒に考えて、コミュニケートしながらプログラミングをする
- オンサイト顧客とコミュニケートしながらストーリーカードを具体化する
なんていうことが該当します。とにかくコミュニケーションすることで、お互いにフィードバックしながら進むのがXPのスタイル。
XPに限らず、アジャイルな開発に共通して言えることは、工程の初めから全てを見通して進んでいるわけではないということ。
アジャイルなプロセスでは、途中でいろんなことを発見しながら進み、見つかったことをフィードバックしていきます。
私たちが今実行中のICONIXプロセスについても、同じことが言えますね。
ドメインモデリング→ユースケース→ロバストネス分析・・・と進んでいきますが、その途中でいろんなものが見つかります。
たとえば、
- ユースケースを記述している最中にドメインモデルが見つかる。（見つかったら、ドメインモデルのダイアグラムに追加する。）
- ユースケースを記述している最中に、要求が見つかる。（見つかったら、要求に書き足して、ユースケースに関連付けておく。）
- ロバストネス分析をしている最中に、代替ケースが見つかる（見つかったら、ユースケース記述に書き足す）
といった具合です。
実は、ここでエンジニアがフィードバックを怠っても、コードは作成される場合もあります。
でも、「コードができればいいじゃん」的なノリで進むと、実は痛い目に会います。
たとえば、1.の場合にはドメインモデルが足りなくなる。
ドメインモデルは、互いの理解の共通語彙であるので、自分以外のエンジニアや顧客とのコミュニケーションに支障をきたす恐れがある。
また、せっかく発見したのにドメインモデルがないと、へんなクラスにメソッドを割り当ててしまうこともあるでしょう。
2.の場合には、顧客の理解が不足し、受入テストのケースが落ちてしまう可能性が高いです。
要件定義のフェーズでは、全ての要求は出ていないと思ったほうがまちがいないでしょう。
ユースケースを書いているときには、本当によく要求が見つかります。
3.の場合には、やはりコードから代替ケースが落ちる可能性があります。
コードはできたとしても、システムテストのケースからは落ちてしまいそうです。
ICONIXプロセスは、「設計する」ことをとても大事にしていると思います。コードだけではなく、テストも設計駆動なので、
設計へのフィードバックを怠ると、テストも不十分になってしまいます。
ICONIXプロセスに推奨ツールがあるのは、機能面もさることながら、フィードバックの容易性も考えてのことだと考えています。
設計リポジトリを共有し、ほぼ全てを設計できるツールを用いて、何かを見つけたらすぐにフィードバックする。
そういう良いクセを習慣づけて、速く、良いソフトウェアを作れるようになっていきたいものです。
コメントはまだありません。