your mind is the scene of development

Ichitani Toshihiro /papanda2012.10.28

ScrumDoExpo2012OracleAoyamaCenter

Your Mind is the Scene of Development

市谷聡啓Eiwa system management.inc/DevLOVE

As far as we continue expanding and sharing our experience,We may fly in the sky, too.

2012年10月28日日曜日

papandaToshihiro Ichitani

市谷聡啓Company : Eiwa system management.incCommunity : DevLOVE (a founder)

twitter : @papandahatena : papanda0806and living in facebook


Project Forming

Inception Deck Workshop

インセプションデッキで期待の可視化 AgileProjectMangerのミッション

WorkShop Facilitatorとして実践の前に失敗できる場を提供

CampanyWork

CommunityWork


このセッションでは実体験を通じて得られたインセプションデッキに関する私のいくつかの工夫についてご紹介します


なぜインセプションデッキ？


なぜインセプションデッキ？「然るべき人が集まっているか」「プロジェクトが然るべき方向を　向いているか」を明らかにする


なぜインセプションデッキ？「然るべき人が集まっているか」「プロジェクトが然るべき方向を　向いているか」を明らかにする“チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがダメになる”

アジャイルサムライP442012年10月28日日曜日

インセプションデッキ

われわれはなぜここにいるのか

エレベーターピッチ

パッケージデザイン

やることやらないこと

リスト

プロジェクトコミュニティ

技術的な解決策

夜も眠れない問題

期間を見極める

トレードオフスライダー

なにがどれだけ必要か

Whyを明らかにする Howを明らかにする2012年10月28日日曜日






リスト







Whyを明らかにする Howを明らかにする

全体


いつデッキをつくるか？


いつデッキをつくるか？プロジェクトキックオフ？最初のイテレーション？


いつデッキをつくるか？プロジェクトキックオフ？最初のイテレーション？

Too Late


いつデッキをつくるか？契約前予算取り前なぜなら、正しい制約を作るために。



契約予算確定開発Deck前提




確定後にその前提を揺さぶることは難しい


ステルスデッキ




目的に適した制約を作りプロジェクトを開始する

Deck

“ステルスデッキ” デッキ更新


“ステルスデッキ”





リスト








“ステルスデッキ”のポイント


“ステルスデッキ”のポイント

プロジェクト開始前プロジェクト開始後

ステークホルダーにはインセプションデッキとあえていわない

インセプションデッキの目的を明らかにして作る

制約を炙り出すための仕掛けなのでデッキ自体への期待は不要

プロジェクトの方向を明らかにするために関係者の協力が不可欠

ステルスデッキインセプションデッキ


インセプションデッキのCRUD


インセプションデッキのCRUD

Create

Read

Update

Delete

プロジェクト開始前と開始後でそれぞれの目的でデッキを作る

最初はデッキの内容のチームへの定着が必要。週1回全員で点検するなど

デッキの更新とはプロジェクトの方向が変わること。その認識を合わせる

デッキが用を成さなくなるとき


デッキのゴールデンサークル

What

How

Why

具体的な提供

Whyを実現する根拠

何のためにやる

What is ゴールデンサークル?



作りたいものユーザーストーリー

Deck後半5枚<How>

Deck前半5枚<Why>




Deck後半5枚<How>

Deck前半5枚<Why>

Update

Whatの変更、バックログで出し入れ




Deck後半5枚<How>

Deck前半5枚<Why>

Update

技術的解決策の変更やリスクの発生。何がどれだけ必要かへの影響も明らかにする




Deck後半5枚<How>

Deck前半5枚<Why>

Updateプロジェクトの方向が変わる。How、Whatすべてに影響を与える。ステークホルダーの認識を確認する。PJ全体としての判断と合意。

デッキはプロジェクトの探知機その方向の変化を把握できているか？







リスト








インセプションデッキの弱点


インセプションデッキの弱点

Who2012年10月28日日曜日

エレベーターピッチ• [潜在的なニーズを満たしたり、潜在的な課題を解決したり] したい• [対象顧客] 向けの、• [プロダクト名] というプロダクトは、• [プロダクトのカテゴリー] です。•これは [重要な利点、対価に見合う説得力のある理由(プロダクトにお金を払いたい理由)] ができ、• [代替手段の最右翼] とは違って、• [差別化の決定的な特徴] が備わっている。

誰の何を解決するのか?2012年10月28日日曜日

What

How

Why

具体的な提供

Whyを実現する根拠

何のためにやる

ゴールデンサークルにもWhoはない

Who

誰のために


Whoを見落とすな

Whoの分だけピッチがある2012年10月28日日曜日

Whoの分だけピッチがある


Whoの分だけピッチがある

他にもターゲットはいるか？１つに絞れていなくて大丈夫か？


Whoの分だけピッチがあるニーズは全てあらわれているか

ターゲットがこのニーズを持っているとした根拠は何か







リスト








いきなりやらないことは出せない


いきなりやらないことは出せないプロジェクト開始前 Sprint1 Sprint2 SprintN

「いまからPJを始めるのにやらないことだって?」

「スコープの調整のために、これはやらなくて良い」


いきなりやらないことは出せないプロジェクト開始前 Sprint1 Sprint2 SprintN

「いまからPJを始めるのにやらないことだって?」

「スコープの調整のために、これはやらなくて良い」

開発への期待を明らかにする

スコープを明らかにする


やることやらないことで開発への期待を明らかにする


やることやらないことで開発への期待を明らかにする

「開発チームとコミュニケーションをしっかりとりながら進めたい」

関係者の開発への思いを把握する

「ドキュメントに全てのことを書き表すのは無理。」

「あなたの苦い経験を教えてください」







リスト








ご近所さんをご近所さんとして認識せよ誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい


ご近所さんをご近所さんとして認識せよ誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい

顧客は自分の組織を知っているが今回のソフトウェア開発の進め方をまだ知らない

開発チームはソフトウェア開発の進め方を知っているが、相手の組織のことを知らない


ご近所さんをご近所さんとして認識せよ開発のよくある役割を確認する。顧客に過去の開発にあった役割を思い出してもらう。

「うちは社長がUIをチェックすることになっているんです。」

「セキュリティ監査、QA、品質管理、インフラ現行システム担当etc」







リスト








チームを選ぶことはアーキテクチャを選ぶことだ


開発チーム結成

チーム結成後にDeckで確認しても、遅すぎる


チームを選ぶことはアーキテクチャを選ぶことだ

契約予算確定開発Deck前提 Deck


開発チーム結成


ファシリテーターがデッキの出来を左右する





リスト








手ぶらでやったら簡単に事故る2012年10月28日日曜日

練習重要。本番は、本番。

社内で、コミュニティで。


質問力重要良質な問いかけがプロジェクトの行く末を左右する

アクションラーニング問いかけだけで問題解決を進める手法。意味のある質問をするための訓練になる。







リスト







Whyを明らかにする Howを明らかにする

インセプションデッキはソフトウェア開発の始めの始め方

各自の知見を持ち寄ってその工夫を発見しよう


your mind is the scene of development

Technology