Contenu connexe Similaire à 第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 (20) 第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」2. 出版しました
現在絶賛販売中!
(copyright2012 akipii@XPJUG関西) 2
4. TiDDの基本的な問題(2)
@yusuke_arclamp:
チケットの「出し方や受け方や閉じ方」
「しまい方や並べ方」には間違いなくパターンがありますね。
対象物についても類型化できるでしょうし。
もちろんアンチパターンもありますね。
https://twitter.com/yusuke_arclamp/status/240810887185833984
日本の現場で実践されているTiDDのノウハウを共有できないか?
チケットの粒度
チケットの完了条件
チケットの優先度の付け方 etc.
チケットの優先度の付け方
(copyright2012 akipii@XPJUG関西) 4
5. 体系化の方針
1. ツールの説明を排除
TiDDはツールに依存しない
RedmineでもPostItでもチケット駆動は運用可能
2. プラクティスをパターン言語の形式で表現
現場の経験知と常識を拠り所
特定の状況の問題に対して有効な解決法を提示
3. 開発プロセスの作業仮説として提示
本資料は完成版ではない
コミュニティで議論した結果を反映して補強したい
(copyright2012 akipii@XPJUG関西) 5
6. TiDDの体系の構造
の体系の構造
チケット駆動開発
ダイジェストで
原則 ざっくり話します
価値観
プラクティス
フレームワーク 道具
役割
プロセス
(copyright2012 akipii@XPJUG関西) 6
7. TiDDの原則
(copyright2012 akipii@XPJUG関西) 7
8. TiDDの原則
原則とは
価値とプラクティスの領域における不変のルール
1. 最初にチケットありき (Ticket First)
SW開発の作業も課題も障害もチケットへ
チケット無しの作業不可 (No Ticket, No Work)
2. 成果物は構成管理に従う
プログラムや仕様書は構成管理へ
議事録や報告書はWikiやチケット集計へ
(copyright2012 akipii@XPJUG関西) 8
9. チケットとは
チケット
タスク 障害 課題 問合せ 要望
1. 製品の変更時に管理すべき対象プロセス(チケットは製品に従う)
チケットは製品に従う)
2. チケットはワークフローで制御される(チケットはワークフローに従う)
チケットはワークフローに従う)
3. チケットは成果物や仕様ではない(成果物は構成管理に従う)
成果物は構成管理に従う)
(copyright2012 akipii@XPJUG関西) 9
10. TiDDにおける構成管理とは
製品(ビルドラベル付
製品 ビルドラベル付)
ビルドラベル付
リリースタグ付与
リリース
メインライン
(trunk)
#10 release
ソフトウェア資産を記録する仕組み
ソフトウェアの変更を記録する(成果物は構成管理に従う)
成果物は構成管理に従う)
定期的にリリース可能なソフトウェア(資産)にラベル付け(名前
名前
が付けられた安定したバージョン)
が付けられた安定したバージョン
リポジトリにリリースタグを付与(Iteration is version)
製品にビルド番号を付与
(copyright2012 akipii@XPJUG関西) 10
11. TiDDの価値観
(copyright2012 akipii@XPJUG関西) 11
13. TiDDの価値観一覧(作成中)
価値観 望ましい行動 ふさわしくない行動
コミュニケーション ・障害状況を常に共有 ・空中戦の議論
・チームを超えて自発的行動
オープン ・作業を見える化する
・作業を見える化する
見える化 (@g_maeda
g_maeda)
・ヤミ作業 (@g_maeda)
・やるべきことを明確にする(バッ
クログ)
クログ)
コミットメント ・担当したチケットを完了する ・チケットを放置する
・イテレーション終了時にリリー ・リーダーが課題を解決しない
スする
フィードバック ・ユーザや開発者の意見を受け ・大量のフィードバックをさばけ
入れる ない
・運用を改善する ・ふりかえりをしない
勇気 ・チケットを捨てる ・無気力
・作業の阻害要因を打破する ・無関心
(copyright2012 akipii@XPJUG関西) 13
14. TiDDによるパラダイムシフト
従来のWF開発 チケット駆動開発
コスト 納期 コスト 納期
品質 品質 スコープ
品質、コスト、納期は固定 「スコープ」は隠れた変数
→スコープ(チケット)を調整
チケットの取捨選択でスコープ管理する
変化に強いタスク管理が運用可能
(copyright2012 akipii@XPJUG関西) 14
16. プラクティスとは
現場で実証された実践技法
プラクティスは価値観に基づく行動を促す
パターン言語で表現してみる
特定の状況(context)の問題(problem)における解決法(solution)
名前・別名 プラクティス名。別の名称。
頻出場所 プラクティスが出現する工程、作業
挿話証拠 問題が発生する状況でよく見聞きする言動
問題 プラクティスで解決しようとする問題
プラクティスで解決しようとする問題
状況(文脈
状況 文脈)
文脈 問題が発生する状況。プラクティスを適用すべき状況。
問題が発生する状況。プラクティスを適用すべき状況。
プラクティス
解決法 問題を取り除くための解決方法
結果文脈 プラクティスで解決した後に変化した状況
プラクティスで解決した後に変化した状況
関連プラクティス 関連するプラクティス
関連アンチパターン 頻出する望ましくない状況や問題のパターン
(copyright2012 akipii@XPJUG関西) 16
19. No Ticket, No Commit
名前 チケット無しのコミット不可
頻出場所 チケットの閉じ方
挿話証拠 「修正したソースがデグレードしたのは何故?」
問題 障害の記録と、成果物の作業履歴が同期されてない
状況 理由が分からないコミットが多い
解決法 ソースをコミットする時、チケットに変更理由を残してCloseする
ソースをコミットする時、チケットに変更理由を残してCloseする
Close
結果文脈 ・成果物の完成とチケットの完了が同期される
・要件から製品までのトレーサビリティが実現される
関連 ・No Ticket, No Release
プラクティス ・チケット無しのfolk mergeは許さない
・チケット無しのfolkやmergeは許さない
folkや
関連 ・肥満児チケット
アンチパターン ・曖昧な完了基準
(copyright2012 akipii@XPJUG関西) 19
21. タスクはチケットで分割統治
名前 Divide and Conquer
頻出場所 チケットの作り方
挿話証拠 「チケットは機能追加なのに、リファクタリングばかりしている」
問題 開発者が作業しやすいチケットの内容になっていない
状況 チケットの粒度がバラバラ
解決法 残課題や別作業はチケットを分割する
結果文脈 開発者が作業しやすくなり、開発のリズムが生まれる
関連 ・チケットの棚卸し
プラクティス ・No Ticket, No Commit
関連 ・肥満児チケット
アンチパターン ・Closeされないチケット
されないチケット
(copyright2012 akipii@XPJUG関西) 21
22. Iteration is Version
名前 イテレーションはバージョンに同一視
頻出場所 バージョンの登録・終了、チケットの分類
挿話証拠 「期日が守られないチケットが多いね」
問題 リリースが1回だけなので学生症候群になりやすい
状況 納期やマイルストーンがあるのに守られていない
解決法 イテレーションをリリースバージョンとして定期的にリリースする
結果文脈 リリース計画を立てて頻繁に改良できるようになる
関連 ・小規模リリース
プラクティス ・バックログ、Velocity
・バックログ、Velocity
関連 ・空っぽのロードマップ
アンチパターン Closeされないバージョン、工程単位のバージョン
・Closeされないバージョン、工程単位のバージョン
(copyright2012 akipii@XPJUG関西) 22
23. 小規模リリース
消化チケット
開発
規模
消化チケット
消化チケット
1 2 3 イテレーション
小刻みに機能拡張しながら定期的にリリースしていく
Velocity(開発速度
開発速度)=イテレーション単位の平均消化チケット数
開発速度
(copyright2012 akipii@XPJUG関西) 23
26. 問2. チケットの完了条件
停滞したチケット
進捗率90%のまま完了しない
チケットの進捗率と作業ステータスがアンマッチ
作業はほぼ完了したが、課題や仕様の不明点が残った
モンスターチケット
レビュー後の差し戻しが多い
成果物の完了条件の認識がPLとPGで異なる
ワークフローによって完了の定義が違う
タスクは成果物を完成したか否か
課題は解決できて、タスクに変換できたか否か
(copyright2012 akipii@XPJUG関西) 26
27. チケットの棚卸し
名前 Inventory of Tickets
頻出場所 チケットの整理
挿話証拠 「チケットがゴミ箱になっているね」
問題 チケットが最新化されない
状況 チケットが放置されて、開発速度が落ちる
解決法 定期的にチケットを整理して、リリース計画を最新化する
結果文脈 リリース計画が明確になり、チームのVelocityが安定する
リリース計画が明確になり、チームの が安定する
関連 ・開発のリズム
プラクティス ・バックログ
関連 ・チケットが不良在庫
アンチパターン ・停滞したチケット
(copyright2012 akipii@XPJUG関西) 27
28. ペア作業
名前 Pair Work
頻出場所 チケットの渡し方
挿話証拠 「バグ修正とバグ検証の連携作業が上手くいってないね」
問題 2人の連携作業の品質が悪い
人の連携作業の品質が悪い
状況 障害修正やレビュー等、2人のチェックが必要な作業
障害修正やレビュー等、 人のチェックが必要な作業
解決法 各担当者の作業状態にステータスを割り当ててワークフロー化
する
結果文脈 連携作業にキャッチボールのようなリズムが生まれる
関連 チケットはワークフローに従う
プラクティス
関連 足りないステータス
アンチパターン
(copyright2012 akipii@XPJUG関西) 28
29. チケットはワークフローに従う
名前 Tickets follow workflow
頻出場所 チケットの分類
挿話証拠 「顧客の問合せが今のチケットでは管理しにくいね」
問題 1種類のワークフローだけで全プロセスを管理しようとしている
種類のワークフローだけで全プロセスを管理しようとしている
状況 チケット駆動のプロジェクト運営だが、業務分析できていない
解決法 プロセスはワークフロー(チケットの種類 で制御する
プロセスはワークフロー チケットの種類)で制御する
チケットの種類
結果文脈 プロセス単位にチケットが発生し、検査されて完了する
関連 ・ペア作業
プラクティス ・チケット集計もワークフローに従う
関連 ・問合せはバグ修正なり
アンチパターン ・足りないステータス
(copyright2012 akipii@XPJUG関西) 29
30. チケット集計もワークフローに従う
チケット
集計
集計結果 ガントチャート 課題一覧
バグ収束曲線
EVM リスク一覧
ワークフロー タスク バグ 課題
チケット集計結果はワークフロー単位で意味を持つ
ワークフロー毎に分析したい観点は異なる
(copyright2012 akipii@XPJUG関西) 30
34. チケットは製品に従う
名前 Tickets follow a product
頻出場所 プロジェクトの登録・終了、チケットの分類
挿話証拠 「製品の障害チケットがどこに記録されたか分からない」
問題 チケットの集合(プロジェクト)
チケットの集合(プロジェクト)はどの単位にすべきか?
状況 チーム単位でチケット管理されて、チーム間の風通しが悪い
解決法 ・チケット管理はチーム単位ではなく製品単位にする
・製品の変更管理にチケットを関連付ける
結果文脈 ・製品ごとのタスク管理に沿った組織に変化する
・製品ごとのリリース計画が明確になる
関連 ・Conwayの法則 (アーキテクチャは組織構造に従う)
Conwayの法則 アーキテクチャは組織構造に従う)
プラクティス ・プロジェクトで分割統治
関連 ・アーキテクチャに対応しない複数チームのタスク管理
アンチパターン (copyright2012 akipii@XPJUG関西)
・工程単位のプロジェクト 34
35. Scrum of Scrum(又はCCB) 週次追跡
チーム間の課題の棚卸し会議
Scrumマスター(リーダー)同士でチーム横
断の課題を調整する
Scrumマスターが集合
マスターが集合 スクラムオブスクラム ステアリング
した課題管理会議
した課題管理会議 コミッティー
→「課題プロジェクト」
日次追跡
各チームの
「タスク管理プロ
ジェクト」 日次追跡 日次追跡 日次追跡
ScrumチームA ScrumチームB ScrumチームC
アジャイルコンポーネントチーム
(copyright2012 akipii@XPJUG関西) 35
36. チケット管理しやすい組織へ変化
TiDDはプロセスを定量化する手段を提供(見える化)
計画→実施→測定・評価という改善サイクルが生まれる
メンバーの役割が変わる(自己組織化)
リーダーは支援者になり、メンバーは自発的に作業し始める
従来型(WF) TiDD(Agile)
進捗管理
作業指示 課題解決
Excel
チケット
進捗報告
自発的に作業
ペア作業
(copyright2012 akipii@XPJUG関西) 36
37. その他のプラクティス(作成中)
チケット管理の観点 適用可能なプラクティス、概念
チケットの作り方 No Ticket, No Work
チケットの整理 チケットの棚卸し
チケットの閉じ方 No Ticket, No Commit
チケットの渡し方 ペア作業
チケットの分類 分割統治、 チケットはワークフローに従う
チケットの集計 チケット集計もワークフローに従う
ロールでビューを切り替える etc.
チケットの通知 私に聞くな、チケットに聞け(TiDD版ハリウッドの原則)
TiDD版ハリウッドの原則
版ハリウッドの原則)
チケットの並べ方 バックログ etc.
バージョンの作り方 Version is Iteration
プロジェクトの作り方 チケットは製品に従う
(copyright2012 akipii@XPJUG関西) 37