【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/03/agilejapan2012-.html Agile Japan 2012 https://www.facebook.com/AgileJapan2012

1. チケット駆動開発の
課題と展望
2012/03/16
あきぴー＠XPJUG関西
(copyright2012 akipii@XPJUG関西)
1

2. 自己紹介
HN：@akipii
チケット駆動開発の本を出
版 (with @sakaba37)
Redmineを使って、
チケット駆動開発による
Agileな開発方法について
解説しました
2012/3現在、
第5刷(7500部)まで増刷中！
刷
部 まで増刷中！
(既に定番本らしい)
(copyright2012 akipii@XPJUG関西)
2

3. セッションの目的
TiDDの運用方法と実装方法を意見交換したい
運用方法はプロジェクトへのテーラリング
実装方法は機能改善のためのプログラミング
問題提起の例
実プロジェクトでどのように運用すると効果的か？
Agile開発はTiDDでどのように実現すればいいか？
開発業務をTiDDにどのようにマッピングしているか？
不足した機能をどのように実装して解決するか？
SW開発のBest Practiceをどのように実装すべきか？
(copyright2012 akipii@XPJUG関西)
3

4. セッションの概要
3人の講演者がTiDDの課題を提示
あきぴー
中村さん
阪井さん
双方向のパネルディスカッション
質問者はマイクの近くで一列に並んで下さい
質問者はパネラーに1個の質問を問いかけて下さい
その後はパネラーや聴衆で自由に議論しましょう
(copyright2012 akipii@XPJUG関西)
4

5. Agenda
コミュニティの活動状況
Agile編
インフラ編
プロセス編
まとめ
(copyright2012 akipii@XPJUG関西)
5

6. コミュニティの活動状況
(copyright2012 akipii@XPJUG関西)
6

7. 関西の活動～RxtStudy
Redmineとタスク管理に関する勉強会
@pinkmacさん達が立上げた
過去3回の勉強会は大成功
第1回勉強会でRedmine本の著者が勢ぞろい！
@g_maeda, @kuranuki, @akipii, @sakaba37
Redmineの市場があることを再確認！
の市場があることを再確認！
(copyright2012 akipii@XPJUG関西)
7

8. RxTStudyの情報
ハッシュタグ
#RxtStudy でつぶやいてください
活動HP
http://www.rxtstudy.net/
Facebookコミュニティページ
http://www.facebook.com/RxTstudy
(copyright2012 akipii@XPJUG関西)
8

9. 関東の活動～shnagawa.redmine
Redmineを中心とした勉強会
「東のTrac、西のRedmine」と言われている(@nobiinu_and)
関東でRedmineの情報を共有できる場を作ろう！
@haru_iida, @naitoh, @kusukawa, @nobiinu_and,
@yohwadaさん達が集まった
過去2回の勉強会は大成功
デブサミ2012にも出店
(copyright2012 akipii@XPJUG関西)
9

10. shnagawa.redmineの情報
ハッシュタグ
#47redmine でつぶやいてください
活動HP
http://shinagawa.redmine.r-labs.org/projects/shinared
Facebookコミュニティページ
http://www.facebook.com/shinagawa.redmine
(copyright2012 akipii@XPJUG関西)
10

11. Agile開発編
TiDDはAgileと相性が良い
(copyright2012 akipii@XPJUG関西)
11

12. Agile開発に関する課題
イテレーションを運用できていない
空っぽのロードマップ
工程単位のバージョン
イテレーションが本番リリースと連携していない
開発業務がBTSの機能にマッピングできていない
TiDDをやっているのにBTSをフルに使いこなせていない
Agileの概念をBTSのどの機能に対応付けるか？
(copyright2012 akipii@XPJUG関西)
12

