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.

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

7,952 views

Published on

【公開】XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」: プログラマの思索 http://forza.cocolog-nifty.com/blog/2010/02/xp2010-d8d5.html

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」
XP祭り関西2010 - XPJUG関西wiki
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%A3%D8%A3%D0%BA%D7%A4%EA%B4%D8%C0%BE%A3%B2%A3%B0%A3%B1%A3%B0

  • Be the first to comment

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

  1. 1. XP祭り関西2010 チケット駆動開発セッション 2010/2/6 XPJUG関西 (copyright2009 akipii@XPJUG関西) 1
  2. 2. セッションの目的 背景 2005年頃から第2期Agileブーム(Agile2.0と呼ばれる) Agile開発で時代を先取りするビジネス スクリプト言語、軽量フレームワークの普及 TDD、CI、PFなどのAgileプラクティスの伝播 SIerやツールベンダーがAgile開発に注目 しかし、実際の開発現場ではAgile開発の運用は難しい 目的 WikiやBTSを基盤にしたOSSのプロジェクト管理ツールを用いて、 Agile開発の運用を支援する その一例として、チケット駆動開発を説明して共有したい (copyright2009 akipii@XPJUG関西) 2
  3. 3. セッションのスケジュール 1. 2. 3. 4. 説明 チケット駆動開発のプラクティス集 by あきぴー 元気が出るチケット駆動開発 by 阪井さん チケット駆動開発を用いたソフトウェア品質改善事例 by 小枝さん 5. パネルディスカッション~チケット駆動開発の体験談 1. 倉貫さん、阪井さん、小枝さん、あきぴー(司会) 2. KPT形式で体験談を話して比較します 3. 質疑応答 (copyright2009 akipii@XPJUG関西) 3
  4. 4. チケット駆動開発の プラクティス集 2010/2/6 あきぴー@XPJUG関西 (copyright2009 akipii@XPJUG関西) 4
  5. 5. 自己紹介 HN:あきぴー 簡単な職歴 業務系Webシステムの開発部隊に所属 興味 チケット駆動開発(TiDD)、Redmine、TestLinkで アジャイル開発を改善する 活動コミュニティ XPJUG関西、SEA関西、TEF関西など (copyright2009 akipii@XPJUG関西) 5
  6. 6. Agenda アジャイル開発の特徴 アジャイル開発の特徴 アジャイル開発の課題 アジャイル開発の課題 チケット駆動開発の発端 チケット駆動開発とは TiDDがAgileになる理由 が になる理由 TiDDプラクティス集~ 個のプラクティス プラクティス集~10個のプラクティス プラクティス集~ まとめ (copyright2009 akipii@XPJUG関西) 6
  7. 7. アジャイル開発の特徴 超短期間のインクリメンタル型開発 イテレーション単位に頻繁にリリースする(小規模リリース) 顧客からのフィードバックに早期に対応可能 頻繁なリリースでビルド漏れ等のリスクに早期に対応可能 開発作業の自動化 テスト駆動開発(TDD)⇒単体テストの自動化 継続的インテグレーション(CI)⇒ビルド作業を自動化 メインラインモデルによる並行開発 リリースした本番運用のソースは本番ブランチとして生き続ける 次のMajorVersionで本番ブランチが切り替わる 障害修正はbranch、機能追加はtrunkに分けて品質を維持する (copyright2009 akipii@XPJUG関西) 7
  8. 8. アジャイル開発の課題 頻繁に変わるタスク管理 頻繁なリリースの為イテレーション管理が大変 アナログのタスクボードだけでは進捗管理しづらい 継続的な修正と頻繁なリリース管理 継続的なリファクタリングや機能追加を制御するのは難しい 短期間に順次リリースしていくのはやっぱり大変 複数のコードラインを常時保守する並行開発 一度リリースしたソースは本番ブランチとして生き続ける 常に本番運用・開発中の二つのコードラインを保守するのは大変 (copyright2009 akipii@XPJUG関西) 8
  9. 9. チケット駆動開発の発端 TiDDはTracのチケット管理から生まれた(まちゅさん) ITpro Challenge のライトニングトーク(2007/9) http://www.machu.jp/diary/20070907.html#p01 正式名称:Ticket Driven Development BTSを障害管理だけでなくタスク管理に使う(まちゅさん) Redmineでアジャイル開発を初めて実践できた(あきぴー) チケット駆動開発の略称「TiDD」 (えと~さん) 「TDD」だと「テスト駆動開発」と間違えそう チケット駆動開発はAjaxみたい (上田さん) 中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発 (copyright2009 akipii@XPJUG関西) 9
  10. 10. チケット駆動開発とは(1) 障害も仕様変更も作業もチケットで扱う (Issue Tracking) チケットの対象は、SW開発に関する作業全般 BTSチケットをXPのタスクカードのように扱う BTSの運用対象を 拡大する (copyright2009 akipii@XPJUG関西) 10
  11. 11. チケット駆動開発とは(2) 成果物の変更をチケットで追跡する(Ticket Tracking) チケットへ構成管理情報を付与する チケット経由で要件からビルドモジュールまで追跡可能 見積/実績工数・作業期間をチケットで追跡も可能(Time Tracking) (copyright2009 akipii@XPJUG関西) 11
  12. 12. チケット駆動開発とは(3) 並行開発をチケットで管理できる 新規開発(trunk)とその分岐である本番運用(branch)で チケットを使い分ける マージ作業とその発生源の修正作業のチケットを連携し てワークフロー管理する (copyright2009 akipii@XPJUG関西) 12
  13. 13. TiDDがAgileになる理由(1) BTSのチケットをXPのタスクカードのように使う(阪井さん) XPのタスクカードをデジタル化する チケットへ作業内容、進捗情報を付与する 計画に基づかない突然のタスク管理がやりやすい XP BTS タスクボード チケット一覧 置き換え チケット タスクカード (copyright2009 akipii@XPJUG関西) 13
  14. 14. TiDDがAgileになる理由(2) BTSチケット集計結果をタスクボード・かんばんのように扱う(阪井さん) XPのタスクボード・かんばんは、物理的制約がある XPのタスクボード・かんばんは最新化・集計が面倒だが、TiDDはBTSに情 報を集約できる チケット集計結果を進捗報告だけでなく、PLの意思決定支援に使う かんばん (copyright2009 akipii@XPJUG関西) 14
  15. 15. TiDDがAgileになる理由(3) ロードマップをリリース計画のように扱い、小規模リ リースを運用する TiDDはXPの開発ライフサイクルに似たアジャイル開発! (copyright2009 akipii@XPJUG関西) 15
  16. 16. TiDDがAgileになる理由(4) チケットの作業をトピックブランチ上で行う手法もある MercurialやGitを使った並行開発 担当者はトピックブランチ作成後、ガンガン開発&修正する トピックブランチが検証完了になって初めてtrunkへpushする ブランチの作業状態をチケットのステータスで管理できる 複数のチケットの作業順とリリース順が異なる場合に有効 (copyright2009 akipii@XPJUG関西) 16
  17. 17. TiDDプラクティス一覧(あきぴーの提案) 1・チケットファースト ・チケットファースト 2・分割統治(プロジェクト・ ・分割統治 プロジェクト・ イテレーション・チケット) イテレーション・チケット 3・チケットはシンプルに ・ 次バージョンへ バージョン登録 問合せ Redmine チケット更新 集計表示 バージョンClose バージョン 8・見える化 ・見える化 9・朝会 ・朝会 10・ふりかえり ・ふりかえり 4・No Ticket, No Commit ! ・ 5・ペア作業 ・ 6・小規模リリース ・小規模リリース 7・棚卸し ・ (copyright2009 akipii@XPJUG関西) 17
  18. 18. 【1】チケットファースト 入力 チケット 出力  作業 ソース・設計書 担当 開発者 開発者はチケットを受け取ってから作業を開始する 入力:チケット 出力:ソース・設計書等 チケットをXPのタスクカードのように扱う チケットに作業内容・作業履歴・進捗情報・構成管理情報を残す (copyright2009 akipii@XPJUG関西) 18
  19. 19. 【2-1】チケットで分割統治(判谷さん) 粒度は1人が1週間以内に1個の成果物を作るタスク チケットは仕様書ではない。作業指示書である。 実際は1人日以内の作業が多い チケットを分割する観点 WBS単位(成果物の単位) ワークフローはチケットの種類で切り替える Redmineならトラッカー チケットを登録後に分割するタイミング 当初よりも作業が複雑だったと判明した 修正作業にリファクタリング作業が含まれる (copyright2009 akipii@XPJUG関西) 19
  20. 20. 【2-2】イテレーションで 分割統治 イテレーションとリリース予定バージョン を同一視する マイルストーンとバージョンを同一視 リリースしたバージョンはビルド番号を 付与する 例:Major . Minor . Build (. Revision) バックログのイテレーションを作る 顧客からの改善要望 内部課題のイテレーションを作る 開発チームの課題、ToDo 優先度の低いリファクタリング作業 (copyright2009 akipii@XPJUG関西) 20
  21. 21. 【2-3】プロジェクトで分割統治 プロジェクトに分割する観点 サブチーム単位(1チーム約5人) サブシステム単位(モジュール、コンポーネント) ワークフロー/工程単位 問合せや仕様確認と開発は分けた方が管理しやすい ブランチ単位(コードライン) 本番運用ソースと新規開発ソースは分けた方が管理しやすい Trunkへのマージ作業はbranchのチケットとリンクしておく 大規模プロジェクトでは、ノウハウが必要 サブチーム・工程単位でプロジェクトに分割してタスク管理 チケット管理だけの専門担当者(PL)をアサイン チケットの方針決定は、変更管理会議(CCB)で調整する (copyright2009 akipii@XPJUG関西) 21
  22. 22. 【3】チケットはシンプルに 最初から複雑なワークフローで運用しない 開発者が作業しづらいとチケットが更新されなくなる 厳格なワークフロー管理も大事だが、確実なリリースがもっと大事 リリース後のふりかえりMTで運用を少しずつ改善する 進捗率は運用ルールを決める チケットが停滞すると作業状況が分からなくなる 例:0%(未着手)-50%(担当)-100%(解決・完了) 例:0%(未着手・担当)-100%(解決・完了) 頻繁なタスク追加に耐えれるように運用する タスク漏れが一番怖い⇒チケットファーストが重要! チケットファーストが重要! 当初のWBSよりもチケットは必ず(かなり かなり)増える かなり 開発チームのゴールは、厳密な管理よりも確実なリリース 確実なリリース (copyright2009 akipii@XPJUG関西) 22
  23. 23. 【4】No Ticket, No Commit !(まちゅさん) (copyright2009 akipii@XPJUG関西) 23
  24. 24. 【4】No Ticket, No Commit !(まちゅさん) チケット無しのソースコミット不可! →チケットからパッチの理由を検索可能 (copyright2009 akipii@XPJUG関西) 23
  25. 25. 【5】ペア作業 担当者の作業を チケットの状態遷移図 で管理できる チケットは2人以上の担当者がキャッチボールして終わる 開発者がバグ修正後、テスターがバグ検証する 開発者が作業完了後、管理者が承認する 開発者が仕様を質問後、設計者が回答する (copyright2009 akipii@XPJUG関西) 24
  26. 26. 【6】小規模リリース 2~4週間の間隔で、小刻みに機 能拡張しながらリリースする リリース計画をあらかじめ立てて おく リリースのタイミングは、イテレー ションに属するチケットが全て終 了ステータスになること リリースバージョン、終了チケット はChangeLogに残る 自然に繰り返し開発&並行開発 になるのがポイント (copyright2009 akipii@XPJUG関西) 25
  27. 27. 【6】小規模リリース 2~4週間の間隔で、小刻みに機 能拡張しながらリリースする リリース計画をあらかじめ立てて おく リリースのタイミングは、イテレー ションに属するチケットが全て終 了ステータスになること リリースバージョン、終了チケット はChangeLogに残る 自然に繰り返し開発&並行開発 になるのがポイント (copyright2009 akipii@XPJUG関西) 25
  28. 28. 【7】棚卸し 定期的にチケットの状態を最新にする(東さん) チケットが乱発・放置・停滞されないように保守する PLがチケット管理の最終担当者 大規模プロジェクトでは変更管理会議(CCB)を開く ステークホルダー全員でチケットを棚卸しする チケット管理の専門担当者が議長になって開催する サブチーム間でチケット解決を調整する時もある 棚卸し会議はリリース計画を立てる場でもよい 今後のリリース予定のバージョンを立てる チケットの優先順位をステークホルダー全員で議論する (copyright2009 akipii@XPJUG関西) 26
  29. 29. 【8】プロジェクトの見える化 例:Redmine_chartsプラグイン http://github.com/mszczytowski/redmine_ch arts ↓ ・スケジュール差異(SV)を表示 ・最終的にはEVMも可能(?) BTSのチケット自動集計・Wiki機能を使って見える化する バーンダウンチャート、予定・実績工数比較、活動ログで進捗管理 Wiki、フォーラム、ニュースで情報共有 (copyright2009 akipii@XPJUG関西) 27
  30. 30. 【9】朝会 1日の初めに各自の仕事と役割を確認する ロードマップを見ながらチームのゴールを確認 チケットの相互関係から連携作業を意識付け 一人の遅れを皆で支え合う気持ちが大事 朝会は進捗報告の場ではない BTS上でいつでも進捗確認できる リスクは嗅ぎ取るが、問題解決は後で行う 割り込み作業や隠れ作業をなくす 開発者の不安を聞き取り、内部課題へチケット登録 問題解決の方針は関係者だけの会議を開く (copyright2009 akipii@XPJUG関西) 28
  31. 31. 【10】ふりかえり リリース後にKeep,Problem,Try にまとめる チケット集計結果があると効果的 メンバー全員の意見を残す 特に若手・女性が発言しやすいよ うに チケットやワークフローの運用を見 直す絶好のタイミング KPT 開発者の意見は大切 (ふりかえり) 少しずつプロセス改善する 一気に大きく運用を変えるのは難 しい ProblemからTry、TryからKeepへ 移るように (copyright2009 akipii@XPJUG関西) 29
  32. 32. まとめ ツールがサポートすれば、 行動が変わっていく。 行動が変わっていく。 行動が変われば、 行動が変われば、 考え方も変わっていく。 チケット駆動開発でアジャイル開発を実践してみよう BTSがあれば誰でも運用できる TiDDはレコーディングダイエット 記録するだけでプロセス改善できる SW開発の諸問題はソフトウェアで解決していこう! 開発の諸問題はソフトウェアで解決していこう! (copyright2009 akipii@XPJUG関西) 30

×