タグ: Shibuya.trac

Shibuya.trac第11回勉強会

Shibuya.trac第11回勉強会~プロジェクトの可視化~
~ 一歩進んだチケット駆動開発「管理から可視化へ」 ~

URL:

場所:

麹町 KDDI Webコミュニケーションズ会議室

 

Vodpod videos no longer available.

 

チケットシステムによるはじめてのアジャイル開発(lightningX)

TracLightningの紹介

TracLightning≠Trac
→TracはTracLightningの一部

Tracのテンプレートを切り替えることでいろいろな開発形態に対応できる

  • Niagara・・ウォーターフォール用テンプレート
  • Allegro ・・アジャイルスクラム用テンプレート

チケットシステムを使ったスクラム

  1. プロジェクト計画
    • ストーリーの洗い出し
    • ストーリーの消化時間見積もり
    • チケット化
  2. スプリント計画
    • ストーリー選択
    • タスク作成
    • 見積もり調整
    • (インポート用Excel作成)
  3. スプリント実行
    • 作業割り当て
    • 朝会
    • 進捗確認
    • 課題・バグは即チケット化
  4. 振り返り

チケットシステムを使うメリット

  • アジャイル開発に必要なツールが簡単に整う
  • チケットを変更したコードのヒモ付ができる。

ReportInclude、Worktimeプラグインの活用事例について(wadahiro)

サポート業務における事例

従来の方法

  1. 顧客からメールで問い合わせ受付
  2. 開発担当者にアサイン(専任スタッフはいなかった)
  3. 担当者が顧客と直でメールで対応

リーマンショック

コスト圧縮

サポートの専任化と小人数化が行われた

業務の効率化が急務

効率化案

Excel、Projectを使用した共有

すぐ破綻した

Tracを採用

導入にあたって

  • サポート担当から要望聞き取り
  • Pluginの追加で要望を実現していく
  • ないものはPluginを自作した

便利なプラグイン

  • MailArchiveプラグイン
    メールを取り込む
    ↓さらに拡張
    問い合わせメールからチケット発行をクリックのみで可能にした
    ↓結果
    問い合わせ受付からチケットへがスムーズに
    顧客とのやりとりが共有された

いろいろな表示したい情報

Tracのレポート機能は複雑なレポートでも出力できる

欠点:Wikiに埋め込めない
↓そこで
ReportInclude Pluginを開発
wikiにレポートを埋め込むもの
↓その後
パフォーマンス分析レポートがほしい
→プラグインにグラフ描画機能を追加

作業時間の入力

Redmineにはある
つくってみた→WorkTime Plugin

  • MS Projectライク
  • 自分と関係しているチケットが閲覧できる
  • そのまま時間入力ができる
  • レポート機能

続、とある会社でのTrac利用事例~可視化とレポート活用事例~(id:kanu)

レポート機能を使った可視化事例をデモ

さまざまレポートをほぼTracのレポート機能だけで実現している

Redmineには負けないっ!!
プラグインで拡張したワークフローをExcelで状態遷移図にして編集する(id:u-z)

Excelを使ったワークフロー編集のデモ

Excel上でワークフローの表と状態遷移図を編集することで、Trac.iniのワークフロー部の設定情報を生成するもの。

Shibuya.trac 分散バージョン管理勉強会

URL:http://kokucheese.com/event/index/6329/

場所:江東区 古石場文化センター 2階 第1,2研修室

「分散バージョン管理システムってなんなん?」(おかもとさん)

TracLightning 3.0からアジャイル対応

バージョン管理の変遷

CSV:共有モデルのファイル管理

SVN:アトミックなコミット(コミットされるかされないか、リビジョンごとの管理が可能に)

DVCS(分散バージョン管理):ブランチ・マージモデル、ローカルコミット、ローカルでのdiffやログ参照、ログのリファクタリング、マージトラッキング

「GitとHudsonによるきれいなリポジトリの作り方」(bleis さん)

