PBLのためのScrumとチケット駆動開発の融合 ~Scrum+PBL+TiDD~

Cloud Specialist Program Initiative for Reality‐based Advanced Learning

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

○井垣宏*，福安直樹†，佐伯幸郎‡，柗本真佑‡ ，楠本真二*

* 大阪大学大学院情報科学研究科† 和歌山大学システム工学部

‡ 神戸大学大学院システム情報学研究科

PBLのためのScrumとチケット駆動開発の融合～Scrum＋PBL＋TiDD～



enPiT(Education Network for Practical Information Technologies)

2© Cloud Spiral partners 2013



カリキュラムの基本方針

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

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

クラウド基礎PBL(1W)

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

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

分散開発)

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

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

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

クラウド開発演習

3

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

3



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

4

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

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

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

ScrumScrum

Product Owner

2種類のバーンダウンチャート

スプリント計画

振り返り（KPT）

チケット駆動開発

チケットシステム(Trac)

タスクの記録，抽出

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

プレゼンテーション

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

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

MongoDB

テスト技法

単体テスト，カバレッジ

結合テスト

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

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

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

Webアプリケーション開発

チームビルディング

Scrum Master

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

スプリントレビュー

概要設計書(ドメインモデル，クラス図，シーケンス図，ロバスト

ネス図)の書き方，読み方

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

等)

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

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

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

Delivery(納期計画)

© Cloud Spiral partners 2013 4



Project‐based Learning*

5

コンテンツ主体

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

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

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

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

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

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

• 有期性がある

• 価値の創造に繋がる開発体験を伴う

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

© Cloud Spiral partners 2013



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

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

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

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

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


クラウド基礎PBL

6


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

クラウド基礎PBLの風景



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

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

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

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

向いていない点もいくつか有り


Scrum

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

8



以下のフレームワークを8/22~26に実施したPBLに適用した


Scrumフレームワーク

Product Owner

顧客

スプリントレビュー

開発

Scrum Master

開発メンバ

Product Owner

インクリメント

スプリント（1~4W)

9

振り返り(KPT)

スプリント計画

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

Product Owner



スプリントの時間は常に決まっている（タイムボックス）

残業を前提としないため，授業時間が決まっているPBLに向いている

スプリント終了時にデモが実行できることが前提となっている

動作するアプリケーションを教員が確認できるため，最後になって何もできなかったということが無い

自己組織化

全員が何をすべきかを認識し，多能工として開発に貢献することが求められるため，PMや特定の開発者に負荷が集中しにくい


Scrum＋PBLの良いポイント

10



スプリントの時間は常に決まっている（タイムボックス）

残業を前提としないため，時間が足りない

スプリント終了時にデモが実行できることが前提となっている

時間の限られたPBLでは，デモが実行できるところまで到達しないスプリントがありうる

自己組織化

Scrum Masterや各メンバが何をすれば良いかわからない


Scrum＋PBLの難しいポイント

11



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


スプリントの時間配分

スプリント計画(任意)


開発(10:30~17:00)

Scrum Master

開発メンバ


Product Owner

顧客(教員)

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

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

Product Owner

スプリント（1日)

12



プロダクトバックログの粒度をできる限り小さくした

ただしデモができるレベルで

必ずしも毎日デモが実施できなくとも良いものとした

ただしデモ実施は評価対象とした


スプリントレビュー要件の緩和

13



Quality守るべきプロダクト品質の定義スプリントレビューで評価守るべきプロセス品質の定義（後述）タスクごとの完了の定義を明記プロセスの記録を必須とする

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

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


自己組織化のためのプロジェクト目標の策定

14



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

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

特定の開発者に特定のタスクが集中することを避ける

