DoorKeeper
http://aepreading.doorkeeper.jp/events/3690
以下の書籍をターゲットとした読書会なのです。
 | アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ (2009/01/29) Mike Cohn、マイク コーン 他 商品詳細を見る |
場所はアジャイルサムライ横浜道場と同じく、アットウェアさんです。
参加者は8名かな。ディスカッションに最適な人数です。
前回（第一章）のブログはコチラ。
4/12(金) AEP読書会 第一章「計画の目的」に参加してきたので、4/11の「SQLアンチパターン読書会」のブログに続いてメモ書きました。 makopi23.blog.fc2.com/blog-entry-66.… #aep_reading_tokyo
— makopi23さん (@makopi23) 2013年4月13日もう二ヶ月近く前なのか。月日が経つのは早い。
ちなみに今回も、最初からピザとビールを飲み食いしながらの進行です。
注文＆買出し、ありがとうございますッ！
発表は前回と同じく @takaesu0 さんです。毎度準備ありがとうございます。
資料はAEP読書会のFacebookに公開されています。（上のは表紙の一部）
https://www.facebook.com/groups/aep.reading.tokyo/
以下、個人メモ。
---
■ストーリーポイント vs 理想時間
・著者のMike Cohnは、最近はストーリーポイントを使わず、理想時間で見積りをやっているらしい。
■"Plan Outcomes, Not Actions" 「成果を計画せよ、作業を計画するな」
・WBSは作業じゃない！ by @haradakiro
・世界的な定義じゃない。
・wikipediaの説明を見ても一目瞭然。http://ja.wikipedia.org/wiki/Work_Breakdown_Structure
Plan Outcomes, Not Actions / WBS は、作業分解構造ではないのよ。 - haradakiro's blog kiroh.hateblo.jp/entry/2012/12/…
— H.Yokotaさん (@hyokota) 2012年12月20日■計画作りが失敗する５つの理由「2.マルチタスク化が遅れを助長する」
・Rubyだと、シングルコアでもマルチスレッドにした方が速いことがあるらしい。
→ I/O待ちが解消されるため。（Rubyに限らないかもしれない）
・クラークとウィールライトの研究のグラフ（書籍の図2.2）を見ると、同時に担当するタスクの数が１でも、タスクにかける時間の割合が70%までしか上がらない。
→ つまり、シングルタスクでも30%分は、他が原因で作業が止まることを表している。
・P.42「作業をグループではなく個人に割り当てたらより深刻な状況になる」
→ 作業は個人でなはくグループに割り当てるべき。
①グループなら、融通が利く。
②得意な人に作業を依頼できる。
③今のリソースでやろうとするすると無理なことがある。
■計画作りが失敗する５つの理由「3.優先順位の順にフィーチャを開発していない」
・書籍「実践反復型ソフトウェア開発」では、期間を固定する「タイムボックス」に対して、開発する機能の数を固定するアプローチを「フィーチャーボックス」と言っている。
→ このアプローチはダメ（へっぽこ）だと言っている。
 | 実践 反復型ソフトウェア開発 (2012/12/01) 津田 義史 商品詳細を見る |
