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

19,621 views

Published on

【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 #47redmine: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/11/4redmine-47redm.html

第4回勉強会 - shinagawa.redmine
http://shinagawa.redmine.r-labs.org/projects/shinared/wiki/第4回勉強会

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
19,621
On SlideShare
0
From Embeds
0
Number of Embeds
15,037
Actions
Shares
0
Downloads
0
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

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

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

×