オープンソースカンファレンス2009 Hokkaido Redmineで始めるチケット駆動開発 佐藤琢哉（nazo） http://labs.nazone.info/

1. PHP部の紹介も終わったところで

2. Redmineで始めるチケット駆動開発 佐藤琢哉 LOCAL PHP部

3. あれ、ここってPHP部の時間じゃ…

4. 技術的な話はほとんど出てきません

5. 開発手法の話なのでPHPプログラマにも安心して使えます

6. 自己紹介 佐藤琢哉 aka nazo 旭川出身 東京在住 株式会社RYUS所属(http://ryus.co.jp) rhaco-ja？ LOCAL PHP部 Hatena : nazone twitter/wassr : nazo

7. LOCALの人になりました

8. アジェンダ チケット駆動開発について Redmineについて 具体的な使い方 まとめとおまけ

9. そもそも何の話？

10. Redmine？チケット駆動開発？

11. 日本語でおｋ

12. タスク管理を効率的に行うための話です

13. わかりづらい説明

14. チケット駆動開発

15. チケット駆動開発？

16. チケット タスクの最小単位 例えば「検索フォームで未入力の状態で検索するとエラーになるので修正する」 例えば「新規登録画面を実装する」 バグ登録フォームで登録したバグ１つ バグ以外の新規開発もチケット

17. 一つのタスク＝チケット

18. チケット駆動開発 タスクをチケットの単位まで細かく区切って、それを消化していく開発手法 すべてのタスクがチケットとして存在するので、タスクの量がわかる チケットにステータスが付いているので、タスクの消化量がわかる

19. チケットの消化量＝進捗具合

20. どのくらい進んでいるかがチケットの量でわかる

21. プログラミングに限らず使える

22. 普通の進捗管理の問題点 誰が何してるのかわからない！ あの機能誰に振ったっけ？ あれ作るのに他の人の作業の完了を待たないといけない？ その機能大きいから他の人と分担させたいんだけど…え、全部に手をつけてるから分担できない？

23. 普通の進捗管理の問題点 どこまでの機能が完成予定なのかわからない 次回のリリースはどこまで含めるんだっけ？ あの機能は当然完成してるものだと思ってたんだけど…

24. それEXCELでできるよ！

26. EXCELガントチャートの問題点 ガントチャートだからそもそも１日単位でしかタスクをアサインできない １日に何時間振るの？ １日のタスクの順序は？ そのタスクは現在どういう状況？

27. EXCELガントチャートの問題点 そもそも修正が面倒 一人で全部設定するの？ 複数人でやったら誰がどこを編集したかわかる？

28. そこでチケット駆動開発

29. そして

30. チケット駆動開発のためのRedmine

31. 注意

32. チケット駆動開発で調べるといろいろ出てきますが

33. どれが正しい方法というわけではありません

34. 今回の紹介は私の個人的な体験に基づいて作成したものです

35. どれが正しいというわけではないので、皆さんの状況に合わせてご利用下さい

36. Redmineとチケット駆動開発

37. Redmine？

39. Redmineとは Ruby On Railsをベースに作られたIssue Tracking System （懸案管理システム：ITS） いわゆるtracとかMantisみたいなの チケットを登録して、チケットの管理を行うためのシステム

40. trac

41. Mantis

42. Redmineのいいところ 複数プロジェクトの管理ができる 多数の案件を抱えている人には必須 豊富な標準機能 チケット、Wiki、タイムライン、ガントチャート、カレンダー、リポジトリ、ファイル管理、etc… 標準で日本語対応

43. インストール方法とか http://redmine.jp/ に大体載ってます ryus.co.jpのスタッフブログでも少し書きました

44. インストールの説明とかしても仕方ないので

45. 実際の作業の流れを追ってみましょう

46. タスクの進め方

47. ワークフロー タスク発生 チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

48. ここから実際の流れ

49. タスク発生！

50. タスクをチケットとして登録

51. タスクをチケットとして登録

52. チケット登録時の説明を簡単にすると

53. １つのチケットはあまり時間がかからないように

54. チケットを見て疑問点がないように

55. 以上！

56. 以下詳細

57. タスクをチケットとして登録 ほどほどに細かく分ける 当然細かすぎてもよくない 最初は細かすぎると思うくらいでいいかも １つのチケットは１人の担当者で解決できるようにする ケースバイケース

58. タスクをチケットとして登録 時間がかかりすぎている、いつ終わるかわからない、と感じたらもっと細かくする 明らかにまとめたほうがいいと感じたらまとめる １つのタスクを解決するのに、別の大きな問題が発生したら、途中ででもチケットを分割する

59. １つのチケットは最大でも１日で終わるレベル

60. チケット入力フォーム

61. 入力フォーム説明

62. トラッカー チケットの大枠の分類。全プロジェクト共通

63. 題名 そのチケットの内容を的確に表すもの 短いよりは長いほうがいいが、長すぎないように 「検索が動かない」よりは「検索結果が0件になる」のほうがいい 「検索が動かない」だと、「ボタンを押しても反応しない」とか「次の画面が真っ白になる」とか「ボタンを押すと関係ない画面が表示された」という例も考えられる

64. 説明 そのチケットの内容を詳細に記述 以下の要素が必須 具体的な発生条件（わかる範囲まで調べる） URL 入力内容 その結果どうなるか 本来期待される動作 チケットを起こした後に担当者がチケットを起こした人に再度質問しないようにする

65. ステータス そのチケットの現状 とりあえず最初は当然「新規」

66. 優先度、担当者、開始日、期限日、予定工数、進捗、ファイル 説明不要

67. Watchers このチケットを監視する人 監視対象になると、マイページの「ウォッチ中のチケット」で確認できる 自分は起票者でも担当者でもないけど、そのチケットの進捗を確認したい時などに使う

68. 関連するチケット チケットを起こした後に設定可能 「このチケットを終わらせるにはあのチケットを先に終わらせないといけないよねー」みたいな時に設定する 片方で設定すると相互リンクされる

69. チケットを起こしたら

70. タスク発生 ワークフロー チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

71. 担当者を決める

72. 担当者はチケットが割り振られたら

73. タスク発生 ワークフロー チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

74. 優先度や期限などから作業順序を判断し作業を開始する

75. 担当者が作業中にするチケット操作

76. 進捗 通常は0%->100%で終了することが多い 少し長めのチケットの場合、数時間おきに進捗を更新するとスケジュールが把握しやすくなる 作業開始時はステータスを「担当」にする

77. コメント（注記） 作業中に気になったことや、メモしておきたいことは随時記入する 起票者と担当者が遠隔地にいる場合（OSS開発とかでありそう）、ここを「このチケットに対するフォーラム」的な扱いとして議論することもある

78. こうして作業を進めていき

79. 終わった！と思ったら

80. タスク発生 ワークフロー チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

81. 解決に必要なもの 確認方法 ソースコード ステータスを「解決」にする

82. まずコミットがされていること

83. コミット プロジェクトのリポジトリを事前に設定 コミットログに「refs #1111」のようにチケット番号を書くと、そのチケットへの相互リンクが作られる コミットログに「fixes #1111」のようにチケット番号を書くと、そのチケットが自動的に解決状態になる（要設定） refsとかfixesの文字は任意に設定可能

84. 起票者が確認可能であること

85. 確認 Webアプリの場合はそれを確認するURL その他の場合はどのテストを実行すると判別できるか、など 「私の環境では動いたんだけど…」とかの基本的なミスをなくすために、自分以外の環境で動作を確認できるようにする

86. タスク発生 ワークフロー チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

87. 確認 問題があればフィードバック（差し戻し）にする フィードバックになったチケットは、それだけで時間の無駄が発生しているということになるので、どうすればフィードバックになるチケットが無くなるかを考える必要がある。

88. タスク発生 ワークフロー チケット登録 担当者アサイン 作業確認 終了 管理者タスク 実作業 解決 開発者タスク

89. 終了 お疲れ様でした！

90. 「チケット駆動」の名の通り

91. チケットの扱いが重要なので

92. プロジェクトの体制や環境に合わせてカスタマイズすると使いやすくなります

93. ガントチャートとか

94. あくまでおまけ程度の機能です

95. 「全ての開発作業がチケットとして登録されている」状態を目標としてみてください

96. 実際に弊社（RYUS）でも使っています

97. RYUSでは… しばらくMantisで管理 Mantisちょっと機能たりなくね？ そこでRedmine 移行スクリプトも標準であるよ！でもかなり手を入れた

98. RYUSでは… ステータスの追加 保留とか 却下とか 一部Mantis時代の名残も

99. CSS調整大事

100. チケット一覧カスタマイズ

101. classとかIDとか最初から振られているのでCSS側を変更するだけ

102. その他便利機能

103. ロードマップ マイルストーン 次回のリリースではどのチケットがcloseされている必要があるか？を一覧できる 予定工数を入れておけば、「トータルで何時間かかるか」も見ることができる

104. Wiki Textile記法 h1. 見出し # リスト チケット番号の自動リンク付き（#1234） リビジョンへの自動リンク付き（r1234）

105. フォーラム、ニュース プロジェクト自体の報連相に ニュースはRedmineのトップページに出る

106. リポジトリ連携 GitやMercurialにも対応 単純なリポジトリブラウザとしても便利 refsやfixesでチケットと連動 設定するときはcronでリポジトリ情報を取得するようにする（説明省略）

107. まとめ

108. Redmineを使うと

109. タスク管理が楽になる

110. メリット タスク管理がとにかく楽 Wikiとかもあるので情報の集約ができる コミットとタスク（チケット）を関連付けできる

111. よくわかんないという方は

112. とりあえずインストールして触ってみてください

113. 使ってみないとわかりません

114. 難点 インストールがやや面倒 Railsアプリの経験がないと… Windows環境は更に難関 APIとか拡張方面に弱い このへんはtracのほうが上

115. インストールは楽なほうがいい

116. PHPだともっと楽だよね！

117. PHPでRedmineみたいなのあればなぁ…

118. PHPならカスタマイズも楽なのになぁ…

119. そこで

120. Candycane 安藤祐介（yandod）さんが中心になって作られているオープンソースプロダクト CakePHPでRedmineを作る！ RedmineのコードをベースにCakePHPに移植するのが第一目標 将来的には独自路線の使いやすさを目指す

121. Candycane

122. 本当はこれの紹介を重点的にしたかったのですが

123. 私が既にあまり関わっていないためそれほど紹介できません

124. orz

125. 今夏公開予定！（らしい）

126. おわり