scrum × pbl × チケット駆動開発

Cloud Specialist Program Initiative for Reality‐based Advanced Learning

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

井垣宏大阪大学大学院情報科学研究科

～Scrum × PBL × TiDD～



名前：井垣宏（IGAKI Hiroshi) Twitter: @hirocell

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

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

の開発」プロジェクト

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

© Cloud Spiral partners 2013 2

自己紹介



enPiT(Education Network for Practical Information Technologies)

3© Cloud Spiral partners 2013



カリキュラムの基本方針

クラウド開発基礎(下記演習と合わせて

10日×4コマ@中之島センター)

クラウド基礎PBL(1W)

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

クラウド発展PBL(3回の対面講義と

分散開発)

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

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

前期合宿前半合宿後半後期

クラウド開発演習

4

受講生：修士課程１年，個人で数100行のプログラミング経験

4



クラウド開発基礎及びクラウド基礎PBL(事前知識学習及び合宿前半）

5

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

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

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

Scrum

4つのイベント

3つのプロダクト

プロジェクトの透明化

プロジェクトの適応

チケット駆動開発

チケットシステム(Trac)

タスクの記録，抽出

ファシリテーションスキル

プレゼンテーション

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

Java，JavaScriptによるWebアプリケーション実装

MongoDB

テスト技法

単体テスト，カバレッジ

結合テスト

アプリケーションサーバ(Tomcat)

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

Scrum＋チケット駆動開発クラウド環境を利用した開発手法

Webアプリケーション開発

チームビルディング

3つのロール

会議の進め方，議事録のまとめ方

プロジェクトの検査

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

詳細設計書 (ロバストネス図，クラス図，シーケンス図，javadoc，DB仕様書，

テスト仕様等)の読み方

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

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

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

Delivery(納期計画)

© Cloud Spiral partners 2013

5



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

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

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

プロダクトとプロセス詳細設計書は教員が作成し，与えた

何をどのようなステップで開発するか，プロセスをどうするかは基本的なルール以外は受講生が策定し，実施した


クラウド基礎PBL

6


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

クラウド基礎PBLの風景



Project‐based Learning*

8

コンテンツ主体

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

何を開発するか教員が決め，プロジェクトマネジメントも教員が行う

開発対象は学生が決めるが，プロセスは教員が管理する

何を開発するか教員が決め，プロセスは学生が管理する

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

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

• 有期性がある

• 価値の創造に繋がる開発体験を伴う– 典型的には，チームで実施される

• 教員による統制された支援を伴う




従来の教育手法では育成が難しかった能力の効率的な育成が可能となった

チームによる課題解決

受講生の自律性

実践的なプロダクト/プロセススキルの育成


PBLのメリット



PBLにおける既存課題とその改善

これまで

評価困難既存のPBLでは，成果物

評価やアンケート，教員の主観による評価が多い

‐>プロセス評価が困難

学習機会の不均衡一部のできる学生に開発

負荷が集中し，一部の学生しかプロダクト/プロセススキルを獲得できない

我々の目標

プロダクトとプロセスの定量的な評価

チケット駆動開発にもとづくプロセスの記録・管理

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




受講生の開発行動をチケットとして管理させる

‐>プロジェクトの透明化

‐>チケットログを用いたプロジェクトの検査・適応

課題

チケットに必要な情報

チケットの粒度

‐>PBLの目的にあわせて決定する必要がある


PBL＋チケット駆動開発

コンポーネント：class A種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xマイルストーン：UC01

Scrum教育では？



アジャイルソフトウェア開発フレームワーク

決まっているのは枠だけで方法論ではない

アジャイルソフトウェア開発の多く(66%*)でScrumが利用されている

短期間での実施を前提としたPBLに向いている


Scrum

*Vision One, “State of Agile Development” conducted between July 22nd and November 1st, 2011.

12



3つのロール，4つのイベント，3つの成果物


Scrumフレームワーク

Product Owner

顧客

スプリントレビュー

開発

Scrum Master

開発メンバ

Product Owner

インクリメント

スプリント（1~4W)

13