13. 【反例】空っぽのロードマップ
名前
空っぽのロードマップ
頻出場所
リリース計画
症状と結果
・バージョンやロードマップの機能を運用してない
・数えられないぐらいチケットが溜まっている
・開発のリズムが無い
挿話証拠
「残業や休日出勤が多いね」
根本原因
チケットの納期がなく、リリースが１回だけ
再構想解の
プラクティス
・小規模リリース
・バックログ
再構想による解
決
・イテレーションをリリース予定バージョンに紐づける
・リリース計画を立てて頻繁に改良する
変種
・放置されたチケット
・Closeされないバージョン
されないバージョン
(copyright2012 akipii@XPJUG関西)
13

14. 【反例】工程単位のバージョン
名前
工程単位のバージョン
頻出場所
リリース計画
症状と結果
・Redmineバージョンを工程で分けている
バージョンを工程で分けている
・障害や仕様変更のたびにバージョンがReopenされる
・障害や仕様変更のたびにバージョンが
される
挿話証拠
「いつになってもリリースできないね」
根本原因
・WF型開発にこだわりすぎ
型開発にこだわりすぎ
・リリースの終了基準が不明確
再構想解の
プラクティス
・小規模リリース
・イテレーションで分割統治
再構想による解決
・イテレーション単位に順次リリースしていく
・リリースの終了基準を明確にする
変種
・Closeされないバージョン
されないバージョン
・ゴールの見えないバージョン
(copyright2012 akipii@XPJUG関西)
14

15. BTSとTiDDの対応表
BTS
TiDD
チケット
障害報告票
タスクカード
(ストーリーカード
ストーリーカード)
ストーリーカード
レポート
障害一覧
タスクボード
(バックログ
バックログ)
バックログ
ワークフロー
バグ検証
作業全般
バグ修正履歴を追跡
成果物の変更履歴を追跡
バージョン
リリース予定(済
リリース予定 済)
バージョン
イテレーション
(スプリント
スプリント)
スプリント
プロジェクト
工程単位
機能
トレーサビリティ
製品単位
ブランチ単位
TiDDはBTSの機能を流用したプロセス
は
の機能を流用したプロセス
(copyright2012 akipii@XPJUG関西)
15

16. チケットはタスクカード (Ticket First)
BTSチケットをXPのタスクカードのように扱う(@sakaba37)
チケットに作業履歴・進捗・構成管理の情報を付与する
計画外の作業や変更された作業をチケットで追跡しやすい
チケットをストーリーカードとして扱う運用もある(例：Pivatal Tracker)
タスクカード(例
タスクカード 例)
タスク番号：21
ストーリー番号：11
開始日：2009/7/14
終了日：2009/7/17
予定工数：32時間
実績工数：28時間
説明：カート画面に売れ筋商品機能を実装
ノート：共通ライブラリを使う
(copyright2012 akipii@XPJUG関西)
16

17. No Ticket, No Commit !
(copyright2012 akipii@XPJUG関西)
17

18. No Ticket, No Commit !
・チケット無しのソースコミット不可 (@machu)
・成果物の変更をチケットで追跡する
(Traceability)
(copyright2012 akipii@XPJUG関西)
17

19. バージョンはイテレーション
バージョンを2～ 週間ごとに順
バージョンを ～4週間ごとに順
次リリースしていく
バージョンに紐づく全てのチケットが
完了になればリリース
長期計画はリリース計画、短期計画
はイテレーション計画で使い分け
リリース済みバージョンとSCMタ
リリース済みバージョンと
タ
グを同一視
バージョン→チケット→ソース修正
履歴へ追跡可能
期限のないバージョンはバックロ
グや内部課題のように扱う
Scrumのバックログは要望の貯蔵庫
リリースの優先順位によってイテレー
ション間を移動する
(copyright2012 akipii@XPJUG関西)
18

20. インフラ編
可用性に難あり
(copyright2012 akipii@XPJUG関西)
19

