チケット管理システム大決戦第二弾

65,379 views

Published on

6/30に実施したShibuya.trac第12回勉強会チケット管理システム大決戦第二弾の資料です。

Published in: Technology

チケット管理システム大決戦第二弾

  1. 1. チケット管理システム 大決戦 第二弾 2011/6/30 Shibuya.trac 第12回勉強会flickr.com/photos/11226747@N07/4450250126/
  2. 2. 本日の目次• 自己紹介 (10分)• テーマ1 (40分) – そのツールの良いところ(気にいってるところ)と ダメなところ• テーマ2 (40分) – そのツールをどのように開発プロセスに組み込ん でいるか• テーマ3 (20分) – チケット管理システムの運用方法• 質疑応答 (20分)
  3. 3. 本日の登壇者のご紹介
  4. 4. @kanu_ - かぬ • 名前:かぬ • 出身:北海道(関東在住の方が長くなりました) • 職業:某物流企業の子会社SIer勤務 • 所属:品質管理(主はプロセス管理・改善) 現在はパートタ゗ムでScrum Master@kanu_ かぬ • Shibuya.tracメンバー • Trac Lightning/Kanon コミッター • 認定スクラムマスター (2010年6月受講) • Twitter : @kanu_ blog : d.hatena.ne.jp/kanu-orz
  5. 5. BTS/ITSの遍歴 • Trac歴 5年 – 2006年~ :自身の持つ保守案件で利用開始 – 2007年~ :保守部隊での顛末管理に利用開始 – 2009年~ :全社での進捗報告レポートとしての利用推進開始 – 2011年~ :Scrumプロジェクト(トラ゗ヤル)での利用開始@kanu_ かぬ • 利用経験のあるBTS/ITS – 影舞(2004~2006) • 外部常駐中に自社部隊との不具合・要望などの案件管理用 – Redmine(2009) • 他部署のお手伝い-頓挫 – Sourceforge.jp • Shibuya.tracで利用中
  6. 6. @haradakiro – 原田騎郎 • わらじ三足 – SCM コンサルタント(ソースコードじゃなくてサプラ ゗チェーン) – ドメ゗ンモデラ(DDD なのでコードも書くよ) – ゕジャ゗ルコーチ(認定スクラムプロフェショナル)@haradakiro 原田 • 株式会社 情報システム総研 • 株式会社 Odd-e Japan @haradakiro http://www.facebook.com/harada.kiro/
  7. 7. @haradakiro – 原田騎郎 • Trac 使うまで – 2003 年頃 – SI所属 SourceForge EE 3 系を使う – 2004 年頃 – YukiWiki/PukiWiki とか – 2005 年頃 – Buildix 日本語通らない ;_;@haradakiro 原田 – 2006 年頃 – Trac 月と出会う • Trac 使ってから – 2007 年以降 – プロジェクトは始めるまえに Trac 作ってから考える – 2008 年以降 – 現職場に転社 Trac は全部゗ンター ネット上へ。素の Trac を使うことが多い
  8. 8. @daipresents – Dai Fujihara アーキテクチャ&コアテクノロジー課所属 標準化とかライブラリ開発をするチームで@daipresents リーダーみたいなことやってます 沖縄の離島巡りが好き Web : http://daipresents.com/Fujihara About Redmine 2006 ~ 2008は受託開発でTrac利用 2009 ~ 2010は個人でRedmineを使って社内展開 きっかけはRubyの勉強がしたかったから
  9. 9. @takanafu - 関 崇匡 • エンタープラ゗ズ系のこてこてなウォーターフォールPJ から研究開発などのゕジャ゗ルPJなんかで技術支援や標 準化をやってます • Adobe Flex ゗ンストラクター • 株式会社 ゕドヴゔンスト・ソフト・エンジニゕリング@takanafu 関 • RedmineLE(redmineのTracLightningみたいなもの) をひっそりと公開中 http://sourceforge.jp/projects/redminele/ • http://d.hatena.ne.jp/takanafu/ (5日坊主) • 4年前くらいから利用開始。その他にはTrac、Bugzilla、 JIRAなどいろんなものを使っていた。
  10. 10. @ohnuki – 大貫 浩 • JIRAを中心にしたソフト開発ツールのコンサル – 提案~実装~サポートまでいろいろやってます – IDE好きなプログラマ。CとJavaを10年。最近はExt.JS – あと仮想化とThinkPadが好き。 – そして全てが洗練されたAppleより、全サービスのUI@ohnuki 大貫 がバラバラなGoogleが好き。 • JIRA(Atlassian)との関わり – 2007~ Apache Geronimoの翻訳プロジェクトで Atlassian JIRAとConfluence知る – 2009~ AtlassianパートナーとなってJIRA販売 – 2011 ~ 売上が受託開発とAtlassianビジネスで逆転
  11. 11. @yusukey - 山本 裕介 • オープンソースデベロッパ • Twitter4J、”侍” などを開発 • Twitter APIポケットリフゔレンス – 7月15日発売、予約受付中!@yusukey 山本 http://samuraism.jp/ @yusukey
  12. 12. @yusukey - 山本 裕介 • Jira歴 6年(2006年~) – 2006年~: Pebble(ブログソフト)コントリビュータ – 2007年~: Twitter4J 開発 • Jira以外のチケット管理システム利用経験@yusukey 山本 – 2002年~: Clarify CRM(BEA Systems) – 2006年~: Numara Footprints(Fast Search&Transfer) – 2007年~: Trac – 2007年~: Bugzilla – Excel(現在とあるプロジェクトで) – Scarab(評価したことがあるだけ)
  13. 13. @ikikko - 中村知成 • 中村知成 (@ikikko, id:ikikko) • 所属 本社:福岡 拠点:東京・京都 – 株式会社ヌーラボ – Shibuya.trac、日本Jenkinsユーザ会@ikikko 中村 • 半分中の人 – Backlogの開発に直接携わってはいません – 一番近いヘビーユーザ • 今日は、ヌーラボで携わっているプロジェクト からいくつか取り上げてお話します
  14. 14. Backlogとは@ikikko 中村 • エンジニゕ以外もターゲット層 – デザ゗ナー – 翻訳者 – 経理・事務担当 など • メ゗ンはASPサービス
  15. 15. @ikeike443 • 池田尚史(いけだたかふみ) • 株式会社シャノン@ikeike443 池田 • Jenkinsプラグ゗ン開発者 • Play! framework 好き
  16. 16. BTS利用遍歴 • 2001~2004:Excel • 2005~2008:独自ツール • 2008~2009:Trac • 2010~Now :Backlog@ikeike443 池田
  17. 17. @Ryuzee – Ryutaro YOSHIBA • アジャイルコーチ • 認定スクラムプロフェショナル(CSP) • 認定スクラムマスター(CSM) • 認定スクラムプロダクトオーナー(CSPO)@Ryuzee YOSHIBA • Shibuya.tracのスタッフ • スクラム道の共同設立者 • Scrum Boot Camp発案者 • TIS,野村総合研究所を経てベンチャーのCTO • http://www.ryuzee.com
  18. 18. テーマ1各ツールの良いところと悪いところ
  19. 19. 良いところ • SQLを用いた柔軟なレポート • Trac Lightningの存在@kanu_ かぬ • Shibuya.tracの存在 • 豊富なプラグ゗ン • 無料であること
  20. 20. SQLを用いた柔軟なレポート Tracのみでワンストップなプロジェクトの可視化が可能。@kanu_ かぬ
  21. 21. Trac Lightningの存在 • Trac+svn+maven+Jenkinsが5分で構築可能 • クラ゗ゕントPCで手軽に試すことが可能 – Linux向けにはKanonも登場@kanu_ かぬ
  22. 22. Shibuya.tracの存在 • Tracをきっかけにして、似た悩みを持つ開発者 同士が悩みを共有し繋がることが出来る場 • Tracに限らず、DVCSやゕジャ゗ル、CIなどに ついても悩みを分かち合うことが出来る。@kanu_ かぬ
  23. 23. 豊富なプラグイン • シンプルな本体を強化する多くのプラグ゗ン – Trac-hacksだけでも500を遙かに超えるWikiマクロ やプラグ゗ン。 – Version Upへの追従も、実績による安心感@kanu_ かぬ
  24. 24. 無料であること • サーバーとOSさえ用意できれば無料で利用可能 • 利用が拡大してもラ゗センスのコスト増が無い。@kanu_ かぬ
  25. 25. 残念なところ • プラグ゗ンを入れないと貧弱 • 操作感、統一感が゗マ゗チ@kanu_ かぬ • Reportは意外と大変 • 最も残念なのは・・・
  26. 26. プラグインを入れないと貧弱 • Trac Lightningに同梱の プラグ゗ンは45個 – 素のTracからこの状態を 作るのは困難@kanu_ かぬ • ワークフローのWeb-UI編集 に決定打が無い – ワークフローのWeb-UI編集に は定番がない。 – 結局、INIの編集が一番確実 http://www.flickr.com/photos/oogoom/3541084081/
  27. 27. 操作感、統一感がイマイチ • 漢らしいともいわれる操作感 – JIRAやRedmineと比較すると 一世代前な感じは否めない • プラグ゗ンで機能強化可能な反面、 全体としての統一感に欠ける。@kanu_ かぬ – ただしAgilo、ciklone除く http://www.agile42.com/en/agilo/ http://ciklone.com/ http://www.flickr.com/photos/shvmoz/2310971713/
  28. 28. Reportは意外と大変 • SQLは便利だが作るのは骨が折れる@kanu_ かぬ
  29. 29. Tracの最も残念なこと • Rubyではないこと – Shibuya.tracのOSCのブースなどで、 「仕事がRubyなんでRedmine使ってます。 TracってPythonなんですよね?」@kanu_ かぬ と非常に多くの人から言われる。 もしTracがRuby on Railsだったら・・・ もしPythonが日本でもっと流行していたら・・・
  30. 30. @haradakiro – Trac の良いところ • ゗ンストールが簡単 – TracLightning だとさらに簡単 (Thanks a LOT!!) • デフォルト設定で、ふつうに使える@haradakiro 原田 • Python だった – 昔 Ruby の環境をいじると怒られたりしたけれど、 Python は誰も使ってなかったので問題なかった 
  31. 31. @haradakiro – Trac の悪いところ • 行儀の悪いプラグ゗ンが沢山いる(いた?) – いれると収拾つかなくなることが多い • バージョンゕップのときとか • プラグ゗ンのゕン゗ンストールではまったことが何度か@haradakiro 原田 – ときどき sqlite が壊れる • PostgreSQL にしてバックゕップしているけど、こんどは゗ ンストールが面倒 • 複数プロジェクトで゗ンスタンスを増やしてし まうと管理が面倒
  32. 32. Redmineの良いところ @daipresents Fujihara
  33. 33. Redmineの良いところとダメなところ • 良いところ – (RedmineLEを使えば)゗ンストールが簡単 – 簡単なプラグ゗ンはすぐ作れる – とことんまでカスタマ゗ズできる ワークフロー系システムのバックエンドとして活用@takanafu 関 – しやすい(社内稟議システムで活用) – プラグ゗ンが充実している – 複数プロジェクトやプラ゗ベートチケットなど便利 な機能がデフォルトでたくさんある
  34. 34. Redmineの良いところとダメなところ • ダメなところ – ちょっと込み入ったカスタマ゗ズしようとすると極 端に難易度が上がる – 複数プロジェクトを持てるけどチケット番号が通し なので都合が悪い時がある@takanafu 関 – RedmineのせいじゃないけどWindowsで動かすとパ フォーマンスが微妙(Passenger) – Wikiがちょっと使いづらい – 複数プロジェクト間でカスタムチケット等のフゖー ルドが共有できるので、一度たくさんカスタム フゖールドを作るとうざい
  35. 35. JIRAの良いところ • 標準カスタマ゗ズと開発カスタマ゗ズ@ohnuki 大貫
  36. 36. JIRAの良いところ • 標準カスタマ゗ズと開発カスタマ゗ズ@ohnuki 大貫
  37. 37. JIRAの良いところ • 標準カスタマ゗ズと開発カスタマ゗ズ@ohnuki 大貫 画像はatlassian.comより
  38. 38. JIRAの悪いところ • ゗ンストールして使い始めるまでの敷居が高い • 日本語の情報が多くない@ohnuki 大貫 画像はAmazon.co.jpより
  39. 39. Jiraの良い所 • 美しいUI、豊富なキーボードショートカット@yusukey 山本
  40. 40. Jiraの良い所 • 簡単な゗ンストール – ダウンロード、展開、startup.shを起動するだけ@yusukey 山本
  41. 41. Jiraの良い所 • 自動バックゕップ – フゔ゗ルに定期バックゕップ。復旧も簡単@yusukey 山本
  42. 42. Jiraの良い所 • 多くのデータベースに対応 – MySQL, PostgreSQL, SQL Server, Oracle – 管理者の慣れ親しんだDBで運用可能@yusukey 山本
  43. 43. Jiraの良い所 • 豊富なプラグ゗ン – Universal Plugin Managerで簡単゗ンストール@yusukey 山本
  44. 44. Jiraのダメな所 • メモリを食いがち、512MBは欲しい@yusukey 山本 – が、384MBのiBookでJira、WebLogic Server、 PostgreSQLと合わせて運用した経験あり
  45. 45. Jiraのダメな所 • ワークフローのカスタマ゗ズがやや煩雑@yusukey 山本
  46. 46. Jiraのダメな所 • 細かなチューニング、運用にはJavaやTomcat の知識が必要@yusukey 山本
  47. 47. Backlogの良いところ • 楽しくコミュニケーションできる • デザ゗ンがかわいい・親しみやすい@ikikko 中村 • 管理に手間がかからない – サーバ管理が不要 – 1分で、登録して使い始めることができる
  48. 48. とあるプロジェクトの風景 バーンダウンチャート@ikikko 中村 絵文字 Backlogスター
  49. 49. Backlogのダメなところ • 柔軟なカスタマ゗ズができない – Backlog API(XML-RPC)は用意されている • (他ツールと比べて)エンジニゕ向け機能が弱い@ikikko 中村 • お金がかかる
  50. 50. @ikeike443 池田 Backlog 良いところ
  51. 51. Scrumとマッチ • バーンダウンチャート出せる@ikeike443 池田
  52. 52. 日本の現場分かってる • ガントチャートも出せる(Excelも)@ikeike443 池田
  53. 53. 日本の現場分かってる • 企業のセキュリテゖチェックシートにも回答 してくれる →上層部を説得しやすい?@ikeike443 池田
  54. 54. 国産だから 日本語対応完璧 余計なことで悩まない!@ikeike443 池田
  55. 55. 親しみやすいデザイン • 非エンジニゕも安心!@ikeike443 池田
  56. 56. コラボがしやすい • 非エンジニゕとのコラボ • デザ゗ンが良く、デザ゗ナーさんや営業さんといっ た非エンジニゕにも受け入れてもらいやすい • 社外とのコラボ •@ikeike443 池田 SaaSなので、余計な手間なく初めから゗ンター ネットに公開されている
  57. 57. SaaSだから • メンテナンスフリー • セキュリテゖも安心 • すぐ使える@ikeike443 池田
  58. 58. APIがある • データの出し入れ自由自在 • レポーテゖング • 他システムとの連携 • その他カスタマ゗ズ@ikeike443 池田
  59. 59. その他機能豊富 • マルチプロジェクト • フゔ゗ル共有(WebDAV) • Wiki • SVN連携@ikeike443 池田 • Jenkins連携 • ガラケー対応
  60. 60. Backlog@ikeike443 池田 頑張ってほしいところ
  61. 61. マルチプロジェクト • マルチプロジェクトで使えるけど • プロジェクト間タスク移動できない • タスクの親子関係、階層作れない • エピック、ストーリー、タスクの粒度@ikeike443 池田
  62. 62. SCMとの連動もう一歩 • hook書きたい • gitも使いたい@ikeike443 池田
  63. 63. レポーティング • 検索条件の保存が出来ない • APIを使わない限り自由度がやや低い@ikeike443 池田
  64. 64. テーマ2ツールをどのように開発プロセスに組み込んでいるか
  65. 65. 開発プロジェクトの体制 • 開発人数 – 1~15人程度(プロジェクトの規模次第) • 基本進捗及び成果物管理にTrac利用 • 少人数の場合 – タスク管理はExcel、不具合はTicketというパターンもあり • 外部公開@kanu_ かぬ – 開発、保守部隊共に社外への公開は無し – 進捗報告及び保守報告レポートはTracを元に出力
  66. 66. 開発プロセス • ウォーターフォール(基本) – WBSを元にタスク分割を行い、タスクをチケットとして登録 – 設計書を含め成果物をSubversionへ保管 – Subversionにコミット時に、コミットコメントを 使って作業時間をTicketへ反映 – 計画は線形で行うため、Excelで作ったガントチャートで実施@kanu_ かぬ • ゕジャ゗ル(スクラム) – ストーリーと、それに紐付くタスクをチケット管理 • ストーリーはWiki併用 – 作業時間記録も基本ウォーターフォールと同じ • 見積時間の変更を行い残作業時間の朝会時に報告。 – その他のプロセスはスクラムのプロセスに従う – 朝会用にスプリントのチケットをPostItへ印刷
  67. 67. 進捗の報告 • 進捗の報告をTracのレポートで行っている。 – 進行中工程(局面、゗テレーション)における、 • 見積工数(規模)の消化状況(完了タスクのみ) • 見積工数(規模)に対する実工数の状況(完了タスクのみ) • 作業中タスクと工程内の未着手タスクの完了予測 – 完了済み工程(局面、゗テレーション)における、 • 見積工数(規模)に対する実作業工数@kanu_ かぬ • 発生している問題点(リスク)の内容と対処方法(予定含む) – 完了予測と遅延対策 • 見積工数(規模)に対する実作業工数の対比による 稼働までスケジュールの確度 • 遅延が予測される場合、原因とその対策について – 工程完了後のレビュー(or ふりかえり)で出た問題点について • 問題点(リスク)の内容 • 問題点(リスク)への対処方法(結果) • 問題点(リスク)への対処方法(予定)
  68. 68. 報告形式 • @kanu_ かぬ
  69. 69. タスクボード @kanu_ かぬ
  70. 70. 報告・可視化用に 使っている主なプラグイン • TimingAndEstimation • ReportInclude – 時間の積算用 – TracReportをWikiに表示させる • タ゗ムトラッキング ためのプラグ゗ン • 管理上最重要プラグ゗ン • Ticket/Milestone/Report などで – Web-Query UIコンポーネント 利用可能 • Queryに中計・大計表示 – Reportだけではなくグラフの表示 http://trac- も可能 hacks.org/wiki/TimingAndEstimationPlugin • 棒グラフ/積み上げ棒グラフ/折れ@kanu_ かぬ 線グラフ/円グラフ • QueryChart http://fr.sourceforge.jp/projects/shibuya- trac/wiki/plugins%2FReportIncludePlugin – チケットのステータス変動の日付 の記録 • ExtendedVersion – 日付を元にバーンダウン/ゕップ チャートの表示 – Milestoneをversionでまとめる為 http://weekbuild.sakura.ne.jp/trac/wiki/T のプラグ゗ン racDoc/QueryChart – MilestoneをTimeBox化して利用 する際に、 • StickyTicketPlugin 全体を見渡すのに非常に便利。 – チケットをPostItに印刷 – 表示の形式はMilestoneとほぼ同 じ – タスクボード用 http://trac- http://trac- hacks.org/wiki/ExtendedVersionPlu hacks.org/wiki/StickyTicketPlu gin gin
  71. 71. 連携している主なツール • Subversion – ソース、ドキュメントは全て格納 – コミットフックを使ってTimingAndEstimationプラ グ゗ンでの作業時間積算と、Tracのチケット連携を 行っている。@kanu_ かぬ • Jenkins – 結合テスト環境及び本番リリース用のビルドの管理 – プロジェクトによっては常時結合 – ビルド結果をTracのタ゗ムラ゗ンに表示 • Eclipse-Mylyn – EclipseからのTracチケット連携用 – 普及度は高くない
  72. 72. @haradakiro – 開発プロセス • Scrum (+DDD)を採用(チームは3人から7人) • ストーリーの管理は、Trac の外 • スプリントプランニングの結果を Trac に登録@haradakiro 原田 • 進捗はタスクボード+バーンダウンチャート • タスクが進んだら Trac にも登録 • Trac+Hudson(Jenkins)+デモサーバ • ユーザ、コンサルタントは常に開発現場にはいられ ないので、Trac、デモサーバを確認
  73. 73. @haradakiro – タスクボード@haradakiro 原田
  74. 74. @haradakiro – Trac 画面@haradakiro 原田
  75. 75. @haradakiro – そんなので? • IT Japan Award 2011 – 準グランプリ@haradakiro 原田 • 小島プレス工業 – 異業種でも利用可能なSaas型 EDI 基盤
  76. 76. @haradakiro – タスクボード@haradakiro 原田
  77. 77. @haradakiro – タスクボードに@haradakiro 原田
  78. 78. @haradakiro – バーンダウン@haradakiro 原田
  79. 79. @haradakiro – Trac 画面@haradakiro 原田
  80. 80. @haradakiro – Trac Wiki@haradakiro 原田
  81. 81. @haradakiro – Trac上 概念クラス@haradakiro 原田
  82. 82. @haradakiro – 開発プロセス デモ確認 現要求を伝える 施主 改善点の提示@haradakiro 原田 ヒアリング デモ実施 プロダクトバックログのレビュー レビューでのヒアリング 設計 開発 プロダクトバックログの作成 見積 スプリントバックログの確認 スプリントバックログの作成 開発
  83. 83. 開発プロセス (Redmine) @daipresents Fujihara
  84. 84. 開発プロセス (Redmine)@daipresentsFujihara 予想実績(単位は日)
  85. 85. 開発プロセス (Redmine)  ベロシテゖの見える 化はExcelでグラフ 化して壁に貼ってい る@daipresents  青が予想、緑が実績  赤は平均。人数の増 減があるため測定し ているFujihara  トレンドとして「実 績/予想」や、「1発 目のスプリントとの 比較」も計算
  86. 86. 開発プロセス (Redmine) @daipresents Fujihara
  87. 87. 開発プロセス (Task Board) @daipresents Fujihara
  88. 88. 開発プロセス (Redmine) @daipresents Fujihara
  89. 89. 開発プロセス (Redmine) Before After@daipresents 10% 90%Fujihara 規律 協調
  90. 90. 開発プロセス (Redmine) マッチする 外部要因となる作業@daipresents 小さいチーム マッチしない 個人用TODOFujihara プランニングポーカーの風景
  91. 91. どのように開発プロセスに組み込んでいるか ■WF+請負+指定管理方法(Excel)の場合 • プロジェクトのWBS特定レベル(画面だったり機能 だったり)に合わせて内部では「マスターチケット」を 作って、そこに関連づけた工程単位の子供チケットをぶ ら下げて、あとは通常のTiDD。@takanafu 関 • プロジェクト指定の進捗管理Excelや故障管理Excelはチ ケットから生成するマクロを作って、発注元には完全に 従っているように見せておいて内部では全てチケットで 管理。 • 単体試験(チーム内部)まではSVN(or GIT)+ Jenkins+xUnit+PMD等でゕジャ゗ル的に開発。試験 項目報告ExcelもTPから生成することも。
  92. 92. どのように開発プロセスに組み込んでいるか ■支援(客先常駐作業)の場合 • とにかく全ての作業はチケットに登録。 • 基本的にメールは使わずチケットと関連づけたリポジト リにソースコードやドキュメントをコミット。 ■その他やっていること@takanafu 関 • 企画段階や上流設計工程から関与できたプロジェクトの 場合は、どんなに昔ながらの現場でも構成管理方法や故 障管理、回帰テストの自動化、CIを提案する。 • チェックリストや規約などはできる限りPMDや CheckStyleのカスタムルールにする。
  93. 93. どのように開発プロセスに組み込んでいるか ■なかなかRedmineを受け入れてくれない現場の場合 • その現場で利用している帳票やExcelと同じ見た目で入 力もしくは閲覧できるViewを作ると案外受け入れてく れる。 • 巧みな話術でしつこくキーマンを洗脳する。@takanafu 関 – Excelなんて、とか思っても絶対口にも顔にも出さないで、 Excelの利点を認めつつも・・・のように提案する。 • 便利な仕組みを使うことによってやる事が無くなる人の 仕事を用意してあげる。 – 結合試験計画の前倒しや、テストデータ整備など後工程で人手 が必要になるものを先にやってもらう、チケットクローズ係に なってもらうなど。
  94. 94. JIRAとウォータフォール • JIRAはバグ管理のみ • プロジェクトの作業計画、進捗管理はExcelや Notes、MS-ProjectでWBS管理@ohnuki 大貫
  95. 95. JIRAとアジャイル • ゕジャ゗ル管理ツールGreenHopperを使う@ohnuki 大貫 少人数(10人未満)の管理方法か?
  96. 96. JIRAとWBS(構造化チケット) 自社組織に合うチケット構造を定義 し、計画立案と進捗管理を行う(標 準化)。ツールはその構造に従った 構造化Viewを提供する。 チケット階層@ohnuki 大貫 ストーリ モジュール タスク
  97. 97. Jiraをどのように開発プロセ スに組み込んでいるか@yusukey 山本
  98. 98. Twitter4Jの開発 • ユーザー、コントリビュータ: 32人 – チケット登録 • コミッタ: 1人 - チケット編集、クローズ • 登録ユーザ数: 全90人@yusukey 山本
  99. 99. 開発参加ガイドライン@yusukey 山本 JIRAを中心とした開発参加ガ゗ドラ゗ン
  100. 100. Twitter4J開発の流れ 1. MLでバグ報告・機能追加要求を受ける 2. 課題登録 3. githubで修正、pull requestを貰う 4. Jenkinsがテストを確認 5. テストがパスしたら課題をクローズ
  101. 101. 開発で使っているサービス、ツール コードリポジトリ ビルド、テスト コーディング CI service hook 課題管理 開発マシ ン CIサーバ github.com
  102. 102. Jira と GitHubの連携 JIRA Git plugin
  103. 103. Jira と Jenkinsの連携@yusukey 山本 Jenkins JIRA plugin
  104. 104. Jira と IDEの連携@yusukey 山本 Atlassian Connector for IntelliJ IDEA
  105. 105. 開発プロセス • 基本方針 – できる限りの情報をBacklogに集約 – サポート・問い合わせ対応でのメールのやり取り – 今進んでいるプロジェクトの進捗状況 – 仕様についての質問 など@ikikko 中村 • 社外公開の有無 – 関連する人全員をメンバーとする – できない場合は、公開プロジェクトと非公開プロ ジェクトに分ける
  106. 106. 開発プロセス • チーム構成 – 少人数(数人~十人弱)のプロジェクトが多い – デザ゗ナーなどとも協業 • 併用しているツール@ikikko 中村 – Cacoo, Skype, EtherPad, Jenkins リゕルタ゗ムで共同編集できる テキストエデゖタ
  107. 107. 例:問い合わせ対応への組み込み 問い合わせメールから、Backlogにチケット自動登録@ikikko 中村 http://www.backlog.jp/blog/2009/03/post.html
  108. 108. 例:Cacooでの開発プロセス@ikikko 中村 http://www.slideshare.net/nulab/seasarwebcacoo
  109. 109. 例:Cacooの開発プロセス@ikikko 中村 http://www.slideshare.net/nulab/seasarwebcacoo
  110. 110. 例:Cacooの開発プロセス@ikikko 中村 やりとりをBacklogに集約
  111. 111. Backlog どうやって使ってるか@ikeike443 池田
  112. 112. 社外ユーザとの利用多数@ikeike443 池田
  113. 113. 3年半 206@ikeike443 池田 プロジェクト 一人平均3−10プロジェクトの利用?
  114. 114. 利用形態 社内 社外 開発 導入 プロジェクト型 社内 WEB制作@ikeike443 池田 依頼 協業 チケット型 期限 FAQ
  115. 115. 社外ユーザなど文化の異なる人と タスク SVN@ikeike443 池田 フゔ゗ル 社外 社内 Wiki サブバージョ ンがさー メールで
  116. 116. 雑務から新しい仕事を創る 定期的に タスク棚卸@ikeike443 池田 分析
  117. 117. APIの利用による定形・自動化 Backlog Backlog API@ikeike443 池田 定形タスク カスタムバーンダウン
  118. 118. 製品開発 • プロダクトバックログ:GoogleDocs • スプリントバックログ:Backlog • バグ管理:Bugzilla • バージョン管理:SVN, CVS@ikeike443 池田 • CIサーバ:Jenkins
  119. 119. DEV コミットフック 日々のコミット 開発マシン@ikeike443 池田 すべてのバグ管理 スプリント中の (≒プロダクト チケット管理 バックログ) QA CVS QAのリポジトリは 定期実行 DEVと別 複数環境並行
  120. 120. 実際のルール • 月初に定形タスクをAPIで投入(開発の標準タスク 等) • 月初にさらに6-8割程度までタスクを作成 • 1タスクは8時間以内(超えるものは分割) •@ikeike443 池田 予定と実績の時間は入力し、バーンダウン生成 • 月末にタスク分析で失敗の原因を探る
  121. 121. 付箋も大いに活用
  122. 122. テーマ3チケット管理システムの運用方法
  123. 123. 運用 • 社内サーバーで運用中 – サーバ機 • Dell T300 • Xeon X3363 2.8Ghz • Memory 4GB • Disk 280GB(Raid5+Hotspare)@kanu_ かぬ – バックゕップ • Jenkinsで毎晩実行 – Trac及びsvnをHot copy(3日分保存) – Hot copyをzip圧縮しNASへ(14日分保存) – その他 • 全文検索用にHyperEstraier用Index生成(Jenkinsで日に2回) • 基本は放置だが運用部隊にJenkisの運用関連Jobチェックを 毎朝お願いしている。
  124. 124. 改善要望について • 要望は品質管理チームで取りまとめ – プロセス改善の目的を兼ねているため • 既存プラグ゗ンで対応可能な場合は実施 – 目的を再確認し、開発プロセス及び要求資料の改善を提示する ことも少なくない。@kanu_ かぬ • チケットへの項目追加など – 基本的にはプロジェクト一任。 – 運用しきれない管理項目を増やす傾向があるので、 立ち上げ当初は適宜ゕドバ゗スを行っている。 • 管理用のTrac Report – 基本的にはプロジェクト一任。 – 全体的に利用できそうな場合は、品質管理チームにて作成する 場合もあり。
  125. 125. 現状の問題点 • 個人への依存 – 部署対応ではあるものの完全に個人へ依存 – 依存脱却への取り組みは始まったが成果は出ていない • やらされる、使わされるに慣れていて、改善への興味が薄い? • Tracの管理@kanu_ かぬ – 管理がTracのWeb-UIのみで完結しない – Tracに関わる広い知識が必要 • Subversion, Apache, Python, Maven, Jenkins等々 • 銀の弾丸 – 道具が解決してくれると思っている傾向がある。 – 開発プロセスを含めたポリシーの徹底が必要
  126. 126. Users & Version 1400 登録者累計 0.9.6 1200 0.9.4 1000 2.5年で1000ユーザ 0.9.2@daipresents 800 開発、ビジネス問わ ず社員全員が使える 0.9.0 600 形に 0.8.4 400Fujihara 0.8.0 200 0 2年ぐらい
  127. 127. チケット管理システムの運用方法 • 社内サーバーに設置して、業務(案件)単位にプロジェ クトを作成。 • ゕクセス制御はLDAP連携で整備。 • 基本セットはredmine+LDAP+jenkins+SVN+ xUnit&PMD系&カバレッジ系(言語別)。@takanafu 関 • ある程度はマクロですぐに提供できるようにしている。 • 案件のリーダーに対する布教活動。 • 社内プレゼンでの布教活動。 • ある程度標準化したチケットの種別やカスタムフゖール ドと運用方法を準備して使いまわしている。
  128. 128. JIRA運用のよくあるパターン • 運用する人:社内IS部門 – JIRAユーザーは数百人規模 – ユーザーとグループは全社認証情報と連携(AD多い) – ただしプロジェクト設定はプロジェクト管理者に権限委譲 • データ量:数年使って数十万チケットになる@ohnuki 大貫 • ゕベ゗ラビリテゖ:24時間365日止まらないで – HW障害対策は必須、パフォーマンス検討も時々行う • バックゕップ:まちまちで難しい – 会社(組織)の標準バックゕップ方法に準拠 • フラッシュコピー、テープ、DB共通バックゕップ • オンラ゗ンバックゕップできるDBやバックゕップソフト利用
  129. 129. 自宅サーバーで運用中 • フレッツ光 • Value Domain(DDNS): twitter4j.org • Mac Mini(Core2Duo,2.66GHz,8GB)@yusukey 山本 フレッツ光 ダイナミックDNS Ethernet Internet AirMac Extreme Mac Mini
  130. 130. 管理 • 基本放置 • カスタマ゗ズは最小限 – gitプラグ゗ンを入れている程度 • 新バージョンが出たらなるべく早めに適用@yusukey 山本 – これまでに10のバージョンを適用: 3.x系: 3.9.2, 3.12.3, 3.13.1 4.x系: 4, 4.0.2, 4.1, 4.2.0, 4.2.2, 4.3, 4.3.4 – バージョンゕップで問題が出たことはなし • まれに脆弱性の通知がメールで来るのでパッチ
  131. 131. 管理上の問題点と今後の展望 • ユーザーはあまり見てくれていない – メーリングリストとJiraの串刺し検索? • 省電力化 – クラウドにデプロ゗?@yusukey 山本 – Jira Studio for OSSの利用? • http://open.jira.com/secure/Dashboard.jspa
  132. 132. Backlogの運用方法 • サーバ管理 – (プロジェクトチーム側では)゗ンフラ面を特に考 慮する必要無し • チケット管理方針@ikikko 中村 – 「楽しくコミュニケーションすること」を重視 – あまりガチガチにしない
  133. 133. 現状の管理における問題点 • メール爆発 • 情報の分散 – Backlog, Skype, EtherPad, Cacoo – チケットに起こす前のたたき台の場所とか・・・@ikikko 中村 他ツールの良いところを取り入れていきたい (と個人的に思ってます)
  134. 134. システムの運用管理 • システム運用管理: • ヌーラボさん • 業務運用管理: • 事業部ごとに複数の管理者@ikeike443 池田
  135. 135. 現場が自由に使っている • 社内外でプロジェクトが立ち上がるたび、 Backlogにプロジェクトを作る • 最低限のルールのみ決めておいて、後は現場 の判断@ikeike443 池田 • お客様、協力会社様、社員、全ての関係者を 入れてプロジェクトを運用
  136. 136. テーマ4質疑応答

×