アジャイルプラクティス 達人プログラマに学ぶ開発者の習慣
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
- 作者: Venkat Subramaniam,Andy Hunt,木下史彦,角谷信太郎
- 出版社/メーカー: オーム社
- 発売日: 2007/12/22
- メディア: 単行本(ソフトカバー)
- 購入: 35人 クリック: 995回
- この商品を含むブログ (291件) を見る
どんな本なの?
アジャイル開発の方法論や心得を45のプラクティスに分けて解説してます
全部のプラクティスに「バランスが肝心」というコーナーがあって、
盲目的に方法論を実践するのではなく、有効活用できるような心得が書かれているのが特徴
また、本の最後にいろんな立場や環境の人向けに、どのプラクティスから実践していくのがよいか
解説がされていて、実践に向けての敷居が下げられていたのが、特徴的でした
実用的やねー
んで、アジャイルって何ぞ?
重要度の高い事柄に注力し、重要度の低い事柄には労力を裂かないようにする開発方法
具体的にはどんな感じに開発してくの?
小規模のメンバーでタスクを共有し、
イテーション(反復)という、1〜4週間程度の頻度でリリースを行って、
顧客にデモを行い、フィードバックを得て、機能を実装していく
なので、「設計は指針であって指図ではない」として、詳細な仕様を最初に決めるのではなく、
検証を行いながら、詳細な部分を詰めていくといった感じ
イテレーションの締め切りは厳守として、間に合わないものは取捨選択して、
リリースを遅らせない事で、開発のリズムを保つ事が重要みたい
リズムを保つ事で、停滞を発生させず、とにかく前に進む姿勢を保てるみたい
それで、各種方法論を用いて、短いイテレーション内でストレス無く作業を行うように工夫をする
欠点とかもあるんでしょ?
10人程度の小規模で、全員の意識が高く、同一の場所で作業する場合の方法論なので、
それ以外では、効果はあんまり保障できないです
たとえば、協力会社メンバーを50人タコ部屋に押し込んで…みたいな場所には向かなそう
ただ、本では必要なプラクティスだけ取捨選択すれば良い、と書かれているので、
各自の環境で使えそうなものだけもらうってやり方でもよいのではないかしら?
気になった箇所
3:人ではなくアイディアを批判する
- 問題点を気づかせるような問いかけをする
- 「2人のユーザが同時にログインしたらどうなりますか?」
- 誰かを叩くのではなく、解決策を得るのが目的
11:指針は指針であって指図ではない
- 設計には「戦略的設計」と「戦術的設計」がある
- 戦略的設計が、用件定義に近い感じ
- 戦略的設計を元に、戦術的設計をインクリメンタルに組み立てていく
- 戦術的設計先に組み立てると…
- 更新が大変
- 誤った前提の設計を元に製造が行われる
- 設計とは「意図」を表したもの。具体的な手順を示すものではない
20:作る前から使う
26:コードで伝える
- 余計なコメントでお茶を濁さず、コードで挙動がわかるような実装をする
- コメントが多いと、ソースの修正時に、コメントの修正も必要になって手間だし、
コメントの修正漏れというリスクが増える
- コメントが多いと、ソースの修正時に、コメントの修正も必要になって手間だし、
44:コードをレビューする
45:みんなに知らせる
- 情報発信機という考え
- 時と共に変化する情報を張り出したポスターのようなもの
- タスクや進捗だけでなく、マネージャが興味を持ちそうな情報を張る
- ホワイトボードや、wiki等、みんなが見るところならどこでも構わない
- かせいさん注:物理的に目に付きやすいホワイトボードがいいのでは無いかしら
こちらみたいに→FFTT:ホワイトボードを使ったタスク管理