集中型と比較した分散型の利点

  • 集中型
    • 間違った操作が全体に影響
    • 気後れしてしまう
  • 分散型
    • 自由なコミット
    • 作業のやり直しが可能

リポジトリとWCの関係

  • 集中型
    1つのリポジトリに複数ののワーキングコピー
  • 分散型
    1つのリポジトリに1つのワーキングコピー

=>意外と分散型のほうがシンプル

分散型は更新先を複数持てる。

きれいなリポジトリ

DVCSでも解決できない問題があるので、きれいなリポジトリを構成する必要がある

きれいなリポジトリ=最新版がいつでもビルド可能なリポジトリ

実現するには?

CIの導入
→リポジトリが更新されるたびにビルドを走らせることにより、素早いフィードバックを得ることができる

しかしフィードバックだけでは足りない=>ビルドが壊れるとその状態が取得できてしまう。

そこでDVCSを利用する。2つの利用方法

  • ブランチを分割
  • リポジトリを分割
    開発者ごとにリポジトリ(プライベートブランチ)
    きれいなリポジトリ(セントラルブランチ)

ブランチ分割法

hookでmasterブランチにpushできないようにする

プライベートブランチの更新をhookしてビルド

hudsonのgitプラグインの設定で簡単に設定できる

リポジトリ分割法

セントラルリポジトリは外部から取得専用にする

プライベートリポジトリの更新をhookしてビルド

開発者が増える際の設定が多い

まとめ:DVCSとCIできれいなリポジトリを。実現方法は複数ある。

「TracLightningとTortoiseHgのゆるふわな連携」(ゆかわさん)

Mercurial

  • 単機能(1コマンド1機能)
  • 拡張機能が豊富
  • 差分で履歴を管理(Gitはスナップショット)
  • 4種類のブランチ
    →名無しブランチというものがある

拡張機能をがしがし使う必要がある

「git-svn使ってみる?」(riskさん)

git-svnの基本的な説明

git-svnとはsvnとgitの中継

git-svnが利用可能なソフト(windows)

msysgit ・ cygwin

「Mercurialで別オリジンのリポジトリ間で同期を取る運用の仕方について」(monjudohさん)

Mercurialで別オリジンのリポジトリ間の同期を取る運用の仕方について – 文殊堂

LT1. 「Gitでの歴史の改変方法の紹介」(神速さん)

改変を実際にデモ

git add -p

複数の変更から一部選択してコミット

git rebase -i

rebaseする際にそれまでコミットした内容を再度編集でき、改変もできる

LT2. 「SVNユーザのためのBazaarガイド」(iwataさん)

Bazaarの紹介

Bazaarをおすすめするケース

  • デザイナさんとかにVCSを使って欲しい時
  • 日本語ファイル名を使いたい時
    (SVNと同じレベルで)
  • SVNを使いながら段階的にDVCSを利用したい
  • レベルの低い人

Bazaarをおすすめできないケース

  • VSインテグレーション機能が必要なとき

コンセプト

  • 誰でも使えるバージョン管理
  • better SVN

リモートリポジトリからチェックアウトするとリモートリポジトリとバインドすることができる
→ローカルリポジトリにコミットするとリモートにも反映される

LT3. 「Hudsonからみるバージョン管理」(さぼてんさん)

2011年2月25日にhudson勉強会やります。

HudsonでDVCSをつかうと

  • ヒエラルキー構造が持てる
  • pre tested commit
    コミット前のテストが可能

より柔軟な開発環境を構築可能

LT4. 「ビューティフルなデバッグの話」(かわにしさん)
「beautiful code」、「why programs fail」より「差分デバッグ」

git bisect

テストプログラムを作成して、どのリビジョンからテストが失敗するかを二分検索で見付け出してくれる。

後説

今日のメモ:
大福ロシアンルーレット(いちご=はずれ、バナナ、栗、わさび)の大当たりである、「わさび入り大福」は4つの中でいちばん値段が高い