振り返り(KPT)

スプリント計画

プロダクトバックログスプリントバックログ

各種仕様書



Scrumフレームワークの理解各イベントにおけるプロセスと成果物各ロールの振る舞いプロセスの透明化（記録），検査，適応

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

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

ション


我々のPBLで教えたいこと(教授目標)



開発時間は固定し，計画・振り返りに余裕をもたせた


スプリントの時間配分(タイムボックス)

スプリント計画(任意時間)


開発(10:30~17:00)

Scrum Master

開発メンバ

インクリメントProduct Owner

顧客(教員)

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

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

Product Owner

スプリント（1日)

15

各種仕様書



Quality仕様書に則したプロダクト（ソフトウェアコンポーネ

ント群）が開発できているかスプリントレビューで評価プロセスルールを遵守できているか（後述）プロセスが適切に記録されているか

AssignmentAssignment制約を守れているか（後述）

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


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

16



プロダクトの種類ごとのDoD(Definition of Done)を策定

例(*.java)：


遵守すべきプロセスルールの例

ルール（一部抜粋）：

• SR2.実施したタスクがすべて正しくTicketシステムに記録されていること• 障害の記録や割り当て状況，タスク実施時間，見積時間が記録されていることが重要

• PR1. 作成（ソースコード）or バグ修正(ソースコード)‐>レビューの順に連続して実施されたタスクにおいて，各タスクの担当者は異なっていなければならない

サンプルコード

各種仕様書

レビューチェックリスト

レビュー報告書

必要に応じて更新される

Done

バグ修正

レビュー

ソースコード

OK

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

作成(ソースコード)

作成（単体テスト）

単体テストコードwith

単体テスト項目表

コーディング規約

実装計画書

単体テスト計画書

17



タスクが適切に分担されているかを示す指標

各自が分担するタスクの量や種類がメンバー間で均等であること

特定の受講生に特定のタスクが集中することを避ける

受講生に習得して欲しいプロダクト/プロセススキルにあわせてタスク分担の基準を決定する


Assignment

18



必須制約

作成（ソース）：全開発期間終了時，各メンバのタスク担当数がチームの平均値*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つ以上を対

象とした作成(単体テスト)を実施すること


Assignment制約の例



スプリントバックログ＝チケット群

スプリント計画時にチケット作成


スプリント計画へのTiDD導入

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

20

コンポーネント：class A種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

コンポーネント：class B種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

コンポーネント：class C種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

コンポーネント：class D種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

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

スプリント計画(任意時間)


各種仕様書


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

チケット入力項目

タスク分類作成（ソース）作成（単体テスト）レビュー作成（結合テスト）バグ修正（ソース）バグ修正（単体テスト）バグ修正（結合テスト）結合テスト

最終プロダクト名一覧Account.javaEventModel.javaindex.htmldwr.xml:

日時入力補助プラグイン

スプリント名Sprint1stSprint2ndSprint3rdSprint4th



生チケットを何枚か掲載


チケット例



開発と連動してチケットを操作する

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


開発へのTiDDの導入

開発(10:30~17:00)

Scrum Master

開発メンバ

Product Owner





コンポーネント：class E種類：単体テスト着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]


23



開発と連動してチケットを操作する

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


開発へのTiDDの導入

開発(10:30~17:00)

Scrum Master

開発メンバ

Product Owner







24



CI: Continuous Integration(継続的インテグレーション）とは

テストも含めて「全てが自動化された」「再現可能な」ビルドを「日に何度も」行うこと† インテグレーションに関わるバグを少しでも早く検知するため

25

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

コミット

開発者

編集

ワークコピー

開発者

編集

ワークコピー

コミット

バグバグ

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

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

コミット

開発者

編集

ワークコピー

開発者

編集

ワークコピー

コミット

自動ビルド自動テスト

バグ

ビルド

テスト



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

• PR4. 作成（単体テスト) or バグ修正(単体テスト)完了時には，コンパイル可能な状態で成果物をリポジトリにコミットすること

• 必ずしも単体テストが正常に通る状態である必要はない


開発へのCI(Continuous Integration)の導入

