Soumettre la recherche
Mettre en ligne
チケット管理システム大決戦第二弾
•
61 j'aime
•
52,846 vues
Ryutaro YOSHIBA
Suivre
6/30に実施したShibuya.trac第12回勉強会チケット管理システム大決戦第二弾の資料です。
Lire moins
Lire la suite
Technologie
Signaler
Partager
Signaler
Partager
1 sur 137
Recommandé
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
What should you shift left
What should you shift left
Yasuharu Nishi
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
Recommandé
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
What should you shift left
What should you shift left
Yasuharu Nishi
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
kiita312
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
TOCから俯瞰するリーンスタートアップ
TOCから俯瞰するリーンスタートアップ
Taro Kawai
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
ChatGPTのビジネス活用とセキュリティ
ChatGPTのビジネス活用とセキュリティ
Daisuke Masubuchi
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
masayoshi takahashi
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
Shinya Nakajima
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
例外設計における大罪
例外設計における大罪
Takuto Wada
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
Ito Takayuki
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
こわくない Git
こわくない Git
Kota Saito
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
Nobuhiro Yoshitake
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
Tomohisa Kusukawa
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
Shunsuke (Sean) Osawa
Jiraの紹介(redmineとの比較視点にて)
Jiraの紹介(redmineとの比較視点にて)
Hiroshi Ohnuki
Contenu connexe
Tendances
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
kiita312
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
TOCから俯瞰するリーンスタートアップ
TOCから俯瞰するリーンスタートアップ
Taro Kawai
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
ChatGPTのビジネス活用とセキュリティ
ChatGPTのビジネス活用とセキュリティ
Daisuke Masubuchi
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
masayoshi takahashi
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
Shinya Nakajima
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
例外設計における大罪
例外設計における大罪
Takuto Wada
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
Ito Takayuki
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
こわくない Git
こわくない Git
Kota Saito
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
Nobuhiro Yoshitake
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
Tomohisa Kusukawa
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Tendances
(20)
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
TOCから俯瞰するリーンスタートアップ
TOCから俯瞰するリーンスタートアップ
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
ChatGPTのビジネス活用とセキュリティ
ChatGPTのビジネス活用とセキュリティ
テストコードの DRY と DAMP
テストコードの DRY と DAMP
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
例外設計における大罪
例外設計における大罪
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
こわくない Git
こわくない Git
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
インセプションデッキ:やらないことリストとトレードオフスライダーをやってる話
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
En vedette
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
Shunsuke (Sean) Osawa
Jiraの紹介(redmineとの比較視点にて)
Jiraの紹介(redmineとの比較視点にて)
Hiroshi Ohnuki
Henrik Kniberg - Scrum and XP beyond the trenches
Henrik Kniberg - Scrum and XP beyond the trenches
AgileSparks
ストーリーポイントをつけれるようになるために必要な3つのこと
ストーリーポイントをつけれるようになるために必要な3つのこと
Katsunobu Harada
プランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくり
Reimi Kuramochi Chiba
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
Yagi Natsuki
En vedette
(6)
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
Jiraの紹介(redmineとの比較視点にて)
Jiraの紹介(redmineとの比較視点にて)
Henrik Kniberg - Scrum and XP beyond the trenches
Henrik Kniberg - Scrum and XP beyond the trenches
ストーリーポイントをつけれるようになるために必要な3つのこと
ストーリーポイントをつけれるようになるために必要な3つのこと
プランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくり
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
Similaire à チケット管理システム大決戦第二弾
第2回 -Play部屋- Play 2.0はじめて&もくもく会
第2回 -Play部屋- Play 2.0はじめて&もくもく会
Kazuhiro Hara
Osc2010 Slide
Osc2010 Slide
Kaoru NAKAMURA
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
Koichi ITO
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
Shuji Yamada
Osc2010 tokyo fall コミュニティ紹介
Osc2010 tokyo fall コミュニティ紹介
Kaoru NAKAMURA
JAWS-UGサミット2011春 LT資料
JAWS-UGサミット2011春 LT資料
Yuuki Namikawa
続・Twitter bootstrap入門 #html5j
続・Twitter bootstrap入門 #html5j
Toshiaki Maki
Hatena blogdevelopmentflow
Hatena blogdevelopmentflow
Yasuhiro Onishi
2015/10/14 JJUGナイトセミナー「テスト駆動開発ここが聞きたい」
2015/10/14 JJUGナイトセミナー「テスト駆動開発ここが聞きたい」
Hiroyuki Ohnaka
[141004] cedec 2014 참관기 & 강연 리뷰 #1
[141004] cedec 2014 참관기 & 강연 리뷰 #1
MinGeun Park
インドのインターネット環境との戦い方
インドのインターネット環境との戦い方
健一 辰濱
Yapc2012ltthon
Yapc2012ltthon
Junya Murabe
Play ja 3_update
Play ja 3_update
Takafumi Ikeda
DX Suite & UiPath さっくり読み取りさっくり連携
DX Suite & UiPath さっくり読み取りさっくり連携
Chuki ちゅき
北海道の南端で勉強会やります
北海道の南端で勉強会やります
deflis
Chainerで学ぶdeep learning
Chainerで学ぶdeep learning
Retrieva inc.
Spring Boot + Doma + AngularJSで作るERP (LINE Fukuoka Meetup版)
Spring Boot + Doma + AngularJSで作るERP (LINE Fukuoka Meetup版)
学 松崎
Sparkコミュニティに飛び込もう!(Spark Meetup Tokyo 2015 講演資料、NTTデータ 猿田 浩輔)
Sparkコミュニティに飛び込もう!(Spark Meetup Tokyo 2015 講演資料、NTTデータ 猿田 浩輔)
NTT DATA OSS Professional Services
SpringOne Platform 2018 全体報告
SpringOne Platform 2018 全体報告
Takuya Iwatsuka
SpringOne Platform 2018 全体報告
SpringOne Platform 2018 全体報告
apkiban
Similaire à チケット管理システム大決戦第二弾
(20)
第2回 -Play部屋- Play 2.0はじめて&もくもく会
第2回 -Play部屋- Play 2.0はじめて&もくもく会
Osc2010 Slide
Osc2010 Slide
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
Osc2010 tokyo fall コミュニティ紹介
Osc2010 tokyo fall コミュニティ紹介
JAWS-UGサミット2011春 LT資料
JAWS-UGサミット2011春 LT資料
続・Twitter bootstrap入門 #html5j
続・Twitter bootstrap入門 #html5j
Hatena blogdevelopmentflow
Hatena blogdevelopmentflow
2015/10/14 JJUGナイトセミナー「テスト駆動開発ここが聞きたい」
2015/10/14 JJUGナイトセミナー「テスト駆動開発ここが聞きたい」
[141004] cedec 2014 참관기 & 강연 리뷰 #1
[141004] cedec 2014 참관기 & 강연 리뷰 #1
インドのインターネット環境との戦い方
インドのインターネット環境との戦い方
Yapc2012ltthon
Yapc2012ltthon
Play ja 3_update
Play ja 3_update
DX Suite & UiPath さっくり読み取りさっくり連携
DX Suite & UiPath さっくり読み取りさっくり連携
北海道の南端で勉強会やります
北海道の南端で勉強会やります
Chainerで学ぶdeep learning
Chainerで学ぶdeep learning
Spring Boot + Doma + AngularJSで作るERP (LINE Fukuoka Meetup版)
Spring Boot + Doma + AngularJSで作るERP (LINE Fukuoka Meetup版)
Sparkコミュニティに飛び込もう!(Spark Meetup Tokyo 2015 講演資料、NTTデータ 猿田 浩輔)
Sparkコミュニティに飛び込もう!(Spark Meetup Tokyo 2015 講演資料、NTTデータ 猿田 浩輔)
SpringOne Platform 2018 全体報告
SpringOne Platform 2018 全体報告
SpringOne Platform 2018 全体報告
SpringOne Platform 2018 全体報告
Dernier
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
sugiuralab
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
Dernier
(8)
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
チケット管理システム大決戦第二弾
1.
チケット管理システム
大決戦 第二弾 2011/6/30 Shibuya.trac 第12回勉強会 flickr.com/photos/11226747@N07/4450250126/
2.
本日の目次 • 自己紹介 (10分) •
テーマ1 (40分) – そのツールの良いところ(気にいってるところ)と ダメなところ • テーマ2 (40分) – そのツールをどのように開発プロセスに組み込ん でいるか • テーマ3 (20分) – チケット管理システムの運用方法 • 質疑応答 (20分)
3.
本日の登壇者のご紹介
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の開発に直接携わってはいません – 一番近いヘビーユーザ • 今日は、ヌーラボで携わっているプロジェクト からいくつか取り上げてお話します
14.
Backlogとは @ikikko 中村
• エンジニゕ以外もターゲット層 – デザナー – 翻訳者 – 経理・事務担当 など • メンはASPサービス
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
18.
テーマ1 各ツールの 良いところと悪いところ
19.
良いところ
• SQLを用いた柔軟なレポート • Trac Lightningの存在 @kanu_ かぬ • Shibuya.tracの存在 • 豊富なプラグン • 無料であること
20.
SQLを用いた柔軟なレポート
Tracのみでワンストップなプロジェクトの可視化が可能。 @kanu_ かぬ
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/
28.
Reportは意外と大変
• SQLは便利だが作るのは骨が折れる @kanu_ かぬ
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 にしてバックゕップしているけど、こんどは ンストールが面倒 • 複数プロジェクトでンスタンスを増やしてし まうと管理が面倒
32.
Redmineの良いところ
@daipresents Fujihara
33.
Redmineの良いところとダメなところ
• 良いところ – (RedmineLEを使えば)ンストールが簡単 – 簡単なプラグンはすぐ作れる – とことんまでカスタマズできる ワークフロー系システムのバックエンドとして活用 @takanafu 関 – しやすい(社内稟議システムで活用) – プラグンが充実している – 複数プロジェクトやプラベートチケットなど便利 な機能がデフォルトでたくさんある
34.
Redmineの良いところとダメなところ
• ダメなところ – ちょっと込み入ったカスタマズしようとすると極 端に難易度が上がる – 複数プロジェクトを持てるけどチケット番号が通し なので都合が悪い時がある @takanafu 関 – RedmineのせいじゃないけどWindowsで動かすとパ フォーマンスが微妙(Passenger) – Wikiがちょっと使いづらい – 複数プロジェクト間でカスタムチケット等のフゖー ルドが共有できるので、一度たくさんカスタム フゖールドを作るとうざい
35.
JIRAの良いところ
• 標準カスタマズと開発カスタマズ @ohnuki 大貫
36.
JIRAの良いところ
• 標準カスタマズと開発カスタマズ @ohnuki 大貫
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分で、登録して使い始めることができる
48.
とあるプロジェクトの風景
バーンダウンチャート @ikikko 中村 絵文字 Backlogスター
49.
Backlogのダメなところ
• 柔軟なカスタマズができない – Backlog API(XML-RPC)は用意されている • (他ツールと比べて)エンジニゕ向け機能が弱い @ikikko 中村 • お金がかかる
50.
@ikeike443 池田
Backlog 良いところ
51.
Scrumとマッチ
• バーンダウンチャート出せる @ikeike443 池田
52.
日本の現場分かってる
• ガントチャートも出せる(Excelも) @ikeike443 池田
53.
日本の現場分かってる
• 企業のセキュリテゖチェックシートにも回答 してくれる →上層部を説得しやすい? @ikeike443 池田
54.
国産だから
日本語対応完璧 余計なことで悩まない! @ikeike443 池田
55.
親しみやすいデザイン
• 非エンジニゕも安心! @ikeike443 池田
56.
コラボがしやすい
• 非エンジニゕとのコラボ • デザンが良く、デザナーさんや営業さんといっ た非エンジニゕにも受け入れてもらいやすい • 社外とのコラボ • @ikeike443 池田 SaaSなので、余計な手間なく初めからンター ネットに公開されている
57.
SaaSだから
• メンテナンスフリー • セキュリテゖも安心 • すぐ使える @ikeike443 池田
58.
APIがある
• データの出し入れ自由自在 • レポーテゖング • 他システムとの連携 • その他カスタマズ @ikeike443 池田
59.
その他機能豊富
• マルチプロジェクト • フゔル共有(WebDAV) • Wiki • SVN連携 @ikeike443 池田 • Jenkins連携 • ガラケー対応
60.
Backlog @ikeike443 池田
頑張ってほしいところ
61.
マルチプロジェクト
• マルチプロジェクトで使えるけど • プロジェクト間タスク移動できない • タスクの親子関係、階層作れない • エピック、ストーリー、タスクの粒度 @ikeike443 池田
62.
SCMとの連動もう一歩
• hook書きたい • gitも使いたい @ikeike443 池田
63.
レポーティング
• 検索条件の保存が出来ない • APIを使わない限り自由度がやや低い @ikeike443 池田
64.
テーマ2 ツールをどのように開発プロセ スに組み込んでいるか
65.
開発プロジェクトの体制
• 開発人数 – 1~15人程度(プロジェクトの規模次第) • 基本進捗及び成果物管理にTrac利用 • 少人数の場合 – タスク管理はExcel、不具合はTicketというパターンもあり • 外部公開 @kanu_ かぬ – 開発、保守部隊共に社外への公開は無し – 進捗報告及び保守報告レポートはTracを元に出力
66.
開発プロセス
• ウォーターフォール(基本) – WBSを元にタスク分割を行い、タスクをチケットとして登録 – 設計書を含め成果物をSubversionへ保管 – Subversionにコミット時に、コミットコメントを 使って作業時間をTicketへ反映 – 計画は線形で行うため、Excelで作ったガントチャートで実施 @kanu_ かぬ • ゕジャル(スクラム) – ストーリーと、それに紐付くタスクをチケット管理 • ストーリーはWiki併用 – 作業時間記録も基本ウォーターフォールと同じ • 見積時間の変更を行い残作業時間の朝会時に報告。 – その他のプロセスはスクラムのプロセスに従う – 朝会用にスプリントのチケットをPostItへ印刷
67.
進捗の報告
• 進捗の報告をTracのレポートで行っている。 – 進行中工程(局面、テレーション)における、 • 見積工数(規模)の消化状況(完了タスクのみ) • 見積工数(規模)に対する実工数の状況(完了タスクのみ) • 作業中タスクと工程内の未着手タスクの完了予測 – 完了済み工程(局面、テレーション)における、 • 見積工数(規模)に対する実作業工数 @kanu_ かぬ • 発生している問題点(リスク)の内容と対処方法(予定含む) – 完了予測と遅延対策 • 見積工数(規模)に対する実作業工数の対比による 稼働までスケジュールの確度 • 遅延が予測される場合、原因とその対策について – 工程完了後のレビュー(or ふりかえり)で出た問題点について • 問題点(リスク)の内容 • 問題点(リスク)への対処方法(結果) • 問題点(リスク)への対処方法(予定)
68.
報告形式
• @kanu_ かぬ
69.
タスクボード
@kanu_ かぬ
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、デモサーバを確認
73.
@haradakiro – タスクボード @haradakiro
原田
74.
@haradakiro – Trac
画面 @haradakiro 原田
75.
@haradakiro – そんなので?
• IT Japan Award 2011 – 準グランプリ @haradakiro 原田 • 小島プレス工業 – 異業種でも利用可能なSaas型 EDI 基盤
76.
@haradakiro – タスクボード @haradakiro
原田
77.
@haradakiro – タスクボードに @haradakiro
原田
78.
@haradakiro – バーンダウン @haradakiro
原田
79.
@haradakiro – Trac
画面 @haradakiro 原田
80.
@haradakiro – Trac
Wiki @haradakiro 原田
81.
@haradakiro – Trac上
概念クラス @haradakiro 原田
82.
@haradakiro – 開発プロセス
デモ確認 現要求を伝える 施主 改善点の提示 @haradakiro 原田 ヒアリング デモ実施 プロダクトバックログのレビュー レビューでのヒアリング 設計 開発 プロダクトバックログの作成 見積 スプリントバックログの確認 スプリントバックログの作成 開発
83.
開発プロセス (Redmine)
@daipresents Fujihara
84.
開発プロセス (Redmine) @daipresents Fujihara
予想実績(単位は日)
85.
開発プロセス (Redmine)
ベロシテゖの見える 化はExcelでグラフ 化して壁に貼ってい る @daipresents 青が予想、緑が実績 赤は平均。人数の増 減があるため測定し ている Fujihara トレンドとして「実 績/予想」や、「1発 目のスプリントとの 比較」も計算
86.
開発プロセス (Redmine)
@daipresents Fujihara
87.
開発プロセス (Task Board)
@daipresents Fujihara
88.
開発プロセス (Redmine)
@daipresents Fujihara
89.
開発プロセス (Redmine)
Before After @daipresents 10% 90% Fujihara 規律 協調
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 大貫 ストーリ モジュール タスク
97.
Jiraをどのように開発プロセ
スに組み込んでいるか @yusukey 山本
98.
Twitter4Jの開発
• ユーザー、コントリビュータ: 32人 – チケット登録 • コミッタ: 1人 - チケット編集、クローズ • 登録ユーザ数: 全90人 @yusukey 山本
99.
開発参加ガイドライン @yusukey 山本
JIRAを中心とした開発参加ガドラン
100.
Twitter4J開発の流れ 1.
MLでバグ報告・機能追加要求を受ける 2. 課題登録 3. githubで修正、pull requestを貰う 4. Jenkinsがテストを確認 5. テストがパスしたら課題をクローズ
101.
開発で使っているサービス、ツール
コードリポジトリ ビルド、テスト コーディング CI service hook 課題管理 開発マシ ン CIサーバ github.com
102.
Jira と GitHubの連携
JIRA Git plugin
103.
Jira と Jenkinsの連携 @yusukey
山本 Jenkins JIRA plugin
104.
Jira と IDEの連携 @yusukey
山本 Atlassian Connector for IntelliJ IDEA
105.
開発プロセス
• 基本方針 – できる限りの情報をBacklogに集約 – サポート・問い合わせ対応でのメールのやり取り – 今進んでいるプロジェクトの進捗状況 – 仕様についての質問 など @ikikko 中村 • 社外公開の有無 – 関連する人全員をメンバーとする – できない場合は、公開プロジェクトと非公開プロ ジェクトに分ける
106.
開発プロセス
• チーム構成 – 少人数(数人~十人弱)のプロジェクトが多い – デザナーなどとも協業 • 併用しているツール @ikikko 中村 – Cacoo, Skype, EtherPad, Jenkins リゕルタムで共同編集できる テキストエデゖタ
107.
例:問い合わせ対応への組み込み
問い合わせメールから、Backlogにチケット自動登録 @ikikko 中村 http://www.backlog.jp/blog/2009/03/post.html
108.
例:Cacooでの開発プロセス @ikikko 中村
http://www.slideshare.net/nulab/seasarwebcacoo
109.
例:Cacooの開発プロセス @ikikko 中村
http://www.slideshare.net/nulab/seasarwebcacoo
110.
例:Cacooの開発プロセス @ikikko 中村
やりとりをBacklogに集約
111.
Backlog
どうやって使ってるか @ikeike443 池田
112.
社外ユーザとの利用多数 @ikeike443 池田
113.
3年半
206 @ikeike443 池田 プロジェクト 一人平均3−10プロジェクトの利用?
114.
利用形態
社内 社外 開発 導入 プロジェクト型 社内 WEB制作 @ikeike443 池田 依頼 協業 チケット型 期限 FAQ
115.
社外ユーザなど文化の異なる人と
タスク SVN @ikeike443 池田 フゔル 社外 社内 Wiki サブバージョ ンがさー メールで
116.
雑務から新しい仕事を創る
定期的に タスク棚卸 @ikeike443 池田 分析
117.
APIの利用による定形・自動化
Backlog Backlog API @ikeike443 池田 定形タスク カスタムバーンダウン
118.
製品開発
• プロダクトバックログ:GoogleDocs • スプリントバックログ:Backlog • バグ管理:Bugzilla • バージョン管理:SVN, CVS @ikeike443 池田 • CIサーバ:Jenkins
119.
DEV
コミットフック 日々のコミット 開発マシン @ikeike443 池田 すべてのバグ管理 スプリント中の (≒プロダクト チケット管理 バックログ) QA CVS QAのリポジトリは 定期実行 DEVと別 複数環境並行
120.
実際のルール
• 月初に定形タスクをAPIで投入(開発の標準タスク 等) • 月初にさらに6-8割程度までタスクを作成 • 1タスクは8時間以内(超えるものは分割) • @ikeike443 池田 予定と実績の時間は入力し、バーンダウン生成 • 月末にタスク分析で失敗の原因を探る
121.
付箋も大いに活用
122.
123.
テーマ3 チケット管理システムの 運用方法
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 池田 • お客様、協力会社様、社員、全ての関係者を 入れてプロジェクトを運用
137.
テーマ4 質疑応答