Scrum × PBL × チケット駆動開発

分野・地域を越えた実践的情報教育協働ネットワーク

～Scrum × PBL × TiDD～
井垣宏
大阪大学大学院情報科学研究科

Cloud Specialist Program Initiative for Reality‐based Advanced Learning


自己紹介
名前：井垣宏（IGAKI Hiroshi)
 Twitter: @hirocell

博士（工学）
 奈良先端科学技術大学院大学で取得

現所属：大阪大学大学院情報科学研究科
役職：特任准教授
 「ソフトウェアイノベーション先導のための研究教育プログラム
の開発」プロジェクト

専門分野
 クラウド環境を用いたソフトウェア工学教育
 ユーザインタフェース
 クラウドコンピューティング，SOA
© Cloud Spiral partners 2013

2


enPiT(Education Network for Practical
Information Technologies)



3


カリキュラムの基本方針
受講生：修士課程１年，個人で数100行のプログラミング経験
前期

合宿前半

クラウド開発基礎
(下記演習と合わせて
10日×4コマ
@中之島センター)

クラウド基礎
PBL(1W)

合宿後半

クラウド開発
応用(1W)

後期
クラウド発展PBL
(3回の対面講義と
分散開発)

クラウド開発演習
クラウドを利用したアジャイル開発(Scrum)の学習
－チームでどのように作るか（チームビルディング）
－プロセス・プロダクト品質を意識したScrum開発
－継続的インテグレーション


クラウドを利用したプロダクトの学習
－クラウドを使って何ができるか
－チームでクラウドを使った問題解決をする

4
4


クラウド開発基礎及びクラウド基礎PBL(事前知識学習及び合宿前半）
Scrum＋チケット駆動開発
Scrum
3つのロール
4つのイベント
3つのプロダクト
プロジェクトの透明化

クラウド環境を利用した
開発手法

QADにもとづく
プロジェクト管理

DaaS(Desk top as a Service)を利
用した開発

Quality(プロダクト・プロセス品質)

チケットシステムと版管理システム
(svn)を利用したタスク管理

Assignment(タスク割り当て，
知識伝達)

CIツール(jenkins)を利用した
継続的統合とテスト可視化

Delivery(納期計画)

プロジェクトの検査

プロジェクトの適応

MVCモデルの理解と各層
の実装

チケット駆動開発
チケットシステム
(Trac)
タスクの記録，抽出

ファシリテーションスキル
プレゼンテーション

MongoDB
Java，JavaScriptによる
Webアプリケーション実装
アプリケーションサーバ
(Tomcat)

Webアプリケーションフレームワーク(DWR)の利用

概要設計書(ドメインモデル，クラス図，シーケン
ス図，ロバストネス図)の書き方，読み方

詳細設計書 (ロバストネス図，クラス図，シーケ
ンス図，javadoc，DB仕様書，
テスト仕様等)の読み方

テスト技法

チームビルディング
会議の進め方，議
事録のまとめ方

単体テスト，カバレッジ
結合テスト


Webアプリケーション開発

5 5



クラウド基礎PBL
期間：8/22~26
 ただし，開発期間は22~25の4日間
 受講生は最寄りのビジネスホテルに期間中泊まり込み

場所：大阪大学中之島センター
 会場は9:00~21:00まで利用可能

受講生：49名
 西日本9大学の受講生が参加
 スキル等にバラつきあり
 ただし，全員が事前知識講義受講済み

プロダクトとプロセス
 詳細設計書は教員が作成し，与えた
 何をどのようなステップで開発するか，プロセスをどうするか
は基本的なルール以外は受講生が策定し，実施した


6


クラウド基礎PBLの風景



7


Project‐based Learning*
• 有期性がある
• 価値の創造に繋がる開発体験を伴う
– 典型的には，チームで実施される

• 教員による統制された支援を伴う
コンテンツ主体

プロセス(プロジェク
トマネジメント）主体

開発対象は学生が
何を開発するか教
員が決め，プロジェ決めるが，プロセス
クトマネジメントも教は教員が管理する
員が行う
何を開発するか教
員が決め，プロセス
は学生が管理する

開発対象もプロセス
も学生が管理する

Hadj Batita, “A model for an innovative project‐based learning management system for engineering education,”
CALIE'2001 ‐ Computer Aided Learning in Engineering Education, 2001


8


PBLのメリット
従来の教育手法では育成が難しかった能
力の効率的な育成が可能となった
チームによる課題解決
受講生の自律性
実践的なプロダクト/プロセススキルの育成



9


PBLにおける既存課題とその改善
これまで

評価困難
 既存のPBLでは，成果物
評価やアンケート，教員
の主観による評価が多い
 ‐>プロセス評価が困難

学習機会の不均衡
 一部のできる学生に開発
負荷が集中し，一部の学
生しかプロダクト/プロセス
スキルを獲得できない

我々の目標
プロダクトとプロセスの定量
的な評価
 チケット駆動開発にもとづく
プロセスの記録・管理

受講生ごとの開発記録に
もとづく学習機会の均一化


10


PBL＋チケット駆動開発
受講生の開発行動をチケットとして管理させる
 ‐>プロジェクトの透明化
 ‐>チケットログを用いたプロジェクトの検査・適応
コンポーネント：class A
種類：実装
着手時刻：13:00
終了時刻：14:00
見積時間：0.5H
総時間：1.0H
担当者：受講生X
マイルストーン：UC01

課題

 チケットに必要な情報
 チケットの粒度
‐>PBLの目的にあわせて決定する必要がある
Scrum教育では？


11


Scrum
アジャイルソフトウェア開発フレームワーク
決まっているのは枠だけで方法論ではない

アジャイルソフトウェア開発の多く(66%*)で
Scrumが利用されている
短期間での実施を前提としたPBLに向いて
いる
*Vision One, “State of Agile Development” conducted between July 22nd and
November 1st, 2011.


12


Scrumフレームワーク
3つのロール，4つのイベント，3つの成果物
スプリント計画
各種仕様書

振り返り(KPT)

プロダクトバックログ

スプリントバックログ

スプリント（1~4W)
顧客

スプリント
レビュー

開発

開発メンバ

Product Owner
Product Owner

インクリメント


Scrum Master

13


我々のPBLで教えたいこと(教授目標)
Scrumフレームワークの理解
各イベントにおけるプロセスと成果物
各ロールの振る舞い
プロセスの透明化（記録），検査，適応

チームソフトウェア開発プロセス
構成管理, CI(Continuous Integration)等
実装，レビュー，テスト

プロダクトスキル
MongoDB, JavaScript, JavaによるWebアプリケー
ション


14


スプリントの時間配分(タイムボックス)
開発時間は固定し，計画・振り返りに余裕をもたせた
スプリント計画(任意時間)

振り返り(KPT)
（19時まで)

