Your SlideShare is downloading. ×
Scrumと組織
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrumと組織

8,897
views

Published on

2011/

2011/

Published in: Technology

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

No Downloads
Views
Total Views
8,897
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
111
Comments
0
Likes
14
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scrumと組織
  • 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/
  • 3. なぜAgileが必要なのか?
  • 4. 企業のおかれた状況• ビジネスの環境の変化• 迅速な意思決定と具現化が求められる• 変化しないことは市場から見捨てられるリスク がある• 企業自身が変化していくことが強く求められる• IT投資の目的の変化 – 業務効率化から戦略実現へ – いままではコスト削減、業務効率化ができていれば 良かったが、システムが他社との競争力の源泉に なってきている – よいシステムを早期に市場に投入することが、強く 求められる
  • 5. 競争の速度の変化
  • 6. ビジネスモデルの賞味期限が短縮
  • 7. 変化への対応「事前に綿密にたてた計画を長期間遵守」ではなく「変化が起こることを前提に頻繁に軌道修正」することが必要
  • 8. ソフトウェアの不確実性• 不確実性コーン From 10 Deadly Sins of Software Estimation by Steve McConnell, ©2002-2007
  • 9. 納期の確率分布• ソフトウェゕの納期予測は確率分布である 一般的にプロジェクトマネージャがリリース可能日を設定する場合、 最もリリースできる確率が高い日を選ぶが、その日にリリースできな い可能性の方が高い
  • 10. システムの機能の利用割合 • 64%の機能はほとんど使われない いつも使う システムの機能の利用割合 7% よく使う 13% まったく使われない たまに使う 45% 16% ほとんど使 われない 19%Standishの2000年の調査より
  • 11. 7つのムダ トヨタ生産方式におけるムダの分類• 作り過ぎのムダ – 使われない機能、ビジネス価値を生まない機能• 手待ちのムダ – 仕様待ち、ビルド待ち、テスト待ち• 運搬のムダ – タスク切り替え• 加工のムダ – 開発に利用しない報告書、重複した部品• 在庫のムダ – 過剰なドキュメント• 動作のムダ – 分散開発による移動時間、ツール不足による手作業• 不良をつくるムダ – バグの後工程での発覚と手戻り
  • 12. Agileとは?顧客の価値を実現し開発に関わるメンバーの幸せを実現し会社の利益をあげるそのための 道具 http://www.flickr.com/photos/dhammza/474654705/
  • 13. Scrumの基礎http://www.flickr.com/photos/royskeane/413103429/
  • 14. Scrum=フレームワーク• 基本価値観 – 自己組織化 – タ゗ムボックス – 検査と適応• 技術的プラクテゖスは定めていない• 他のAgile開発手法との併用を妨げない• 現実的にはXPのプラクテゖスの一部の採用が不 可欠(後述)
  • 15. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 16. プロダクトオーナー・製品の責任者
  • 17. プロダクトオーナー• 製品に必要な機能をとりまとめる• リリース日とリリース内容を決める• 製品が生む利益について責任を持つ• 機能の優先順位を定める• 機能と優先順位を見直す• 作業の結果を受け入れる、 または拒否する• スプリントを中止できる
  • 18. プロダクトオーナー不在• 典型的アンチパターン• ステークホルダーが多い場合に問題が顕在化• フゖードバックプロセスの欠如• チームは… – 何を作ってよいか分からない – 作っているものが正しいか分からない – 作っているものにビジネス価値があるか分からない対応策プロダクトオーナーの選任またはプロダクトオーナーチームの立ち上げ
  • 19. スクラムマスター• スクラムプロセスの番人• 外部の干渉からチームを守る
  • 20. スクラムマスター• プロジェクトマネジメントの代表• スクラムの価値とプラクテゖスの 実現に責任を負う• 障害事項を取り除く• チームが十分に機能し生産的で あることを保証する• 全ての役割の人たちと密接な 協力関係を保てるようにする• 外部の干渉からチームを守る
  • 21. チーム • 5~9人 • 機能横断的 • メンバーはフルタ゗ムプロジェクトへ参加 • チームは自己組織化されている
  • 22. チーム• チーム全体でプロジェクトに取り組む• チームでゴールに向かって一丸となって 進めることをコミットする• タスクの担当はチームで決める• こなしたタスクの多寡で評価されない• メンバーの交代はスプリントと スプリントの間のみ• チームのルールに従う責任• 常に改善する責任
  • 23. チームのルールに従う責任• 全てのゕジャ゗ルなプロセスはチームへ の権限移譲とチーム内での文化および規 範の確立を必要とする• デ゗リースクラムに出席する責任• 完了の定義に従って作業を行う責任• チームメンバーを助ける責任• チームメンバーを育てる責任
  • 24. 常に改善する責任
  • 25. ふりかえりによる改善• プロセス改善の場• 個人攻撃はしない• 個人の評価に結び付けない• 特定の人ばかりが喋るのはNG• Tryはほんとうにできている?追跡重要• 同じProblemが毎回でてきていない?• 全部の問題に一度に手をつけないことが良い場 合も• 出来ることから改善する態度
  • 26. コミットメントとは何か?• チームが「全力で選択したストーリーをDoneにし ようとする」ことをコミットと呼ぶ これはチームの責任であり、個人の責任ではない• 見積もりはコミットメントではない – が多くの場合見積もりがコミットとして扱われる悪い習慣 がある• 複数スプリント経過後、チームのベロシテゖが明ら かな場合は、ベロシテゖに基づいてストーリーを チーム全員の合意でコミットする場合はある
  • 27. 豚と鶏POとSMとチーム ユーザー、マネージャ、 ステークホルダー…
  • 28. オペレーションプロセスの変化• 従来のコマンド・コントロール型から、自律 化・自己組織化への変化が求められる – コマンド・コントロール • 上司の命令に従っていれば良い、という価値観 – メンバーはやらされ感を持つ – 上司の指示を遵守したかどうかが評価の観点に – 人が育たない。通常は上司の劣化コピーに… – 現状に不満をもつ優秀な人から順に退職… – 自己組織化 • 上司は責任とチームで解消できない問題の解決を担う • 上司は後方支援、フゔシリテーター役になる • チームを信じる
  • 29. チーム運営• チームのビジョンの共有 – チームがチーム足りえる目的を共有することでチー ムメンバーのモチベーションを維持する• 自己組織化した組織における改善のループ – 常に改善できることがないか?という意識を持つ – 気づきの場としての振り返りミーテゖング – 振り返りで出た問題をそのままにしない、Tryが出来 ているかのモニタリングを継続的に行う
  • 30. 現場リーダーや管理職の役割の変化 • 従来の役割・振る舞い • 求められる役割・振る舞い – ピラミッド組織 – ネットワーク型組織 – コマンド・コントロー – 自律・自発の支援 ル – 民主的 – 権威的 – 流動性のある – 流動性がない – 導く – 答えをいう – 褒める – 叱る – 肯定 – 否定 – チームの自主性に任せ – マ゗クロマネジメント る自己組織化されたチームで仕事をできるようにするためには、外部からのマイクロマネジメントを止める必要がある。通常チームは指示があればそれに従ってしまうものであるため、外部からの指示がなくならない限り、チームは自己組織化したチームにはならない。
  • 31. リーダーシップのモデル(SL理論) • リーダーシップのモデル は左図のように4つに分 類される。 – S1:具体的な指示と監督 – S2:説明と疑問への回答 – S3:参加型 考えを合わせて決めら れるように仕向ける 考えを説明し、疑問に 応える – S4:委任型 • ゕジャ゗ルなチームの リーダーはS3/S4を目指 す。通常WFではS1に該 当 • 有効なリーダーシップは 具体的に指示し、事細 かに監督する 部下・組織の成熟度に 仕事遂行の責任をゆだ ねる よって異なるhttp://www.situational.com/ より図を引用
  • 32. 人材育成• チームが人を育てる• OJTによるマンツーマンな人材育成ではなく、 チーム全員が協力しあってお互いの能力を向上 させる• チーム内での勉強会などの開催も有効。僅かな 時間的投資が後に何倍にもなる• 文化や環境によって人の成長速度は変わる
  • 33. 人事評価• 個人単位の評価からチーム単位の評価• 評価プロセスの透明性 – 誰もが納得する評価基準 – ゕジャ゗ルな開発プロセスにおける透明性を懲罰に 利用しない – 評価の不透明さは、人が育たなくなる第一歩 – 評価の不透明さは、個人によるタスクの抱え込み、 問題の隠ぺい、手抜き、過剰なバッフゔの確保など につながる
  • 34. 現実的なScrumの導入
  • 35. Doneの定義とは• チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの一覧。• 例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く• ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。• Doneの定義はチームの成熟度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。
  • 36. Doneの定義(例) • ストーリーのDoneの定義 • 内部リリースのDoneの定義 – テストコード、プロダクションコード – 全てのスプリントのDoneの定義を満 含め全てのコードがチェック゗ンされ たす ている – ゗ンストーラーが作られている – 全てのユニットテストをパスしている – 操作ガ゗ドが更新されている – 全ての受け入れテストが用意され、そ – トラブルシューテゖングガ゗ドが更新 れにパスしている されている – ヘルプフゔ゗ルが自動で作られている – 障害発生時の復旧計画が更新されてい – 機能テストにパスしている る • スプリントのDoneの定義 – 全てのテストス゗ートにパスしている – 全てのストーリーのDoneの定義が満 • 製品リリースのDoneの定義 たされている – 全ての内部リリースのDoneの定義を – プロダクトのバックゕップが更新され 満たす ている – 負荷テストが実施されている – パフォーマンステストが完了している – パフォーマンステストが実施されてい – パッケージ、クラス、ゕーキテクチャ る のダ゗ゕグラムを更新されている – ネットワークダ゗ゕグラムが更新され – 全てのバグが解決しているか、対応の ている 時期を決めている – セキュリテゖゕセスメントに合格して – ユニットテストによるコードカバレー いる ジが80%以上である – 脅威分析試験に合格している – 障害発生時の復旧計画がテストされて いる
  • 37. XPとScrumの融合 • スクラムのプラクテゖス • XPのプラクテゖス(古典的な12個の – 役割 場合) • スクラムマスター – 計画ゲーム • チーム – 短期リリース • プロダクトオーナー – メタフゔ – 儀式 – シンプルな設計 • デ゗リースクラム – 自動化されたテスト • スプリント計画ミーテゖング – リフゔクタリング • スプリント・レビュー – ペゕ・プログラミング • スプリント振り返り – コードの共同所有 – 作成物 – 継続的な結合 • プロダクトバックログ – 週40時間労働 • スプリント・バックログ – オンサ゗ト顧客 • バーンダウンチャート – コーデゖング規約 スクラムのプラクテゖスに、XPの赤文字箇所のプラクテゖスを統合すること で、技術的な面でプロジェクト全体をカバーできる。XPの週40時間労働という プラクテゖスは採用しない. スクラムではチームの自律性を重要視するので, 働 く必要があれば残業でも休日出勤でもする(がオーバーペースは必ずツケがあ るので、スプリントの振り返りでの改善検討対象にすること)
  • 38. Scrumでの品質の作りこみ 24時間 スプリント 2~4週間 スプリントゴール 返品 スプリント 出荷可能な製品の Return キャンセル バックログ 積み上げ Gift wrap クーポン Cancel ギフト包装 クーポン 単体テスト、結合テスト、 受け入れテストがスプリンプロダクトバックログ ト単位(もしくはリリース単 位)で行われる.
  • 39. Scrumでの品質の作りこみスプリント終了時には「テスト」が完了.スプリントレビューで顧客のビジネス要件への適合性も確認できるhttp://www.flickr.com/photos/kakutani/2761992149/
  • 40. Scrumでの品質の作りこみScrumではフレームワークの定義のみで、テスト自動化については触れられていない.しかしアジャイル開発においてはテスト自動化は必須 小規模リリースのたびに手動 でテストすると後半のスプリ ントになるにつれてテストコ ストが膨らむ自動化しないとソフトウェゕ規模に応じて、テスト工数の占める割合が増加していく(=価値への投資が減少)
  • 41. テストの4象限 ビジネス面(ビジネス的品質) 【自動と手動】 【手動】※1 機能テスト 探索的テスト ストーリーテスト シナリオテスト プロトタ゗プ ユーザビリテゖテスト シミュレーション ユーザー受入テスト ゕルフゔ版、ベータ版 チ 製 ー 第2象限 第3象限 品 ム を を 【自動化】 【ツール】 批 支 評 援 単体テスト パフォーマンステスト コンポーネントテスト 負荷テスト セキュリテゖテスト 第1象限 第4象限 技術面(技術的品質)※1 ATDD等では自動化
  • 42. 第1象限での自動評価テスト件数と結果(単体、結合) PMD警告件数完了の定義をもとに、できる限り自動で検証できる仕掛けを用意するCheckstyle警告件数 カバレージ
  • 43. チーム活動の評価コード行数 コミット時間アクティビティ
  • 44. ドキュメント• ドキュメントを全く書かないわけではない• 必要な時期に必要なものを書く – 法令順守に必要な文書は、開発初期から必要なわけ ではない。 – 一方で保守・運用の資料はひとたびProductionリ リースしたタ゗ミングから常に保守される必要があ る。 – 自動化できるものは自動化する• 完了の定義にドキュメントを含める• 文書承認主義の組織の場合は、組織自体を改革 する必要がある
  • 45. 失敗するScrum
  • 46. 失敗するScrum• 個人の対立• 混乱• 規律がない• 破壊的な振る舞い• 無気力• 恐れ• 支配• 反感・嫌悪• 過剰な優越感• 無視• 立場を決める• ぬるま湯• 無関心
  • 47. 失敗するScrum• マ゗クロマネジメント• ミニウォーターフォール• 責任追及、詳細な報告• チームの決定を覆す• スクラムマスター=チー ムの責任者• ヒロ゗ズム、悪い価値観• コマンドコントロール• 専門化、責任の限定• 階層組織型の思考• 個人保証• コンプラ゗ゕンス• 非難
  • 48. 失敗するScrum• スプリントNのプロセスがスプリン ト1と同じ• ベロシテゖが分からない• 顧客へのデモをしない• コードレビューをしない• 単調なスタンドゕップミーテゖング• チェック゗ンの前にテストがない• 悪いメトリクス• チームでのリフレクションの欠如• 個人でのリフレクションの欠如• コミットメントがない• 学習しない、価値の誤った定義• 安全地帯の範囲しかやらない
  • 49. 失敗するScrum• 変化に対応する時間を持たない• ゕクションのないふりかえり• うまくいかないことを繰り返しやる• リフゔクタリングの欠如• 結論や決定事項のないスプリントレビュー• テストがない• やり方が決まっていない• うまく機能しないスクラムマスター• 弱いプロセス、押し付け型のプロセス• 組織からのプレッシャー、プロダクトオーナーが 見えない、権限委譲がない• 適応しない、変化の頻度が高すぎる
  • 50. 失敗するScrum• 成り行きまかせの結果• タスクの引継ぎ• 特定の人だけが顧客と相対する• チーム計画がない• チームメートのペースにあわせない• 顧客のかわりに決めてしまう• チェック゗ン競争• コミュニケーションパスの硬直化• 責任をシェゕしていない• プッシュ型• 縄張り争い• 分散• 政治
  • 51. まとめ• ビジネス速度の変化に対応するのにAgileが必要• 見積は不確実で無駄なものを作りがち• ビジネス価値を基準をしたシステム作り• 個人ではなくチームによる行動• プロセス改善の責任• 完了の定義が必須。品質とリンクさせる• ドキュメントも必要• Agileな開発が失敗する原因の多くは文化