-
Notifications
You must be signed in to change notification settings - Fork 47
ReadingAgileSamuraiInShibuya20110803
- 読書会終了後に有志で飲み会があると思います。
- どんどんWikiになんでも書いてください。（まずいことがあれば消しますので）
インセプションデッキのテンプレート https://github.com/agile-samurai-ja/support
現場に行って確かめることが大事｡現場でしかわからないことはたくさんある｡
この章を読んで、下記の記事を思い出した。
明快なキャッチフレーズが大事ということは共通していると思う。
日経ものづくり ホンダ イノベーション魂！ 【第14回】コンセプトと本質（3）言葉の力
http://techon.nikkeibp.co.jp/article/HONSHI/20110427/191476/
特に後半は書きにくい(競合､差別化の決定的特徴など)｡しかし､わからないことを理由に書かないと､プロジェクトは失敗する｡わからないなら､わからないことをはっきりさせる(談)
ゲーム開発の現場で経験者がいた｡プロデューサがつくってチームで目的を共有｡シンプルに書くことが大事｡
この本で紹介されているエレベータピッチのテンプレートは「キャズム」に載ってるやりかた｡なぜこうするのかについて知ったほうがやりやすい｡ (ref: 「キャズム」 http://www.amazon.co.jp/dp/4798101524 )
「我々はなぜここにいるのか？」「エレベーターピッチを作る」「パッケージデザインを作る」は種類的に類似点があると感じますが、自分は「エレベーターピッチを作る」が折々で振り返って確認する際の素材にバランス良さそうと思いました
自社開発オレオレレガシーフレームワークを新しいものに入れ替えたいという事例｡レガシーコード減るとかでは説得できない｡それによってどんな価値を顧客に提供できるのか説明することで説得できたといういい話｡
- 携帯音楽ストレージをMicrosoftは「40GBともの大容量を実現」と表現する。
- Appleは「3000曲も持ち歩ける大容量」と表現する。
- この話聞いててもし日本のメーカーがiPhoneを作ったらを思い出しました。
ここに記載されている内容は全く以って同意。単に開発だけでなく、商品企画にも応用できると思う。 ユーザにとっては体験が全て。フィーチャーに興味はないと思ってよい。 「何を体験したいのか」を明確にしておくと、仕様を作る際のメンバー間のコンセプト共有も円滑になる。
みみっちい機能を断るみたいなのは､ユーザストーリーと優先順位で対応可能｡やらないことリストは､もっとでかい機能に対して使う
やらないことを今決めるのか､「あとで決める」に置いとくのか｡優柔不断だと「あとで決める」が肥大化しまくるのでは?? → やらないことリストは制約｡旧システムとの連携をやらないとか､DBの構造変更はしないとか､そういう根本的なものを書く｡
「あとで決める」が多いプロジェクトは破綻する｡
前回、アジャイルは0か1ではなく、取り入れられるものから、と言う話があったが、顧客を巻き込めない限りは他の顧客向けの仕事をするしかない、とある。 つまり、顧客を巻き込むことはアジャイル開発の絶対条件ということか？
- 「そういうのを断らず進めるとどうなっちゃうんですか」「炎上しちゃいます」みたいな会話があった｡
- そうしないと失敗するなら､それを伝えるべき
- 「やらないと失敗しますよと言い続けて失敗すればいいんじゃないでしょうか」
- 失敗事例トークになった
- 取引先を選ぶ
感想: 顧客が価値あるソフトウェア開発にコミットしないとエンジニアのモラルが崩壊して「価値のないソフトウェアを開発するのに成功した」とか言い出す
顧客が関わってくれるようになるまで時間を引き延ばすことができない場合はどうするのでしょうか？ ＊仕事をキャンセルすることもできない
「嗚呼、この方もご近所さんとして意識するべきだったんだあー」というような意外なご近所さんと遭遇された事はありますか？
この勉強会を１つのプロジェクトに見立てて、テーブル毎に4章の5項目を相談するのはどうでしょうか？結果をwikiに書き込むなどで発表？
複数の案が、ある場合は、どのようにすべきでしょう？
(完成した場合の性能の見積もりが難しいなど､どのアーキテクチャを採用すべきかわからない場合)
- ケースバイケースだが､まずはその問題を明らかにすることが大切｡
5.1 からリスクを抜粋し、真に恐ろしい問題を検討するのかな？
- それに限らず､ソフトウェア開発をするうえで考えられるリスク
- そして､取り組む価値のあるリスクを見極める
取り組む価値のあるリスクと取り組む価値のないリスクとの振り分けは「やらないことリスト」にも似ていると思った
- そのリスクに取り組むことで､自分やチームがどれだけの価値を生み出せるか?を考える
- リスクに対しても「あとで決める」はあるのか
- その時に取り組むか取り組まないか判断する
- 判断はその時点でのスナップショットなので､判断が将来変わることはある
- 可視化しろ､更新しろ(wikiと同じ)
- wikiを活用できないチームはアジャイルになれない!!!
大きな仕事を成し遂げようと思ったら、それをもっと小さな、制御できる単位へと分割… が印象的 アジャイルな開発では色々な粒度での「分割」が見受けられる、手に負える課題であれば気持ちの余裕もできる 経験を重ねながら「チームの制御可能な単位の大きさ」を見定めて行くと良いかも
「時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。」（p88）
⇒受託開発の経験では、プロジェクトを始めるとき、顧客はスコープこそが固定したいものだと考えがちだと思う。顧客のためを思えばこそ、時間と予算と品質は固定なものであってスコープのみが調整可能だということを、どのようにしてサムライたちは顧客と合意を形成していくのだろう。トレードオフ・スライダーを使ってその合意を可視化すると、具体的にどんなメリットが生まれるだろう。機会を見つけてやってみたい。
「時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。」（p88）
⇒時間、予算は、定義（数字）を決めることは比較的容易だと思いますが、品質は定義が難しく、何を持って品質が問題ないかを見極めるは容易ではないと思います。サービス内容によっても品質に注力するパワーも違う面があると思います（例：命、お金、個人情報を扱うか否かなど）。その点はみなさまどう思われるのでしょうか。
- ここで言う品質とは､「当たり前に動く」こと､要望されている通りに動作すること｡だから「品質固定」と言っているのだ｡
- 「要求したとおりに動く」以下の品質とかありえないよね
顧客にスコープを絞ってもらう為には、優先順位のしっかり付いたユーザストーリーと日々の誠実な価値の提供があってこそかなと感じた
「捉えどころのないもの」の例えが今ひとつ掴みきれません…
ジョブズ
4.4で「やらないことリスト」、5.4で「何をあきらめるか」で似ていると思った。インセプションデッキの全体像（なぜ）を4章、具現化を5章（どうやって）で扱ってますが、どちらの側面でも出てくるのですね。
- やらないことリストはまじでやらない
- トレードオフ・スライダーは､優先度が低くてもやらないわけではない｡重要だが､しかし他のもののほうが大事なので手を抜く｡
具体的なインセプションデッキを見てみたい
- 自分で作れば見られるので作れ
ユーザストーリーをあまり大きくないインデックスカードに書いて詳細を詰め込まない様にするのは、早期の段階で詳細な検討をするコストが将来の過程で無駄になるかもしれないという可能性を避けられる、必要になったときにFace to Faceで詳細確認すればよいと
複雑な条件分岐ケースなどは、一覧表などにしてもらった方が効率的なことがあります。
そういえばですが、熱心な弟子が最後に「自分でもよく考えてみます」と締めくくる事が多いけど、そういう姿勢が大事なんだなと感じる
お客さんとユーザーストーリーを共有されている方は、どのように共有されていますか？
アジャイルでは開発中に要件定義書、仕様書を作りこまないですが、 リリースする時は要件定義書、仕様書を作りこんで提出しますか？ ＊要件定義書、仕様書が無い場合、リリース後、数年経過して機能追加する必要が発生した場合に困ると思います。
p.122 「モレなくダブリなくストーリーを集められているだろうか？」という確認はこの時点ではどの程度重要なのだろうか。「次のイテレーションでカバーできるからOK」？それとも「この時点でしっかり押さえておいたほうがよい」？