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