デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」 #devsumi #devsumiB

チケット駆動開発のフレームワーク
～現場の経験知からパターン言語へ

14-B-5 小川明彦
XPJUG関西
XPJUG関西

Developers Summit 2013 Action ! 1

チケット駆動でよく聞かれる質問
似たような質問が多い
チケットの粒度
複数チームのタスク管理

判断基準が暗黙知なので明確でない
現場のノウハウが形式知として共有されていない

チケット駆動開発(TiDD)はAgile開発なのか？
日本の開発現場で生まれたアジャイルな実践技法
人によって説明がバラバラ


体系化の方針
1. ツールの説明を排除
TiDDはツールに依存しない
RedmineでもPostItでもチケット駆動は運用可能

2. プラクティスをパターン言語の形式で表現
現場の経験知を再利用できる形式にする
特定の状況の問題に対して有効な解決法を提示

3. 原則・価値観・プラクティスでまとめる
開発フレームワークの作業仮説として提示
コミュニティで議論した結果を反映して補強したい

TiDDの原則、
価値観、
プラクティス


TiDDの原則
原則とは
価値とプラクティスの領域における不変のルール

1. 最初にチケットありき (Ticket First)
SW開発の作業も課題も障害もチケットへ
チケット無しの作業不可 (No Ticket, No Work)

2. 成果物は構成管理に従う
プログラムや仕様書は構成管理へ
議事録や報告書はWikiやチケット集計へ


チケットとは

製品の変更時に管理すべき対象プロセス(チケットは製品に従う
チケットは製品に従う)
チケットは製品に従う
チケットはワークフローで制御される(チケットはワークフローに従う
チケットはワークフローに従う)
チケットはワークフローに従う
チケットは成果物や仕様ではない(成果物は構成管理に従う
成果物は構成管理に従う)
成果物は構成管理に従う


構成管理とは

ソフトウェア資産を記録する仕組み　(成果物は構成管理に従う
成果物は構成管理に従う)
成果物は構成管理に従う
バージョンは、ソフトウェア資産を確定させる締日
チケットはリリースに至るまでのコミット履歴というメタ情報

TiDDの価値観とは
何が望ましく何がふさわしくないのかという基準
価値を実現するためにプラクティスを実践する


プラクティスとは
現場で実証された実践技法
プラクティスは価値観に基づく行動を促す
パターン言語で表現してみる
特定の状況の問題における解決法

名前・別名プラクティス名。別の名称。
頻出場所プラクティスが出現する工程、作業
状況(文脈
状況文脈)
文脈問題が発生し、価値が妨害される状況(context)
問題が発生し、価値が妨害される状況

問題プラクティスで解決しようとする問題
プラクティスで解決しようとする問題(problem)
で解決しようとする問題

解決法問題を取り除くための解決方法(solution)
問題を取り除くための解決方法
結果文脈プラクティスで解決した後に変化した状況。
プラクティスで解決した後に変化した状況。
別の価値を促進する副次的な効果。

TiDDが目指す世界


パターンの適用例
～チケットの粒度に関する問題


「チケットの粒度」に関する問題
あいまいなチケット
チケットがタスクではなく仕様書になっている
作業内容がよく分からない

肥満児チケット
タスク分割が不十分
当初の見積りよりも倍以上の工数がかかる

放置されたチケット
チケットを細かくすれば、チケットは乱発されやすい
期日やリリースバージョンが未定の「今すぐ」チケット

No Ticket, No Work
名前チケット無しの作業不可
頻出場所チケットの作り方

状況担当者の作業が公開されていない
オープンを妨害
→オープンを妨害
問題作業がチケットに記録されていない

解決法チケットを起票してから作業を開始する

結果文脈・日々のタスク管理はメンバー自身で行うようになる
コミットメント、勇気の効果
→コミットメント、勇気の効果
・チーム内で情報共有が促進される
コミュニケーションの効果
→コミュニケーションの効果

TiDDによるパラダイムシフト

チケットの取捨選択でスコープ管理する
　　変化に強いタスク管理が運用可能

No Ticket, No Commit
名前チケット無しのコミット不可

頻出場所チケットの閉じ方

状況ソース修正が意図された修正なのか判別できない
コミットメントを妨害
→コミットメントを妨害
問題障害の記録と、成果物の作業履歴が同期されてな
い
解決法ソースをコミットする時、チケットに変更理由を残して
Closeする
Closeする
結果文脈トレーサビリティの実現によって保守作業で役立つ
フィードバックの効果
→フィードバックの効果


TiDDの運用サイクル


Iteration is Version
名前イテレーションはバージョンに同一視

頻出場所バージョンの登録・終了、チケットの分類
状況リリース計画が現実と合致していない
オープンを妨害
→オープンを妨害
問題リリースが１回だけなので学生症候群になりやすい
解決法イテレーションをリリースバージョンとして定期的に
リリースする
結果文脈・マイルストーンごとにリリースできるようになる
コミットメント、勇気の効果
→コミットメント、勇気の効果
・開発中の経験知がフィードバックされて蓄積される
フィードバックの効果
→フィードバックの効果

小規模リリース

　小刻みに機能拡張しながら定期的にリリースしていく
　 Velocity(開発速度
開発速度)＝イテレーション単位の平均消化チケット数
開発速度

開発のリズム
チケットの作業に集中 (Scrumの集中
の集中)
の集中
割り込み作業はしない

コミットのリズム
コミットと同時にチケットをCloseする (No Ticket, No Commit)

定期的なリリース
持続可能な開発ペース (Velocity)

定期的なイベントで検査 (Scrumの透明性
の透明性)
の透明性
毎日の朝会
リリースごとにふりかえり

TiDDは自発的行動を促す

開発者に自己管理する勇気の基盤を与える
作業の見える化がメンバー間の信頼関係を強化する
リーダーは管理者から支援者へ変わる

その他のプラクティス(作成中)
チケット管理の観点適用可能なプラクティス、概念
チケットの作り方 No Ticket, No Work
チケットの整理チケットの棚卸し
チケットの閉じ方 No Ticket, No Commit
チケットの渡し方ペア作業
チケットの分類分割統治、チケットはワークフローに従う
チケットの集計・チケット集計もワークフローに従う
・ロールでビューを切り替える etc.
チケットの通知私に聞くな、チケットに聞け(TiDD版ハリウッドの原則)
TiDD版ハリウッドの原則
版ハリウッドの原則)

チケットの並べ方バックログ etc.

バージョンの作り方 Iteration is Version
プロジェクトの作り方チケットは製品に従う

まとめ


まとめ
パターン言語で現場の経験知を表現できそう
状況と問題によってプラクティスを使い分ける
パターンで経験知の本質を取り出したい

TiDDとAgile開発の親和性を説明できそう
透明性、小規模リリース、持続可能な開発ペース etc.
TiDDは価値観に基づく行動を促す

プラクティスが生成的(generative)な特徴を表現したい
生成的
単独のプラクティスから「品質」「効率」は出現しない
プラクティスの相乗効果として「計画」「品質」「リズム」が現れる


ご清聴
ありがとう
ございました

デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」 #devsumi #devsumiB

More Related Content

What's hot

Viewers also liked

Similar to デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」 #devsumi #devsumiB

More from akipii Oga

デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」 #devsumi #devsumiB