各種仕様書



スプリント（1日)
顧客
(教員)

スプリント
レビュー（15分）

開発
開発メンバ
(10:30~17:00)
Product Owner

Product Owner



Scrum Master

15


教授目標に合わせたプロジェクト評価基準の策定

Quality
仕様書に則したプロダクト（ソフトウェアコンポーネ
ント群）が開発できているか
 スプリントレビューで評価
プロセスルールを遵守できているか（後述）
プロセスが適切に記録されているか

Assignment
Assignment制約を守れているか（後述）

Delivery
計画通りに開発が進められているか


16


遵守すべきプロセスルールの例
プロダクトの種類ごとのDoD(Definition of Done)
を策定
例(*.java)：
必要に応じて
更新される
コーディング規約
実装計画書

レビュー
チェックリスト

サンプルコード

単体テストコード
with
単体テスト項目表

バグ修正

ソースコード

作成
（単体テスト）

単体テスト計画書

作成
(ソースコード)

NG
レビュー

レビュー
報告書

任意の状態から発
生する可能性あり

OK

Done

各種仕様書

ルール（一部抜粋）：

• SR2.実施したタスクがすべて正しくTicketシステムに記録されていること
• 障害の記録や割り当て状況，タスク実施時間，見積時間が記録されていることが重要
• PR1. 作成（ソースコード）or バグ修正(ソースコード)‐>レビューの順に連続して実施されたタスク
17
において，各タスクの担当者は異なっていなければならない


Assignment
タスクが適切に分担されているかを示す指標
各自が分担するタスクの量や種類がメンバー間で
均等であること

特定の受講生に特定のタスクが集中すること
を避ける
受講生に習得して欲しいプロダクト/プロセススキ
ルにあわせてタスク分担の基準を決定する



18


Assignment制約の例
必須制約
作成（ソース）：全開発期間終了時，各メンバのタスク担
当数がチームの平均値*1.2～0.8以内に収まること
作成（単体テスト）：全開発期間終了時，各メンバのタス
ク担当数がチームの平均値*1.2～0.8以内に収まること
レビュー：全開発期間終了時，各メンバのタスク担当数
がチームの平均値*1.2～0.8以内に収まること
Optional制約
 作成（結合テスト）を各開発者がそれぞれ1回以上実施
 結合テストを各開発者がそれぞれ1回以上実施
 全開発者が全種類のファイル(*.java, *.html, *.xml)を1回以上作成・編集すること
 各開発者がcontroller, model, viewの各パッケージに含まれるコンポーネントそれぞれ1つ以上を対
象とした作成(ソース)を実施すること
 各開発者がcontroller, model, viewの各パッケージに含まれるコンポーネントそれぞれ1つ以上を対
