オブジェクト開発の真髄を読んでる
オブジェクト開発の神髄?UML 2.0を使ったアジャイルモデル駆動開発のすべて
- 作者: Scott W.Ambler,越智典子,オージス総研
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2005/07/13
- メディア: 大型本
- クリック: 27回
- この商品を含むブログ (30件) を見る
図書館で借りて読んでる
とりあえずいいと思ったのは書き残しておく
アジャイルアライアンス宣言
アジャイルとは機敏であること
アジャイルソフトウェア開発における4つの宣言
プロセスやツールよりも個人や相互作用
- 考えなければならない最も重要な要因は人間
- その人達がどう協力して仕事をするか
- 例え素晴らしいツールやプロセスがあってもうまく行かない
分かりやすいドキュメントよりも動作するソフトウェア
- ソフトウェア開発の第一の目的→ソフトウェアを作ること。決してドキュメントを作ることではない
- ドキュメントを作るのが目的なら、ドキュメント開発である
- もちろん、ドキュメントを適切に記述すれば、非常に有益な指針となる
契約上の駆け引きよりも顧客との協調
- 何が欲しいかを教えてくれるのは顧客だけ
- 顧客はシステムの仕様を正確に記述するスキルが無いし、最初から正しく理解しているわけでもないし、意見が変わることもある
- 顧客と一緒に仕事をするのは大変だが、それが仕事の現実
- 顧客と契約を結ぶのは重要だが、それで顧客とのコミュニケーションが必要なくなるわけでもない
計画を硬直的に守ることよりも変化への対応
- 変化はソフトウェア開発において現実に起こること
- ソフトウェアプロセスにはその現実を反映させないといけない
- 優先順位は様々な理由で変わる
- プロジェクト計画は必要だが、柔軟でなくてはいけない
- チャート図を何枚も作成する必要は無く、もっと単純なものでいい
テストについての(筆者の個人的な)見解
目的は欠陥を見つけることである
- テストの第一の目的はテスト対象の正確さを確認すること
- すなわち、テストの成功とはバグが見つかること
あらゆる成果物は妥当性を検証することができる
- ソースコードだけでなく、あらゆる成果物をテストすることができる
- 最低でもモデルと文書をレビューして、コード作成以前に不具合を発見し、修正することができる
早くから頻繁にテストする
- 変更コストは指数関数的に増大する可能性がある→できるだけ早くテストするべき
テストによって自信が生まれる
成果物のリスクに応じてテストを行う
- リスクが高いものほどレビューやテストの必要性が高くなる
- 言い換えると、航空交通管制システムのテストには相当な工数をつぎ込むべきだが、HelloWorldアプリのテストにはその必要なない
1度のテストは1000もの言葉に勝る
- 私に向かってアプリケーションが動くと言うことはできる
- だが私はテスト結果を見せるまで信用しません
テストとは修正することでは「ない」
- テストとはは不具合を発見するもの
- 不具合の修正は別に行う
アジャイルなドキュメントとは
利害関係者の投資を最大限に活かす文書である
- ドキュメントは利害関係者にとって最低でもプラスの価値を提供しなければならない
- 理想を言えば、可能な限りの最大の価値を提供しなければならない
- システムのドキュメントに投資するかどうかはビジネス上の判断であって技術上の判断ではない
- 利害関係者のお金なので、ドキュメントに投資するかどうかを決めるのは開発者ではなく利害関係者であるべき
- ただし、多くの場合、ある種のドキュメントの重要性を利害関係者に教える必要がある
簡明な文書である
1つの目的を達成している文書である
- 例えば、システムのユーザマニュアルと運用マニュアルと要求文書を作成するのが妥当かもしれない
- この3つの目的を1つの文書で達成しようとするのは不適切
- ドキュメントはソースコードと同様、システムの一部である
変化する可能性の低い情報(例:アーキテクチャ)が書かれている文書である
- 情報が変化する可能性が高ければ高いほど、多くの時間をかけてその情報についての文書を書くことはあまり意味が無い
- 書き終わる前に情報はおそらく変化するし、保守しつづけることは困難
「知っておくべき事柄」が書かれている文書である
- アジャイルな文書には設計の根本にある理由、要求、利用手順、運用手順などの情報を記述する
- これらの情報はちょっと見ただけでは分かりにくい、非常に重要なもの
具体的な利用者を想定して書かれており、その利用者の仕事に役立つ文書である
- ドキュメントの作成は顧客と密接に協力して進めなくてはならない
- もしそうでなければ、ドキュメントが多すぎたり、必要の無いドキュメントを作成したり、作成したドキュメントが実際のニーズに合っていなかったりするリスクがある
- ドキュメントは欲しいというだけのものではなく、実際に必要なものでなければならない
そこそこ正確で、そこそこ一貫していて、そこそこ詳細な文書である
- アジャイルな文書は完璧である必要はない
- そこそこのものでさえあればいい
文書に十分な索引がついている
- 書かれている情報をすぐに見つけることができなければ、ドキュメントは役に立つとは言えない
- そのため、索引や目次は大事
ホワイトボードをうまく使う
- ホワイトボードはモデリングツール
- 世界中で最もよく導入されているモデリングツール
- 必要である以上のドキュメントが必要だと考えている人を安心させるには、デジタル写真で写したホワイトボードが有効
- そのままでは見づらいので、二値化処理やフィルタ処理するなどして見やすく加工する
- フラッシュが図の端になるようにうまくカメラを向ける
- ホワイトボードの絵は永久に残せるものではないが、デジタル写真なら残せる
- 欠点はホワイトボードのデジタル写真は変更しにくい点とチームが同じ場所に集まっていなければホワイトボードが使えない
- 集まっていない場合は、他のモデリングツールを検討する
アジャイルであり続けるには(ユースケースモデリング)
- ユースケースモデリングはすぐにアジャイルでなくなってしまう
- アジャイルでありつづけるには、そこそこ役に立つだけの成果物を作成することに集中する必要がある
- 成果物は完璧である必要はない
- ユースケースは完璧でなくても、それで世界が終わってしまうことはない
- 時間をかければ完璧に近くなるかもしれないが、それにどんな価値があるのか
- 「利害関係者の投資を最大限に生かそう」の原則を常に心に留め、常に価値のあることだけを行おう
- 私と一緒にご唱和ください。「ユースケースは役立ちさえすればよいのです。ユースケースは役立ちさえすればよいのです。ユースケースは役立ちさえすればよいのです。ユースケースは役立ちさえすればよいのです。」
続きはまた今度書きます