CIに関するルールをどの程度遵

守できているかを定量的に把握できるようになった



振り返りのための判断基準の多くをチケットから取得できる

Assignment，プロセスルール

客観的なデータに基づいて振り返りが可能となった


振り返りへのTiDDの導入

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






27

教員によるプロジェクト評価にも活用できるようになった



分析対象

チケット群

CI記録

svnコミットログ


評価基準（QAD）の定量評価



0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

preSprint Sprint1st Sprint2nd Sprint3rd Sprint4th

B1

B2

B3

B4

B5

B6

B7

B8

B9

PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，

コンパイル可能でかつすべての単体テストが正常に通る状態で成果物をリポジトリにコミットすること

CIのビルド成功率

全コミットのうちPR

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



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

レビュー済コンポーネント数

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1


GB1

GB2

GB3

GB4

GB5

GB6

GB7

GB8

GB9

全コンポーネントのうちSR

3を満たすものの割合




作成(ソース)のAssignment制約

0

10

20

30

40

50

60

70

80

90

100

preSprint2 Sprint1st Sprint2nd Sprint3rd Sprint4th

系列1

系列2

系列3

系列4

系列5

系列6

系列7

系列8

系列9

各チームにおいて，各Sprint

終了時点で

Assignment

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



0%

20%

40%

60%

80%

100%

120%

140%

160%

180%

200%



作成(ソース)のAssignment制約:悪かったチーム(GB9)

GB

9内の各メンバ(

5名)

が担当した作成（ソース）

タスク数を平均担当タスク数と比較した割合



0%

20%

40%

60%

80%

100%

120%

140%

160%

180%

200%

220%

240%



作成(ソース)のAssignment制約:良かったチーム(GB1)

GB


6名)

が担当した作成（ソース）

タスク数を平均担当タスク数と比較した割合



最終スプリント開始時の開発予定US数と実際に開発できたUS数及びその割合

実装US(User Stories)&達成率

チーム開発US数

実績/開発予定US数

GB6 ○ ○ ○ ○ ○ ○ ○ 7 100.0%

GB7 ○ ○ ○ ○ ○ × 5 83.3%

GB1 ○ ○ ○ ○ ○ × × × × 5 55.6%

GB5 ○ ○ ○ × ○ 4 80.0%

GB8 ○ ○ × ○ ○ 4 80.0%

GB3 ○ ○ ○ ○ × × × 4 57.1%

GB9 ○ ○ ○ × × 3 60.0%

GB2 ○ ○ ○ × × 3 60.0%

GB4 ○ ○ ○ × × × 3 50.0%



受講生のコミットと登録されたチケットの対応がどの程度とれているか

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

コミット‐チケット対応(評価対象外)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%


GB1

GB2

GB3

GB4

GB5

GB6

GB7

GB8

GB9

全コミットのうち関連する

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



コミットとチケットの対応が取れていない受講生が何名か存在する

コミット‐チケット対応(評価対象外)：悪かった例（GB1）

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%


GB


6名)

それぞれの

コミット群について関連するチケットが

存在するものの割合



すべての開発者がコミット前後でのチケット登録を意識していた

コミット‐チケット対応(評価対象外)：良かった例（GB9）

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%


GB


5名)

それぞれの

コミット群について関連するチケットが

存在するものの割合



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


定量的なフィードバック



導入・設定のためのCUI 50名9チームの全サーバの初期設定，設定変更（コンポーネント登録等）をGUIでやっ

てられない

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

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

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

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

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

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


チケットシステムに求めるもの（あるいはなぜ私が4年前にTracを選んだか）



Scrumの初期教育にチケット駆動開発を導入してみた

プロジェクトの透明化，検査，適応，評価において非常に有用であることがわかった


まとめ



チームだけでなく，個人レベルでのフィードバックも

開発生産性，バグ混入率等

評価の対象とはしない

チケットの正確さを評価する仕組みの導入

入力漏れの自動チェック

開発状況との比較による誤り検出

定量評価の自動化

今は毎日教員が手作業で頑張ってます＞＜


今後の課題