プログラマの思索

第13回RxTStudy勉強会の感想をメモ。

【元ネタ】
RxTStudy #13 「Redmine再入門～達人に学ぶRedmineの徹底指南」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【1】@g_maedaさんの講演では、Redmine初心者が必ずチェックすべき初期設定の内容と、farend_basicテーマの解説があり、すごく参考になった。

例えば、オフショア・ニアショアでRedmineを外部に公開して共有する場合、セキュリティの設定は必須だ。
「認証が必要」はON、「デフォルトで新しいプロジェクトは公開にする」はOFFにした方が安全だ。
実際、ググってみると、外部から丸見えになっているRedmineがあるらしい。
あな恐ろしや。

バージョン管理ツールのコミットログにチケット番号を記載して連携する場合、「refs」「fixes」にチケット番号を付けるやり方が普通だが、参照用キーワード設定画面で「*」を設定すると、コミットログに「#チケット番号」があるだけで自動でリンク表示してくれるらしい。
これは便利だ。

@g_maedaさん作成のfarend_basicテーマやfarend_fancyテーマは僕も便利に使っている。
お話を聞くと、チケットのコメントを削除する時に誤ってチケットそのものを消す誤操作をなくすために、枠を囲ったり、履歴を明確に表示する背景色を付けるなど、UI改善に力を入れている。
チケット更新の絶対日付表示、ページネーションのUI、チケット一覧の色分け表示などはとても便利。

【2】@sakaba37さんのプロセス支援のお話。
チケット駆動開発は、WF型開発やAgile開発の枠を広げようとする箇所で適用すると上手くいくのでは、という指摘は、なるほどと思う。
あくまでも、色んなプロセスの支援ツールなのだ。

【2-1】この後に@agilekawabataさんの講演もあったが、興味深い話もあった。
大企業で約1千人のユーザがRedmineを使っている現場を見ると、RedmineのあるプロジェクトはWF型開発、別のプロジェクトはアジャイル開発で使い分けて運用している所がある。
実際、Redmineでは、プロジェクトごとにワークフローやカスタムフィールドを使い分けれるし、各種の機能も選択できる。

つまり、一つの企業の中の開発案件に対し、それぞれの特徴を生かして、Redmineプロジェクトごとに開発プロセスを割り当てて、別々に運用することができる。

しかし、経営層や上司の観点では、WF型開発やアジャイル開発のプロジェクトを横断して、横串でプロジェクトの進捗状況を把握したい要望がある。
そこで、Redmineでは、プロジェクトの階層構造を当てはめれば、子プロジェクトのチケットを親プロジェクトで集計して見ることもできる。

すなわち、Redmineは、色んな種類のプロセスがあっても、別々にプロジェクト単位に管理できるし、親子プロジェクトを使って進捗状況を集計して横断的に見ることもできる。
したがって、Redmineは柔軟な進捗管理も可能だし、多様なプロセスをそれぞれに管理できる柔軟さも持っているのが面白い。

【3】僕の話は、Backlogsプラグインを使ってScrumを運用できるよ、という話。
実際に使ってみようと試しているのだが、Scrumのプロセスやロールごとの操作をRedmineの機能に上手くマッピングできているのがすごく面白い。

話が駆け足になってしまい、「リリース」という機能の詳細を説明できなかったけれど、「リリース」というBacklogsプラグイン機能は、上手く使えば、1日～1週間の短いリリースサイクルにも適用できる。
例えば、プロダクトバックログにあるストーリーを「リリース」ごとにカテゴライズして分別し、「リリース」にあるストーリーをいくつかの「スプリント」に割り当てて、順次リリースしていくように運用すれば良い。
そうすれば、JiraAgileのように、リリースサイクルが極端に短いアジャイル開発にも適用できるだろう。

【4】LT3人も含めて、パネルディスカッションを行った。
今回も経験者のお話がすごく興味深かった。

【4-1】「Redmineのインストールは超簡単」「すごく難しい」という質問に対し、@g_maedaさんいわく、bundlerで自動的にgemsがインストールされるので、なぜインストールが難しいのか、分からない、とのこと。
Rubyistの人は、問題ないみたいだ。

しかし、他の方に聞くと、WindowsにRedmineをインストールする人がすごく苦労されているようだ。
たとえば、WindowsにBitnamiでRedmineをインストールできたものの、チケット数が既に10万近くになり、性能が悪くなっている、というお話もあった。
また、社内ネットワークがボトルネックになっている、という話もあって、共感できる部分があった。

【4-2】「チケット管理のルールを事前に説明会を開いて説明する」「自然に馴染んでいく」という質問に対し、やはり「事前に説明していく」という人達の方が多かった。

@g_maedaさんいわく、社内のメンバーでRedmineの操作に慣れていない人がいるし、バイトの人が来ていると、先生に断りなくチケットを作って良いか、と聞いてくることもあるので、事前に説明している、とのこと。

【4-3】@agilekawabataさんいわく、ボトムアップでRedmineのチケット管理のルールを改善していく場合もある。
例えば、ある企業では、事業部ごとにRedmineサーバーが立っているので、社内にRedmineインスタンスが20個以上もある。
つまり、各Redmineは各事業部ごとに、独自のワークフローを作り、運用している。

しかし、全社で一つのRedmineで管理していこうという雰囲気が出てきて、その時に、各Redmineのワークフローを整理しようとし始めた。
すると、各Redmineのワークフローは似ているものがあり、それらをリファクタリングしながら、全社で統一的なワークフローを整備していく流れが出ている、と。
つまり、20個以上のRedmineごとのワークフローをリファクタリングすることで、全社共通のワークフローを標準プロセスとして抽出することができるわけだ。

この話は、標準プロセスをトップダウンで押し付けるのではなく、ボトムアップにプロセスをリファクタリングしながら標準プロセスを整備していくやり方もある、という指摘。
そういう考え方がすごく面白い。

他にもLTで、「営業マンのRedmineの使い方」「工場でのRedmineの使い方」の事例もあり、参考になる話が多かった。
プラグインを24個も入れている点がすごく興味深い。