・その製品のその機能が必要で使う人にとっては、その機能は100%必要なものとなる。
→ 「だから作れ」と上層から言われることが、組み込み開発の場合だとあった。いかにも日本的。
■計画作りが失敗する５つの理由「4.不確実性を無視している」
・「設計漏れ」と「要求分析漏れ」を切り分けないといけない。
→ 開発が上手くいかなかった場合に、一律「設計漏れ」とする風習がある。
■計画作りが失敗する５つの理由「5.見積りがコミットメントになっている」
・６月から８月の間に出来ます、と言った場合、それは確率論になる。
→ ６月だと何％、８月だと何％の可能性で完成している、みたいな。
→ でも、結局はパーキンソンの法則で８月完成になるのでは。
■バッファの扱い
・CCPMでは「バッファは隠すべきではない」というスタンス。
・スクエニでは、バッファをエンジニアに見せている。
・バッファはタスク全体に積む。タスク１つ１つに積むべきはない。
・バッファを積むのではなく、あえて短めの期間を割り当てることがある。
→ 長くとると、早く終わっても期間ちょうどで終わっても、「終わった」とひとくくりに纏められる。
→ そうなると、正しく評価できなくなる。
■見積りとコミットメント
・見積もりは確率。
・コミットメントは確率ではない。
・自社で開発するスケジュールと、お客さんへのコミットメントが同一視されているのが問題。
・未来予測のスケジュールがコミットメントになるのが可笑しな話。
・そうは言っても、受託だとお客さんと契約を結ぶから、見積りとコミットメントを切り離すのは難しい。
・ベンダもユーザも、両方ともムリだとわかっていても、監査が通らないので非現実的な契約をすることがある。
・デルファイ法が発展してプランニングポーカーになった。
■2章まとめ「話し合ってみよう」
■1. ユーザに提供するフィーチャではなく作業を基準に計画を立てると、どんな問題が発生するだろうか？
・完了定義が難しくなる。
・タスクに落としちゃうと部分最適になっちゃう。
- フィーチャを実現する手段はいろいろある。なので「どうすれば実現できるんだろう」という方向に向く。
- でも、それを作業にすると、単に「もっと手を動かせよ」という方向に向いてしまう。
・何をするかじゃなくて、何が欲しいのか、に注力するのがいい。
・最後はタスクに落ちるが、それを落とすのは極力遅らせるのが良い、とスクラムではしている。
・フィーチャは「What」で、作業は「How」。
・タスクへは作業者が落とせばよい。PMが決めることではない。
・なぜみんなフィーチャでやらないのか、というと、「タスクのほうが上司への説明がしやすいから」
→ タスク完了は「完了報告書のハンコ」で済む。フィーチャの完了定義は難しい。
・そのような組織を変えるのもスクラムマスターの役割である。
・会議は、責任の所在を曖昧にするためのもの。
・作業に落とすと工夫しなくなる。
■2.あなたの周囲では見積りとコミットメントは同じだろうか？
その場合にはどんな問題が起きているだろうか？どうすればこの誤解を解けるだろうか？
・見積りがコミットメントになる例として「引っ越し」の例が出た。
- 引越し業者が見積りに来て、「半日で終わる」と回答した。
- 実際に引越しが完了するまでに丸1日かかった。
→ 依頼者は半日で終わることがコミットメントだと思ってしまう。追加料金を要求されても逆に怒る。
・SIの世界では、コミットメントがあって逆線表的に見積もりをつくることがある。
「納期」が確定していて、それに間に合うようにスケジュールを作る場合、見積りはコミットメントかも。
■3.あなたのプロジェクトでマルチタスク化はどんな影響を及ぼしているだろうか？
どうすればマルチタスク化による悪影響を軽減できるだろうか？
・自分が抱えている作業を明示する。そうしないと次から次へと作業が上から降ってくる。
・WIP(Work In Progress)で、同時実行数を制御する。
→ 完了しないタスクはいったんフリーズさせて、新しいタスクを振るようにしている。
・タスクボードのDoingの欄を細くして、物理的にDoingになるタスクが制限されるようにしている。
・逆に、マルチタスクで良いこともあった。
- プログラミングとかで良い方法が思いつかず悩みまくってハマッた際に、別のタスクへ作業を切り替えた。
- その後、またプログラミングに作業を戻した際に、良い解決方法がパッと気付くことができた。
→ 別のタスクをやることで頭をいったんリフレッシュしたほうが、閃くことが何回かあった。
★感想：
19時半から開始だったが、あっという間に22時になった感じ。
人数的にも内容的にも、ディスカッションには最適な状況だったと思います。
んでも私、ビールを１リットル飲んでて少し酔っ払ってたぞ！
見積り、難しいですよね。。。
自分の数日分の作業を見積もるのも困難なのに、プロジェクト全体の見積りとなると、もう。。。orz
あと、小さく区切って見積もってイテレーティブに進める方法って、これまでの人生で自然と身に付いちゃってると感じています。
趣味のプログラミング然り。受験勉強然り。などなど。
自分の生活の範囲内ではWFでなくアジャイルな見積りで日々生きてる人のほうが多いのでは。
あとスケジュール作ると、それが確定情報として一人歩きするのが問題なんですよね。。。
と、参加者もいろいろ思うところがあったようで、話が脱線しつつも熱いディスカッションになりました。
勉強会のディスカッションって、脱線もある意味、醍醐味なんですよねぇ。むしろそっちのほうが意義があったり。
発表担当の @takaesu0 さん、会場提供の道場主さん、皆様、ありがとうございましたー
