Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
はじめてのスクラム導入記

HELLO, SCRUM
自己紹介

 今村哲也
 独立系SIerの子会社 ⇒ 独立
 ビジネス情報系のシステム開発
  官公庁
  原子力発電所
  空港
 チームリーダー
要約

 チームにスクラムを導入した2年4ヶ月
  を、5分でお話します。
 便宜上、チームを3つの時期に区別して
  います。
 最後に、経験から学んだ大切なことを2
  つ、お話します。
プロジェクトの紹介

 基幹系システムのリプレイス案件
 アジャイル開発プロセスの経験者なし
 在籍期間 2年4ヶ月
 私たちのチーム
  2名~7名
  パートナー社員主体   ⇒   メンバーが流動的
3つの時期
                 2008/7         2008/11
 2007/7          •XP経験者         •チームメンバー          2009/10
 •参画              ...
スクラムごっこ(約1年)


  2007/7
  • 参画




           2008/7
           • XP経験者の加入
スクラムのロールとイベント
   スクラムマスター
       優しい独裁者
       メンバーの意志を尊重するが、チームの方針や仕事の割り振りはリーダーが決める。
   プロダクトオーナー
       暗黙的
   プロダ...
ごっこからの卒業(約半年)


2008/7
• XP経験者の加入




             2008/11
             • チームメンバーの
               総入れ替え
スクラムマスター

問題
 リーダーが決定することは、チームとして決
  定する機会を奪い、チームが自己組織化する
  機会を奪う。

改善
 チームの運営モデル
  優しい独裁者モデル   ⇒ 民主主義モデル
 チームの方針や仕事の割...
プロダクトバックログ
問題
 リスケジューリングするにあたって、過去の見積もり
  方法では誤差が大きい。

改善
 チームとプロダクトオーナーが協力して、
 半日~2日以内に終わる作業の一覧として作成する。

背景
 機能モジュールに...
プラクティス

 ペアプログラミング
 ランチタイム・コードレビュー
 継続的結合環境
 テスト駆動開発
 リファクタリング
 アジャイルソフトウェア開発宣言の唱和
 クレドの時間
ツールの紹介

 タスクカンバン
私たちのスクラム(約1年)

2008/11
• チームメ
  ンバーの
                    2009/2
  総入れ替              • オブラブ
                               ...
プロダクトバックログ

問題
 お客様が求めている価値よりも、それをもた
 らす製品そのものに意識が向いている。

改善
 チームとプロダクトオーナーとユーザー
  が協力して、
 ユーザーストーリーの一覧として作成す
  る。
プロダクトバックログ
問題
 相対見積もりの方が、早く正確に見積もれる。
 理想人日で見積もると、その人日でコミットメントしたと
  捉えられてしまう。

改善
 ストーリーポイントによる相対見積もりを導入する。

悩み
 チームにスト...
日次スクラムミーティング

問題
 朝が早いメンバーは、朝会で昨日の作業が共有
  される前に今日の作業に着手する。朝会で共有
  された内容によっては、実施した作業が無駄に
  なる。

改善
 朝会(10:00~)+夕会(16:00~)...
プラクティス

 明確に定義されたプロダクトオーナー
 ユーザーストーリー
 ストーリーポイントによる相対見積もり
 プランニングポーカー
 リリース基準
 受入テスト
 20%ルール
 ブラウンバッグミーティング
ツールの紹介
 タスクカンバン




 プランニングポーカー
ツールの紹介
 コミットベル




 クッシュボール
2つの大切なこと

 目の前のチームに目を向ける
  経験を積んだり、メンバーが入れ替わったりすること
  で、チームに適したやり方も変わっていきます。
    メンバーが入れ替わったときは、
       やり方を見直すとき!

 アジャ...
すくすくスクラム

「1人1人が、リーダーだ!」
 ~状況依存型リーダーシップモデル~

  1月25日(月) 19時~21時
  日本橋三井タワー 14階
  株式会社QUICK プレゼンルーム
ありがとうございました
Upcoming SlideShare
Loading in …5
×

Hello Scrum-はじめてのスクラム導入記

3,301 views

Published on

Published in: Technology
  • Be the first to comment

