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

3,198 views
3,146 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,198
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
16
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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. ありがとうございました

×