第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」

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

あきぴー@shinagawa.redmine
(copyright2012 akipii@XPJUG関西) 1

出版しました

現在絶賛販売中！

TiDDの基本的な問題(1)
似たような質問が多い
チケットの粒度
チケットの完了条件
複数チームのタスク管理

同じ問題でも状況で異なる
情報システム部門
複数チームのタスク管理

暗黙的な判断基準を明確にしたい
チケットの取捨選択
チケットの優先順位付け

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. チケットは成果物や仕様ではない(成果物は構成管理に従う)
成果物は構成管理に従う)


TiDDにおける構成管理とは
製品(ビルドラベル付
製品ビルドラベル付)
ビルドラベル付

リリースタグ付与

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

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

TiDDの価値観


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

価値観コミュニケーション

フィードバック

コミットメント
オープン

勇気


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

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


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

コスト納期コスト納期

品質品質スコープ

品質、コスト、納期は固定「スコープ」は隠れた変数
→スコープ(チケット)を調整

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

TiDDのプラクティス


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

問1.チケットの粒度


問1.チケットの粒度
肥満児チケット
タスク分割が不十分
当初の見積りよりも倍以上の工数がかかる
作業してみたら不明点や課題が出て状況が変わった

放置されたチケット
チケットを細かくすれば、チケットは乱発されやすい
本番リリース直後に同一原因の障害を大量に登録してしまう
期日やリリースバージョンが未定の「今すぐ」チケット


No Ticket, No Commit
名前チケット無しのコミット不可
頻出場所チケットの閉じ方
挿話証拠「修正したソースがデグレードしたのは何故？」

問題障害の記録と、成果物の作業履歴が同期されてない
状況理由が分からないコミットが多い
解決法ソースをコミットする時、チケットに変更理由を残してCloseする
ソースをコミットする時、チケットに変更理由を残してCloseする
Close

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

トレーサビリティ
成果物の変更をチケットで追跡する(Traceability)
チケットへ構成管理情報を付与する
チケット無しのソースコミット不可 (No Ticket, No Commit !) (@machu)
変更理由をチケット経由で要件からビルドモジュールまで追跡可能
リバースエンジニアリングや仕様変更の影響調査に適用できる


タスクはチケットで分割統治
名前 Divide and Conquer
頻出場所チケットの作り方
挿話証拠「チケットは機能追加なのに、リファクタリングばかりしている」
問題開発者が作業しやすいチケットの内容になっていない
状況チケットの粒度がバラバラ
解決法残課題や別作業はチケットを分割する

結果文脈開発者が作業しやすくなり、開発のリズムが生まれる

関連・チケットの棚卸し
プラクティス・No Ticket, No Commit
関連・肥満児チケット
アンチパターン・Closeされないチケット
されないチケット

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

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

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

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

消化チケット

消化チケット

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

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


問2. チケットの完了条件


問2. チケットの完了条件
停滞したチケット
進捗率90％のまま完了しない
チケットの進捗率と作業ステータスがアンマッチ
作業はほぼ完了したが、課題や仕様の不明点が残った

モンスターチケット
レビュー後の差し戻しが多い
成果物の完了条件の認識がPLとPGで異なる

ワークフローによって完了の定義が違う
タスクは成果物を完成したか否か
課題は解決できて、タスクに変換できたか否か

チケットの棚卸し
名前 Inventory of Tickets
頻出場所チケットの整理
挿話証拠「チケットがゴミ箱になっているね」
問題チケットが最新化されない
状況チケットが放置されて、開発速度が落ちる
解決法定期的にチケットを整理して、リリース計画を最新化する

結果文脈リリース計画が明確になり、チームのVelocityが安定する
リリース計画が明確になり、チームのが安定する

関連・開発のリズム
プラクティス・バックログ
関連・チケットが不良在庫
アンチパターン・停滞したチケット

ペア作業
名前 Pair Work
頻出場所チケットの渡し方
挿話証拠「バグ修正とバグ検証の連携作業が上手くいってないね」
問題 2人の連携作業の品質が悪い
人の連携作業の品質が悪い

状況障害修正やレビュー等、2人のチェックが必要な作業
障害修正やレビュー等、人のチェックが必要な作業
解決法各担当者の作業状態にステータスを割り当ててワークフロー化
する
結果文脈連携作業にキャッチボールのようなリズムが生まれる

関連チケットはワークフローに従う
プラクティス
関連足りないステータス
アンチパターン

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

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

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

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

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

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

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

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

問3. 複数チームのタスク管理


問3. 複数チームのタスク管理
巨大プロジェクト
1個のITSプロジェクトで2チーム以上のタスクを管理
チケットが多すぎて整理もできない

工程単位のプロジェクト
設計・開発・テストなどの工程単位にプロジェクトを作る
保守フェーズに入ると破綻する

複数チームにまたがる課題管理
他チームに連携する作業や課題はどのように管理するか？
CCB(変更管理会議)やScrum of Scrumでの課題管理は、
どこに配置するか？

Conwayの法則
「アーキテクチャは組織に従う」
「組織はアーキテクチャに従う」
http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/Translations/GDP/pattern14.htm

ソフトウェアのどの部分であれ、それを作った組織の構造を反映する
例：コンパイラを4つのグループで作れば、4パスコンパイラになる

製品(派生元
製品派生元)
派生元 SCMリポジトリ
リポジトリ

派生製品リリース
ブランチ


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

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

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

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

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

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

Scrum of Scrum(又はCCB) 週次追跡

チーム間の課題の棚卸し会議
Scrumマスター(リーダー)同士でチーム横
断の課題を調整する

Scrumマスターが集合
マスターが集合スクラムオブスクラムステアリング
した課題管理会議
した課題管理会議コミッティー
→「課題プロジェクト」
日次追跡
各チームの
「タスク管理プロ
ジェクト」日次追跡日次追跡日次追跡

ScrumチームA ScrumチームB ScrumチームC
アジャイルコンポーネントチーム

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

従来型(WF) TiDD(Agile)

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

Excel
チケット

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

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

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

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

まとめ
「チケットの粒度」「チケットの完了条件」はTiDDの本質
的な問題
大量のチケットをいかに捌いて、チームを前進させるか

パターン言語でTiDDの特徴を表現できそう
TiDDはプラクティスの集合
プラクティスは一つではなく、状況と問題によって使い分ける

プラクティスが生成的(generative)である特徴を表現したい
プラクティスの効果として「計画」「品質」「効率」が現れる
プラクティスから価値観に基づく行動が生まれる


あなたの経験と常識を元に
「チケットの粒度」 or 「チケットの完了条件」
を１つずつまとめて下さい

(1)どんな状況でどんな問題を
どのように解決して「上手くいったか」
(2)どんな状況でどんな問題を
解決しようとして「失敗した」か

制限時間：３０分
発表：５分

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


第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」

More Related Content

第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」