-out of date- ブログ版

--/--/--(--) --:--:--

[] スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

2010/03/13(土) 13:34:09

[] 読んだ書籍:XPエクストリーム・プログラミング アドベンチャー (The XP series)

XPエクストリーム・プログラミング アドベンチャー (The XP series)



本の印象:

  • XPの実際のフローが具体例を入れつつ解説されている。
  • Javaで書かれた「匂うコード」をリファクタリングする流れを、ソースコード付きで解説。
  • 本全体ではなく、各章毎に「参考文献」が説明されてるので目的の書籍を探しやすい。

記憶に残ったこと


リリース計画のストーリーの重要度の付け方の項目。

リリース計画:計画
これらを考える場合,「ねばならない」,「べきである」,「だと良い」というように考えよう。
お客さんの「したい」(WANT)という要望をそのまま受けるのではなく、
「ねばならない」(MUST)・「べきである」(SHOULD)・「だと良い」(MAY)に分類してから受け取る。

重要度をきちんと把握せずに作業を行うと、
往々にして重要度の低い仕事に無駄に時間を割いてしまう。

MUST, SHOULD, MAYのドキュメント → RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels (日本語訳)


「昨日の天気」ルール。

40時間労働
XPチームでは「昨日の天気」ルールを使う。次のイテレーションでは今回行った分と同じだけの作業が出来ると見積る(要するに、明日の天気は今日の天気から予測する。そして、最後のイテレーションのペースが次のイテレーションの予測になる)。このルールにより、チームは自然な生産レベルを保つことができる。
1作業にかかる時間を適当に予測して、
電卓を叩いて作っただけ作業見積りなんてやめるべきだよね・・・


評価:

☆☆★ (また読みたい)
スポンサーサイト
コメントを書く
トラックバック:0 - http://nekosakana.blog50.fc2.com/tb.php/684-9e3ce0e3
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。