チケット駆動開発をパターン言語で読み解く～「成功するプロジェクトのための開発基盤と手法」

チケット駆動開発をパターン言
語で読み解く
～「成功するプロジェクトのための開発基盤と手法」
グロースエクスパートナーズ(株)セミナー

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

出版しました

現在絶賛販売中！

Agenda
Agile開発の課題
チケット駆動開発とは
TiDD運用後
TiDDの基本的な問題
TiDDの体系化
TiDDの原則・価値観・プラクティス
パターンの適用例
まとめ


Agile開発の課題
頻繁に変わるタスク管理
頻繁なリリースでタスク管理が大変
アナログのPostIt、かんばんだけでは進捗管理しづらい

継続的な修正と頻繁なリリース管理
継続的な修正と頻繁なリリース管理
と頻繁なリリース
継続的なリファクタリングや機能追加を制御するのは難しい
短期間に順次リリースするプロセスはやっぱり大変


チケット駆動開発とは
チケット駆動開発はTracのチケット管理から生まれた(まちゅさん)
http://www.machu.jp/diary/20070907.html#p01

正式名称：Ticket Driven Development (まちゅさん)

BTS/ITSを障害管理だけでなくタスク管理に使う(まちゅさん)
チケット駆動開発の運用ルールは二つだけ
BTSチケットはXPのタスクカードのように扱う(Ticket First)(阪井さん)
チケット無しのソースコミット不可 (No Ticket, No Commit !) (まちゅさん)

BTSの運用対象を
の運用対象を
拡大する

TiDDの運用サイクル


TiDD運用後
プロジェクトの問題や進捗を見える化できた
残タスク、進捗率がリアルタイムに一目瞭然
プロジェクトのゴールや問題点をチームで共有できる

TiDDが自然に
が自然にAgile開発になった(あきぴー)
が自然に開発になった
XPの小規模リリースを自然に運用できた
チケットの取捨選択が本来のマネジメント(えと～さん)


TiDDの基本的な問題
@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の価値観とは
何が望ましく何がふさわしくないのかという基準
価値を実現するためにプラクティスを実践する


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

勇気・必要最低限のチケットを実施・無気力
・作業の阻害要因を打破する・無関心


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

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

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

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

TiDDが目指す世界


パターンの適用例

問1.チケットの粒度


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

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

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


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

問題作業がチケットに記録されていない

状況担当者の作業が公開されていない

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

結果文脈・日々のタスク管理はメンバー自身で行うようになる
・チーム内で情報共有が促進される


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

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


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

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

問題障害の記録と、成果物の作業履歴が同期されてな
い
状況ソース修正が意図された修正なのか判別できない

解決法ソースをコミットする時、チケットに変更理由を残して
Closeする
Closeする
結果文脈トレーサビリティの実現によって保守作業で役立つ


トレーサビリティ

イテレーション

仕様変更障害運用ガント
チャート
詳細化
詳細化集計
チケット設計タスク
相ボード
互開発調査タスク
リ
ンロード
ク RLS準備
準備マップ
テスト

リンク
構成管理設計書ソース
実行エビデンス

テストケースファイル


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

頻出場所バージョンの登録・終了、チケットの分類
問題リリースが１回だけなので学生症候群になりやすい

状況リリース計画が現実と合致していない

解決法イテレーションをリリースバージョンとして定期的に
リリースする
結果文脈・マイルストーンごとにリリースできるようになる
・開発中の経験知がフィードバックされて蓄積される


小規模リリース

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

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

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

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

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


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


問2. チケットの完了条件
停滞したチケット
進捗率90％のまま完了しない
チケットの進捗率と作業ステータスが不一致

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

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

チケットの棚卸し
名前 Inventory of Tickets
頻出場所チケットの整理
問題チケットが最新化されない
状況チケットが放置されて、開発速度が落ちる
解決法定期的にチケットを整理して、リリース計画を最新化
する
結果文脈リリース計画が明確になり、チームのVelocityが安
リリース計画が明確になり、チームのが安
定する


柔軟なチケット管理 Ver1.0
リファクタリング

Ver1.0 ワークフロー変更
バグ修正
Ver1.0
機能Aの修正、
機能Bの修正

チケットをチケット更にチケットを分割
起票
Ver1.1
バグ修正

バージョン変更

ペア作業
名前 Pair Work
頻出場所チケットの渡し方
問題 2人の連携作業の品質が悪い
人の連携作業の品質が悪い

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


非同期な連携作業

担当者の作業を
チケットの状態遷移図
で管理できる
チケットは2人以上の担当者がキャッチボールして終わる
開発者がバグ修正後、テスターがバグ検証する
開発者が作業完了後、管理者が承認する
開発者が仕様を質問後、設計者が回答する

チケットはワークフローに従う
名前 Tickets follow workflow
頻出場所チケットの分類
問題 1種類のワークフローだけで全プロセスを管理しよう
種類のワークフローだけで全プロセスを管理しよう
としている
状況チケット駆動のプロジェクト運営だが、業務分析でき
ていない
解決法プロセスはワークフロー(チケットの種類で制御する
プロセスはワークフローチケットの種類)で制御する
チケットの種類
結果文脈プロセス単位にチケットが発生し、検査されて完了す
る


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

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

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

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

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


問3. 複数チームのタスク管理
工程単位のプロジェクト
設計・開発・テストなどの工程単位にプロジェクトを作る
保守フェーズに入ると破綻する

複数チームにまたがる課題管理
他チームに連携する作業や課題はどのように管理するか？
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の法則 (アーキテクチャは組織構造に従
う))
・製品ごとのリリース計画が明確になる


CCB(変更管理会議) 週次追跡

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

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

開発チームA 開発チームB 開発チームC


TiDDは自発的行動を促す

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

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

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

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

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

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

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


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


チケット駆動開発をパターン言語で読み解く～「成功するプロジェクトのための開発基盤と手法」

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à チケット駆動開発をパターン言語で読み解く～「成功するプロジェクトのための開発基盤と手法」

Similaire à チケット駆動開発をパターン言語で読み解く～「成功するプロジェクトのための開発基盤と手法」 (20)

Plus de akipii Oga

Plus de akipii Oga (20)

Dernier

Dernier (12)

チケット駆動開発をパターン言語で読み解く～「成功するプロジェクトのための開発基盤と手法」