①プラクティス何から始める？(30分) ② 実践にあたってよくある … ·...

Toshihiro Ichitani All Rights Reserved.

本日の目次

① プラクティス何から始める？(30分) ② 実践にあたってよくある質問 (30分) ③ Q&A (30分)


http://about.me/papanda0806

Ichitani Toshihiro

市谷聡啓@papanda

http://about.me/papanda0806


受託→SIer→サービス→受託→

プロダクトオーナー(企画者)支援アジャイル開発プロジェクトマネージャアジャイル開発コンサルタント

ここまでのあらすじ

「リーン開発の現場」


・現実的な作戦・理論より実践・大規模プロジェクト・カンバンの活用・チーム編成・問題の原因分析・テストの自動化戦略・見積もり・平鍋健児の解説・電子版もありますetc...

監訳角谷信太郎共訳市谷聡啓藤原大


本日の目次



インセプションデッキ

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

エレベーターピッチ

パッケージデザイン

やることやらないこと

リスト

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

技術的な解決策

夜も眠れない問題

期間を見極める

トレードオフスライダー

なにがどれだけ必要か

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


なぜ、インセプションデッキからか？・既存のやり方を大きく変えなくて　良い(追加)のではじめやすい。・部分的に始められる。まずはデッキ　の最初の一枚から。・効果がでやすい。共通認識づくりが　目的のため。


インセプションデッキワークショップ

10個のタフクエスチョン

？なんのためにデッキを

つくりますか?

デッキのゴールデンサークルなぜインセプションデッキを作るのか？


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


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

アジャイルサムライP44




PJを始める前に関係者の認識をあ

わせる

PJの状況や背景についてチームで話しあっておくことで、チームは状況に応じた適切な

判断が下せる。



“プロジェクトを始める前に関係者の認識を合わせる”とは？


“プロジェクトを始める前に関係者の認識を合わせる”とは？

プロジェクトメンバーが互いに持っている期待を明らかにし適切に調整する。

期待マネジメント


期待マネジメント・確認できた最古の書籍　「達人プログラマー」　※最近では「アジャイルサムライ」邦訳版コラムに・PMBOKと期待マネジメント　第3版まで明記はない　　第4版からコミュニケーションマネジメントの中に　第5版からステークホルダーマネジメントとして格上げ

　　※10個目の知識エリア　





わせる

デッキのゴールデンサークルどうやってインセプションデッキを作るのか？


How to Inception Deck ・なぜわれわれはデッキを作るのか・10個のタフクエスチョン・関係者全員で・1デッキ=60分～90分・叩き台作り->全員で叩く->整理・紙またはOnlineツール・ふりかえり、リリース後に見直す・開発プロセスに組み込む


Inception Deck & Processプロジェクトの方向付けインセプションデッキ

要求の収集、見積り、順序付けユーザーストーリー収集WS等

リリース計画リリース計画ミーティング

イテレーション開発へ







リスト









Inception Deck Pattern ・Why→要求収集(epic)→How 　- 基本パターン







リスト








要求収集


Inception Deck Pattern ・Why→要求収集(epic)→How 　- 基本パターン・Why→How→要求収集　- やるべきことがだいたい分かっている


Inception Deck Pattern ・Why→要求収集(epic)→How 　- 基本パターン・Why→How→要求収集　- やるべきことがだいたい分かっている・Why→How→Go/NoGo→Why→How 　- プロジェクト開始判断が必要


Inception Deck Pattern ・Why→要求収集(epic)→How 　- 基本パターン・Why→How→要求収集　- やるべきことがだいたい分かっている・Why→How→Go/NoGo→Why→How 　- プロジェクト開始判断が必要・Why + α 　- 簡易的に。αでトレードオフスライダー等


How to Inception Deck ・なぜわれわれはデッキを作るのか・10個のタフクエスチョン・関係者全員で・1デッキ=60分～90分・叩き台作り->全員で叩く->整理・紙またはOnlineツール・ふりかえり、リリース後に見直す・開発プロセスに組み込む

我われはなぜここにいるのか•大事な理由その1 •大事な理由その2 •大事な理由その3

<このプロジェクトの根幹に関わる理由を1つ、ここに書く

絶対に実現しなければいけないこととは？

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

誰の何をどうやって解決するのか?


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

Who

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

誰の何を解決するのか?


Whoを見落とすな

Whoの分だけピッチがある


Whoの分だけピッチがある


Whoの分だけピッチがある他にもターゲットはいるか？１つに絞れていなくて大丈夫か？

“彼ら”のニーズになっているか?

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

「重要な利点」は、ニーズを満たす理由になっているか。

「競合」が、達成できていないニーズを「差別化要因」は捉えているのか。


(プロダクトの名前)

(素敵な写真)

(最高のキャッチコピー)

(ユーザーへのアピールその1)



何ができるのか?効能は何か

やらないことリストやるやらない

あとで决める

スコープに何が入らないのか? 37


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


いきなりやらないことは出せないプロジェクト

