覚書程度のログなので、間違えてても気にしないでください。
あ、でもほかの人もみれるから、なんかまずそうなら、連絡ください
--以下ログ
かおるんさん
o 事例紹介
+ こないだ収束したプロジェクトの紹介
+ 環境
# C#
# Trac
# Suvcersion
# Hudson
# TestLink
+ 人数
# 4人
+ 期間
# 半年
+ ついこないだ片付いた
o 実績
+ チケット
# チケット701
# Suv リビジョン2000ぐらい
o テスト
+ テストにテストリンクを使うと、テストという工程が進みやすい
+ バグはガンガンチケットへ変換
+ チケットは開発者に戻り、修正
+ 修正後、Hudsonビルドが通る
+ 直ったバージョンでテスト
o ビルドするときにやったこと
+ ビルドのときにバージョンを組み込み
+ Svnにタグ付け
+ マイルストーンを設定して次のビルドに生かす。
o 利点
+ Trac
# やることの明確化
# ゴールを見えるように
# タスクの割り振りがしやすい（メンバーは処理しやすい）
# チケットの消化具合で、作業終了時間を調整できる
* 残業の必要性を判断できる。
+ Subversion
# 最新のソースを探す必要は無い
# 確実に元に戻せる保証がある
* 余計なコメントを消去できる（ソースがきれいになる）
# brunchを使うことで、複数人数の開発が楽になる
# コミットフックでTracと連携
* チケットにリンクすることで作業履歴を残せる。
+ Hudson
# 『自分の環境でビルドできない』を防ぐ
# 誰でもビルドを行うことが出来る（ボタンをワンクリック）
* デイリービルドで品質アップ
# リリース可能な状態のソフトを常に取りだせる
+ TestLink
# TestLinkは、Test用Tracと同じだよ！
# 何をやるかはTestLinkに集約できる
* テストケースの管理
* テストの実行
* テスト結果の管理、集計
# TestLinkの実行結果から、Tracのチケットリンクが出来る
o 今後
+ Hudsonを中心とした、単体テストに対して自動的に結果反映していく
+ 「簡単に出来ないことをお任せできる」システム
o まとめ
+ ツールを駆使することで、TiDDを進める環境を作れる
+ ツールに対してソフトで肉付けしていけば、もっと良い開発環境に。
たかやまさん
o 赤本かきました。
o 8末に第二版 お願いします。
o DB構成まで説明
o 0.12のことにも触れています
o Trac 0.12 の 説明
+ 10月1日リリース（？）
+ 新機能
# マルチリポジトリ
# trac-adminコマンド
* 添付ファイル
* 設定
# 国際化
* Officialで日本語サポート（日付に問題？）
+ 翻訳
# 日本語翻訳作業
* Shibuya.tracにやり方が！
* 誰か手伝って
* 翻訳めんどくさい
* 環境、Unix
* 検索で [Trac0.12 翻訳] で SF検索
☆あきぴーさん
o Trac、redmine の機能比較
+ TiDDに必要な必須機能
o アジャイル開発の特徴
+ 長短期間の繰り返し型開発
# XPが2週、SCRUMは4週でまわす
# 頻繁に繰り返すので、要求改善をフィードバックしやすい
# リリース作業のリスクに早期対応できる
+ 開発作業の自動化
+ メインラインモデルによる平行開発
# 複数のコードラインが走っている
# burunch（安定）とtrunk（追加）にわけて開発していく
+ アジャイル開発は複雑なインフラが必要
o アジャイル開発の課題
+ 頻繁に変わるタスク管理
# 頻繁にリリースするので、いてレーション管理が大変
# アナログタスクボードだけでは進捗管理しづらい
+ 継続的な修正による変更管理
# 頻繁な機能追加を制御するのは難しい
# タスクボードだけでは不十分
+ 複数のコードラインを常時保守する平行開発
# 品質の保守
# BrunchとTrankへのマーー時
+ TiDDはこの問題点を解決するための手段！
o チケット駆動開発とは
+ BTSののチケットをXPのタスクカードのように使う
+ 障害、仕様変更、作業もチケットで扱う（Issue Tracking）
# 作業状態、進捗をチケットで一元管理する
+ ソースの変更をチケットと関連付ける
# ソース修正 -> チケット
# 運用保守時に修正理由を追跡しやすい（できる）
+ 平行開発をチケットで管理する
# 新規（trunk）と分岐（brunch）でチケットを使い分ける
o チケット駆動開発の運用サイクル
1. バージョンを作る
2. チケットの作成
3. チケット解決
4. バジョン付けでリリース
5. バージョンに対しての振り返り
6. ユーザーから、改善要望、障害発生 のフィードバック
o ポイント1 : チケット
+ Q
# チケットは仕様書？
# チケットの粒度
# チケットの乱発放置しない運用
+ A
# チケットは作業指示書
# チケットは要件管理に使える、チケットをストーリーカードに（？）
# チケットは、1日から5日程度で片付くレベル
# 複雑タスク、遅延タスクは、分割統治
# 定期的にチケットの棚卸し（一週間に一回程度は必要）
# チケット保守派、現場リーダー
+ Redmine
# うまく書けば、進捗管理まで可能
# チケットとソースのリンク
+ Trac
# チケットの相互リンクが無い
# 開始日/終了日/工数/進捗率が無い -> trac.iniで追加できる
o ポイント2 : ワークフロー
+ Q
# 課題管理や問い合わせ管理がやりにくい
+ A
# ワークフローの種類を増やす
# 担当者の作業状態を、ステータスと対応付ける
* 作業者とテスターのリンクとか
# 振り返りMTでワークフローを見直す
* 状況に応じた打ち合わせをフィードバック
* イテレーションで改善していく
+ Redmine
# ワークフローの管理画面がある
* 簡単に増やせる
* ロールによって、ステータスに権限をかけられる
+ Trac
# 4種類
# trac.iniで修正できるが、修正が難しい
o ポイント4：プロジェクト
+ Q
# 複数プロジェクト機能はどのように使う？
# 大規模案件でもTiDDを運用できるか？
+ A
# 5人以下のサブチーム単位でプロジェクトを作る
# チームは、コードライン/モジュール/ワークフロー/お客さん問い合わせ等で分割する
# 大規模プロジェクトでは、チケットの管理だけのリーダーを置く（全てのチケットを管理する）
# チケットの棚卸しは、課題管理会議（CCB）で決定する（試行錯誤中）
# 並行開発のタスク管理には、
+ Redmine
# プロジェクトの親子関係を作れる
# サマリを使って管理していく
+ Trac
# 単一プロジェクトでは使えない（プラグインで使える）
o ポイント4：イテレーション
+ Q
# マイルストーンとバージョンの違い
# TiDDをアジャイル開発に適用する注意点は？
+ A
# マイルストーンは、進捗報告のタイミング
* Tracはマイルストーンをリリースタイミング？
# バージョンはリリースのタイミング
# ロードマップをイテレーション計画とみなす
# イテレーションをリリース予定のバージョンで管理する
# 小刻みに終了履歴を残していく
+ Redmine
# イテレーションとバージョンを同一視するのがミソ
# 変更履歴はイテレーションの終了履歴になる
* 終了したチケットの消化を確認できる。
# 見かけ上の進捗と、実際の進捗が見れる
+ Trac
# マイルストーンとバージョンが厳密に区別
# マイルストーンの終了日を過ぎたらロードマップから消える
o ポイント5：ソース管理と連携
+ Q
# チケットとソースを連携する方法は？
# ソース管理と連携しなくていいですか？
+ A
# Refs と fixes をうまく使う
# チケットなしのコミット不可ルールを手低するのが重要
# リリース履歴がチケット経由のソース修正履歴になる
+ Redmine
# リモートSCMをサポート
# SVN以外のSCMとも連携できる
# redmineは、refsとfixes の役割を明確に分けられる
+ Trac
# リモートSCMをサポートしていない
o ポイント6:レポート
+ Q
# MSProjectの進捗管理と連携しずらいけど、なぜ？
# 進捗報告を自動生成できないですか？
+ A
# 顧客向けの進捗は、ストーリーカード
# TiDDはタスクカード
# BTSのチケット集計機能を活用
# チケット入力さえ徹底できれば意思決定情報を出力できる
* システムのレポートをチケットの情報から抽出できる
+ Redmine
# tracのようなクエリ機能が無い
# 工数集計の機能が弱い
# 集計画面で作業の滞りが一目で分かる
+ Trac
# レポート機能はTracが優れている
o TiDDで必須な機能
+ 柔軟なワークフロー（重要）
+ 進捗がわかるロードマップ（重要）
o TiDDのプラクティス
+ タスクはチケットに分割して統治
+ チケットファースト
+ チケットで分割統治
+ 小規模リリース
+ ふりかえり
o まとめ
+ BTSをアジャイル開発へ応用していく
+ TiDDを運営支援システムへ
# PLはチケット集計機能で得られた進捗品質情報を意思決定に使う
+ TiDDを日本発のアジャイル開発へ発展させたい
# ベストプラクティスをまとめたい！
はっさくさん
o TiDDの先に（Trac Redmine の活用事例）
o 上司へのアプローチに
o 開発は経営の始まり
+ 開発は、始まった時点でお客さんの価値を作り出している
o 開発のライフサイクルを通じて、TiDDを運用していく
o アプローチ
+ 実績を入れておけば、EVMも出力可能
+ 工事進行基準に対応可能
# 途中までの価値と進捗を残せる
o TiDO（チケット駆動運用）
+ ITILをredmineで実現できる
o 抽象化と実践
o 現実的に適用できることから実行していく
o 抽象化して、出来る部分から
o 目的に応じてフレームワークを構築していく
o ツールは使わなくても出来る -> 便利だから使う
o Samll start & Quick win
o ひとつ離れた視点からのTracやRedmine
☆まちゅさん
o ウォーターフォールがこの先、生き残るには
o TiDDの名付け親
o 結論
+ この先いらなくないか？
o TiDD
o さかのぼる水
o フィードバックを認める
o ドキュメント管理にもTiDD
☆パネルディスカッション
おかもと さん
こえだ さん
まちゅ さん
あきぴー さん
はっさく さん
o Keep
+ 社内標準とかを打破できるなにかにならないか
+ チケットに仕様を展開することで、数えられる仕様を。
+ 品質保証部門と開発部門の対立を和らげる
# 初期段階からテスターを巻き込む = テストと一体化した開発
+ 試験状況の管理を自動化したいから使った、すごい楽になった
+ 開発で他の人の作業が見える
+ 開発者がやりやすい。
+ 若い人ほど慣れやすい。
+ イテレーションのリズムを生み出す（振り返りのタイミングを作り出す）
+ 実績をいれることで集計しやすい（実績、集計の自動化）
o Problem
+ だんだんめんどくさくなって来る（そんなとこま入れるのか？）
+ チケットを使わない人との連携の問題（中継者の実績で誰の問題かわからなくなる。）
+ Webでいちいち入れるのがめんどくさい
+ 出力も、いまいちきれいに出ない
+ 要求管理に使うには、TiDDが回らない
# ストーリーカードをチケットに乗せられるか？
+ チケットの粒度
# PM（PIMBOK）の世タスクの粒度は80時間なので合わない
# いかにしてリンクさせるか？
o Try
+ TiDDやってみたい が 知名度が無い
+ TiDDを当たり前にしていきたい
+ チケットを種類で集計して、発信していく
+ ソースコードのレビューとチケットの連携
# Redmineのプラグインに存在する
+ 現場の意思決定が出来るシステムまで昇華させる
+ 出来るプログラマ + 出来るテスター の開発
+ 上司に紹介して、状況判断できるだけのツールへ
o 質問
+ TestLinkへ、Excelから乗り換えるメリット
# 意見
* 画面遷移がやりづらい
* 入力しずらい
# 反論
* Excelだと集計が大変なので、タイムラグが発生
* テストリンクに合う形式で作っておいて、マクロで一括インポート
* 繰り返しテストするときに、バージョンを通しての集計などが可能
o テストは全体を網羅するようにたてて、弱い部分をテストしていく
+ Web製作で1個の作業 + チケットがリンクしていくときに、一個のチケットを複数の人間で管理するには？
# 流れが直列であれば、ワークフローでやれば良いと思う。
# 担当者が自分のワークフローを行っていく（担当者ごとにチケットを振っていく）
# 成果物チケットに対して、タスクチケットを作っていく
* マネージャーは成果物のみを見ておくことで、煩雑さを軽減
# チケットの状況、サマリーをメールで飛ばしたい
* 朝会で対応できる（5分でいいから）
* 進捗は分かりづらいので、あと何日で終わるのかを意識してみる。
* チケットファーストの意識
Powered by ScribeFire.
