Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
チケット駆動開発のフレームワーク現場の経験知からパターン言語へ                                     ダイジェスト版                あきぴー@RxtStudy    (copyright2012...
出版しました    現在絶賛販売中!     (copyright2012 akipii@XPJUG関西)   2
TiDDの基本的な課題(1)   チケット駆動とは何か、何を価値とするのか、        単純な原則を抽出して     改めて体系づけ直すべきではないか。                     http://www.amazon.co.jp...
TiDDの基本的な課題(2) @yusuke_arclamp: チケットの「出し方や受け方や閉じ方」 「しまい方や並べ方」には間違いなくパターンがありますね。 対象物についても類型化できるでしょうし。 もちろんアンチパターンもありますね。   ...
体系化の方針1. ツールの説明を排除   TiDDはツールに依存しない   RedmineでもPostItでもチケット駆動は運用可能2. プラクティスをパターン言語の形式で表現   現場の経験知と常識を拠り所   特定の状況の問題に対して有効な...
TiDDの体系の構造    の体系の構造チケット駆動開発                                    ダイジェストで     原則                             ざっくり話します     価値...
TiDDの原則・価値    (copyright2012 akipii@XPJUG関西)   7
TiDDの原則 原則とは   価値とプラクティスの領域における不変のルール1. 最初にチケットありき (Ticket First)   SW開発の作業も課題も障害もチケットへ   チケット無しの作業不可 (No Ticket, No Work)...
チケットとは                   チケット     タスク    障害          課題                問合せ     要望1.   製品の変更時に管理すべき対象プロセス(チケットは製品に従う)      ...
構成管理とは                                製品(ビルドラベル付                                製品 ビルドラベル付)                               ...
価値とは何が望ましく何がふさわしくないのかという基準チケットの取捨選択に関わる判断基準価値を実現するためにプラクティスを実践する   価値         コミュニケーション              フィードバック              ...
TiDDの価値一覧(作成中)  価値             望ましい行動                            ふさわしくない行動コミュニケーション ・障害状況を常に共有                      ・空中戦の議...
TiDDによるパラダイムシフト従来のWF開発                    チケット駆動開発      品質                       コスト               納期コスト        納期        ...
TiDDのプラクティス    (copyright2012 akipii@XPJUG関西)   14
プラクティスとは  現場で実証された実践技法      プラクティスは価値に基づく行動を促す  パターン言語で表現してみる      特定の状況(context)の問題(problem)における解決法(solution)名前・別名       ...
No Ticket, No Commit名前       チケット無しのコミット不可頻出場所     チケットの閉じ方挿話証拠     「ソースが修正された変更理由を誰か知ってますか?」問題       障害の記録はあるが、実装された成果物に紐...
Iteration is Version名前        イテレーションはバージョンに同一視頻出場所      バージョンの登録・終了、チケットの分類挿話証拠      「開発にリズムがなくて、残業や休日出勤が多すぎだ」問題        リ...
小規模リリース                                   消化チケット開発規模                消化チケット     消化チケット         1            2              ...
開発のリズムチケットの作業に集中(Scrumの集中) 割り込み作業はしないコミットのリズム コミットと同時にチケットをCloseする(No Ticket, No Commit)定期的にリリースする 適切で持続可能な開発ペース(Velocity)...
チケットはワークフローに従う名前        Tickets follow workflow頻出場所      チケットの分類挿話証拠      「顧客の問合せが今のチケットでは管理しにくいね」問題        1種類のワークフローだけで全...
チケット集計もワークフローに従う                          チケット                 集計集計結果   ガントチャート                                課題一覧       ...
チケットは製品に従う名前        Tickets follow a product頻出場所      プロジェクトの登録・終了、チケットの分類挿話証拠      「製品の障害チケットがどこに記録されたか分からない」問題        チケ...
チケット管理しやすい組織へ変化 TiDDはプロセスを定量化する手段を提供(見える化)    計画→実施→測定・評価という改善サイクルが生まれる メンバーの役割が変わる(自己組織化)    リーダーは支援者になり、メンバーは自発的に作業し始める ...
その他のプラクティス(作成中)チケット管理の観点    適用可能なプラクティス、概念チケットの作り方     No Ticket, No Workチケットの最新化     チケットの棚卸しチケットの閉じ方     No Ticket, No C...
続きは品川Redmineで2012/11/10(土) 品川Redmine勉強会 at 東京                                丸山さん(Redmineコミッタ)、                           ...
コミュニティでTiDDのプラクティスを創り出していきましょう      ご清聴  ありがとうございました    (copyright2012 akipii@XPJUG関西)   26
Upcoming SlideShare
Loading in …5
×

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

4,783 views

Published on

【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/10/6rxtstudy-rxt-1.html
第6回RxTstudy : ATND
http://atnd.org/events/31719

Published in: Technology
  • Be the first to comment

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

  1. 1. チケット駆動開発のフレームワーク現場の経験知からパターン言語へ ダイジェスト版 あきぴー@RxtStudy (copyright2012 akipii@XPJUG関西) 1
  2. 2. 出版しました 現在絶賛販売中! (copyright2012 akipii@XPJUG関西) 2
  3. 3. TiDDの基本的な課題(1) チケット駆動とは何か、何を価値とするのか、 単純な原則を抽出して 改めて体系づけ直すべきではないか。 http://www.amazon.co.jp/dp/4798125067TiDDの原則や価値とは何か? 暗黙的に判断している基準(価値観、原則)を明確にしたい (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. 構成管理とは 製品(ビルドラベル付 製品 ビルドラベル付) ビルドラベル付 リリースタグ付与 リリースメインライン(trunk) #10 release ソフトウェア資産を管理する仕組み ソフトウェアの変更を記録する(成果物は構成管理に従う) 成果物は構成管理に従う) 定期的にリリース可能なソフトウェア(資産)にラベル付け(名前 名前 が付けられた安定したバージョン) が付けられた安定したバージョン リポジトリにリリースタグを付与(Iteration is version) 製品にビルド番号を付与 (copyright2012 akipii@XPJUG関西) 10
  11. 11. 価値とは何が望ましく何がふさわしくないのかという基準チケットの取捨選択に関わる判断基準価値を実現するためにプラクティスを実践する 価値 コミュニケーション フィードバック コミットメント オープン 勇気 (copyright2012 akipii@XPJUG関西) 11
  12. 12. TiDDの価値一覧(作成中) 価値 望ましい行動 ふさわしくない行動コミュニケーション ・障害状況を常に共有 ・空中戦の議論 ・チームを超えて自発的行動 オープン ・作業を見える化する ・作業を見える化する 見える化 (@g_maeda g_maeda) ・ヤミ作業 (@g_maeda) ・やるべきことを明確にする(バッ クログ) クログ)コミットメント ・担当したチケットを完了する ・チケットを放置する ・イテレーション終了時にリリー ・リーダーが課題を解決しない スするフィードバック ・ユーザや開発者の意見を受け ・大量のフィードバックをさばけ 入れる ない ・運用を改善する ・ふりかえりをしない 勇気 ・チケットを捨てる ・無気力 ・作業の阻害要因を打破する ・無関心 (copyright2012 akipii@XPJUG関西) 12
  13. 13. TiDDによるパラダイムシフト従来のWF開発 チケット駆動開発 品質 コスト 納期コスト 納期 スコープ品質、コスト、納期は固定 コスト、納期は固定 →納期は分割リリース   スコープ(チケット)を調整 チケットの取捨選択でスコープ管理する   変化に強いタスク管理が運用可能 (copyright2012 akipii@XPJUG関西) 13
  14. 14. TiDDのプラクティス (copyright2012 akipii@XPJUG関西) 14
  15. 15. プラクティスとは 現場で実証された実践技法 プラクティスは価値に基づく行動を促す パターン言語で表現してみる 特定の状況(context)の問題(problem)における解決法(solution)名前・別名 プラクティス名。別の名称。頻出場所 プラクティスが出現する工程、作業挿話証拠 問題が発生する状況でよく見聞きする言動問題 プラクティスで解決しようとする問題 プラクティスで解決しようとする問題状況(文脈状況 文脈) 文脈 問題が発生する状況。プラクティスを適用すべき状況。 問題が発生する状況。プラクティスを適用すべき状況。 プラクティス解決法 問題を取り除くための解決方法結果文脈 プラクティスで解決した後に変化した状況 プラクティスで解決した後に変化した状況関連プラクティス 関連するプラクティス関連アンチパターン 頻出する望ましくない状況や問題のパターン (copyright2012 akipii@XPJUG関西) 15
  16. 16. No Ticket, No Commit名前 チケット無しのコミット不可頻出場所 チケットの閉じ方挿話証拠 「ソースが修正された変更理由を誰か知ってますか?」問題 障害の記録はあるが、実装された成果物に紐付いていない状況 実装された意図が忘れ去られた解決法 ソースをコミットする時にチケットへ変更理由を残す結果文脈 ・要件から製品までのトレーサビリティが実現される ・チケットの完了条件に成果物の完成も含まれる関連 ・チケット無しのfolkやmergeは許さない ・チケット無しのfolkやmergeは許さない folkプラクティス ・No Ticket, No Release関連 ・デグレードアンチパターン ・曖昧な完了基準 (copyright2012 akipii@XPJUG関西) 16
  17. 17. Iteration is Version名前 イテレーションはバージョンに同一視頻出場所 バージョンの登録・終了、チケットの分類挿話証拠 「開発にリズムがなくて、残業や休日出勤が多すぎだ」問題 リリースが1回だけなので学生症候群になりやすい状況 納期やマイルストーンがあるのに守られていない解決法 イテレーションをリリースバージョンとして定期的にリリースする結果文脈 リリース計画を立てて頻繁に改良できるようになる関連 ・小規模リリースプラクティス ・バックログ、Velocity ・バックログ、Velocity関連 ・空っぽのロードマップアンチパターン Closeされないバージョン、工程単位のバージョン ・Closeされないバージョン、工程単位のバージョン (copyright2012 akipii@XPJUG関西) 17
  18. 18. 小規模リリース 消化チケット開発規模 消化チケット 消化チケット 1 2 3 イテレーション  小刻みに機能拡張しながら定期的にリリースしていく   Velocity(開発速度 開発速度)=イテレーション単位の平均消化チケット数 開発速度 (copyright2012 akipii@XPJUG関西) 18
  19. 19. 開発のリズムチケットの作業に集中(Scrumの集中) 割り込み作業はしないコミットのリズム コミットと同時にチケットをCloseする(No Ticket, No Commit)定期的にリリースする 適切で持続可能な開発ペース(Velocity)定期的なイベントで検査 毎日の朝会 毎週の棚卸し会 リリースごとにふりかえり (copyright2012 akipii@XPJUG関西) 19
  20. 20. チケットはワークフローに従う名前 Tickets follow workflow頻出場所 チケットの分類挿話証拠 「顧客の問合せが今のチケットでは管理しにくいね」問題 1種類のワークフローだけで全プロセスを管理しようとしている 種類のワークフローだけで全プロセスを管理しようとしている状況 チケット駆動のプロジェクト運営だが、業務分析できていない解決法 プロセスはワークフロー(チケットの種類 で制御する プロセスはワークフロー チケットの種類)で制御する チケットの種類結果文脈 プロセス単位にチケットが発生し、検査されて完了する関連 ・ペア作業プラクティス ・チケット集計もワークフローに従う関連 ・問合せはバグ修正なりアンチパターン ・足りないステータス (copyright2012 akipii@XPJUG関西) 20
  21. 21. チケット集計もワークフローに従う チケット 集計集計結果 ガントチャート 課題一覧 バグ収束曲線 EVM リスク一覧ワークフロー タスク バグ 課題 チケット集計結果はワークフロー単位で意味を持つ ワークフロー毎に分析したい観点は異なる (copyright2012 akipii@XPJUG関西) 21
  22. 22. チケットは製品に従う名前 Tickets follow a product頻出場所 プロジェクトの登録・終了、チケットの分類挿話証拠 「製品の障害チケットがどこに記録されたか分からない」問題 チケットの集合(プロジェクト) チケットの集合(プロジェクト)はどの単位にすべきか?状況 チーム単位でチケット管理されて、チーム間の風通しが悪い解決法 ・チケット管理はチーム単位ではなく製品単位にする ・製品の変更管理にチケットを関連付ける結果文脈 ・製品ごとのタスク管理に沿った組織に変化する ・製品ごとのリリース計画が明確になる関連 ・Conwayの法則 (アーキテクチャは組織に従う) Conwayの法則 アーキテクチャは組織に従う)プラクティス ・プロジェクトで分割統治関連 ・アーキテクチャに対応しない複数チームのタスク管理アンチパターン (copyright2012 akipii@XPJUG関西) ・工程単位のプロジェクト 22
  23. 23. チケット管理しやすい組織へ変化 TiDDはプロセスを定量化する手段を提供(見える化) 計画→実施→測定・評価という改善サイクルが生まれる メンバーの役割が変わる(自己組織化) リーダーは支援者になり、メンバーは自発的に作業し始める 従来型(WF) TiDD(Agile)進捗管理作業指示 課題解決Excel チケット進捗報告 自発的に作業 ペア作業 (copyright2012 akipii@XPJUG関西) 23
  24. 24. その他のプラクティス(作成中)チケット管理の観点 適用可能なプラクティス、概念チケットの作り方 No Ticket, No Workチケットの最新化 チケットの棚卸しチケットの閉じ方 No Ticket, No Commitチケットの渡し方 ペア作業チケットの分類 分割統治、 チケットはワークフローに従うチケットの集計 チケット集計もワークフローに従う ロールでビューを切り替える etc.チケットの通知 私に聞くな、チケットに聞け(TiDD版ハリウッドの原則) TiDD版ハリウッドの原則 版ハリウッドの原則)チケットの並べ方 バックログ etc.バージョンの作り方 Version is Iterationプロジェクトの作り方 チケットは製品に従う (copyright2012 akipii@XPJUG関西) 24
  25. 25. 続きは品川Redmineで2012/11/10(土) 品川Redmine勉強会 at 東京 丸山さん(Redmineコミッタ)、 岡本隆史さん(@LightningX)、 小久保さん(@yusuke_kokubo) も講演されます! (copyright2012 akipii@XPJUG関西) 25
  26. 26. コミュニティでTiDDのプラクティスを創り出していきましょう ご清聴 ありがとうございました (copyright2012 akipii@XPJUG関西) 26

×