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.

RedmineとTracの機能比較~TiDDに必要な必須機能

12,830 views

Published on

第4.5回Shibuya.trac勉強会発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」(2009/9/11)
meeting/04.5 - Shibuya.trac Wiki - Shibuya.trac - SourceForge.JP
http://sourceforge.jp/projects/shibuya-trac/wiki/meeting%2F04.5

【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」: プログラマの思索 http://forza.cocolog-nifty.com/blog/2009/09/45shibuyatracre.html

Published in: Technology

RedmineとTracの機能比較~TiDDに必要な必須機能

  1. 1. RedmineとTracの機能比較 ~TiDDに必要な必須機能 2009/9/11 あきぴー@XPJUG関西 (copyright2009 akipii@XPJUG関西) 1
  2. 2. 自己紹介 HN:あきぴー 簡単な職歴 業務系Webシステムの開発部隊に所属 プログラミングからプロジェクト管理まで何でも 興味 チケット駆動開発(TiDD)、Redmine、TestLinkで アジャイル開発を改善する 活動コミュニティ XPJUG関西、SEA関西、TEF関西など (copyright2009 akipii@XPJUG関西) 2
  3. 3. Agenda アジャイル開発の特徴 アジャイル開発の課題 チケット駆動開発とは チケット駆動開発の運用 サイクル ポイント1:チケット ポイント :チケット ポイント2:ワークフロー ポイント :ワークフロー ポイント3:プロジェクト ポイント :プロジェクト ポイント4:イテレーション ポイント :イテレーション ポイント5:ソース管理と ポイント :ソース管理と 連携 ポイント6:レポート ポイント :レポート TiDDに必要な必須機能 に必要な必須機能 に必要な必須 TiDDのプラクティス のプラクティス まとめ (copyright2009 akipii@XPJUG関西) 3
  4. 4. アジャイル開発の特徴 超短期間の繰返し型開発 イテレーション単位に頻繁にリリースする(小規模リリース) 障害修正、改善要望のフィードバックに対応可能 リリース作業のリスクに早期に対応可能 開発作業の自動化 テスト駆動開発⇒単体テストの自動化 継続的インテグレーション⇒ビルド作業を自動化 メインラインモデルによる並行開発 新規開発(trunk)をリリース後、本番運用(branch)を生成する 障害修正はbranch、機能追加はtrunkに分けて品質を維持する アジャイル開発は複雑な構成管理インフラが必要! (copyright2009 akipii@XPJUG関西) 4
  5. 5. アジャイル開発の課題 頻繁に変わるタスク管理 頻繁なリリースの為イテレーション管理が大変 アナログのタスクボードだけでは進捗管理しづらい 継続的な修正による変更管理 継続的なリファクタリングや頻繁な機能追加を制御するのが難しい タスクボードによるステータス管理だけでは不十分 複数のコードラインを常時保守する並行開発 複数のコードラインの品質を保守するのは大変 Branchからtrunkへのマージ作業に手間がかかる チケット駆動開発(TiDD)は上記を解決するプロセスだ! は上記を解決するプロセスだ! チケット駆動開発 (copyright2009 akipii@XPJUG関西) 5
  6. 6. チケット駆動開発とは(1) BTSのチケットをXPのタスクカードのように使う XPのタスクカードをデジタル化する 障害も仕様変更も作業もチケットで扱う (Issue Tracking) 作業状態、進捗情報はチケットで一元管理 (copyright2009 akipii@XPJUG関西) 6
  7. 7. チケット駆動開発とは(2) ソースの変更はチケットと関連付ける 修正時にソースをチケットとリンクする 運用保守時にソース修正理由を追跡しやすい (copyright2009 akipii@XPJUG関西) 7
  8. 8. チケット駆動開発とは(3) 並行開発をチケットで管理する 新規開発(trunk)とその分岐である本番運用(branch)でチケット を使い分ける それぞれのチケットを連携させワークフロー管理する (copyright2009 akipii@XPJUG関西) 8
  9. 9. チケット駆動開発の運用サイクル (copyright2009 akipii@XPJUG関西) 9
  10. 10. チケット駆動開発の運用サイクル PL、PGの作業を チケットの状態遷移図 で管理できる (copyright2009 akipii@XPJUG関西) 9
  11. 11. 【1】チケット チケットは仕様書ですか? チケットはどれくらい詳細に書くべきか? チケットを乱発、放置しない運用の注意点は? チケットをXPのタスクカードのように扱う チケットは要件管理にも使えるはず(試行錯誤中) 1個の成果物を1~5人日以内に作る程度 複雑なタスク、遅延したタスクは分割統治 定期的にチケットの棚卸しを行う チケット保守担当者は現場リーダー (copyright2009 akipii@XPJUG関西) 10
  12. 12. 【1-1】Redmineチケット Redmine Ver 0.8.4 チケットの種類と番号 作業状態 リリースするバージョン マージ作業のチケット とリンクする (copyright2009 akipii@XPJUG関西) 11
  13. 13. 【1-1】Redmineチケット Redmine Ver 0.8.4 チケットの種類と番号 作業状態 リリースするバージョン チケットとソース がリンクする マージ作業のチケット とリンクする (copyright2009 akipii@XPJUG関西) 11
  14. 14. 【1-2】Tracチケット (copyright2009 akipii@XPJUG関西) Trac Ver 0.11.ja1 12
  15. 15. Trac Ver 0.11.ja1 【1-2】Tracチケット ・チケットの相互リンク機能がない (プラグインで対応可能) ・開始日/終了日/工数/進捗率の項目がない (trac.iniに追加可能) (copyright2009 akipii@XPJUG関西) 12
  16. 16. 【2】ワークフロー 課題管理や問合せ管理がやりにくいです。 いい方法はありませんか? ワークフローの種類を増やす 担当者の作業状態をステータスと対応づける ふりかえりMTでワークフローを見直そう (copyright2009 akipii@XPJUG関西) 13
  17. 17. 【2-1】Redmineワークフロー (copyright2009 akipii@XPJUG関西) 14
  18. 18. 【2-1】Redmineワークフロー ソフトウェア開発のワークフローは BTSのワークフロー機能で 制御できる ユーザ権限と チケット種類の単位で ステータスの現在・移行先を 指定する ステータスの移行先 現 在 の ス テ ー タ ス (copyright2009 akipii@XPJUG関西) 14
  19. 19. 【2-2】Tracワークフロー (copyright2009 akipii@XPJUG関西) 15
  20. 20. 【2-2】Tracワークフロー 【trac.iniのワークフロー設定】 のワークフロー設定】 [ticket-workflow] accept = new -> assigned accept.name = 着手する accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY leave = * -> * leave.default = 1 leave.name = 更新しない leave.operations = leave_status reassign = new,assigned,reopened -> new reassign.name = 担当者変更 reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reopen = closed -> reopened reopen.name = 差し戻す reopen.operations = del_resolution reopen.permissions = TICKET_CREATE resolve = new,assigned,reopened -> closed resolve.name = 解決にする resolve.operations = set_resolution resolve.permissions = TICKET_MODIFY ・Trac.iniのワークフロー設定を修 正するのは難しい ・チケットの種類に応じてワークフ ローを増やせない(プラグインで対 応可能) (copyright2009 akipii@XPJUG関西) 15
  21. 21. 【3】プロジェクト 複数プロジェクト機能はどのように使うべきか? 大規模案件でもTiDDを運用できるか? 5人以下のサブチーム単位でプロジェクトを作る コードライン/モジュール/ワークフロー等の単位で分割する 大規模プロジェクトでは、チケット管理だけのリーダーを置く チケットの棚卸しは課題管理会議で決定する(試行錯誤中) 並行開発のタスク管理には複数プロジェクト機能が必須 (copyright2009 akipii@XPJUG関西) 16
  22. 22. 【3-1】Redmineプロジェクト プロジェクトの親子関係を 作れる プロジェクトを選択できる ↓ branch、顧客問合せ用は 別プロジェクトにする 終了したプロジェクトは 非公開にできる (copyright2009 akipii@XPJUG関西) 17
  23. 23. 【3-1】Redmineプロジェクト プロジェクトの親子関係を 作れる プロジェクトを選択できる ↓ branch、顧客問合せ用は 別プロジェクトにする サブプロジェクトのサマリを 親プロジェクトと関連付ける 終了したプロジェクトは 非公開にできる (copyright2009 akipii@XPJUG関西) 17
  24. 24. 【3-2】Tracプロジェクト ・単一プロジェクトのみ ・プラグインで複数プロジェクト対応 (copyright2009 akipii@XPJUG関西) 18
  25. 25. 【4】イテレーション マイルストーンとバージョンの違いは? TiDDをアジャイル開発に適用する注意点は? マイルストーンは進捗報告のタイミング バージョンはリリースのタイミング アジャイル開発ではロードマップをイテレーション計画と見なす イテレーションをリリース予定のバージョンで管理する 小刻みにリリースしながら終了チケットをリリース履歴として残す →小規模リリース (copyright2009 akipii@XPJUG関西) 19
  26. 26. 【4-1】Redmineバージョン ・ロードマップ機能はRedmineが最 も優れている ・イテレーションとバージョンを同一 視するのがミソ ・変更履歴はイテレーションごとの終 了チケットの履歴になる (copyright2009 akipii@XPJUG関西) 20
  27. 27. 【4-1】Redmineバージョン ・ロードマップ機能はRedmineが最 も優れている ・イテレーションとバージョンを同一 視するのがミソ ・変更履歴はイテレーションごとの終 了チケットの履歴になる (copyright2009 akipii@XPJUG関西) 20
  28. 28. 【4-2】Tracマイルストーン (copyright2009 akipii@XPJUG関西) 21
  29. 29. 【4-2】Tracマイルストーン ・マイルストーンとバージョンは厳密に 区別されている ・マイルストーンの終了日を過ぎたら、 ロードマップから消える (copyright2009 akipii@XPJUG関西) 21
  30. 30. 【5】ソース管理と連携 チケットとソースを連携する方法は? ソース管理と連携しなくていいですか? SVNコミットログに「refs」「fixes」とチケットNoを書く 「fixes #チケットNo」でステータスと進捗率も更新できる ソース管理と連携しない場合、タスク管理だけのTiDD 「チケット無しのコミット不可」のルールを徹底するのが重要 リリース履歴がチケット経由でソース修正履歴になる (copyright2009 akipii@XPJUG関西) 22
  31. 31. ・リモートSCMをサポート! ・SVN以外のSCM(CVS, Git, Mercurial等)と連携可能 (copyright2009 akipii@XPJUG関西) 23
  32. 32. 「fixes #チケットNo」とコミットログに書くと、進捗率やス テータスを自動更新してくれる ⇒ソース管理連携はRedmineが最も優れている ・リモートSCMをサポート! ・SVN以外のSCM(CVS, Git, Mercurial等)と連携可能 (copyright2009 akipii@XPJUG関西) 23
  33. 33. VersioningSystemBackend – The Trac Project http://trac.edgewall.org/wiki/VersioningSystemBackend ・リモートSCMをサポートしない ・SVN以外のSCM(CVS, Mercurial 等)と連携できない(プラグインで対応 可能) (copyright2009 akipii@XPJUG関西) 24
  34. 34. 【6】レポート MSProjectの進捗管理とチケット駆動開発のタス ク管理が連携しにくいです。何故でしょうか? 進捗報告を自動生成できないですか? 顧客向けの進捗報告はストーリーカードの単位 TiDDの進捗報告はタスクカードの単位 BTSのチケット集計機能を活用する チケット入力さえ徹底できれば意思決定情報を出力できる (copyright2009 akipii@XPJUG関西) 25
  35. 35. ・Tracのようなクエリ機能がない ・工数集計の機能が弱い (copyright2009 akipii@XPJUG関西) 26
  36. 36. ・Tracのようなクエリ機能がない ・工数集計の機能が弱い (copyright2009 akipii@XPJUG関西) 26
  37. 37. レポート出力機能はTracが最 も優れている ↓ 工数集計も可能 (copyright2009 akipii@XPJUG関西) 27
  38. 38. レポート出力機能はTracが最 も優れている ↓ 工数集計も可能 (copyright2009 akipii@XPJUG関西) 27
  39. 39. 【番外編】Mantis (Ver 1.1.8) ・複数プロジェクト対応 ・ロードマップ+変更履歴を表示 ⇒Tracよりも機能が多く使いやすい? (copyright2009 akipii@XPJUG関西) 28
  40. 40. TiDDに必要な必須機能 チケットを障害も要望も作業にも扱う(Issue Tracking) チケットをXPのタスクカードのように扱う 柔軟なワークフロー管理機能 インシデントや課題管理はバグ修正フローと異なる 一目で進捗が分かるロードマップ 一目で進捗が分かるロードマップ ロードマップをイテレーション計画に使う 終了チケットの履歴はリリース履歴として残る 複数プロジェクト機能 branchや顧客問合せは別プロジェクトに管理する チケットとソース管理を連携する 要件から成果物までのトレーサビリティを保証する レポート出力 チケット集計結果から出力された進捗や品質のメトリクスを意思決定に使う (copyright2009 akipii@XPJUG関西) 29
  41. 41. TiDDに必要な必須機能 チケットを障害も要望も作業にも扱う(Issue Tracking) チケットをXPのタスクカードのように扱う TiDDをタスク管理にする機能 をタスク管理にする機能 柔軟なワークフロー管理機能 インシデントや課題管理はバグ修正フローと異なる 一目で進捗が分かるロードマップ 一目で進捗が分かるロードマップ TiDDをアジャイル化する機能 をアジャイル化する機能 ロードマップをイテレーション計画に使う 終了チケットの履歴はリリース履歴として残る 複数プロジェクト機能 branchや顧客問合せは別プロジェクトに管理する チケットとソース管理を連携する 要件から成果物までのトレーサビリティを保証する レポート出力 チケット集計結果から出力された進捗や品質のメトリクスを意思決定に使う (copyright2009 akipii@XPJUG関西) 29
  42. 42. TiDDのプラクティス キャッチフレーズは「タスクはチケットに分割して統治せよ」 タスクはチケットに分割して統治せよ タスクはチケットに分割して統治せよ チケット・ファースト(Ticket First) チケット・ファースト プロジェクトの作業はチケットを受け取ってから始める チケット無しで成果物の更新不可 チケットで分割統治(Divide and Conquer) チケットで分割統治 チケットの粒度は追跡可能なタスクまで細分化する バージョン毎にチケットをグループ化してまとめる 小規模リリース(Small Releases) 小規模リリース バージョン毎に小さく作って小刻みにリリースする リリース結果は終了チケットの履歴として残る ふりかえり(Retrospect) ふりかえり チケット集計結果からワークフローの運用などを次バージョンで改善しよう (copyright2009 akipii@XPJUG関西) 30
  43. 43. TiDDのプラクティス キャッチフレーズは「タスクはチケットに分割して統治せよ」 タスクはチケットに分割して統治せよ タスクはチケットに分割して統治せよ TiDDの基本プラクティス の チケット・ファースト(Ticket First) チケット・ファースト プロジェクトの作業はチケットを受け取ってから始める チケット無しで成果物の更新不可 PLが意識すべきプラクティス が意識すべきプラクティス チケットで分割統治(Divide and Conquer) チケットで分割統治 チケットの粒度は追跡可能なタスクまで細分化する バージョン毎にチケットをグループ化してまとめる TiDDをアジャイル化するプラクティス をアジャイル化するプラクティス をアジャイル化 小規模リリース(Small Releases) 小規模リリース バージョン毎に小さく作って小刻みにリリースする リリース結果は終了チケットの履歴として残る ふりかえり(Retrospect) ふりかえり TiDDをファシリテーション化するプラクティス を チケット集計結果からワークフローの運用などを次バージョンで改善しよう (copyright2009 akipii@XPJUG関西) 30
  44. 44. まとめ TiDDはBTSに依存しないアジャイル開発 Redmine/Trac/Mantis等でも運用可能 BTSのプロジェクト管理機能をアジャイル開発へ応用する TiDDをプロジェクト運営支援システムへ機能強化したい PGはチケットが進捗報告代わり PLはチケット集計機能で得られた進捗/品質情報を意思決定に使う TiDDを日本発のアジャイル開発へ発展させたい! 運用事例からベストプラクティスをまとめたい 謝辞 勉強会を準備して頂いたShibuya.tracの方々 TiDDについて議論してくれたXPJUG関西の皆さん (copyright2009 akipii@XPJUG関西) 31

×