21. インフラに関する課題
大人数利用を想定していない
大量アクセスでWebサーバーがダウン
大量アクセスでSVNリポジトリがダウン
信頼性や可用性をクリアする事が今後の課題
SCM連携を強化する
大人数利用ではPost-commit-hookの機能がネックになる
Redmineのリポジトリ画面をリフレッシュ
RedmineのWebサービス機能でPost-commit-hook
JenkinsでPost-commit-hookをポーリング化
(copyright2012 akipii@XPJUG関西)
20

22. RedmineのWebサービス機能
小技(0.9): コミットと同時にリポジトリの情報を取得する
Redmine.JP Blog http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/
(copyright2012 akipii@XPJUG関西)
21

23. RedmineのWebサービス機能
小技(0.9): コミットと同時にリポジトリの情報を取得する
Redmine.JP Blog http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/
Post-commit-hook
をWebサービス化する
サービス化する
(copyright2012 akipii@XPJUG関西)
21

24. SCM連携をポーリング化
Post-commit-hookをポーリング
をポーリング
イベントドリブン化)する
化(or イベントドリブン化 する
→Jenkinsによるバッチ処理化
によるバッチ処理化
(copyright2012 akipii@XPJUG関西)
22

25. プロセス編
ツールの自己目的化の罠
(copyright2012 akipii@XPJUG関西)
23

26. プロセスに関する課題
ツールの運用が自己目的化してしまう
マネージャは帳票出力やデータ分析にこだわりがち
ツールに依存しすぎ
TiDDはツール無しでは運用できないのか？
トラッカーを理解できていない
開発業務のワークフローを分析できていない
TiDDはプロジェクト管理の問題をソフトウェアの問題
に置き換える
解ける問題に変換すれば人は自然に動き出す(Facilitation)
ツールの一機能でBest Practiceを実装する
(copyright2012 akipii@XPJUG関西)
24

27. トラッカーのライフサイクル
ライフサイクルに応じて
ワークフローは変わる
登録
Redmine
分割
更新
Application Lifecycle
Management(ALM)の
の
概念に繋がる
(copyright2012 akipii@XPJUG関西)
25

28. トラッカーは知識操作パターンで統一
同じワークフローを持つトラッカーは、抽象化して一
つにまとめる
「タスク」は作業のインスタンスを抽象化した概念
トラッカーが多すぎると管理しにくくなる
(copyright2012 akipii@XPJUG関西)
26

29. トラッカーは帳票で区別
Redmine
帳票出力
各種帳票
トラッカー
進捗一覧
障害一覧
タスク
バグ
課題一覧
課題
BTSから出力される帳票単位にトラッカーを作る
ワークフローやチケットの属性が大きく異なるから
(copyright2012 akipii@XPJUG関西)
27

30. ソフトウェアで解ける問題に変換
プロジェクト管理は労働集約的な作業が多い
上司や顧客への報告資料作り
メトリクスを出力して分析・是正対策作り
予定/実績工数を集計してコスト管理
報告資料のためのチケット集計機能を強化しよう
チケットの粒度は役割の観点で変える
オブジェクト指向やAgileの歴史に似ている
オブジェクト指向はプログラミングの一技術から設計(OOA)
やプロセス(RUP)へ発展
開発現場で生まれたXPやScrumがIT業界を席巻している
開発現場から生まれたTiDDも更に発展できるはず
(copyright2012 akipii@XPJUG関西)
28

31. まとめ
Agile開発をTiDDで強化したい
Agile開発をもっと緻密に組織的にしたい
規律を持ちながら軽量なプロセスにしたい
RedmineをIT企業の基幹システムにする
全プロジェクトの進捗は社員全員に丸見え
信頼性や可用性のクリアはこれから
プロジェクト管理の問題をソフトウェアで解決していく
ソフトウェアの問題にすればAgile開発が得意
ソフトウェアが時代にようやく追いついた
現代は世の中の問題をソフトウェアで解決していく流れ
例：Apple, Google, Amazon, Twitter, Facebook etc.
(copyright2012 akipii@XPJUG関西)
29

32. ご清聴
ありがとう
ございました
(copyright2012 akipii@XPJUG関西)
30