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

クラウド基礎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

チケット駆動開発(TiDD)
– タスクの決定，割り当て，実行といった開発の進捗をチケットに
対する操作と組み合わせて行う開発手法
• チケット
– 開発者が行ったタスク内容が記録されるもの
受講生A
作成
割り当て
着手
チケット
受講生X
終了
成果物：class A
種類：実装
着手時刻：
終了時刻：
見積時間：
総時間：
担当者：
マイルストーン：UC01
成果物：class A
種類：実装
着手時刻：
終了時刻：
見積時間：
総時間：
担当者：受講生X
成果物：class A
種類：実装
着手時刻：13:00
終了時刻：
見積時間：0.5H
総時間：
成果物：class A
種類：実装
終了時刻：14:00
見積時間：0.5H
総時間：1.0H
* 小川明彦, 阪井誠, "チケット駆動開発," 翔泳社, 2012.
現状の把握や
プロセスの振り返りに
非常に有用
19

以下のフレームワークにチケット駆動開発を導入した
Scrum＋PBL＋TiDD
開発
(10:30~17:00)
Scrum Master
開発メンバ
Product Owner
顧客
(教員)
スプリント
レビュー（15分）
振り返り(KPT)
（19時まで)
Product Owner
スプリント（1日)
20

スプリントバックログ＝チケット群
スプリント計画時にチケット作成
スプリント計画へのTiDD導入
チケットにより，スプリントバーンダウンチャートの
自動生成が可能
21
成果物：class A
種類：実装
見積時間：0.5H
総時間：1.0H
スプリント：UC[Login]
成果物：class B
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class C
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class D
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class E
種類：単体テスト
着手時刻：
終了時刻：
見積時間：0.5H
総時間：
担当者：

開発と連動してチケットを操作する
現状把握が可能となる
 スプリントバーンダウンチャートの自動更新
 Assignment状況の把握
 残タスクの可視化
開発へのTiDDの導入
開発
(10:30~17:00)
Scrum Master
開発メンバ
Product Owner
成果物：class A
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class B
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class C
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class D
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class E
見積時間：0.5H
総時間：1.0H
22

開発と連動してチケットを操作する
現状把握が可能となる
 スプリントバーンダウンチャートの自動更新
 Assignment状況の把握
 残タスクの可視化
開発へのTiDDの導入
開発
(10:30~17:00)
Scrum Master
開発メンバ
Product Owner
成果物：class A
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class B
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class C
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class D
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class E
見積時間：0.5H
総時間：1.0H
23

振り返りのための判断基準の多くをチケット
から取得できる
Assignment，DoD
客観的なデータに基づいて
振り返りが可能となった
振り返りへのTiDDの導入
振り返り(KPT)
（19時まで)
成果物：class A
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class B
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class C
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class D
種類：実装
見積時間：0.5H
総時間：1.0H
成果物：class E
見積時間：0.5H
総時間：1.0H
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
preSprint
Sprint1st
Sprint2nd
Sprint3rd
Sprint4th
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
preSprint
Sprint1st
Sprint2nd
Sprint3rd
Sprint4th
D: 生産性（チケット数比）
preSprintは8/22より前の7/26（合宿期間外）に実施したスプリント

定量的なフィードバック

合宿に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: コミット‐チケット対応
※コミット時に、開発者が着手中の
チケットが存在しているかどうか

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

More Related Content

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