ブックマークの変更をお願いします。PRESENTER今回読み進める本は、『アジャイルソフトウェア開発の奥義』です。第2版までは日本語版が出てます。内容的にはどの版のものを読んでも大丈夫。Hallちなみに版が進むごとにサンプルコードの言語がより高水準な言語に変わっています。追加で挿入されています。コードで読みたい場合は、書店からなくなる前に第1版を買っておいた方がよいです。以下、各章ごとのポイントや議論のメモです。Preface(序文)単なるパターン集ではなく、そのパターンが「なぜ」生き残ったのかという過程を知ることが大切。社長)は、11個のオブジェクト指向の原則をまとめている。それに従って設計することで、デザインパターンですら導き出される。アジャイルを大規模な開発に適用できるか?当初は大規模開発に適さないのでは?という懸念があったが、結果として大規模開発においてもアジャイル開発が主流になりつつある。いつものことだが日本では普及が遅れている。大規模プロジェクトにおけるアジャイル開発に関しては、下記の記事や書籍が参考になる。規模の大小を問わずうまくいく。」という疑問が出てくる。アジャイルソフトウェアプロセスを使ってオフショア開発(English)アジャイルソフトウェアプロセスを使ってオフショア開発(日本語)分析と設計はオンショアで行い、構築をオフショアで行い、そして受入試験をオンショアで行うというやり方よりも、オフショアのチームにできるだけ多くの工程をやらせると問題が改善される。作業工程に沿って分けるのではなく、機能面に沿った分割を行う。バグフィクスからやらせると、開発者は変更するよりも多くのコードを読むことになるので、コードベースに精通することができた。オフショア開発においては、ドキュメントを作成するための時間を確保する必要がある。Wiki、良質の電話回線を用意すること。Practices(アジャイルプラクティス)プロジェクトをうまくまわすためにルールやプロセスをどんどん導入してしまうと、逆に重くなってうまくいかない。悪循環...マネージャーは開発環境を構築する前にチームを構築するべき。環境はチームメンバーに最適化させるのがよい。高価なツールを導入する前に小さなところから始める。フリーのツールを実際に使ってみて、本当に使えるのか試してみる。ツールの前にホワイトボードやグラフ用紙を使ってみる。大きなデータベースを使う前にプレーンテキストファイルを使ってみる。重要で差し迫った必要のあるドキュメント以外は作成しない。読みやすいドキュメントを用意する必要はあるが、多すぎるドキュメントは、少なすぎるドキュメントよりもたちが悪い。ドキュメントが多すぎると、ソースコードを変更したときにドキュメントを修正して整合性を保つのに時間がかかる。メンテナンスされていないドキュメントが存在していると、そこには嘘が書かれていることになり、逆に混乱を招く。ソースコードは嘘をつかない。ドキュメントは手短に、洗練されたものだけ用意するのがよい。ドキュメントは長くても12ページ~24ページ(1、2ダース)に保ち、抽象度の高い設計構造を示したドキュメントを用意するとよい。新メンバーが参入した場合に、より詳細な設計構造を教えたい場合は、隣に座ってコミュニケーションを取るのが効率がよい。顧客との密接な協調関係を築くこと。「コスト」や「納期」などの条件を決める契約ではなく、「相互の協調関係」について取り決めた契約書を用意する。「近くで一緒に働こう」といったものがよい。うまくいった一例としては、「顧客側の受け入れテストに合格した機能ブロックの分だけ対価を支払う」という契約がある。どのように受け入れテストを行うかなどの詳細は契約では決めていない。計画は日程がずれるだけでなく、形そのものが変わっていくもの。