第6回RxtStudy発表資料　チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」

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

あきぴー@RxtStudy
(copyright2012 akipii@XPJUG関西) 1

出版しました

現在絶賛販売中！

TiDDの基本的な課題(1)

チケット駆動とは何か、何を価値とするのか、
単純な原則を抽出して
改めて体系づけ直すべきではないか。

http://www.amazon.co.jp/dp/4798125067

TiDDの原則や価値とは何か？
暗黙的に判断している基準(価値観、原則)を明確にしたい


TiDDの基本的な課題(2)
@yusuke_arclamp:
チケットの「出し方や受け方や閉じ方」
「しまい方や並べ方」には間違いなくパターンがありますね。
対象物についても類型化できるでしょうし。
もちろんアンチパターンもありますね。

https://twitter.com/yusuke_arclamp/status/240810887185833984

日本の現場で実践されているTiDDのノウハウを共有できないか？
チケットの粒度
チケットの完了条件
チケットの優先度の付け方　etc.
チケットの優先度の付け方


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

2. プラクティスをパターン言語の形式で表現
現場の経験知と常識を拠り所
特定の状況の問題に対して有効な解決法を提示

3. 開発プロセスの作業仮説として提示
本資料は完成版ではない
コミュニティで議論した結果を反映して補強したい


TiDDの体系の構造
の体系の構造

チケット駆動開発
ダイジェストで
原則ざっくり話します

価値

プラクティス

フレームワーク道具

役割

プロセス

TiDDの原則・価値


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

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

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


チケットとは
チケット

タスク障害課題問合せ要望

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


構成管理とは
製品(ビルドラベル付
製品ビルドラベル付)
ビルドラベル付

リリースタグ付与

リリース
メインライン
(trunk)
#10 release

ソフトウェア資産を管理する仕組み
ソフトウェアの変更を記録する(成果物は構成管理に従う)
成果物は構成管理に従う)
定期的にリリース可能なソフトウェア(資産)にラベル付け(名前
名前
が付けられた安定したバージョン)
が付けられた安定したバージョン
リポジトリにリリースタグを付与(Iteration is version)
製品にビルド番号を付与

価値とは
何が望ましく何がふさわしくないのかという基準
チケットの取捨選択に関わる判断基準
価値を実現するためにプラクティスを実践する

価値コミュニケーション

フィードバック

コミットメント
オープン

勇気


TiDDの価値一覧(作成中)
価値望ましい行動ふさわしくない行動
コミュニケーション・障害状況を常に共有・空中戦の議論
・チームを超えて自発的行動
オープン・作業を見える化する
・作業を見える化する
見える化 (@g_maeda
g_maeda)
・ヤミ作業 (@g_maeda)
・やるべきことを明確にする(バッ
クログ)
クログ)
コミットメント・担当したチケットを完了する・チケットを放置する
・イテレーション終了時にリリー・リーダーが課題を解決しない
スする
フィードバック・ユーザや開発者の意見を受け・大量のフィードバックをさばけ
入れるない
・運用を改善する・ふりかえりをしない

勇気・チケットを捨てる・無気力
・作業の阻害要因を打破する・無関心


TiDDによるパラダイムシフト
従来のWF開発チケット駆動開発

品質コスト納期

コスト納期スコープ

品質、コスト、納期は固定コスト、納期は固定
→納期は分割リリース
　　スコープ(チケット)を調整

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

TiDDのプラクティス


プラクティスとは
現場で実証された実践技法
プラクティスは価値に基づく行動を促す
パターン言語で表現してみる
特定の状況(context)の問題(problem)における解決法(solution)
名前・別名プラクティス名。別の名称。
頻出場所プラクティスが出現する工程、作業
挿話証拠問題が発生する状況でよく見聞きする言動
問題プラクティスで解決しようとする問題
プラクティスで解決しようとする問題
状況(文脈
状況文脈)
文脈問題が発生する状況。プラクティスを適用すべき状況。
問題が発生する状況。プラクティスを適用すべき状況。
プラクティス
解決法問題を取り除くための解決方法
結果文脈プラクティスで解決した後に変化した状況
プラクティスで解決した後に変化した状況
関連プラクティス関連するプラクティス
関連アンチパターン頻出する望ましくない状況や問題のパターン

No Ticket, No Commit
名前チケット無しのコミット不可
頻出場所チケットの閉じ方
挿話証拠「ソースが修正された変更理由を誰か知ってますか？」