Specialist ではなく Generalist (多能工）を


Assignment

15



必須制約

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



DoD(Definition of Done)を教員が策定し，提示

例：


守るべきプロセスの定義

ルール（一部抜粋）：• PR1. 作成（ソースコード）or バグ修正(ソースコード)‐>レビューの順に連続して実施されたタスクにおいて，

各タスクの担当者は異なっていなければならない• PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，コンパイル可能でかつすべての単体テス

トが正常に通る状態で成果物をリポジトリにコミットすること

サンプルコード

各種仕様書

レビューチェックリスト

レビュー報告書

必要に応じて更新される

Done

バグ修正

レビュー

ソースコード

OK

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

作成(ソースコード)

作成（単体テスト）

単体テストコードwith

単体テスト項目表

コーディング規約

実装計画書

単体テスト計画書

17



チームの目標と守るべきプロセスが明確になることで，Scrum Master等の作業内容が（少し）明らかになった

プロジェクト目標の把握，改善

現状を把握する手段が無い

客観的に確認できる手段がなければ，どうしても適当かつ曖昧になる

教員も評価できない


プロジェクト目標における課題

そこで・・・18


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

チケット駆動開発(TiDD)– タスクの決定，割り当て，実行といった開発の進捗をチケットに対する操作と組み合わせて行う開発手法

• チケット

– 開発者が行ったタスク内容が記録されるもの

受講生A作成

割り当て

着手

チケット

受講生X

終了

成果物：class A種類：実装着手時刻：終了時刻：見積時間：総時間：担当者：マイルストーン：UC01

成果物：class A種類：実装着手時刻：終了時刻：見積時間：総時間：担当者：受講生Xマイルストーン：UC01

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

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

* 小川明彦, 阪井誠, "チケット駆動開発," 翔泳社, 2012.

現状の把握やプロセスの振り返りに非常に有用

19



以下のフレームワークにチケット駆動開発を導入した


Scrum＋PBL＋TiDD




開発(10:30~17:00)

Scrum Master

開発メンバ


Product Owner

顧客(教員)

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


Product Owner

スプリント（1日)

20



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

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


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

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


21


成果物：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]



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

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


開発へのTiDDの導入

開発(10:30~17:00)

Scrum Master

開発メンバ

Product Owner





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


22



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

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


開発へのTiDDの導入

開発(10:30~17:00)

Scrum Master

開発メンバ

Product Owner







23



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

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


振り返りへのTiDDの導入







24

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



0%

20%

40%

60%

80%

100%

A B C D E F G H I


Q: 適正レビューコンポーネント割合※最後のタスクがレビュー・結合テスト

になっているコンポーネント



0%

20%

40%

60%

80%

100%

A B C D E F G H I


A: Assignment制約遵守状況



0

5

10

15

20

25

30

35

40

A B C D E F G H I

preSprintSprint1stSprint2ndSprint3rdSprint4th


D: チケットあたりの見積誤差

preSprintは8/22より前の7/26（合宿期間外）に実施したスプリント



0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

A B C D E F G H I

preSprintSprint1stSprint2ndSprint3rdSprint4th


D: 生産性（チケット数比）

preSprintは8/22より前の7/26（合宿期間外）に実施したスプリント


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

定量的なフィードバック



合宿にAssignment制約があったのが，プログラ

ム未経験者としてはとてもありがたかったです．おかげで，未経験の状態から最後には人に教えられるようになるところまでなりました．

Assignmentのお陰で開発,議論ともに,だんだんと参加できた気になった

Assignmentは救済措置の一つなのかなとおもった


Assignment制約に関する受講生からのコメント



まとめ Scrum＋PBL＋TiDD ScrumをPBLに適用する際の課題を改善できたタイムボックス，スプリントレビュー，自己組織化

PBLにおける下記の既存課題も改善できた作業負荷や得られる経験の偏りプロセス軽視プロジェクトの定量評価

今後の課題チケットの妥当性正確なデータをどこまで入力しているか漏れについては自動チェック可能

受講生の詳細な開発動向とチケットを比較し，ミスを自動検出できるようにしたいある程度は自動化できた（後述）


まとめと今後の課題



0%

20%

40%

60%

80%

100%

A B C D E F G H I


Q: コミット‐チケット対応※コミット時に、開発者が着手中の

チケットが存在しているかどうか