Hello Scrum-はじめてのスクラム導入記

  1. 1. はじめてのスクラム導入記 HELLO, SCRUM
  2. 2. 自己紹介  今村哲也  独立系SIerの子会社 ⇒ 独立  ビジネス情報系のシステム開発  官公庁  原子力発電所  空港  チームリーダー
  3. 3. 要約  チームにスクラムを導入した2年4ヶ月 を、5分でお話します。  便宜上、チームを3つの時期に区別して います。  最後に、経験から学んだ大切なことを2 つ、お話します。
  4. 4. プロジェクトの紹介  基幹系システムのリプレイス案件  アジャイル開発プロセスの経験者なし  在籍期間 2年4ヶ月  私たちのチーム  2名~7名  パートナー社員主体 ⇒ メンバーが流動的
  5. 5. 3つの時期 2008/7 2008/11 2007/7 •XP経験者 •チームメンバー 2009/10 •参画 の加入 の総入れ替え •離任 スクラム ごっこ 私たちの ごっこ からの スクラム 卒業 最初にスクラムごっこ  「スクラムでやります!」と宣言して、  試行錯誤しながらプラクティスを実践していた時期 そしてごっこからの卒業  XP経験者が加入して、  プラクティスの背景にある考え方を学ぶことで、“アジャイルさ”というもの を理解していった時期 最後に私たちのスクラム  チームメンバーが総入れ替えになって、  新しいチームにとってのアジャイルさを話し合うところから、私たちのやり方 を模索していった時期
  6. 6. スクラムごっこ(約1年) 2007/7 • 参画 2008/7 • XP経験者の加入
  7. 7. スクラムのロールとイベント  スクラムマスター  優しい独裁者  メンバーの意志を尊重するが、チームの方針や仕事の割り振りはリーダーが決める。  プロダクトオーナー  暗黙的  プロダクトバックログ  機能モジュールや共通コンポーネントの一覧として、WBSからリーダーが作成した。  理想人日  スプリント  二週間  スプリント計画  スプリントレビュー  振り返りミーティング  日次スクラムミーティング  夕会(17:00~)
  8. 8. ごっこからの卒業(約半年) 2008/7 • XP経験者の加入 2008/11 • チームメンバーの 総入れ替え
  9. 9. スクラムマスター 問題  リーダーが決定することは、チームとして決 定する機会を奪い、チームが自己組織化する 機会を奪う。 改善  チームの運営モデル  優しい独裁者モデル ⇒ 民主主義モデル  チームの方針や仕事の割り振りは、チームで 話し合って決める。
  10. 10. プロダクトバックログ 問題  リスケジューリングするにあたって、過去の見積もり 方法では誤差が大きい。 改善  チームとプロダクトオーナーが協力して、  半日~2日以内に終わる作業の一覧として作成する。 背景  機能モジュールには共通するパターンがあり、作業内 容を正確に予見できた。  1年弱の経験から、製品の仕様と作業内容を正確に理 解していた。
  11. 11. プラクティス  ペアプログラミング  ランチタイム・コードレビュー  継続的結合環境  テスト駆動開発  リファクタリング  アジャイルソフトウェア開発宣言の唱和  クレドの時間
  12. 12. ツールの紹介  タスクカンバン
  13. 13. 私たちのスクラム(約1年) 2008/11 • チームメ ンバーの 2009/2 総入れ替 • オブラブ 2009/10 え 冬合宿 • 解散 2008/12 2009/6 • 『アジャ • 認定スク イルの衰 ラムマス 退と凋 ター研修 落』
  14. 14. プロダクトバックログ 問題  お客様が求めている価値よりも、それをもた らす製品そのものに意識が向いている。 改善  チームとプロダクトオーナーとユーザー が協力して、  ユーザーストーリーの一覧として作成す る。
  15. 15. プロダクトバックログ 問題  相対見積もりの方が、早く正確に見積もれる。  理想人日で見積もると、その人日でコミットメントしたと 捉えられてしまう。 改善  ストーリーポイントによる相対見積もりを導入する。 悩み  チームにストーリーポイントを理解してもらうことが難し かった。  理想人日は十分に機能していたので、理想人日による相対 見積もりに留めた方がチームにフィットしたかもしれない。
  16. 16. 日次スクラムミーティング 問題  朝が早いメンバーは、朝会で昨日の作業が共有 される前に今日の作業に着手する。朝会で共有 された内容によっては、実施した作業が無駄に なる。 改善  朝会(10:00~)+夕会(16:00~) 補足  夕会を開催することで、その日の作業はその日 のうちに共有した。
  17. 17. プラクティス  明確に定義されたプロダクトオーナー  ユーザーストーリー  ストーリーポイントによる相対見積もり  プランニングポーカー  リリース基準  受入テスト  20%ルール  ブラウンバッグミーティング
  18. 18. ツールの紹介  タスクカンバン  プランニングポーカー
  19. 19. ツールの紹介  コミットベル  クッシュボール
  20. 20. 2つの大切なこと  目の前のチームに目を向ける 経験を積んだり、メンバーが入れ替わったりすること で、チームに適したやり方も変わっていきます。 メンバーが入れ替わったときは、 やり方を見直すとき!  アジャイルであることに囚われない アジャイルでないものが機能しない訳ではなく、ア ジャイルなものが機能する訳でもない。 アジャイルであるかどうかよりも、 それが機能しているかどうかに目を向ける!
  21. 21. すくすくスクラム 「1人1人が、リーダーだ!」 ~状況依存型リーダーシップモデル~ 1月25日(月) 19時~21時 日本橋三井タワー 14階 株式会社QUICK プレゼンルーム
  22. 22. ありがとうございました

×