問題障害の記録はあるが、実装された成果物に紐付いていない
状況実装された意図が忘れ去られた
解決法ソースをコミットする時にチケットへ変更理由を残す

結果文脈・要件から製品までのトレーサビリティが実現される
・チケットの完了条件に成果物の完成も含まれる
関連・チケット無しのfolkやmergeは許さない
・チケット無しのfolkやmergeは許さない
folk
プラクティス・No Ticket, No Release
関連・デグレード
アンチパターン・曖昧な完了基準

Iteration is Version
名前イテレーションはバージョンに同一視
頻出場所バージョンの登録・終了、チケットの分類
挿話証拠「開発にリズムがなくて、残業や休日出勤が多すぎだ」
問題リリースが１回だけなので学生症候群になりやすい
状況納期やマイルストーンがあるのに守られていない
解決法イテレーションをリリースバージョンとして定期的にリリースする

結果文脈リリース計画を立てて頻繁に改良できるようになる

関連・小規模リリース
プラクティス・バックログ、Velocity
・バックログ、Velocity
関連・空っぽのロードマップ
アンチパターン Closeされないバージョン、工程単位のバージョン
・Closeされないバージョン、工程単位のバージョン

小規模リリース
消化チケット
開発
規模

消化チケット

消化チケット

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

開発のリズム
チケットの作業に集中(Scrumの集中)
割り込み作業はしない
コミットのリズム
コミットと同時にチケットをCloseする(No Ticket, No Commit)
定期的にリリースする
適切で持続可能な開発ペース(Velocity)
定期的なイベントで検査
毎日の朝会
毎週の棚卸し会
リリースごとにふりかえり


チケットはワークフローに従う
名前 Tickets follow workflow
頻出場所チケットの分類
挿話証拠「顧客の問合せが今のチケットでは管理しにくいね」
問題 1種類のワークフローだけで全プロセスを管理しようとしている
種類のワークフローだけで全プロセスを管理しようとしている

状況チケット駆動のプロジェクト運営だが、業務分析できていない
解決法プロセスはワークフロー(チケットの種類で制御する
プロセスはワークフローチケットの種類)で制御する
チケットの種類

結果文脈プロセス単位にチケットが発生し、検査されて完了する

関連・ペア作業
プラクティス・チケット集計もワークフローに従う
関連・問合せはバグ修正なり
アンチパターン・足りないステータス

チケット集計もワークフローに従う
チケット
集計

集計結果ガントチャート課題一覧
バグ収束曲線
EVM リスク一覧

ワークフロータスクバグ課題

チケット集計結果はワークフロー単位で意味を持つ
ワークフロー毎に分析したい観点は異なる

チケットは製品に従う
名前 Tickets follow a product
頻出場所プロジェクトの登録・終了、チケットの分類

挿話証拠「製品の障害チケットがどこに記録されたか分からない」

問題チケットの集合(プロジェクト)
チケットの集合(プロジェクト)はどの単位にすべきか？

状況チーム単位でチケット管理されて、チーム間の風通しが悪い

解決法・チケット管理はチーム単位ではなく製品単位にする
・製品の変更管理にチケットを関連付ける

結果文脈・製品ごとのタスク管理に沿った組織に変化する
・製品ごとのリリース計画が明確になる
関連・Conwayの法則 (アーキテクチャは組織に従う)
Conwayの法則アーキテクチャは組織に従う)
プラクティス・プロジェクトで分割統治
関連・アーキテクチャに対応しない複数チームのタスク管理
アンチパターン (copyright2012 akipii@XPJUG関西)
・工程単位のプロジェクト 22

チケット管理しやすい組織へ変化
TiDDはプロセスを定量化する手段を提供(見える化)
計画→実施→測定・評価という改善サイクルが生まれる
メンバーの役割が変わる(自己組織化)
リーダーは支援者になり、メンバーは自発的に作業し始める

従来型(WF) TiDD(Agile)

進捗管理
作業指示課題解決

Excel
チケット

進捗報告
自発的に作業
ペア作業

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

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

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

続きは品川Redmineで
2012/11/10(土)　品川Redmine勉強会　at 東京

丸山さん(Redmineコミッタ)、
岡本隆史さん(@LightningX)、
小久保さん(@yusuke_kokubo)
も講演されます！


コミュニティで
TiDDのプラクティスを
創り出していきましょう
ご清聴
ありがとうございました


第6回RxtStudy発表資料　チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de akipii Oga

Mais de akipii Oga (20)

Último

Último (9)