【TFSUG】プロダクトオーナーシップ

4,405 views

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,405
On SlideShare
0
From Embeds
0
Number of Embeds
417
Actions
Shares
0
Downloads
49
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

【TFSUG】プロダクトオーナーシップ

  1. 1. プロダクトオーナーシップ 柴山 洋徳 @shibao800 2012/9/20 http://www.flickr.com/photos/plasticbag/2197013436
  2. 2. Scrumhttp://www.flickr.com/photos/conchur/3358169824/
  3. 3. Scrumとは? 複雑なプロダクトを開発・維持 するためのフレームワーク 可能な限り価値の高いプロダクトを 生産的、創造的に届けるためのもの シンプルでわかりやすいという特徴http://www.flickr.com/photos/conchur/3358169824/
  4. 4. Scrumのプロセス 顧客
  5. 5. Scrumのフレームワーク ロール • プロダクトオーナー • スクラムマスター • チームメンバ • スプリント計画 イベント • スプリントレビュー • ディリースクラム • レトロスペクティブ 成果物 • プロダクトバックログ • スプリントバックログ • インペディメントリスト
  6. 6. プロダクトオーナーhttp://www.flickr.com/photos/28288573@N07/560101355
  7. 7. http://www.flickr.com/photos/28288573@N07/560101355 プロダクトオーナー プロダクトの責任者 スクラムマスター プロセスの責任者 http://www.flickr.com/photos/saragoldsmith/2896144414http://www.flickr.com/photos/28288573@N07/560101355
  8. 8. プロダクトの価値を最大化するhttp://www.flickr.com/photos/digitalcurrency/2438119267
  9. 9. http://www.flickr.com/photos/interllectual/73657348
  10. 10. Sprintに出来る限り詰め込もうとするPOhttp://www.flickr.com/photos/kisocci/4359335672
  11. 11. ContinuousQuestionhttp://www.flickr.com/photos/valeriebb/3006348550
  12. 12. トレーニングが大切 プロジェクトの成功はPOにかかっている 特に、Scrum導入初期はPOの影響は大 スクラムマスターだけではなく、POのトレーニングも必須 POがお客様の場合は、お客様と一緒のトレーニングも
  13. 13. プロダクトの機能と特徴を定義するhttp://www.flickr.com/photos/viagallery/4962826227
  14. 14. http://www.flickr.com/photos/interllectual/73657348
  15. 15. いろいろついてると凄いと思っているPOhttp://www.flickr.com/photos/popculturegeek/5917936778
  16. 16. ContinuousQuestionhttp://www.flickr.com/photos/valeriebb/3006348550
  17. 17. POもチームメンバー POもScrumチームのメンバーであり、協調していく 当然、チームはPOに意見してもいい 優先順位付けやフィーチャの価値について意見していこう プロダクトオーナーチームとしてPOをサポートするのもあり
  18. 18. プロダクトのリリース計画をたてるhttp://www.flickr.com/photos/teegardin/5912231439
  19. 19. http://www.flickr.com/photos/interllectual/73657348
  20. 20. リリースのマイルストーンしか決めないPOhttp://www.flickr.com/photos/akuchling/59791505
  21. 21. ContinuousQuestionhttp://www.flickr.com/photos/valeriebb/3006348550
  22. 22. リリース計画とは戦略である リリースとは、プロダクトの価値を高める機会 リリース計画は、プロダクトの価値を高める戦略である 価値の流れ→フィーチャの流れ→リリース計画 ユーザーストーリマッピングを使う
  23. 23. プロダクトバックログを管理するhttp://www.flickr.com/photos/rameshng/5723481678
  24. 24. http://www.flickr.com/photos/interllectual/73657348
  25. 25. プロダクトバックログを長期間放置するPOhttp://www.flickr.com/photos/kentamabuchi/4616039938
  26. 26. ContinuousQuestionhttp://www.flickr.com/photos/valeriebb/3006348550
  27. 27. 定期的なバックロググルーミング 要求は劣化する。市場、環境は変化している プロダクトバックログは、プロダクトの価値を体現するもの しかし、バックログの管理は想像以上にハード 定期的なイベントとして、バックログのお手入れ(バックログ グルーミング)ミーティングを設定する
  28. 28. 成果の受け入れ可否を判断するhttp://www.flickr.com/photos/usfsregion5/5808624923
  29. 29. http://www.flickr.com/photos/interllectual/73657348
  30. 30. 受け入れ基準を後出しするPOhttp://www.flickr.com/photos/31029865@N06/7704553226
  31. 31. ContinuousQuestionhttp://www.flickr.com/photos/valeriebb/3006348550
  32. 32. バックログアイテムをReadyにする バックログアイテムは、スプリント計画会議までにReadyで ある必要がある アイテムの受け入れ基準もReadyとなる条件の一つ 受け入れ基準は、DoD(definition of Done)の一つ DoDは、Scrumの透明性において重要な要素だ 受け入れ基準の後出しは、“無駄”につながる
  33. 33. プロダクトオーナーシップhttp://www.flickr.com/photos/tenz1225/6217529904
  34. 34. プロダクトオーナーシップの4要素 Management Technique Leadership Visionaryhttp://www.flickr.com/photos/intelphotos/6763293297 http://www.flickr.com/photos/zzpza/3269784239 http://www.flickr.com/photos/nicmcphee/250890495/
  35. 35. Visionary http://www.flickr.com/photos/nicmcphee/250890495/
  36. 36. Visionary プロダクトのビジョンを描く 「何を作りたいか」ではなく 「なにを解決したいか」 人々の心を動かすのはビジョンと情熱 プロダクトは変化しても、ビジョンは通 常、変化しない http://www.flickr.com/photos/nicmcphee/250890495/
  37. 37. ゴールデンサークル What How Why
  38. 38. ゴールデンサークル~ダメなケース What How Why
  39. 39. ゴールデンサークル~良いケース What How Why
  40. 40. 某ALM製品のケース 我々のALM製品は素晴らしく What 自動ビルドからCIまで、なんでも How でき、インストールも簡単で、 ユーザフレンドリーです。 Why おひとついかがですか?
  41. 41. TFSのケース 我々のすることはすべて、ビジネ ス価値を最大化する開発環境 を実現することが重要だという信 What 念のもとで行っています。 私たちがビジネス価値を最大化 How する手段は、価値の流れの中で 継続的フィードバックを実現する、 ソフトウェアライフサイクル全体を Why 統合管理できる製品なのです。 その結果、こうして素晴らしい ALM製品ができあがりました おひとついかがですか?
  42. 42. ゴールデンサークルとビジョン Product Strategy Vision
  43. 43. Management
  44. 44. Management 従来のPMスキルも必須スキル コントロールパラメータが変わるため、 マネジメント方法の転換が必要 定義済みプロセス制御 VS 経験的 プロセス制御 顧客がいる場合には、リスクの考え方 が変わる
  45. 45. マネジメントトライアングル Fixed Parameter Scope Time ResourceTime Resource Scope Variable Parameter
  46. 46. デスマーチ Fixed Parameter Scope Time Resource Variable Parameter
  47. 47. マネジメントの転換 PM PO プロダクト品質 ビジネス価値 計画駆動 予測駆動 タイムマネジメント スコープマネジメント
  48. 48. リスクの変化 明確な「ビジネスリスク」と「システムリスク」の責任分担から、 相互のリスクの共有へ 真のビジネスパートナーシップ Business System Business System Risk Risk Risk Risk
  49. 49. 品質管理の話 内部品質や外部品質のやり方にこだわる前に、やることが あるんじゃないでしょうか? Process Internal External Quality Quality Quality Quality in Use
  50. 50. Leadership http://www.flickr.com/photos/nicmcphee/250890495/
  51. 51. Leadership プロダクトの成功はPOの責任 ビジョンによってチームを強力にリード 協調によりステークホルダーと対話 POはプロダクトに責任はあるが、 チームへ指示することは許されない http://www.flickr.com/photos/nicmcphee/250890495/
  52. 52. Leadershipの4要素 勇気 信頼 追究 謙虚
  53. 53. 勇気 TOCの心1:ものごとはそもそもシンプルである POの意思決定のスピードがビジネスのスピード POは、大胆な意思決定があらゆる局面で求められる 複雑に思える状況も、紐解けばシンプルと信じ、勇気ある 意思決定を行おう
  54. 54. 信頼 TOCの心2:人はもともと善良である 信頼関係の前提は、性善説 POは、チームのパフォーマンスを最大化させねばならない ビジョンと信頼関係により、自己組織化を促す
  55. 55. 追究 TOCの心3:対立には、常に、妥協なき解決方法がある 品質vsデリバリー、計画的なリリースvsプロダクトの適応と 柔軟性、など様々な局面で対立に妥協なき解決をはかる ビジョン達成のために、妥協のない最高のプロダクトを追究 する
  56. 56. 謙虚 TOCの心4:わかっているとは決して言わない 自分の考えていること、知っていることが全て、正しいと思っ た瞬間から、思考停止が始まる POは全知全能ではない。本当のユーザは誰ですか? 失敗から学ぶ
  57. 57. Technique http://www.flickr.com/photos/zzpza/3269784239
  58. 58. Technique POの活動は多岐にわたる さまざまな活動をサポートするための テクニックを活用しよう  ビジネスモデルキャンパス  プラグマティックペルソナ  インセプションデッキ  ユーザーストーリーマッピング etc http://www.flickr.com/photos/zzpza/3269784239
  59. 59. Technique詳しく知りたい方は・・・@fullvirtue さん主催の「プロダクトオーナー勉強会」へhttps://sites.google.com/site/spostudy/
  60. 60. 自己紹介 柴山 洋徳 (Twitter:shibao800) 仕事  CCPM/TOC コンサルティング  組織変革コンサルティング  社内システム開発のスクラムマスター  社内システム開発のプロダクトオーナー  社内アジャイルコーチ
  61. 61. さあ、今日から、楽しいプロダクトオーナーライフを送りましょう! Fin. TFS , Team Foundation ServerおよびVisual Studio は、米国 Microsoft CORPORATIONの米国およびその他の国における登録商標または商標です。 その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。

×