象とした作成(単体テスト)を実施すること


19


スプリント計画へのTiDD導入
スプリントバックログ＝チケット群
スプリント計画時にチケット作成
スプリント計画(任意時間)
各種仕様書



コンポーネント：class B
種類：実装：class C
コンポーネント
種類：実装：class D

種類：実装：class E
種類：実装
種類：単体テスト
見積時間：0.5H
着手時刻：
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
終了時刻：
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
スプリント：UC[Login]
総時間：
担当者：

チケットにより，スプリントバーンダウンチャートの
自動生成が可能


20


チケット入力項目
タスク分類
作成（ソース）
作成（単体テスト）
レビュー
作成（結合テスト）
バグ修正（ソース）
バグ修正（単体テスト）
バグ修正（結合テスト）
結合テスト

最終プロダクト名一覧
Account.java
EventModel.java
index.html
dwr.xml
:

スプリント名
Sprint1st
Sprint2nd
Sprint3rd
Sprint4th

日時入力補助プラグイン


21


チケット例
生チケットを何枚か掲載



22


開発へのTiDDの導入
開発と連動してチケットを操作する

開発
開発メンバ
(10:30~17:00)
Product Owner

Scrum Master

種類：実装
見積時間：0.5H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
総時間：1.0H

現状把握が可能となる
 スプリントバーンダウンチャートの自動更新
 Assignment状況の把握
 残タスクの可視化


23


開発へのTiDDの導入
開発と連動してチケットを操作する

開発
開発メンバ
(10:30~17:00)
Product Owner

Scrum Master

種類：実装
見積時間：0.5H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
総時間：1.0H

現状把握が可能となる
 スプリントバーンダウンチャートの自動更新
 Assignment状況の把握
 残タスクの可視化


24


CI: Continuous Integration(継続的インテグレーション）とは
テストも含めて「全てが自動化された」「再現可能な」ビル
ドを「日に何度も」行うこと†
 インテグレーションに関わるバグを少しでも早く検知するため
ビルド
版管理システムテスト

自動ビルド

版管理システム
(Subversion)リポジトリ

(Subversion)リポジトリ

コミット
ワークコピー

バグ

コミット
ワークコピー

バグ

コミット

自動テスト

コミット

ワークコピー

ワークコピー

バグ

編集

編集

編集

編集

開発者

開発者

開発者

開発者
25

†Martin Fowler, “Continuous Integration,” http://www.martinfowler.com/articles/originalContinuousIntegration.html ,Sep. 2000.


開発へのCI(Continuous Integration)の導入
• PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，コンパイル可能でかつ
すべての単体テストが正常に通る状態で成果物をリポジトリにコミットすること
• PR4. 作成（単体テスト) or バグ修正(単体テスト)完了時には，コンパイル可能な状態で
成果物をリポジトリにコミットすること
• 必ずしも単体テストが正常に通る状態である必要はない

CIに関するルールをどの程度遵
守できているかを定量的に把
握できるようになった



26


振り返りへのTiDDの導入
振り返りのための判断基準の多くをチケット
から取得できる
Assignment，プロセスルール
客観的なデータに基づいて
振り返りが可能となった
振り返り(KPT)
（19時まで)
教員によるプロジェクト評価にも
活用できるようになった


種類：実装
見積時間：0.5H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
見積時間：0.5H
総時間：1.0H
総時間：1.0H


27


評価基準（QAD）の定量評価
分析対象
チケット群
CI記録
svnコミットログ



28


CIのビルド成功率
 PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，
コンパイル可能でかつすべての単体テストが正常に通る状態で成
果物をリポジトリにコミットすること
全

100%

コ
ミ

90%

ッ
の

80%

ち

70%

PR

ト

60%

う

3
を
満
た
す
コ
ミ
ッ
ト
の
割
合

B1
B2
B3
B4
50%

B5
B6

40%

B7
30%

B8
B9

20%
10%
0%
preSprint

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


レビュー済コンポーネント数
SR3.結合テスト対象のストーリーの全成果物はレビューま
ですべて完了していなければならない
全

1

コ
ン
ポ

0.9

ネ

0.8

ト

0.7

ー
ン
の

GB1
GB2

ち

0.6

SR

う

0.5

3
を
満
た
す
も
の
の
割
合

GB3
GB4
GB5
GB6

0.4

GB7
0.3

GB8
GB9

0.2
0.1
0
preSprint

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


作成(ソース)のAssignment制約
100

Sprint

Assignment
制
約
を
遵
守
で
き
て
い
る
人
数
の
割
合

各
チ
ー
ム
に
お
い
て
，
各

50

90
80
系列1

70

系列2
系列3

60

終
了
時
点
で

系列4
系列5
系列6

