Embedded Files
ケーススタディ：ボムシェルタースタジオ（P266～）
ケーススタディ：ボムシェルタースタジオ（P266～）
P.266 「プロダクトオーナー」
→P.47 第3章アジャイル手法 1-1. １つのチームとして働く で出ました。(Ｙｏｕ＆Ｉ)
1. 1日目 - 月曜の朝（P267～）
1. 1日目 - 月曜の朝（P267～）
P.267 「ドーナツをどうぞ」
→P.183 第15章イテレーションの長さを決める 1-3.フィードバックの得やすさ で出ました。(Ｙｏｕ＆Ｉ)
P.267 「フランク、まだ始められません」
→P.74 第6章見積りの技法 1.チームで見積もる で出ました。(Ｙｏｕ＆Ｉ)
P.270 「ユーザーストーリー」
→P.50 第3章アジャイル手法 1-4. ビジネス上の優先度を重視する で出ました。(Ｙｏｕ＆Ｉ)
2. ユーザーストーリーの見積り（P274～）
2. ユーザーストーリーの見積り（P274～）
P.274 「ストーリーポイント」
→P.61 第4章ストーリーポイントによる規模の見積り、P.92 第8章ストーリーポイントと見積り で出ました。(Ｙｏｕ＆Ｉ)
P.275 「プランニングポーカー」
→P.79 第6章 見積りの技法 4.プランニングポーカー で出ました。(Ｙｏｕ＆Ｉ)
P.275 「カードにはそれぞれ、1、2、3、5、8と」
→P.75 第6章 見積りの技法 2.見積りのスケール「フィボナッチ数列 」で出ました。(Ｙｏｕ＆Ｉ)
P.277 「大きなフィーチャーの見積りは不正確になります」
→P.74 第6章 見積りの技法 2.見積りのスケール で出ました。(Ｙｏｕ＆Ｉ)
P.280 「カードはバケツですが、中身は水ではなく、砂のようなものだと考えてください。少しなら、余分に上乗せしても大丈夫です」
→運用しやすい表現だと思いました。（だんの）
P.283 「けれども、そのストーリーはとても単純だという場合には、見積りを０ポイントにすればよいのです」
→P.75 第6章 見積りの技法 2.見積りのスケール「見積りに使える値として、ゼロ(0)を採用したいこともある」 で出ました。(Ｙｏｕ＆Ｉ)
3. プロダクトリサーチの準備（P285～）
3. プロダクトリサーチの準備（P285～）
P.285 「表23.6 ディレニーのアンケートの冒頭部分」
→P.131 第11章「望ましさ」による優先順位づけ 1-1.狩野モデルでテーマを評価する で出ました。(Ｙｏｕ＆Ｉ)
4. イテレーションとリリースの計画づくり、第1ラウンド(P287～)
4. イテレーションとリリースの計画づくり、第1ラウンド(P287～)
4-1. 第1イテレーションの計画づくり（P288～）
P.288 「一番リスクが高い」
→P.106 第9章 テーマの優先順位づけ 1-4.リスク 「図9.3 リスクと価値をフィーチャーの優先順位づけに使う」 で出ました。(Ｙｏｕ＆Ｉ)
P.288 「タスクカード」
→P.238 第20章 イテレーション計画のモニタリング 1.タスクボード で出ました。(Ｙｏｕ＆Ｉ)
P.290「一日に一人が作業できる時間は６時間とみなして計画をたてるとよいと思います。」
→タスクの見積りは理想時間なので、理想時間と実時間の関係を共有しておく必要があると思うけど、ここでこのような形で実施していますね。（ヤマモト）
P.290「表23.7『プレイヤーとして、リングだけを認識できる弱いエンジンと対戦できる』のタスクと見積り」
→ここには、「～のテストを自動化する」のタスクが。「～をテストする」とは言っていない。これはなぜ？テストを自動化するところまでやり切ることを意図している、のかもしれないけど、そもそもコードを書くのとテストを書いて自動化するのとは不可分なのでは。コードとテストを書きテストを実行しパスすることを確認することまでが「クラスを書く」タスクだとしたら、テストの自動化は実質やることない０時間タスクになりそうだし。（ヤマモト）
P.290 タスクの洗い出しの仕方がアドホックすぎないかな？抜け・漏れがありそうだが。失敗してからチェックリスト等使うように改善されればいいからいいのかな？（ヤマモト）
P.292 「忘れないで欲しいのですが、テストのタスクはプラサードが全部一人でやらねばならないというわけではないんです」
→P.161 第14章 イテレーション計画づくり 1. イテレーションプランニングではタスクの担当者を決めない で出ました。(Ｙｏｕ＆Ｉ)
P.294 「私にテストを自動化する作業はできないと思うけれど、いいテストケースを考えることならできるから」
→わりと専門特化した集団でも、簡単な作業というのはあって、そこをどれだけ協力できるかというのがチームプレイなんだということがわかった気がする。全員が万能である必要はないが、全員が今何をどういう理由でやっているかがわかっていないとこうはならないよねという意味で。（だんの）
3/16(水)の第12回読書会ではここまで
------------------------------------------------------------------------------------------------------------------------
4/20(水)の第13回読書会はここから
4-2. リリースプランニング（P295～）
P.295 プロダクトリサーチの重要性をすごく感じる部分ですね。こういうことがプロジェクト初期に行えるかどうかというのも、組織としてのアドバンテージのような気がします（だんの）
P.295 「さらにフィーチャには、一元的な、線形のフィーチャと呼ばれるものがあります。」
→P.129～130 第11章 「望ましさ」による優先順位付け 1.顧客満足度の狩野モデルで出ました。（Ｙｏｕ＆Ｉ）
P.301 「一番いい方法は、３イテレーション実際にやってみて、それから答えることです。」
→プロジェクトの初期段階であるならこういった、まずやってみるという手法も可能ですね。（Ｙｏｕ＆Ｉ）
P.302 「特に最初の３イテレーションが経過した後から、状況が詳しくわかるようになっていきます。」
→スゴイ自信だ。言い切った。（Ｙｏｕ＆Ｉ）
5. 2週間後（P303～）
5. 2週間後（P303～）
P.304 動くモノをみたのに、重役が「なんだ、もう動くじゃないか。出荷できるんだろう？」とか言い出さないなんて！（ヤマモト）
6. 第2イテレーションの計画づくり（P305～）
6. 第2イテレーションの計画づくり（P305～）
P.305 ストーリーポイントはオール・オア・ナッシング。（ヤマモト）
→P.228 第19章リリース情報のモニタリング 1.リリースのトラッキング で出ました。（Ｙｏｕ＆Ｉ）
P.305 ベロシティをあまり頻繁に変更しようとしませんね。（ヤマモト）
7. さらに2週間後（P307）
7. さらに2週間後（P307）
P.307 「フィル、遅れではないんだ。」
→これ、社長に話してるんですね。まさにフランク。（ヤマモト）
8. リリース計画の見直し（P307～）
8. リリース計画の見直し（P307～）
P.308 「いままでのスケジュール通りに進めても、ある程度の売り上げは得られるでしょう。けれど一方で、スケジュールを変えれば、それ以上の売り上げが見込める。」
→収益あってのリリース計画なので、計画通りに作れば売れても売れなくても関係ないという発想で仕事をしてはいけないということを、特に日本人は意識したほうがいいかもしれないなと思いました。そうしないと「魅力あるフィーチャー」を無視しちゃうことになりかねないですからね。プロダクトリサーチの重要性とセットで考察したいところです。（だんの）
P.310 「今の状況では、優先順位の低いストーリーが重要ですね。」
→作らなくていいものではなくて、優先順位の低いものはあらかじめ落とす決断をしておくというのがとても重要だと感じま。だいたい行き当たりばったりにその時の感覚でやるかやらないか決めるのではなくて、チーム全員で定義しておくことの重要性を再認識したかも。（だんの）
→繰り返し型開発のメリットだと思います。滝型だと、落とすと決めるまでは分析なり設計なりしてしまっているので、ムダが生じます。繰り返し型だと、単に手を付けなければいいだけだからいいですね。（ヤマモト）
9. 見直した計画の報告（P311～）
9. 見直した計画の報告（P311～）
P.311 「リリースバーンダウンチャート」
→P.230 第19章リリース計画のモニタリング 2.リリースバーンダウンチャート で出ました。（Ｙｏｕ＆Ｉ）
10. 18週間後（P314～）
10. 18週間後（P314～）
P.314「結果として20週間からさらに2週間過ぎてしまいました」
→予定より遅れたら有名なCHAOS Reportでは失敗プロジェクトに分類ですね。でもこのプロジェクトは明らかに成功。総合的にビジネスとして成功したかどうかが問われるわけで。（ヤマモト）
Page updated
Google Sites
Report abuse