第1回 すくすく・スクラム ~スクラム基礎理論~
-
Upload
kazumasa-ebata -
Category
Technology
-
view
1.429 -
download
4
description
Transcript of 第1回 すくすく・スクラム ~スクラム基礎理論~
スクラム 基礎理論編
セントラルソフト株式会社
林 栄一
2009/04/23
クリエイティブな仕事したい人?
自己紹介所属:セントラルソフト株式会社 課長趣味はピアノ、ジェンベ、作曲、たまにライブ。PMとかアーキテクトとか、教育制度のプランニング、運営とか前職では楽器メーカーで電子楽器の開発オブジェクト大好き、モノ作り大好きドラムサークルファシリテーター協会メンバー認定スクラムマスターNLP認定プラクティショナー
トロント アジャイル2008
Thanksチームの皆へ送り出してくれた人達へ今日聞いてくれた人達へ
トム・ポッペンディック
ヘンリック・クニーベルグ
EM ZERO VOL2
滝 vs いきいき
ウォーターフォール
ウォーターフォール
市場 ビジネス IT
市場分析 発注
納品リリース
半年から3年
ウォーターフォールフィードバックの欠落したウォーターフォール・モデルが広まったのは防衛用ソフトウェア開発に関する仕様を定めた米国防総省の規格書(1985年6月)がきっかけだとされる。
これをベースに英国のJSP-188、フランスのGAM-T-17、ドイツのVモデルなどが作成されている。
しかし、これらの標準に基づいて推進されたソフトウェア開発プロジェクトが失敗を重ねたことから、米国防総省は1994年12月に反復型開発を推奨する「MIL-STD-498」定めている。 (wikipedia)
非ウォーターフォール
開発単位:大
上流工程ですべてを見通せる
各工程は一発勝負(実際は、手戻りによるやりなおし多発)
開発単位:小
上流工程ではもれがあるだろう
各行程をやりなおせる
滝 非滝
アジャイル
機能A
機能B
機能C
開発 サービス
開発 サービス
サービス開発
時間軸: 1週間~1ヶ月単位のリリースを繰り返す
機能軸 重要機能から積み上げる
R1 R2 R3
反復(Iterative)インクリメンタル(Incremental)
アジャイル
市場
IT1週間から1ヶ月
ビジネス
市場
ビジネスとITが一体になった「OneTeam」を作り、ミッションとリスクを共有する。やってみて、結果から戦略を作りながら進む。
さて、スクラム
スクラムとは 1/2 日本の製造業の製品開発手法をソフトウエア開発に応用した方法論
繰り返し開発 重要なものから作って使ってもらう 使ってもらって優先順位を区切りごとにメンテ 推進する役割をスクラムマスターという
スクラムとは 2/2
• スクラムチーム 開発を行う。スプリントにコミットする。
• スクラムマスター外部との折衝、チームを雑音から守るミーティングをファシリテートスクラム推進のキーパーソン
• プロダクトオーナー業務の視点で、ROIからプロダクトバックログの優先順位を管理
スクラムの原点 1 スクラム的手法を以前から開発プロジェクトで使っていた企業として、富士ゼロックス、キヤノン、本田技研工業、日本電気、セイコーエプソン、ブラザー工業、3M、ゼロックス、ヒューレット・パッカードなどがある。
これらのプロジェクトについては、一橋大学の野中郁次郎と竹内弘高が Harvard Business Review 誌に "The New New Product Development Game" として発表している(1986年1-2月)。逆に言えば、この論文がスクラムという用語の元となった。
スクラムの原点 2
不自然な円安、素直な労働者、日本文化、優れた自動化などで説明しきれなかったところで、北米自動車産業がトヨタの成功は一般労働者の能力の有効活用に基づくことを認めた。
Toyotaについての論文
スクラムの原点 3
“ プロセスの原理がよく把握できた分野でモデル駆動方式を利用するのは主流だが、そのプロセスは複雑な場合は実験の結果や経験基づく方法を利用すべきである。”
Process Dynamics, Modeling, and Control, Ogunnaike and Ray,
Oxford University Press, 1992
スクラムの原点 4Agile Manifesto
我々は自ら実践し、またそうしようとする他の人々を支援することを通じて、ソフトウェア開発のより良き方法を見いだそうとしている。
この活動を通じて我々は:個人とその相互関係を、プロセスやツールよりも動くソフトウェアを、包括的なドキュメントよりも顧客とのコラボレーションを、契約交渉よりも変化に対応することを、計画に従うことよりも価値あるものと考えるに至った。
スクラムの基礎となる価値
自己組織化
予測型 ⇒ 実測駆動
問題の原因はプロセスや技術ではなく人間に依存する
スクラムの概要
実測駆動管理と制御プロセスからなる振り返りと調整のループ2~4週間ごとの納品原理は単純管理しない管理チームの責任と権限
•スプリント 一ヶ月のイテレーション 。いつでも 納品。
• デイリースクラム 毎日定時に15分間のミーティング、 朝会
• プロダクトバックログ 業務視点で優先順位付けされたリスト
• スプリントバックログ スプリント(イテレーション)で 実現する作業リスト
• スプリント計画ミーティング スプリントバックログを作成する ミーティング
• スプリントレビュー スプリントの終了時に行う振り返り
スクラムのプロセス
スクラムのロール• スクラムマスター 外部との折衝、チームを雑音から守る ミーティングをファシリテート スクラム推進のキーパーソン
• プロダクトオーナー 業務の視点で、ROIからプロダクト バックログの優先順位を管理
• スクラムチーム 開発を行う。スプリントにコミットする。
スクラムマスター
NOTプロジェクト管理者− チームによる自己管理− 内部調整− 他の人や他のチームとの調整
権限無い⇒チームが決める
組織変革の主役
指示型⇒促進型
(ちなみに)従来の管理者 部下の管理と監視が役割
− 指示を出して結果を確認− 部下の選択を承認する権限を維持する− 部下が使えるリソースと情報を制限する
顧客ではなく、作業者の管理によって、作業が決まる。
結果として順応が発想力より優先される
プロダクトオーナー 1
完成図と方向性を把握している
• 機能の詳細などを決め、リリースの内容と日付を決める
• プロダクト収益性(ROI)の責任者• 機能の市場価値をもとに優先順位を決める• スプリントごとに機能と優先順位を変える権限を持つ
プロダクトオーナー 2いままではプロジェクトを技術者に丸投げして完成させる責任は技術者であるという意識。
スクラムではスプリントレビューや検証と調整の責任がプロダクトオーナーと顧客に戻る。
• スプリントごとに収益性と投資収益率の判断をする
• 総責任者
プロダクトバックログ 1
技術、機能、問題点の一覧表
• 問題は後で作業タスクに書き換えられる仮タスク
• 臨時発生、優先順位付け完了、作業期間見積もり完了
• 優先順位の高いものはより詳細に
• 複数チームでも一つの表
• プロダクトオーナーが優先順位の責任者
• だれでも追加でき、貢献できる
• 常時に更新され、目に入るところに提示
• ビジネスプランまたは事業方向性をもとに作られる
プロダクトバックログ 2
管理する項目
・テストについて
・ほかのシステムや製品に連携することや依存すること
・連携機能の納品日
・一番詳しい人
シンプルさを維持すること
プロダクトバックログ 3
プロダクトバックログ 4リリースバーンダウン
スプリントプランニングプロダクト バッロッグ
チームの 作業能力
ビジネス状況
技術の安定
実行可能な
作業量
レビュー
検証
整理
次のスプリント目標
プロダクトバックロッグ
スプリントバックロッグ
スプリントバックログ 1
スプリントバックログ 2•タスクを通じて、プロダクトバックロッグを実装される機能に落と
し込む
• タスクの作業量は時間数で予測、大抵1から16時間
• 16時間以上と予測されたタスクは後で分解する
• タスクを 割り当てるのではなく、チーム員が自分で担当するタスク
を選ぶ。
• 残る作業時間は毎日更新
• チーム全員はタスクを新規作成、編集、作条する権利はある
• スプリントの作業内容が見えてくる
• 作業内容が不明確な場合は大きめに見積もって後で分解
• タスクや作業の進行中に、残りの作業時間数を更新する
スプリントバックログ 3
スプリントバックログ4 スプリントバーンダウン
デイリースクラム(朝会)
毎日の15分だけの状況報告ミーティング
• 毎回、同じ場所、同じ時間
• できれば、会議室。そのばで立ってやってもいい。
• 3つの質問
‒ 前回からなにをしたか
‒ 次回まで何をするか
‒ その作業の障害になること
• 障害、そして、決意
スプリントレビュー 1
スプリントレビュー 2
振り返り(レトロスペクティブ)
• スプリントが終わる度によりよいプロセスへ
• スクラムマスターがファシリテートする
• 良い点と改良できる点を洗い出す
• より複雑な問題の対策はチームが提案する
スプリントレビュー 2
振り返り(レトロスペクティブ)
• スプリントが終わる度によりよいプロセスへ
• スクラムマスターがファシリテートする
• 良い点と改良できる点を洗い出す
• より複雑な問題の対策はチームが提案する
目的
目標
~のために
~までにこの目標を達成する
目的
目標
のために
スプリント終了までにこのストーリーを達成する
スプリントテーマ
ストーリーストーリーストーリーストーリー
目的
目標
のために
このタスクを完了する
ストーリー
タスクタスクタスクタスク
目的
目標 ストーリー
タスク
目的
目標
スプリントテーマ
ストーリーストーリーストーリー
タスクタスクタスク
スプリントテーマスプリントテーマ
•スプリント 一ヶ月のイテレーション 。いつでも 納品。
• デイリースクラム 毎日定時に15分間のミーティング、 朝会
• プロダクトバックログ 業務視点で優先順位付けされたリスト
• スプリントバックログ スプリント(イテレーション)で 実現する作業リスト
• スプリント計画ミーティング スプリントバックログを作成する ミーティング
• スプリントレビュー スプリントの終了時に行う振り返り
スクラムのプロセス
朝会!
セントラルソフト株式会社
林 栄一
2009/04/23
まず!
アジャイルに必要な基本の姿勢?
ファシリテーション
スクラムマスターって?
外部との折衝、チームを雑音から守る
ミーティングをファシリテート
スクラム推進のキーパーソン
組織変革を推進
⇒ファシリテーターの質!
あるスクラムマスターの一日質問をして、改良箇所を探る:
プロダクトオーナーは大丈夫かな? プロダクトバックログの状況はメンテされてるかな? 自分にとってスクラムの利点を把握しているかな?
チームは大丈夫かな? 単独ではなくチームは協力しながら作業しているかな? チーム内で争論はないか? あったらどうやって解決したかな? チーム自身が判断しているかな?
あるスクラムマスターの一日技法はどうかな?
チームは技法を気にかけ、改良しているかな?
自動テストの状況はどうかな?
組織はどうかな?
チーム同士の協力はあるかな?
どんな組織的な妨害があるのかな?
人事関連の妨害はないかな?
ファシリテーション
• 指示とファシリテーションの違いを説明する‒ 指示型:「今これをしてください」‒ 促進型:「この問題を解決するのにどんな支援が必要」
指示型の表現と促進型の表現をそれぞれ3つを考えてみよう。
ファシリテーション
スプリントの半ばでチームは大幅に遅れている。約束した機能を納品するのは無理のようです。
さて、スラムマスターはどういったらいい?
ストーリー
ASAKAI (デイリースクラム)
毎日の15分だけの状況報告ミーティング
• 毎回、同じ場所、同じ時間
• 3つの質問 ‒ 前回からなにをしたか ‒ 次回まで何をするか ‒ その作業の障害になること
ASAKAI (デイリースクラム)
朝会を通してファシリテーションを探求してみよう!
ASAKAI (デイリースクラム)
目的
1. チーム全体が,必要な情報を短い時間で共有すること。
2. 昨日やったことを振り返り,今日やることを各自が 認識しコミットすること。
3. 朝,気持ちよく仕事のスタートを切ること。
ASAKAI (デイリースクラム)
グランドルール
他人を非難しない
悪いニュースは良いニュース
部外者に発言権はない(鶏と豚)
その場で解決しない (その場で解決したほうがいいか判断すること)
ASAKAI (デイリースクラム)
鳥: おい!ブタ!レストランを開こうぜ!
豚: んんん、どうかな。。。なんと言うレストラン?
鳥:ハムとエッグでどうよ?
豚:それはごめんだ!お前は貢献で済むけど、俺は献身だ
ASAKAI (デイリースクラム)
ASAKAI (デイリースクラム)
朝会のポイント
司会者に報告するのではなく、全員に報告する。 ⇒場合司会者はアイコンタクトをはずす。
硬さとやわらかさのバランス。 ⇒適度なアイスブレークを。
ルール違反はその場で軽く指摘。
正直に話せる雰囲気
クリエイティブな仕事したい人?
幼稚園児小学生中・高校生大学生大人
クリエイティビティースコア
95%75%50%25%10%以下
トニーブザン 講演よりこれは「普通」のことだけど、「自然」なことではない
振り返り
このセッションを振り返ってみよう。
振り返り
ペアシェア相手の言っていることをメモグループシェア マインドマップツアー気付きを持ち帰る アクションに
振り返り
おつかれさまでした!
4q!