アジャイルな見積りと計画づくり：第2部：規模を見積もる「６章 見積りの技法」まとめ - 基本へ帰ろう
プランニングポーカーがうまくいく理由の１つに「個人の見積りを平均した方がより良い結果を残す傾向があるという研究成果がある。グループで話しあって見積もると良い結果になるのもこれと同じだ」というのがある。私も過去の経験から１人で何かを決めるより、皆で話し合って決めた方が、良い結果を生むと感じる。また、皆で決めたことなので、「自分も賛同したことなのでやろう」という意識が非常に強くなるのもいいなと感じる。人は自分の意見には一番素直だと思います。何かを決めてチームに導入するとき、ここが一番大事だなと思っています。しかし、大きなチームや大きな組織の場合、全員で話し合い合意することは難しくなります。リーダーが最終的には「これでやる」と決めて進めていく必要があります。アジャイルチームは少人数なのでそのようなことは起こりにくいでしょう。それは楽しさの要因の１つなのかなと思いました。 目次 見積りの技法 チー
そろそろHadoopについてひとこと言っておくか - nokunoの日記
もうこの手の話題は出尽くした感がありますが、最近Hadoopについて考えることが多いので、エントリにしてみます。なお、ここではベーシックなMapReduce+HDFSのことをHadoopと呼ぶことにします。 HadoopとはHadoopとは言わずと知れたGoogleのMapReduce/GFSのオープンソースのクローンです。MapReduceではプログラマはMapとReduceという2つの関数を書くだけで、並列分散処理をすることができます。これは(1) データを実際に持つマシンにプログラムを配布する (2) MapとReduceをつなぐShuffleフェーズでキーをグループ化してソートする、(3) 障害時のフェールオーバーやレプリケーション、といった処理をフレームワーク側が受け持つことによって、プログラマ側の負担を減らすものです。GFSに対応するHDFSにはファイルをクラスタに分散して保存
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