開始前 Sprint1 Sprint2 SprintN

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

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


いきなりやらないことは出せないプロジェクト

開始前 Sprint1 Sprint2 SprintN

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

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

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

スコープを明らかにする後でスコープ調整できるように考え方を揃えておく



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


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

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

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

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

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

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

コアチーム

(○○グループ)

(他のチーム)

(ほげほげ部門)

関係者全員を！

...思っているよりもずっと大きい！ステークホルダーとの関係を明らかにせよ 43

技術的な解決策の概要

←リスクがある箇所

←今回は対象外

採用する技術: * <プログラミング言語> * <ライブラリ> * <ツール> * <その他の要素技術>

どんな技術やアーキテクチャを採用するのか 44

トレードオフ・スライダー典型的なフォース

機能をぜんぶ揃える(スコープ)予算内に収める(予算)期日を死守する(時間)高い品質、少ない欠陥(品質)

MAX MIN

MAX MIN

MAX MIN

MAX MIN

上記以外で重要なこと

簡単に使える考えさせない！詳細な証跡(なんでもログを取る)

(などなど)

MAX MIN

MAX MIN

MAX MIN

MAX MIN何を優先するべきなのか。判断基準は何か 45

夜も眠れなくような問題は何だろう?•もし起きたらこわーいこと、その1 •もし起きたらこわーいこと、その2 •もし起きたらこわーいこと、その3

どんなリスクがあるのか。 46

俺たちの“Aチーム”人数役割強みや期待すること1 アナリスト必要な分だけ必要なときに分析するスタイルで働ける。

テストも喜んで手伝える。素早い繰り返し型の開発スタイルで働ける。

2 開発者 C#、MVC.NET、jQuery、SQL ユニットテスト、リファクタリング、TDD、継続的インテグレーション

0.5 マネージャ顧客と直接顔を合わせてのコミュニケーションを担当する。状況報告、スコープ調整、予算管理、レポートラインへの報告

誰がどんな役割を担うのか。体制。 47

初回のリリースに必要なもの

3名、3.5ヶ月、$250K

リリース!構築受入テストトレーニング

~3ヶ月 1週間 1週間


どのくらいの期間で何がいくらで出来るのか 48


なぜ、インセプションデッキからか？・既存のやり方を大きく変えなくて　良い(追加)のではじめやすい。・部分的に始められる。まずはデッキ　の最初の一枚から。・効果がでやすい。共通認識づくりが　目的のため。





わせる

PJの状況や背景についてチームで話しあっておくことで、チームは状況に応じた適切な

判断が下せる。



本日の目次



契約は、請負と準委任どうするべき？


契約は、請負と準委任どうするべき？・どちらでもできる。　請負ならば幅でコミット深さで調整・はじめてのアジャイルなら準委任　ただし、事故になるときはなる・準委任の方が責任があいまいに　なり、結局は請負の方が良い場合も


品質の確保は、どう考えるべき？


品質の確保は、どう考えるべき？・各スプリントでの品質確保、自動化　バグつぶしと、仕様面のバグ解消・システムテスト・スプリント　総合的なテストを集中して実施・上記のとおりテストはするので　計測や基準は各社のやり方で良い


ドキュメントは、つくる？のこる？


ドキュメントは、つくる？のこる？・必要なドキュメントはつくる。　①認識あわせのために　　→初期資料　②理解をするために　　→ビジネスルール　③メンテのために　　→全体像を理解できるドキュメント


スコープの調整は、どうやって行なう？


スコープの調整は、どうやって行なう？・幅でコミットメント、深さで調整・交換可能なように規模感の見積と　その可視化(=理解)は必要・スコープを確認し、調節する場を　そもそも開発運営に組み込んでおく　= 計画ミーティング


QCDSをどうコントロールすれば良いのか？


QCDSをどうコントロールすれば良いのか？・コスト、納期、品質で大幅な調整は　できないことが多い→スコープで調整・最初から、トレードオフ基準を作って　おく。最初からというのが重要。・トレードオフスライダー。


スプリントを回すために必要なこととは？


スプリントを回すために必要なこととは？

・4つのイベントをまずはおさえる　①スプリント計画ミーティング　②デイリースクラム　③スプリントレビュー　④ふりかえり


プロダクトバックログスプリント

バックログ

スプリント計画ミーティング

設計/開発/テスト

手入れ/見積/選択

デイリースクラム

スプリントレビュー

スプリントレトロスペクティブ

リリース

プロダクトオーナー

開発チーム

スクラムマスター


誰が何をやっているか状況がわからない！


誰が何をやっているか状況がわからない！

・バックログを管理するツール　→カンバン、Pivotal、Backlog… ・チームのタスクを管理するツール　→タスクボード、カンバン・デジタルにカンバンを運用する　→Google Drive


一枚の絵を全員で見る「リーン開発の現場」P21


本日の目次


①プラクティス何から始める？(30分) ② 実践にあたってよくある … ·...

Documents

Transcript of ①プラクティス何から始める？(30分) ② 実践にあたってよくある … ·...