-
Notifications
You must be signed in to change notification settings - Fork 49
Readingagilesamuraiindwango20110914
kusakabe9012 edited this page Sep 21, 2012
·
14 revisions
参加者：@lchin @yamashiro @guccii @xga @hedachi
- 4つのミーティングの話。
- 多くのアジャイル手法では「みんな同じ場所に集まろう」みたいなことは書かれてるけど、もっと具体的にイテレーション内でどうするのかはあまり書かれてない。
- 要約：どんなアジャイルプロジェクトでも「期待をマネジメントすること」と「フィードバックを得ること」は欠かせない。そのために以下の４つのミーティングを行う。
- ストーリー計画ミーティング
- ショーケース
- イテレーション計画ミーティング
- ミニふりかえり
- 実際どうか？
- 同じ日に全部やったりまとめたりしている。
- ショーケースをあんまりやってない。あんまり見てもらえないことが多い。
- デモする価値の単位の切り方に問題がある？
- 一番価値があるものから順に作っていればもっとうまくいくのでは。
- ストーリー計画ミーティングは何をするのかこの本にあまり書いてない気がする。
- ストーリーの肉付けをするミーティングなのでは。
- ストーリーをタスクのレベルに分割したり、チケットを細かく分割したりするとか。
- 人によってはタスクを細かく分割するのが嫌いな人もいる。開発者次第なところもある。
- やましろ先生は細かく分割して見積もりを出したい派
- ショーケースはやってないけど、ふりかえりはやってる。ふりかえりは簡単で有意義
- 要約：分析の結果を確認するミーティング。分析ちゃんとできてるよね？という話。
- やましろ先生のところでは、１つ２つ先のイテレーションのストーリーを見直したりしている。
- イテレーションが近づいてきたらストーリーを見直して再分割するとか。
- この本のオリジナルのミーティング。特別なテクニックとかではなく「やる前に確認するのが大事だよ」という話。
- 現場ではイテレーションのはじめに見積もりして、どこまでやるのかを決める、とかやりがち
- コラム「誰でも失敗する－恐れるな」
- 日頃から定期的に成果を届けていればたまに失敗しても大丈夫だから挑戦しよう、という話。
- 最初っから失敗したりすると信用を失うので最初は冒険しないほうがいいかも
- 毎回挑戦して失敗するのとかはダメ。あくまで普段成果を出しているということが前提。
- 要約：今回実装したストーリーをデモしてフィードバックを得る。お菓子を持ち込んだりして楽しくやりましょう。という話。
- 結構できてない
- イテレーション単位ではやってないことが多い
- できた瞬間見せてることが多かったりする。定期的にはやってない
- そのほうがいいのでは？という意見も
- 見せてなくてフィードバックをもらってない時もある。そういうのは無くしたい
- 見せても「デモではわからん」と言われる時もある
- 本番環境にリリースされないとわからない、という人もいる
- 機能によっては実際にリリースしないと判断が難しい
- 「見てください」と言ってても誰も見てなくて、本番に上がってから問題ですと言われたりとか
- 完成しない状態で見せるのはどうか？
- そのほうがいい場合もあるが、完成するまで見たくないという人もいる
- 完成してないからどうでもいい所を突っ込まれたりとか
- 要約：開発チームと顧客が一緒になって次のイテレーション計画をし、次の作業量を決める。プロジェクトの現状について、天気アイコンとかを使って顧客と共有。全体が見たいのであればバーンダウンチャートを使えばはっきりと状況を示してくれる。
- ドワンゴではプロジェクト全体のバーンダウンチャートというものはあんまりない？見たことない。あったほうがいいのでは。
- プロジェクト全体のタスク量をあまり把握していないので、優先度の高いタスクがバンバン入ってきて、前に頼まれたものがどんどん後回しになって、いつやるの？みたいな話になることが多い
- たまにタスクの棚卸をしたほうがいいのでは
- 要約：１０～１５分ぐらいで行う短くて集中したミーティング。魔女狩りにならないように、雰囲気作りを大事に。アイディアや経験したことを共有する。最初は場を温める話をして、そのあと失敗したことを話しあうとよい。
- やましろ先生のチームはKPTをやってる http://www.atmarkit.co.jp/aig/04biz/kpt.html
- 何が問題で、それを今後どうするつもりなんだ、というのを共有するといいのでは
- 魔女狩りじゃないということは毎回言ったほうがいい。でないと、どうしても個人攻撃になりがち
- 暗黙知になっているのであれば必要ないかも知れないけど
- 新しい人が入ってきたときにまた言うとか大事
- 嘘をつかない
- 「モンハンが出たから」みたいな事情も誤魔化さずちゃんと話す
- 要約：重要な情報をチーム内で素早く共有することを目的とした集まり。５～１０分ぐらい立ってミーティングする。正式に開催せず、自然に集まる感じで。発表するときは言い方を工夫すると楽しくなるかもね。
- ニコ生部隊は30人ぐらいいるので3チームに分けて週2でやってる（立ってはいない）
- １０人は多いのでさらに２，３チームで分けてやったらいいんじゃない？
- やましろ先生のチームは毎日朝会やってて１人１分ぐらい。１分ぐらいが良い。
- 世界をどう変えたのか、みたいな大袈裟な表現は日本人には合わないかも
- TRPGやると慣れるかも
- 要約：この本に書いてある通りにやる必要はない。いくつかのミーティングを省いたりくっつけたりしてもいい。
- シナリオ1：完成してないストーリー
- 要約：ストーリーが半分できたからといってストーリーポイントを半分加算するみたいなのはよくない。未完のストーリーは次回に持ち越すべき。
- 半分できたと思ってる時は、実際には半分できてないことが多いので理解できる話。
- 「８割まで進むのと残りの２割にかかる時間が同等」という統計をどこかで見た
- シナリオ2：デイリースタンドアップの価値
- 要約：デイリースタンドアップは良い方法だが必須ではない。価値につながらなければ、やり方を変えるか辞めるべき。
- この本は全体的にセンセイ厳しい。
- やる価値があるかは、物理的な位置関係とか、性格とかいろんなものに左右される。
- こういう定期ミーティングをやらないと話をしてくれない人もいるので、その場合は価値がある
- シナリオ３：何も価値を生み出せなかったイテレーション
- センセイは厳しいので、辱めを受けることも価値があるみたいなことを言ってる。
- 価値を生み出せないイテレーションが続いた時などはやる価値があるのでは。
- インセプションデッキを見せる、リリースボードを見せる、これでだいたい状況はわかってもらえるんじゃない？
- ここまでできてりゃ話しやすいよねー
- 正直インセプションデッキはできてない
- 空間（壁）が足りないからうちには無理かも
- 消せる紙を使って朝会の時だけ開いたりしている http://www.obun.co.jp/keserushi/white.html
- プロジェクトは中止になった、という結末について
- デスマになって最悪な状況になるよりはいいので良いことだと思う
- 中止したほうがいいプロジェクトというのはたくさんあるが、こうやって見える化しないからデスマになる
- 本では貼りものが4つ提案されている。
- ストーリーボードだけでいいんじゃね？
- インセプションデッキは壁にスペースがあればかなあ
- やましろさんはストーリーボードを作ってる。リリースボードは貼ってはいない
- Leoさんのところは壁がない
- 短いプロジェクトが多いのでやらないというのもある
- 一つのシステムを担当してるわけじゃなくてプロジェクトがどんどん変わるから難しい
- クロスチームの案件もやってる。Leoさんのグループだけが他のチームの難しい部分だけ手伝うとか
- マスターストーリーリストを電子化してやろうとしている
- 昔ニワンゴでは週に何回かしか来ないバイトの子とペアプロしたりしていた
- 壁にハローワークってというものを貼って、そこからタスクを取ってくるという方式をしていた
- 天井とか床に貼るのは？天井は書けないからダメでは。
- 天井から吊るとか。
- でかいテレビを縦にして置いたりとか
- 開発室をニコファーレみたいにすればいいんじゃね？
- ニコファーレの壁は何使ってるの？
- パチ屋とかと同じLED
- こういうのはできるだけ手間がかからないほうがいいので紙がベストでは
- ツール開発に時間をかけるのもどうなのか
- 上に受けもよくないし。
- うちに文化的に合うのか？
- 宗教っぽい
- 他にこういう思想の理解者がいないとやりにくい
- この見本は数が多すぎじゃね？
- たまに棚卸したほうがいい
- ペアプロで意見が割れた時にこれがあると「こう書いてあるでしょ」と話をして進められるかも
- Eric Evansのドメイン駆動設計(DDD)は良い
- 後半が醍醐味
- 読書会やろうかー
- ニコニコで役に立ちそう
- このシステムとこのシステムをどうやって分けようか、とか
- 大きいシステムをどう分けるか、どう連携するかみたいなアーキテクチャについて書いてある
- 他のチームに影響しないようにインタフェースを保つか、とか
- DDDはドワンゴ的な大規模システムに合ってる
- DDDはプロダクトからのアプローチ。他の本だとプログラマ視点過ぎたりする。
- 毎回１０％使うと書いてある
- １００％と書いてないところがいいね
- 貼りもの禁止の場合はどうすればいい？
- 消せる紙で折りたたみストーリーボードとか
- アジャイル的に見える化すると、見えないようにしてきた人が嫌がる
- レガシーコード改善ガイドを読むといい
- ２４章「もうウンザリです。何も改善できません」が面白い
次回は「第五部 アジャイルなプログラミング」の「第十二章 ユニットテスト：動くことがわかる」からやります。