40

系列7
30

系列8
系列9

20
10
0
preSprint2

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


:悪かったチーム(GB9)
GB

200%
180%
160%
140%

(

タ
ス 9
ク
数内
をの各
平
均メン
担バ
当 5
タ名
ス
クが
数担
と当
比し
較た
し作
た成
割（
合ソ
ー
ス
）

120%

)

100%
80%
60%
40%
20%
0%
preSprint2

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


:良かったチーム(GB1)

GB
240%
220%
200%
180%
160%

(

タ
ス 1
ク
数内
をの各
平
均メン
担バ
当 6
タ名
ス
クが
数担
と当
比し
較た
し作
た成
割（
合ソ
ー
ス
）

140%

)

120%
100%
80%
60%
40%
20%
0%
preSprint2

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


実装US(User Stories)&達成率
最終スプリント開始時の開発予定US数と実際に
開発できたUS数及びその割合
チーム
GB6
GB7
GB1
GB5
GB8
GB3
GB9
GB2
GB4

開発US
数
○
○
○
○
○
○
○
○
○

○
○
○
○
○
○
○
○

○
○
○
○
×
○
○
○
○

○
○
×
○
○
○
×


○ ○ ○
○ ×
○ × × ×
○
○
× ×
×
×
×
×
×

○
×

×
×

実績/開発
予定US数

7
5
5
4
4
4
3
3
3

100.0%
83.3%
55.6%
80.0%
80.0%
57.1%
60.0%
60.0%
50.0%


コミット‐チケット対応(評価対象外)
受講生のコミットと登録されたチケットの対応がど
の程度とれているか

チ
ケ
ッ
ト
が
存
在
す
る
コ
ミ
ッ
ト
の
割
合

 コミットごとに，コミッター，コミットに含まれるコンポー
ネント，コミット日時を取得し，該当するチケットが存在
するか検証
全
コ
ミ
ッ
ト
の
う
ち
関
連
す
る

100%
90%
80%

GB1

70%

GB2
GB3

60%

GB4
50%

GB5

40%

GB6

30%

GB7

20%

GB8
GB9

10%
0%

preSprint
Sprint1st

Sprint2nd

Sprint3rd

Sprint4th


：悪かった例（GB1）
コミットとチケットの対応が取れていない受
講生が何名か存在する
存

100%

GB

在コ
ミ
すッ 1
るト内
も群の
のに各
のつ
割いメ
合てンバ
関
名
連 6
す
るそ
チれ
ケぞ
ッれ
トの
が

90%
80%
70%
60%
50%

(
40%

)

30%
20%
10%
0%
preSprint

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


：良かった例（GB9）
すべての開発者がコミット前後でのチケット登録
を意識していた
存

100%

GB

在コ
ミ
すッ 9
るト内
も群の
のに各
のつ
割いメ
合てンバ
関
名
連 5
す
るそ
チれ
ケぞ
ッれ
トの
が

90%
80%
70%
60%
50%

(
40%

)

30%
20%
10%
0%
preSprint

Sprint1st


Sprint2nd

Sprint3rd

Sprint4th


定量的なフィードバック
項目ごとに数値
化し，チームに
フィードバックを
行った



38


チケットシステムに求めるもの
（あるいはなぜ私が4年前にTracを選んだか）
 導入・設定のためのCUI
 50名9チームの全サーバの初期設定，設定変更（コンポーネント登録等）をGUIでやっ
てられない

 カスタムフィールド
 不要フィールドの削除，必要フィールドの追加
 入力項目毎に必須等の入力制約がほしい
 デフォルト値のままだとエラーになる等

 ワークフローコントロール
 チケット遷移は制御できて欲しい（チケットの手戻りは認めない等）

 全チケットデータへの外部からのアクセス手段
 WriteはAPIで，ReadはDBを直接触れるのがパフォーマンス的に一番良い

 日時情報の入力支援機能
 手作業で日時フォーマットを正しく入力することは不可能に近い

 記録されたチケットのマイニング手段
 学習コストが低いマイニング手法が望ましい

 チケット間の親子関係
 プロダクトバックログ項目とチケットの関係を表現したい


39


まとめ
Scrumの初期教育にチケット駆動開発を導
入してみた
プロジェクトの透明化，検査，適応，評価におい
て非常に有用であることがわかった



40


今後の課題
チームだけでなく，個人レベルでのフィードバックも
 開発生産性，バグ混入率等
 評価の対象とはしない

チケットの正確さを評価する仕組みの導入
 入力漏れの自動チェック
 開発状況との比較による誤り検出

定量評価の自動化
 今は毎日教員が手作業で頑張ってます＞＜


41

Scrum × PBL × チケット駆動開発

More Related Content

Scrum × PBL × チケット駆動開発