-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiindwango20110810
l15n edited this page Aug 10, 2011
·
8 revisions
参加者：@kusigahama @akitsukada @lchin @meso @tlync @erukiti @tdaiki + ニコモバ、ニコ生の中の人
※前回のフォロー 「プログラマはキーボードを持った顧客」とは？
→FAQに答えが。監訳者二人が答えてますよ
https://github.com/agile-samurai-ja/support/wiki/Agilesamuraifaq
#「第II部：アジャイルな方向づけ」/ "Agile Project Inception"
原文タイトル：How to Get Everyone on the Bus
前回からのつづき。
原文タイトル：How it Works
- 作成期間 数日から２週間は長い？
- 人を多く巻き込むから意外とそれくらいかもよ
- 半年間の見通し」とは？→逆に言うと半年以上先の見通しなんか書けないよね、という感じかな。
- 半年っていってるのは案件ごとのことか？でも半年後に作りなおせばいい話だよね
- 企画書に近いけど、企画書は作りっぱなしになることがおおいものだよね。インセプションデッキってバージョン管理とかしたほうがいいのかな
- インセプションデッキのwhyの部分を共有することが大事だから、毎日見なおして復唱するとかするものなのでは。
原文タイトル：The Inception Deck in a Nutshell
-
- 淡々と読み進める -
- 4と9ってかぶってね？レベルの違いだよね、4は開発レベル、9は経営目線くらい
原文タイトル：Seeing the Big Picture
原文タイトル：Ask: Why Are We Here?
- 司令官の意図ってどう知るのか、言葉にされてるのだろうか
- 理念の共有とか、社としての戦略の理解とか、そういうレベルじゃないか？
- 「ユーザーにとっての利益」「ユーザー視点」が書かれているね。サービス提供側の視点が書いてないか？
- 司令官の視点はサービス提供側の視点じゃないか。きっと２つの視点には主従関係があって、それをどうつなぐかだと思う
- バランス？というよりレイヤーが違うと思う
- 例えばドワンゴでいえばどこが「現場」？
- 自分自身がサービスを利用しているときはそこが「現場」だよね。
- 自分でサービスを利用しつくすことが現地現物になるのでは。
- 現地現物はモチベーションにつながる、「言われたから作る」じゃなって、それぞれに判断力がついたりするよね
- インセプションデッキって案件単位に限らず、全体単位だったり、いろんなレベルでできそう
原文タイトル：Create an Elevator Pitch
- エレベータは例えとして、「短く大事なポイントを伝える」ための手段だよね
- むしろ、これが長くなっちゃうプロダクトって魅力が絞りきれてないんじゃないかな
- 「じゃあそれ見せてよ」って言わせるまでの「ツカミ」だね
原文タイトル：Design a Product Box
- テを動かすところが重要だよね
- イメージを具現化して共有できる
- 機能で考えるんじゃなくて効能で考えるってことができる、プログラマに抜けがち
- でもターゲットによるのでは？たとえばプログラマにとっては「魔法のような」じゃなくてスペック一覧のほうが魅力的だったり
- プロジェクトの最後のほうでチームメンバーと一緒にアピールの文章考えると意外と考えているポイントが違ったりするよ
- これってエレベータピッチをさらに具体化する作業なのかな
- マーケティングとセールスの違いがあるんじゃないか、エレベータピッチはマーケティング エレベータピッチはセールス
- あと、同じようなことをいろんな角度から考えてみる、という効果も。
- エレベータピッチは他の製品との比較差別化、パッケージデザインは製品固有の魅力を考える、みたいな
- パッケージデザインしたら魅力的じゃなかったらどうすればいい？
- あるあ（ｒｙ
- それで、ほんとに必要なものなのか？という見直しが出来れば効果的なんじゃないか
原文タイトル：Create a NOT List
- 「やらない」と決めても開発中に『これやらないの？』とか声上がったり実はやりはじめちゃったりすることもある、ちゃんとリスト化して共有しとくべきじゃない？
- 「あとで決める」は曲者かな、どんどんたまってくと思う
- それをちゃんと定期的に見直してリスト整理しとくことが前提だ
- 「やる」「やら」「あと」の線引きが難しいなぁ
- やらない の 「今回は」が重要だと思う
- 例えば「今回は(ﾟεﾟ)ｷﾆｼﾅｲ!!」としても、「次回」やろうとしたとき、設計の根底からくつがえっちゃうようなものだったとき、気にせざるを得なくない？
- まぁケント・ベック的に言えば「気にしない、やらない、やろうとするときリファクタリングするんだ」ってことだよね
- メンバー内で「これは、変えようとすると大変かもしれないけど、今回やらないよ？」とかちゃんと同意することになるんでは * だから、そのときの「メンバー」には顧客も入ってるべきだ。 * 統括責任者もね！
- そして、こまめにやる・やらないを共有しないとえらいことになる
原文タイトル：Meet Your Neighbors
- 他のチームとのコラボ機能つくるときとか、ほんと「ご近所さん」探し重要、知らないとわからないこと多い。
- ご近所さんを探すブレストとか、新鮮だった。
- 「忘れられないようにする」のも大事だ。
- 社内散歩とかオススメ！
- IRCとかメッセも駆使できそう
- 新卒だと同期でネットワーク作れるよね
- 社内勉強会とかも活用したりね
- いやー勇気いるよね でもやらないと後でぜったい痛い目にあうということはわかってるみたいな・・・
- たとえば怖い人とかえらい人がいたとしても、真剣に、十分にアプローチすれば、認めてくれて伝わるもんなのではないかな
- そこのレベルに立つまでの習熟？が大変ではあるだろうな
次回は「第５章 具現化させる」からやります。