-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiindwango20110907
hedachi edited this page Sep 7, 2011
·
9 revisions
参加者：@futoase @kwappa @akitsukada @lchin @tlync @hedachi + 美人天気の中の人
#「第IV部：アジャイルなプロジェクト運営」/ "(原文タイトル?)"
原文タイトル：
原文タイトル：
- 分析してますか？
- ニコ生では最近仕様検討段階で主要メンバー・関係者でレビュー、ミーティングを必ずやれるようになった
- 開発は手戻りありますか？
- 大小あれど手戻りはありますね
- 分析をちゃんとしたとしても手戻りはありうる
- イテレーションに区切ったとしても大きい手戻りがなくなるわけではない
- 成果を分割するのが難しいことがある
原文タイトル：
- 見積もりがけっこう正しいことが前提になるのかな
- 正しいというかそれを前提としてやるということだ
- 計画通りにいかなければ見直す、という方向で動く
原文タイトル：
- ストーリーに対するステップ３つは、一人がやるべきだよね、ステップごとで担当者が変わる
- クリティカルなストーリーを切り出すのが難しいと思う
- 要求的なところで、ほんとに必要なものがあいまいだったりというポイントが難しい
- この場合は比較的わかりやすいストーリーが上がってると思う
原文タイトル：
- 受け入れテストのとこで、ユーザーにそれを考えてもらうってのはいいやり方だと思った
- それで埋もれてた要件も割り出せるかも
- ペルソナはあんまり好きじゃない 場合によるけど作ってるもの次第だ
- 人が中心のものならペルソナもいいだろう、だけど機械中心のシステムだとペルソナはどうだろう
- たとえば経験の浅い人に、なりきりで考えるためにペルソナを考えさせるのは？
- 危険だと思う、あくまでも思い込みにしかならないから
- JITも、あんまりjustすぎると「やりながら考える」に成り下がる
- 精度の問題だけど、ある程度はアーキテクチャとか言語とかレベルでは分析しとくよね現実
- 分析のタイミングとして「一つ前のイテレーション」というのは、個人的にへーと思ったけどそういうもんか（もう少し遅いかと）
- イテレーション頭でやるとあばばばばってなるしスタートがもたつく、けど経験上実際そういうタイミングで分析することもけっこうある
- でもそれはJITすぐる
- 優先度付をもっと早い段階でやるべき
- ペーパープロトタイプは超重要だと思うけど みんなpptでつくろうとするよね
- もっと早く、ラフにどんどん作るべき。紙でもホワイトボードでも
- ライブコーディング的な感じでミーティング中に動きを実装しながら仕様をつめるといいかも
- ストーリーは、技術者だけで挙げると細かすぎ、技術的すぎになったりする
- たとえば「振る舞いの話をしてるときにメモリ量を気にしたり」とかは、気持ちはわからんでもないがズレた議論になる
原文タイトル：
- コードの共有だいじ。容赦なくほかの人のコードを見たり突っ込み入れたりいじったりすべき
- ドワンゴでも、コード共有できてるところ できてないところあるよね
- 息が長いプロダクトとiPhoneアプリとかでずいぶん状況が違うと思う
- ペアプロはやってる？
- 山城先生のところでは、ラフなペアプロも含めれば50%はペアプロだそうな
- ドワンゴの場合、ペアプロするにはデスクが物理的に狭いというような問題もある
- 慣れていない人が多いので、縦割り（非ペアプロ）のほうが早い、というのが現実だと思う
- たまにやるだけでも、たとえばEclipseのスキルの底上げになったりとか、教育的効果が大きい。
- 環境が違うとペアプロが難しい。たとえばエディタの宗教で衝突したときってどう解決してる？
- ゆずる
- お互いにGitHubに上げて共有しながらペアプロしたり
- screenを共有（たまにファイル壊れたりするけど）
- screenやサーバー利用して同時にそれぞれがコードを見れるいじれることが重要じゃなくて、二人で同じカーソルを追うことが大事、やっぱ1キーボードが重要だよ
- イテレーションゼロ（開発作業の準備）
- システムによってはこのイテレーションゼロが非常に重い作業になる場合もある
原文タイトル：
- ドワンゴの場合テストの最終段階としては品質保証部隊がいるけど、受け入れテストとQCはまた別の話だ
- むしろ企画者が受け入れるか、たとえば会長が受け入れるかが受け入れテストの役割になるよね
- 結合テストっていうけど理想は常に結合して確認できてること
- でも実際Mockでユニットテストしてたところを実際に結合してみると想定外のデータがきてあばばばばってなったりするよね
原文タイトル：
- カンバンやバグトラッキングシステムが単なるtodoリストになって、todo挙げることが目的になっちゃうことも
- 最後のコラムはどういう意味だ
- 大事なのはツールでなく、誰でもリリースできる、常にリグレッションテストが回ってバグを把握できるような状況を作ることだ
- この図のカンバンだとWIP=4で各フェーズにタスクが一つ、に見えてるけど、たとえばWIP=6でタスクが２つあるフェーズもある、というのが現実的だ
- この図こそウォーターフォールに見えるよ
- 「アジャイル熱心」な人だと「必ずイテレーションに収めます」って言いたいかもしれないけど、そうじゃないよね
- ３ヶ月消えるけどほんといいの？という意思の疎通を取る道を歩むべき
- 規模がでかいシステム、たとえば全国規模のシステムだったら地域ごとで段階的にリリースできるようにしたり、というのが「スライス」
- ほんとにでかいシステムだとしても、「アジャイル」と規模は違っても段階的にわけて作ってリリースってのはやってんじゃないか、そしてその中でイテレーション的なものを回すとかさ
- 「予算」という概念はなくならないけど、「人月」はなくなってもいいじゃない
- ～その他 人月の神話 から 外科医チーム そして 外科医 ブラックジャックの話など～
次回は「第10章 アジャイルな意思疎通の作戦」からやります。