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.

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

69,857 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  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質疑応答

×