• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hello Scrum-はじめてのスクラム導入記
 

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

on

  • 3,754 views

 

Statistics

Views

Total Views
3,754
Views on SlideShare
3,742
Embed Views
12

Actions

Likes
3
Downloads
13
Comments
0

1 Embed 12

http://www.slideshare.net 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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