予備設計レビューの完了は、ICONIXプロセスにおいて、最も重要なマイルストーンだと思います。
この段階までくると、要求モデルは、実装を開始するために必要な、安定した、強靭な内容にまで洗練されています。開発は、顧客の要求が理解できたと感じ、実装方法は頭の中にかなり具体的にイメージできています。
実際にICONIXプロセスをやってみて、予備設計の内容(ロバストネス分析)がしっかりしていれば、その後の作業は、定型作業に近い感じです。これ以降の実装作業の見積もりと実績の差がほとんどなくなります。
もちろんいろいろ失敗しながら、ようやくそういうレベルになってきた、ということです
最初はうまくいかなかったこと。
実装してからのやり直し
ロバストネス分析をしたはずなのに、要求の理解がロバスト(強靭)ではなく、とても脆弱、という失敗をなんども繰り返しました。 結局、要求分析は時間の無駄なんではないか、という雰囲気がでてくるくらい。
でも、やりかたを反省してみると、手抜きが多いことが発覚。
・画面の模型なしに、ユースケースを書く(特に代替コース)
・ロバストネス図のチェックが甘い(コントロール必須のルールの違反、ドメインモデルと不一致)
・関係者で話をしない。(レビューも手抜きだけど、そもそも、チーム内での会話不足)
画面の紙芝居、ドメインモデル、ユースケースパッケージ図、ユースケース記述、要求レビュー、ロバストネス分析、予備設計レビュー。 それぞれの作業の基本事項を見直すことで、状況は確実に改善しました。
特に重要な変化は、チーム内で、ちょっとした確認作業のおしゃべりが明らかに増えたこと。
しゃべる内容は「業務の用語」つまりドメインオブジェクトの名前を使うことが増えたこと。
ICONIXプロセスは、最初にドメインモデル(業務の用語集)を作って、徹底的にそれを利用し、また洗練させ、詳細化していきます。その結果がそのまま実装クラスになる、というやりかた。
ですから、ICONIXプロセスのやりかたを丁寧にやれば、自然に、あちこちで「業務の用語」を使うようになります。実装クラスの話をしていても、クラスの名前は、業務の用語なんですから。
DDD (ドメイン駆動設計)のユビキタス言語の実践ですね。ドメイン(問題領域)の用語が、チーム内のだれでも、開発工程のどこでも、レイヤアーキテクチャのどこでも、あちこちに登場する。
実装に時間がかかる
単純に言えば、アーキテクチャ(技術方式)が脆弱だったり、アーキテクチャを理解できていないメンバーの学習などで、最初のうちは、かなり実装に時間がかかりました。
アーキテクチャが安定し、フレームワークの使い方のノウハウがチームに浸透してくると、実装時間は大幅に短縮できました。
原因ははっきりしていて、サンプルをコピーして(意味も分からずに)使っているため応用がきかない。ちょっと問題にぶつかると自力で解決できない。
この問題とどうやって戦っているかは、別のカテゴリー(アーキテクチャ)で書きたいと思います。
---
予備設計レビュー完了はほんとうに大きなマイルストンです。
要求も具体的に理解できたし、実装イメージも具体的。チーム全員がようやくここまでたどりついた、そういう手ごたえを持てる場所です。
そう実感できるかどうかで、ICONIXプロセスを自分たちが理解し活用できているかどうかの判断材料になりそうです。ロバストネス分析の目的や効果を実感できれば、ICONIXプロセスを活用できます。
この段階までくると、要求モデルは、実装を開始するために必要な、安定した、強靭な内容にまで洗練されています。開発は、顧客の要求が理解できたと感じ、実装方法は頭の中にかなり具体的にイメージできています。
実際にICONIXプロセスをやってみて、予備設計の内容(ロバストネス分析)がしっかりしていれば、その後の作業は、定型作業に近い感じです。これ以降の実装作業の見積もりと実績の差がほとんどなくなります。
もちろんいろいろ失敗しながら、ようやくそういうレベルになってきた、ということです
最初はうまくいかなかったこと。
実装してからのやり直し
ロバストネス分析をしたはずなのに、要求の理解がロバスト(強靭)ではなく、とても脆弱、という失敗をなんども繰り返しました。 結局、要求分析は時間の無駄なんではないか、という雰囲気がでてくるくらい。
でも、やりかたを反省してみると、手抜きが多いことが発覚。
・画面の模型なしに、ユースケースを書く(特に代替コース)
・ロバストネス図のチェックが甘い(コントロール必須のルールの違反、ドメインモデルと不一致)
・関係者で話をしない。(レビューも手抜きだけど、そもそも、チーム内での会話不足)
画面の紙芝居、ドメインモデル、ユースケースパッケージ図、ユースケース記述、要求レビュー、ロバストネス分析、予備設計レビュー。 それぞれの作業の基本事項を見直すことで、状況は確実に改善しました。
特に重要な変化は、チーム内で、ちょっとした確認作業のおしゃべりが明らかに増えたこと。
しゃべる内容は「業務の用語」つまりドメインオブジェクトの名前を使うことが増えたこと。
ICONIXプロセスは、最初にドメインモデル(業務の用語集)を作って、徹底的にそれを利用し、また洗練させ、詳細化していきます。その結果がそのまま実装クラスになる、というやりかた。
ですから、ICONIXプロセスのやりかたを丁寧にやれば、自然に、あちこちで「業務の用語」を使うようになります。実装クラスの話をしていても、クラスの名前は、業務の用語なんですから。
DDD (ドメイン駆動設計)のユビキタス言語の実践ですね。ドメイン(問題領域)の用語が、チーム内のだれでも、開発工程のどこでも、レイヤアーキテクチャのどこでも、あちこちに登場する。
実装に時間がかかる
単純に言えば、アーキテクチャ(技術方式)が脆弱だったり、アーキテクチャを理解できていないメンバーの学習などで、最初のうちは、かなり実装に時間がかかりました。
アーキテクチャが安定し、フレームワークの使い方のノウハウがチームに浸透してくると、実装時間は大幅に短縮できました。
原因ははっきりしていて、サンプルをコピーして(意味も分からずに)使っているため応用がきかない。ちょっと問題にぶつかると自力で解決できない。
この問題とどうやって戦っているかは、別のカテゴリー(アーキテクチャ)で書きたいと思います。
---
予備設計レビュー完了はほんとうに大きなマイルストンです。
要求も具体的に理解できたし、実装イメージも具体的。チーム全員がようやくここまでたどりついた、そういう手ごたえを持てる場所です。
そう実感できるかどうかで、ICONIXプロセスを自分たちが理解し活用できているかどうかの判断材料になりそうです。ロバストネス分析の目的や効果を実感できれば、ICONIXプロセスを活用できます。