Your SlideShare is downloading. ×
0
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
障害管理からチケット駆動開発へ~BTSから始まる進化の歴史
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

障害管理からチケット駆動開発へ~BTSから始まる進化の歴史

10,411

Published on

DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 …

DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」
9月17日 DevLOVE関西2011CONNECT(大阪府)
http://kokucheese.com/event/index/16663/

【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 #devlove0917: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/09/devlove2011btsd.html

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,411
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. DevLove関西2011 RxTStudyのご紹介 Redmineとタスク管理を考える勉強会 2011/09/17 あきぴー@RxTStudy (copyright2011 akipii@DevLove関西) 1
  • 2. 自己紹介 HN:@akipii チケット駆動開発の本を出 版 (with @sakaba37) Redmineを使って、  チケット駆動開発による  Agileな開発方法について  解説しました 現在 絶賛販売中 (copyright2011 akipii@DevLove関西) 2
  • 3. RxTStudyの目的 Redmine x TaskManagement 勉強会の略称 「プロジェクト管理ツールRedmineによるタスク管理」に関 する関西のコミュニティ 発足人:@pinkmac, @kiy0taka, @hiroe316さんたち 日本にRedmineコミュニティを作りたい! 日本はTracが全盛(?) 「東の 東のTrac、西の 東の 、西のRedmine」と言われている (@nobiinu_and) 関東でも 品川Redmine 品川 コミュニティ発足 (2011/9/8) (copyright2011 akipii@DevLove関西) 3
  • 4. 第1回RxTStudyを開催 勉強会開催に至るまで(2011/7/30) @pinkmacさんのつぶやきが発端 @hiroe316さんが凄腕プロデュースで速攻確定 ATEND告知後、予約殺到でわずか1日で申込締切 日本で出版されたRedmine本の著者が勢ぞろい! Redmineの市場があることを再確認! の市場があることを再確認! (copyright2011 akipii@DevLove関西) 4
  • 5. RxTStudyでやりたいこと Redmineによるタスク管理の事例を共有 ITプロジェクトのタスク管理 情報システム部門、インフラチームのタスク管理 Redmineのパッチやプラグイン開発 Redmineに不足した機能はプラグイン開発 Railsの開発方法は@agilekawabataさんにレクチャして頂く (copyright2011 akipii@DevLove関西) 5
  • 6. RxTStudyの情報 ハッシュタグ #RxtStudy でつぶやいてください 活動HP http://www.rxtstudy.net/ Facebookコミュニティページ http://www.facebook.com/RxTstudy (copyright2011 akipii@DevLove関西) 6
  • 7. 障害管理から チケット駆動開発へ BTSから始まる進化の歴史 2011/09/17 あきぴー@RxTStudy (copyright2011 akipii@DevLove関西) 7
  • 8. 本講演の目的 本来のチケット駆動開発(TiDD)とは何なのか? Togetter http://togetter.com/li/136570 自分がBugzillaでチケット駆動開発と呼ばれる でチケット駆動開発と呼ばれる 自分が でチケット駆動開発 以前のものをやっていた時には、 チーム外からは「ツール使ってるのね」という認識だけで、 軽量さと規律の両立の妙を、 そこにある軽量さと規律の両立の妙 そこにある軽量さと規律の両立の妙を、 なかなか理解してもらうことができなかった。 名前と体系化は重要ですね (@quicy) http://twitter.com/#!/quicy/status/69974630898745344 (1)チケット駆動開発へ進化した歴史を整理したい チケット駆動開発へ進化した歴史を整理したい (2)チケット駆動開発の進化の方向を見極めたい チケット駆動開発の進化の方向を見極めたい (copyright2011 akipii@DevLove関西) 8
  • 9. Agenda 障害管理の手法 Mantisの運用例 チケット駆動開発からAgile開発へ Agile開発への適用例 TiDDの可能性 SW開発の3種の神器 TiDDの効果 まとめ (copyright2011 akipii@DevLove関西) 9
  • 10. 障害管理の手法 Mantisの運用例 (copyright2011 akipii@DevLove関西) 10
  • 11. Excelによる障害管理の課題 バグ情報が散在して混乱しやすい バグが50個、100個以上増えると手に負えない Excelやメールに作業履歴が散らばっている バグの集計や報告書作りに手間がかかる バグ修正と検証のワークフローが複雑 一人の担当者に作業負荷が集中 担当者がたらい回しされてバグが放置されてしまう リリース管理が大変 Excelの管理台帳で障害管理Noとリリースタグを管理 リリース履歴から過去のバグを探しにくい (copyright2011 akipii@DevLove関西) 11
  • 12. Mantisとは PHPで作られたOSSの障害管理システム(BTS) 最新版:1.2.7 (2011/8) http://www.mantisbt.org/ LAMP、WAMP環境で動作 バグ管理に特化している 複数人が違う場所でも 障害報告票を更新可能 (copyright2011 akipii@DevLove関西) 12
  • 13. Mantisの特徴 バグの情報をチケットで一元管理 チケットに作業履歴を集約 過去のバグの検索や集計処理が楽 メトリクスを分析して品質管理 チケットのステータス遷移で制御 バグ修正と検証の連携作業をワークフロー管理 終了チケットをリリース履歴として残す チケットにリリース済み(予定)バージョンを付与 修正済のバグがどのモジュールに反映されているか判別 しやすくする (copyright2011 akipii@DevLove関西) 13
  • 14. Mantisの運用サイクル 障害報告票(チケット のライフサイクルに相当する 障害報告票 チケット)のライフサイクルに相当する チケット 登録 履歴表示 Mantis 制御 集計 更新 (copyright2011 akipii@DevLove関西) 14
  • 15. 【1】プロジェクト設定 複数プロジェクト 機能を持つ (copyright2011 akipii@DevLove関西) 15
  • 16. 【2】チケット登録 チケットの属性は障害報告票に特化している (copyright2011 akipii@DevLove関西) 16
  • 17. Mantisチケットの構造(1) チケットの基本属性はRedmineに似ている に似ている チケットの基本属性は 属性 内容 備考 担当者 バグ修正・検証の担当者 ワークフロー制御を参考 カテゴリ システムの機能・チーム名 全プロジェクトで同一 優先度 作業の優先度 未定・低・中・高・緊急・即時 重要度 バグの影響度 要望・些細・微調整・マイナー・メジャー・ クラッシュ・システム停止 再現性 バグの再現頻度 毎回・時々・不定・未試験・再現不可・ 不明 ステータス 作業ステータス チケットの状態遷移図を参考 要約 チケットの題名 報告者が記入 詳細 バグの詳細内容 再現方法 バグの再現手順 (copyright2011 akipii@DevLove関西) 17
  • 18. Mantisチケットの構造(2) Mantis特有のチケットの属性がある 特有のチケットの属性がある 属性 内容 備考 解決状況 修正結果 不明・実装済・差戻・再現不可・修 正不可・二重登録・修正不要・保 留・後回し プラットフォーム バグが判明した環境 プロフィール編集画面で修 正 OS バージョン 製品バージョン バグが判明した製品 バージョン 修正予定バージョン 修正予定のバージョン ロードマップに表示 修正済バージョン 変更履歴に表示 リリース済のバージョン (copyright2011 akipii@DevLove関西) 18
  • 19. 障害報告票に必要な属性 Excelの障害一覧を元に、普通は属性追加が必要 Mantisのカスタムフィールドで属性追加は可能 属性 内容 備考 原因詳細 バグの原因 設計者が記入 類似バグ有無 類似バグの調査有無 類似バグ詳細 類似バグの調査結果 修正内容 バグの修正内容 修正モジュール 修正モジュール一覧 単体テスト完了日 修正モジュールの単体テスト完了日 検証完了日 開発サーバーの検証完了日 受入完了日 UAT環境の検証完了日 (copyright2011 akipii@DevLove関西) 開発者が記入 設計者が記入 19
  • 20. 【3】ワークフロー制御 (copyright2011 akipii@DevLove関西) 20
  • 21. 【3】ワークフロー制御 バグの再現、修正、検証に適したワークフロー (copyright2011 akipii@DevLove関西) 20
  • 22. ステータスの意味 バグの状態を管理するために特化している ステータス 内容 ロール 新規 バグを報告 報告者 内容確認済 障害報告票を確認済 バグが再現するかどうか未確認 設計者 再現済 障害報告票の手順でバグが再現す ることを確認 設計者 担当者決定 バグの修正方針を立てる 修正担当者をアサインする 設計者→開発者 解決済 バグ修正して開発環境へ反映済 開発者→設計者 フィードバック 修正したバグが直ってないので差し 戻す 設計者→開発者 完了 バグ修正を検証済かつリリース済 設計者 (copyright2011 akipii@DevLove関西) 21
  • 23. 【4】No Ticket, No Commitの発端 障害報告票へソースの修正 履歴を残す運用が発端 履歴を残す運用が発端 ↓ テストや本番運用で発覚した バグは、厳格に変更履歴を 追跡する必要があるから (copyright2011 akipii@DevLove関西) 22
  • 24. 【5】レポート出力 (1) ステータスで色付さ れるので、バグの状態 が分かりやすい (2)検索条件はカスタム クエリで保存可能 (3)ExcelやCSV出力、印 刷をサポート (copyright2011 akipii@DevLove関西) 23
  • 25. Mantisチケットの属性×集計の関連表 (縦:機能×横:チケットの属性) ロール ワークフロー ステータ ス ◯ 解決状 況 ◯ ロードマップ ◯ 変更履歴 ◯ 修正予定 バージョン ◯ (解決済、 解決済、 完了) 完了 担当 者 修正済 バージョン 登録 日 更新日 (実装済 実装済) 実装済 最大放置日 数 平均完了日 数 信頼度成長 曲線 ◯ ◯ ◯ ◯ (完了以外 完了以外) 完了以外 ◯ ◯ ◯ ◯ ◯ (完了 完了) 完了 △ 障害管理に特化しているのでRedmineとは異なる とは異なる 障害管理に特化しているので (copyright2011 akipii@DevLove関西) 24
  • 26. 信頼度成長曲線 時系列の累積バグ数のグラフ システムのリリース判定条件に使う バグが出尽くしたらリリース可能と判断する (copyright2011 akipii@DevLove関西) (1)Mantisのバグ情報から信頼 度成長曲線作成ツール →Rubyでグラフ生成 http://ruby.g.hatena.ne.jp/ga ryo/20071017/1192593589 (2)SRATS(ソフトウェア品質測 定ツール) →MTBFを計算可能 http://www.rel.hiroshimau.ac.jp/~okamu/SRATS/manu al/intro.html 25
  • 27. 【6】ロードマップ ロードマップは リリース計画と同値 (copyright2011 akipii@DevLove関西) 26
  • 28. 変更履歴 (1)変更履歴はリリース履歴 変更履歴はリリース履歴 (2)解決状況=「実装済」の解決済 完了チケットのみ表示する 解決状況=「実装済」の解決済or完了チケットのみ表示する 解決状況=「実装済」の解決済  →修正しなかったチケットはモジュールに反映されていないから、 変更履歴に表示不要。 (copyright2011 akipii@DevLove関西) 27
  • 29. Mantisの利点と課題 突発的に発生するバグを管理しやすい 登録したバグの履歴を追跡できる バグの作業状態をワークフローで制御できる 既存の品質管理の技法が使える バグ収束曲線で品質やテスト完了時期を予測 BTSを仕様変更や課題の管理にも使いたい バグ修正のワークフローはSW開発の基本フロー WikiやSCMリポジトリ閲覧は別ツールが必要 情報共有のためのWikiや掲示板機能がない バグ修正のソース履歴を探す機能がない (copyright2011 akipii@DevLove関西) 28
  • 30. チケット駆動開発から Agile開発へ タスクはチケットに分割して 統治せよ (copyright2011 akipii@DevLove関西) 29
  • 31. BTSからITSへ ITSはBTSを拡張した課題管理システム 障害だけでなく、課題や要望に使う (Issue Tracking) Wiki、SCM連携の機能を含む Post-commit-hookでチケットとSCMリビジョンを紐付ける (copyright2011 akipii@DevLove関西) 30
  • 32. チケット駆動開発とは Tracのチケット管理から生まれた(@machu) http://www.machu.jp/diary/20070907.html#p01 正式名称:Ticket Driven Development (@machu, @hiroe316) BTS/ITSを障害管理だけでなくタスク管理に使う(@machu) チケット無しのコミット不可 (No Ticket, No Commit !) (@machu) TiDDをAgile開発へ適用できた (@akipii) BTSの運用対象を の運用対象を 拡大する (copyright2011 akipii@DevLove関西) 31
  • 33. (1)チケットはタスクカード BTSチケットをXPのタスクカードのように扱う(@sakaba37) チケットに作業履歴・進捗・構成管理の情報を付与する 計画外の作業や変更された作業をチケットで追跡しやすい タスクカード(例 タスクカード 例) タスク番号:21 ストーリー番号:11 開始日:2009/7/14 終了日:2009/7/17 予定工数:32時間 実績工数:28時間 説明:カート画面に売れ筋商品機能を実装 ノート:共通ライブラリを使う (copyright2011 akipii@DevLove関西) 32
  • 34. (2)チケット一覧はタスクボード BTSチケット一覧を のタスクボードのように扱う (@sakaba37) チケット一覧をXPのタスクボードのように扱う チケット一覧を チケット集計機能を進捗・課題・品質管理へ適用する ガントチャート、課題一覧、バグ収束曲線 PDF、Excel出力機能が重要 顧客もPMも帳票にこだわっている かんばん (copyright2011 akipii@DevLove関西) 33
  • 35. (3)柔軟なワークフロー管理 BTSのワークフロー機能を のワークフロー機能をSW開発全般のタスクへ拡張 (@akipii) のワークフロー機能を 開発全般のタスクへ拡張 複数人で連携する作業漏れをなくす (ペア作業 ペア作業) ペア作業 チケットのアクティビティ図 チケットの状態遷移表 チケットの状態遷移図 (copyright2011 akipii@DevLove関西) 34
  • 36. (4)SCM連携でトレーサビリティ (copyright2011 akipii@DevLove関西) 35
  • 37. (4)SCM連携でトレーサビリティ ・チケット無しのソースコミット不可 (@machu) ・成果物の変更をチケットで追跡する (Traceability) (copyright2011 akipii@DevLove関西) 35
  • 38. (5)バージョンはイテレーション ITSバージョンを のイテレーションと同一視する(@akipii) バージョンをXPのイテレーションと同一視する バージョンを 2~4週間単位にVerUpしながら機能も品質も改善していく (小規模リリース 小規模リリース) 小規模リリース モジュール) バージョン (モジュール モジュール →チケット (ITS) →ソース修正履歴 (SCM) へ追跡可能 (copyright2011 akipii@DevLove関西) 36
  • 39. (6)並行開発をサポート (@akipii) BTSの複数プロジェクト機能を並行開発に適用する 派生製品の開発プロジェクトをマッピング 複数のSCMブランチをマッピング 組織構造をマッピング 製品(派生元 製品 派生元) 派生元 SCMリポジトリ リポジトリ 派生製品 リリース ブランチ (copyright2011 akipii@DevLove関西) 37
  • 40. TiDDとAgileの関係 ロードマップをリリース計画のように扱い、小規模リリー スを運用する開発プロセス Redmineによるチケット駆動開発は、XPの開発ライフサイク ルに似たアジャイル開発! アジャイル開発! (copyright2011 akipii@DevLove関西) 38
  • 41. BTSとTiDDの対応表 BTS TiDD チケット 障害報告票 タスクカード (ストーリーカード ストーリーカード) ストーリーカード レポート 障害一覧 タスクボード (バックログ バックログ) バックログ ワークフロー バグ検証 作業全般 バグ修正履歴を追跡 成果物の変更履歴を追跡 バージョン リリース予定(済 リリース予定 済) バージョン イテレーション (スプリント スプリント) スプリント プロジェクト 工程単位 機能 トレーサビリティ 製品単位 ブランチ単位 TiDDはBTSの機能を流用したプロセス は の機能を流用したプロセス (copyright2011 akipii@DevLove関西) 39
  • 42. TiDDの可能性 SW開発の3種の神器 (copyright2011 akipii@DevLove関西) 40
  • 43. チケット駆動開発の意義 BTSをAgile開発のタスク管理へ適用 作業はチケットを起票してから始める(Ticket First) チケット無しの作業不可 (No Ticket, No Work) BTSのワークフロー管理をSW開発全般へ拡張 課題管理やインシデント管理にも適用 トレーサビリティで変更管理をサポート チケット無しのコミット不可 (No Ticket, No Commit) チケットで全ての作業を追跡する (Ticket Tracking) ツール連携で新しい運用方法を見出す BTS/ITS・Wiki・SCM・CIの各種ツールを連携 (3種の神器 種の神器) 種の神器 (copyright2011 akipii@DevLove関西) 41
  • 44. SW開発の3種の神器 (@haru_iida) ITS、SCM、CIの3つのツールの総称 ITS (Issue Tracking System) :課題管理 SCM (Software Configuration Management) :構成管理 CI (Continuous Integration) :ビルド管理 TiDDはツールを組み合わせた新しい使い方の一種 高速・高品質なSW開発を目指す 開発を目指す 高速・高品質な (copyright2011 akipii@DevLove関西) 42
  • 45. SW開発の3種の神器の概要図 課題管理 システム (@akipii) ソース 管理 (copyright2011 akipii@DevLove関西) ビルド 管理 43
  • 46. ITSとSCMの機能関連表  (縦:ITSの各機能×横:SCMの各機能) コードライン (trunk, branch) タグ (tag) リビジョン プロジェクト 製品単位 リリースブランチ単位 - - バージョン - リリース済バージョン - チケット トピックブランチ単位 - コミット単位 トレーサビリティを拡張させた考え方 (copyright2011 akipii@DevLove関西) 44
  • 47. 3種の神器の特徴 高速な開発になる要因 ITS SCM CI 高品質になる要因 ・タスクの変更に強い ・小規模リリース ・柔軟なワークフロー管理 ・強力なレポート機能 ・並行開発 (強力なブランチ管理 強力なブランチ管理) 強力なブランチ管理 ・強力なマージ機能 ・常時ビルド ・トレーサビリティ (変更はチケットで追跡 変更はチケットで追跡) 変更はチケットで追跡 ・常時リリース可能 ・テストの自動化 ツールを組み合わせると大きな威力を発揮する (copyright2011 akipii@DevLove関西) 45
  • 48. Continuous Deliveryへ進化 環境構築 DB DB ラストマイル問題 ↓ 本番環境への リリース作業が Agileでない でない データ移行 Continuous DeliveryはCIの進化形 受入テストやインフラ周りの自動化技術が出てきている AmazonEC2でサーバーのスケールアップを自動化 Vargantやveeweeで仮想開発環境を自動作成する Cucumberで受入テストケースをTDDのように書く(@agilekawabata) データ移行作業をデータベースリファクタリングとみなす (copyright2011 akipii@DevLove関西) 46
  • 49. TiDDの効果 自己組織化 (copyright2011 akipii@DevLove関西) 47
  • 50. 組織全体へTiDDを展開可能 どのチームもPRJ管理の手法は同じ プロセス標準化 管理の手法は同じ(プロセス標準化 どのチームも 管理の手法は同じ プロセス標準化) 作業を引継ぎしやすいので要員の流動化も図りやすい Redmineの複数プロジェクト の複数プロジェクト 機能で組織構造をマッピング 機能で組織構造をマッピング 運用ノウハウ を展開可能 トラッカーの分析が トラッカーの分析が 重要! ヘルプ (copyright2011 akipii@DevLove関西) 48
  • 51. 自律的な組織づくり チームの意思決定に必要な情報を提供(プロセス改善 チームの意思決定に必要な情報を提供 プロセス改善) プロセス改善 計画→実施→測定・評価という改善サイクルが生まれる メンバーの役割が変わる(自己組織化 メンバーの役割が変わる 自己組織化) 自己組織化 メンバーは自発的に作業し始める 従来型(WF) TiDD(Agile) 進捗管理 作業指示 課題解決 Excel Redmine 進捗報告 自発的に作業 ペア作業 (copyright2011 akipii@DevLove関西) 49
  • 52. TiDDが持つAgilityと規律 Agileな概念はツールの 機能で実装可能 な概念はツールの1機能で実装可能 な概念はツールの ツールの制約が規律 規律(Best Practice)をもたらす ツールの制約が規律 をもたらす ツールに慣れれば良い習慣が自然に身に付く 従来型(WF) TiDD(Agile) 【BTSに由来する規律】 に由来する規律】 進捗管理 作業指示 【従来の規律】 運用ルール 作業手順 No Ticket, No Commit No Ticket, No Work Ticket Tracking Excel 進捗報告 3種の神器 種の神器 (copyright2011 akipii@DevLove関西) 50
  • 53. まとめ TiDDはBTSのBest Practiceを引き継いでいる BTSは想定外のバグの管理から生まれた TiDDはBTSの機能をAgile開発に流用した TiDDでメンバーの自発性が出てくる TiDDはプログラミングそのものに集中できる環境を提供 プロジェクトファシリテーションと相性が良い TiDDはXPと同じくプログラマ復権運動 TiDDはPRJ管理の問題をソフトウェアで解決する PMが欲しがる要望はツールの1機能で実現可能 プログラミングで解決できる問題はAgile開発が得意 (copyright2011 akipii@DevLove関西) 51
  • 54. ご清聴 ありがとう ございました (copyright2011 akipii@DevLove関西) 52

×