挑戦の道具としてのチケット駆動開発(長編版)

9,531 views
9,474 views

Published on

第50回 SEA関西プロセス分科会発表資料
2012年12月1日

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

No Downloads
Views
Total views
9,531
On SlideShare
0
From Embeds
0
Number of Embeds
7,348
Actions
Shares
0
Downloads
29
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

挑戦の道具としてのチケット駆動開発(長編版)

  1. 1. 挑戦の道具としての チケット駆動開発 株式会社SRA 阪井 誠
  2. 2. 自己紹介• 阪井誠(さかば、Twitter: @sakaba37)• ソフトウェアプロセス、チケット駆動開発(TiDD)、 アジャイルに興味を持つ「プロセスプログラマー」• 研究開発から現場まで、論文、書籍、雑誌など 2
  3. 3. 本の内容と発表内容TiDDの基本、 障害管理、構成管理、 Mantisの運用例、障害管理からTiDDへ、プロジェクトを成功に導く、アジリティの向上、 アダプタブルWF開発、アジャイルブームを超えて、 高度な運用方法、FAQとアンチパターン集、 テーラリング、 3
  4. 4. ソフトウェア業界のパラダイムシフト• 1990年代に始まった• ネオダマという標語によってソフトウェアハウスは SI erに変わった• 高機能ソフトの開発が容易になり、自由度が増し た反面、リスクが増えた• 技術者の守備範囲はソフトからシステムになり、 今、ビジネスに広がりつつある• 常に新しい分野へのチャレンジが求められるよう になった 4
  5. 5. 1995年の発表より阪井,松本,鳥居, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム95論文集,1995.
  6. 6. 技術者の責任範囲• 開発の効率化とともに責任範囲は広がった – ビジネスは広がったが純粋なソフトウェア開発が 減少した ビジネス ソフトウェア ハードウェア ネットワーク ネオダマ Web クラウド 6
  7. 7. 要求の不安定さ• ハンフリーは機能・インタフェース・環境の変更は 管理されないと開発は不安定になるとした • Watts S. Humphrey, ソフトウェアプロセス成熟度の改善, 日科技連, 1991. 不安定な要求 誤解された要求 未知の要求 大体わかっているか 実現するために必 知っているつもりが、 もしれないが、詳細 要な詳細を理解して 使ってみて違いに気 は流動的 いない づく• プロトタイプ、分離、段階的な開発など、アジャイル やオブジェクト指向につながる提案をしているが どのように管理して解決するかを示していない
  8. 8. パラダイムシフトを生き抜くには• 環境、フレームワーク、ユーザーインタフェース、 ビジネスは日々変化している• ソフトウェア開発は、常に挑戦!• 開発中にノウハウやアイデア、気づきを蓄積し、 共有し、活用しないといけない解決法の一つとして、チケット駆動開発を挑戦の道具として活用する方法を提案します 8
  9. 9. 挑戦の道具としてのチケット駆動開発 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)• 挑戦時の履歴をその後の開発につなげます• 開発者の気付きをチケットに記録します• 協調作業を支援してプロジェクトを活性化します 9
  10. 10. 発表内容• ソフトウェア業界のパラダイムシフト – 技術者の責任範囲 – 要求の不安定性• チケット駆動開発 – チケットによる管理 – ツール連携による自動化 – チケットによるコミュニケーション• 挑戦の道具としてのチケット駆動開発 – 挑戦の道具に必要なもの – チケット駆動開発のテーラリング – 課題と可能性 – 事例 10
  11. 11. TiDDのはじまり Tracブーム• masuidrive的プロジェクトの方針(2007) http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/• まちゅ, 「もうひとつのTDD」, ITpro Challenge のライト ニングトーク http://www.machu.jp/diary/20070907.html#p01• Shibuya.Tracキックオフ チケット駆動開発 誕生• XPJUG関西 TiDD勉強会発足 (2008)• 「Redmineによるタスクマネジメント実践技法」(2010)• RxTstudy、Shinagawa.Redmine(2011)• 「チケット駆動開発」(2012) : 11
  12. 12. チケット駆動開発• ITS(BTS)のチケットで障害、課題、タスクを 管理して個人のタスクとプロジェクトを管理する• 構成管理、Wiki、継続的統合などツールを チケットに連携させて自動化する• プロジェクトの情報をチケットに関連付けて 管理することで、コミュニケーションを支援する 12
  13. 13. チケットによる管理チケットシステム(ITS) プロジェクト 親チケット 障害・課題・タスク ステータス 継続チケット 種類とロール毎のワークフロー レポート、カスタムクエリ、 関連チケット ロードマップ、ガントチャート 等で参照できる
  14. 14. チケット一覧(例:Redmine) SQiP2009発表資料より ©小川明彦, 阪井誠 14
  15. 15. ガントチャート SQiP2009発表資料より ©小川明彦, 阪井誠 15
  16. 16. ワークフロー設定(例:Redmine) ソフトウェア開発のワークフローは BTSのワークフロー機能で 制御できる ユーザ権限と チケット種類の単位で ステータスの現在・移行先を指 定する ステータスの移行先ス現 在 の ス テ ー タ SQiP2009発表資料より ©小川明彦, 阪井誠 16
  17. 17. ツール連携 作業、担当、ステータス、進捗 開始、終了 refs #チケット番号 fixes #チケット番号 コメント バージョン管理 ITS ツール 17
  18. 18. ツール連携とチケット チケットシステム(ITS) CIツール 実行結果 親プロジェクト 参照 チケット 連携 プロジェクト 親タスク/ストーリー バージョン管理 タスク 参照 リビジョン リビジョン ステータス リビジョン 連携 リビジョン チケットの種類とロール毎のワークフロー 継続タスク構成管理、Wiki、 参照CIツールなどを Wiki 関連タスクチケットに連携
  19. 19. チケットによるコミュニケーションの支援 チケットシステム(ITS) CIツール 実行結果 親プロジェクト 参照 チケット 連携 プロジェクト 親タスク/ストーリーバージョン管理 タスク 参照 リビジョン リビジョン ステータス リビジョン 連携リビジョン チケットの種類とロール毎のワークフロー 継続タスク議論や更新を 参照メール、RSS、 Wiki 関連タスクプラグインで通知できる
  20. 20. チケット駆動開発の効果ツールを有効活用してプロジェクトの負担を減らす• ツールが想定するプロジェクトに近づく• 過去: – 履歴の蓄積(経緯の確認、ノウハウの利用)• 現在: – 障害、課題、タスク、実行結果の管理 – 情報共有、自動化、コミュニケーション• 未来: – 計画、備忘録、リスクの見える化 20
  21. 21. 発表内容• ソフトウェア業界のパラダイムシフト – 技術者の責任範囲 – 要求の不安定性• チケット駆動開発 – チケットによる管理 – ツール連携による自動化 – チケットによるコミュニケーション• 挑戦の道具としてのチケット駆動開発 – 挑戦の道具に必要なもの – チケット駆動開発のテーラリング – 課題と可能性 – 事例 21
  22. 22. 挑戦の道具に必要なもの• 新しい環境、実装方法、アプリケーションに挑戦 するには、以下の点を考慮しないといけない – 気づいたことが共有されること – 少ない経験が蓄積されること – 蓄積した経験が生かせることふさわしいチケット駆動開発の運用方法が必要 22
  23. 23. テーラリング1: 気づいたことが共有されること • チケットが容易に起票できるようにする – 起票の権限をメンバーに与える – ワークフローの制限を少なくする• チケットの種類や属性を増やしすぎない – 考えなくてよいようにする – 記入項目を減らす• リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipse 用のMylynプラグイン – コミュニケーションのタイムラグ減ると利用が増える 23
  24. 24. テーラリング2: 少ない経験が蓄積されること• チケット駆動を習慣づける – 基本的な教育 – メリットを感じさせる – 備忘録としての利用 ハーケン(釘)• 利用に向けた支援 カラビナ(止め具) ザイル(ロープ) – カスタムレポートの用意など環境整備 – アドバイスのための棚卸し – ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など) 24
  25. 25. テーラリング3: 蓄積した経験が生かされること• 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはWikiにまとめる• 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする• 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム 25
  26. 26. 自律的なチーム• サーバントリーダーシップ – コマンドコントロールをやめ、 メンバーが能力を生かせるように支援する• マクロマネジメント – マイクロマネジメントをすると依存するようになり、 自律性が失われる• 濡れぞうきんはしぼらない – 本田宗一郎氏がIIJ鈴木幸一社長に送った言葉 – ガチガチの管理からは柔軟な発想は生まれない 26
  27. 27. 課題と可能性• CBR(Case Based Reasoning)の経験による問題 解決する際にはインデックスが重要とされている – 現状では日々の情報整理が必要 – チケット駆動開発の事例報告が少ない – より多くの事例を集めて整理したい• 挑戦の道具としての活用でリスクが低減できる可 能性がある – ソフトウェア開発は常に挑戦だと認識する – チケット駆動開発を活用する – 発想力・提案力のあるチーム作りをする 27
  28. 28. TiDDの事例 そこには山がありました! 28
  29. 29. 概要• 文教パッケージのカスタマイズ(最大8人x1年) o 短納期 & 仕様の決定遅れ・変更 o スキルは高いが経験者が少ない(リーダは途中交代) o オープンフレームワークの初めての組み合わせ (サブシステム、ミドルウェアのバージョン) o 義務感と不安、重苦しい雰囲気、閉塞感、、、 o 守りに入るので、コミュニケーションが悪いシステムテストの時期になると、計画外の環境構築やリリース準備作業が明らかになった(環境に関連するバグも、、、)⇒ そうだ!チケット駆動開発をしよう! 29
  30. 30. オープンなフレームワークの苦しみ長所• 同じようなコードが減る• 個別の業務要件に対する固有の開発だけでよい短所• お約束が多い複雑な作業で、気が抜けない• 工夫できる余地が少ない• 少人数で大規模なシステムが作れてしまう• セキュリティ対策で実行環境の構成は日々変化 ⇒ 煩雑なのに情報が少ない、、、大変! 30
  31. 31. TiDDの実施方式• アダプタブルウォーターフォール(補完型TiDD) • WBSと併用(と言っても更新作業は全てチケットあり)• オープンな運用 • だれでもチケットが作成できる• システムテスト以降• システム全体• メンバー全員• trac(単独) ・・・ SRA共通開発環境(trac,subversion,mailmanの仮想環境)
  32. 32. チケット駆動開発の導入• 宣言と実行 「 バグだけではなく、ソースを触るときや、WBSにない作業をするときは、 チケットを登録してください!」 ハーケン(釘)• 環境の準備 カラビナ(止め具) o レポート(チケットの一覧)の作成  bugのみ、 taskのみ、 その他、など ザイル(ロープ) o 権限の追加  tracの権限の設定は堅いので、チケットを修正できるようにmember にTICKET_ADMINの権限を与えた (リスクを考慮して設定してください)• 教育 • パッケージチームとのQAの経験はあった 32
  33. 33. 結果• チケットの数(BUG以外) o システムテスト:31 o 本番環境構築:42  データの準備、環境準備、BUG関連で増えた作業、 細かな仕様変更など、手順書にない1回だけの作業• 作業漏れ減少!納期までに作業が完了! (知らないこと、気付かないことはできませんでした、、、orz)それ以外にも、メンバーに変化が、、、 33
  34. 34. 目が輝いた! サブリーダ(クラス)なのに遠慮をして いたメンバーが、生き生きしだした• 「チケットを切ってもいいですか?」 ⇒ 義務的な作業からの解放• 「チケットを切っておかないと忘れてしまう!」 ⇒ すくに使いこなしていた• 「ちゃんとクローズしてね」 ⇒ 他の人に指導をしていた!• 「残っているチケットが多くてわかりにくいから整理 しますね」 ⇒ 今後のことも考えている
  35. 35. 事例のまとめ• システムテスト以降にTiDDを導入• 備忘録のつもりで気づいたことをチケット化した• 手順はWikiにまとめた• 計画外の作業を管理できた• 作業を見える化することで コミュニケーションが向上した• メンバーが前向きになり、 プロジェクトが元気になった 35
  36. 36. 注意すべき点o チケットがルーチンワークでないと登録を忘れがちo 他のチケットがないときにチェックを忘れて実施漏れ ⇒ 粒度の大きいチケットの後で発生 ⇒ 粒度が小さいとリズムが生まれて、発生しにくい• 棚卸のバランス ⇒ 防げるが自主性も大切!「チケット見てる?」• クローズしにくいもの (担当がない、チェックリスト的) ⇒課題、リスクに多い。棚卸し、 Wikiを利用する• 気が付かないことは実施できない ⇒ 自由な雰囲気、経験者への依頼、情報収集 36
  37. 37. おわりに• パラダイムシフトは続いている – リスクは増え続け、ソフト開発は常に挑戦である• チケット駆動開発 – プロジェクトの情報を集中管理 – 自動化やコミュニケーションの支援ができる• 挑戦の道具としての利用 – 気づきや経験を蓄積して活用 – 自由で自律的なチーム作りが重要=> ぜひ皆さんも活用してください 37
  38. 38. おわり挑戦の道具としてのチケット駆動開発

×