-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiindwango20110803
l15n edited this page Aug 10, 2011
·
7 revisions
参加者：
- @xga @meso @erukiti @kusigahama @akitsukada @yamashiro @tlync @lchin @meso @kwappa
- 他に、ニコモバ開発、ニコモバ企画、ニコ生開発の人
原文タイトル：Meet Your Agile Team 前回からのつづき。
原文タイトル：How Are Agile Projects Different?
- 顧客とは誰なのか？顧客を決めたい
- サービスの性質上決めにくい
- 企画者？エンドユーザ？
- 「顧客」 = 「使う人」とは限定していない
- 要求、優先順位、スコープを決めるのが役割
- 「問題領域の専門家」 (!= ユーザ)
- それをふまえて、ドワンゴでの「顧客」は？
- 作るものの専門家、思い入れのある人
- 社内ではプロダクトオーナー（責任者）が顧客だということが多い
- 自分（プログラマ）が顧客だということもある
- 企画職は、必ずしも顧客とは限らない
- 顧客じゃなければ、つまり開発チームのメンバーである
- ＜ニコニコでは＞ プロダクトごとに区分けされすぎてないか？
- 適切な責任委譲(分割)は必要では
- 最終的に決定する人を意識する
- 「神」がいることもある
- 顧客の信仰を尊重せよ…
- ＜モバでは＞ ちょっと事情違う
- 優先度を決める人を意識する
- 「自分が顧客」であることも
- アナリスト = 企画、ということが多い
- 顧客：開発も職能横断的
- 複数の役割を持っている人がほとんど
- 企画と開発
- リーダーとメンバー
- アナリストの役割を昔ながらの言い方で言うと
- 要件定義
- 設計？
- それは違うかも
- モック(画面)を作るとか
- まさに「企画」がやってることが「アナリスト」
- そうでもないことも
- 他チームとの折衝をするプロダクト(生・チャンネル)
- 企画がいない
- 誰がアナリストなんだろう？→ リーダー、または古株社員がやることが多い
- 企画がアナリストなのはどうなんだろう？
- 「開発チームの中でアナリストが得意な人」ならいい
- テスターを兼ねることも
- 今までは組織的に遠かったのでうまくいかないことも
- よいプロダクトを生み出せるのなら「帽子が固定」でもかまわない
- 「コードを書くのが仕事じゃない」
- 「キーボードを持った顧客」？
- よくわからない
- 原文も同じような内容
- 要求を形にするから？
- 顧客の思いを動くソフトウェアにする役割だから？
- 訳者の解釈はFAQにある
- 常に顧客の立場で考えることが重要、ということを強調しているのか
- ユーザーストーリーを書いてないことが多い
- 機能をどうやって表現するか？の問題
- 「ストーリー」という単位は便利
- 表現できれば他の方法でもよい
- 企画職は「ストーリー」を意識している？
- もっと大まかにとらえていることが多い
- 品質保証チームが「テスター」
- かっちりした「テスター」の帽子
- できれば近くにいて開発段階から見て欲しい
- 探索的テストは早いフェーズからヤッテホシ
- リソース不足で難しい
- 企画チームにもテストしてもらう
- 本番にデプロイしてからではなく、テスト環境から見せる
- 企画チームはストーリーを意識してみてもらう
- やってるチームもあるよ
- QA終わってやっと見る企画職はよくないよね？
- 「アジャイルなテスター」としては不足
- 従来のテスティングは「not good」ではなく「not enough」
- やってみる？
- 日本の風土では「恥ずかしがる」かも
- アイスブレイクとしてやってみるのはいいのでは
- 特に「役割をはっきり決めてない場合」
- なんでドラッカー？
- ドラッカーは「問いかけることで要求を明らかにする」手法を使うから
- チームビルディングの本によると
- 体を動かす
- ピザを食う
- それって飲みゅにケーションだよね
- 今のチームでやってみたら？
- なんて言うかな？
- 恐ろしい
- リンク先の手法 （著者のブログ記事：http://agilewarrior.wordpress.com/2009/11/27/the-drucker-exercise/ ）
- 紙を用意して書いてもらう、というスタイル
- 4枚の紙にそれぞれ3つずつくらい書く
- 面と向かってしゃべるよりはやりやすい
- 「開発に口出すな感」
- マイクロマネジメントとかたまらん
- ドワンゴはできてるのでは？
- 不在になったらなったで困ることが多い
- 手を動かす人が多いので
- 「プレイングマネージャ」(和製英語)
- プレイングマネージャすぎてアジャイルな役割を見失いがち
- マクロな視点が足りてない
- 開発とマネジメント、同時にやるのはしんどい
- プロジェクト規模による
- 専任でやったほうがお互い幸せでは
- 行き詰まってるプロジェクトはプレイングマネージャの無理で成り立ってることも
- マネジメント手法の改善
- バーンダウンチャートとか
- モードの違い
- 開発は集中したい、タスクスイッチのコストは大きい
- マネージャは割り込みに強くあるべき
- 両方やるのが「キツい」原因かな
- プロジェクト以外のマネジメントもしているケース
- マネージメントのコスト（時間）
- 最小限に抑えたい
- プロジェクトの大きさに比例するなのでは？
- 「顧客」に「ユーザ」を含む感
- ドワンゴでは切り分けが難しいところ
- 絵コンテ(原文：Story Board)
- どっちが通じる？
- 「絵コンテ」？ → あまり通じない
- 訳をツッコミたい
- だけど、実は正しい対訳にはなってる
- 伝わりにくい
- ドワンゴでは誰が？
- 企画、開発、みんなやるべき
- あんまりいない（何人かはいるけど）は
- 育てようとしている
- 個人の意識に依存している
- チームビルディングの視点からは欠けている
- 企画の人は？
- モバイルコンテンツでは育てようとしている
- 使いやすさ命
- アナリストとの切り分けは？
- 重なる部分も多い
- アナリストは「アナリスト」という役割への集団
- 一人のメンバを指すものではない？
- インタフェースのデザインに特化している
- 「グラフィックデザイン」のイメージが強い
- けど、それだけじゃない
- 人間の体験をデザインする
- 作るときにデザインはしている
- してないと作れない
- あまり上手じゃない
- 最初に「コンセプトデザイン」できてる？
- 企画に皮をかぶせるに留まることが多い
- ユーザビリティテスト？
- デザインの「過程」
- UXデザイナに身につけてほしいスキル
- 一般人を集めてテストしたいよね
- ターゲットユーザに触ってもらわないと
- インタビュー
- ラボを持つ会社も
- 集めて使わせて観察する
- アジャイルコーチいるといいよね
- 横断的に見てもらえるといいよね
- 合同コードレビューとかやってみたらよかった
- 他チームのふりかえりの司会をしてもらったことがある
- 他人だからいろいろ引っ張りだせた
- 他チームでコーチングするのはアリじゃないかな
- せきやすさんはセキュリティレビューで横断的に見てるだろうな
- アジャイルコーチとしてできるといいよね
- 複数の帽子をかぶること
- まあまあできてるのかな
- 自己組織化には必要
- 「ちゃんとかぶってる帽子」が少ない
- 3つ以上かぶってる？
- ちゃんとできてる？
原文タイトル：Tips for Forming Your Agile Team
- 一番大事なこと：ゼネラリストに成長させる
- 最初はやったことないことに抵抗が大きかった
- 「成長させる」ために
- 最初から最後まで責任を持つ
- 知らないところをなくす
- 結果積極的に主担当外のことも知るようになった
- 最初は意図的に知らない分野をアサインする
- 経験者をペアにつける
- 「知らないからやりたくない」→「知らないからやってみたい」に変化
- 知らないからやりたくないのは？
- 工数がかかっちゃうから
- 自信がないから
- 新人には効果がある
- ベテランと組ませないとカオス
- 情報公開が大事
- タスクはオープンにする
- 他人が何をやってるか知るのが大事
- ドワンゴは苦手な分野でもある
- ちゃんとミーティングしないと共有できない
- 負荷が高くなると視野が狭くなる
- 意識しないと広がらない
- トップダウンな感じ
- テストが得意なヤツを探せ
- 現実は甘くない、ということ？
- テスト書きたくないヤツはいらないよね
- 無理矢理押し付けるわけにはいかない
「第II部：アジャイルな方向づけ」/ "Agile Project Inception"
原文タイトル：How to Get Everyone on the Bus
原文タイトル：What Kills Most Projects
- うかつに始めると重要な要件が共有されてなかったりする
- あるある
- あっても、全員集まっていないことも多々ある
- 十分に同意できる前に強行する
- 熱意のあるディスカッションの結果を丸投げする
- ちゃんと同意するには
- キックオフ重要
- ブレストに開発者も参加する
- 開発者として参加できる？
- できるよ
- 案件の存在に気付けば
- キックオフする方も必要な相手がわかってない
原文タイトル：Ask the Tough Questions
- ここに載ってることはさすがに最初に聞くだろう？
- いやあ…
- 予算？開発は意識しないことが
- SIとの風土の違い
- 考えずに突っ走る場合も
- 技術者も説明していない
- 企画に「Hadoop使います」とは言わない
- 説明を省くとか
- ドワンゴでは誰が誰に？
- お互いに
- 近いんだし
- 最後まで疑問を残さない
- とにかく突っ込む
- 空気を読むな。モヒカンになりましょう
原文タイトル：Enter the Inception Deck
- 要するに１０個の手強い質問テンプレート
- これを網羅しておくことでキックオフできる感
- 経験で積み重ねて行けばいい
- チーム固有の問題とか
- あくまでスターターキット
- 経験によって育成していく。
- どんどん手強い質問を対していけばよいのでは？
- 目論見書的な位置づけ
- 参加メンバーは読んでないことが多い
- スライドにしている
- プレゼンするのが目的
- 目論見書は固い
- おすすめ：ティム・バーナーズ・リーのWorldWideWeb: ハイパーテキストプロジェクトの提案
- 原文
- 和訳(リンク切れ？） waybackマシンのミラー
- 訳はちょっと堅い
- キックオフLTをやればいいのでは！
- できたものを目論見書に
- 偉い人にプレゼンする
次回は「3.4 インセプションデッキの仕組み」からやります。