Redmineの社内教育の記事のリンク

@saitoさんのRedmineの社内教育の記事が参考になったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「後で読む。RT @Redmine_JP: [Headline] Redmineの教育をどのような観点で行うかの考察。 ①PJ 内の情報共有ステーション、②ストック情報とフロー情報、③タスク毎の小さな計画と、予実管理、④変更管理、⑤excel／ファイル共有 との比較 https://t.co/xRbfU61kEm」 / Twitter

Redmine を教えるということ｜makoto0119｜note

はじめる! Redmine (2017) from Go Maeda

Redmineを社内に普及したい時、@g_maedaさんの資料「はじめる! Redmine (2017)」がお勧め。
図が多く読みやすい。

一方、チケット駆動の考え方ももっと説明したいときもある。
その場合、別途資料を作りたくなる。
@saitoさんの下記の目次も非常に分かりやすい。

１．PJ 内の情報共有ステーション
チケット駆動であれば、No ticket, No workから始めるべきだろう。
チケットが作業の起点になることで、情報共有できるし、進捗報告も不要になる。
何よりも、自分はこのチケットに専念して作業している、と宣言することで、責任を自覚できるし、指示の横槍の防火壁にもなりうる。
チケットは備忘録やToDoリストとも言われる。

２．ストック情報とフロー情報
チケットは、ストックとフローの二重性の性質を持つ。
チケットに記録していながら、ステータスや担当者で、誰がボールを握っているのか、も公開している。
この辺りの運用が馴染むと、チケットのやり合いがオンラインのペア作業みたいな雰囲気になる。

３．タスク毎の小さな計画と、予実管理
チケットの粒度にも関係するだろう。
チケットは1日単位、長くても２～３日単位の方が、メンバーもリーダーも管理しやすい。
Closeされないチケットが長期間残り続けると、何も仕事していないように見えてしまって、お互いにフラストレーションが溜まってしまう。
つまり、チケットの粒度は小さめにし、どんどんCloseしていく運用の方がPJが活発に動いている証拠でもあるし、進捗報告も不要になる。

４．変更管理
Redmineの標準機能では、チケット一覧がWBSになる場合が多い。
仕様変更や、作業の中止などは、チケットを変更するだけでいい。
ガントチャートにはチケットの変更が即座に反映されるので、無駄なガントチャート保守の作業が少なくなるはず。

あえて希望があるならば、Redmineにもプロダクトバックログの機能が欲しい。
おそらくその機能は、Redmineのロードマップ画面で、バージョン単位のチケットの並び順をドラッグ・アンド・ドロップで操作できる機能を追加することになるだろう。
開発者は、チケットの並び順の先頭からチケットを取るだけで、チケットの優先順位が反映されているからだ。

５．excel／ファイル共有 との比較
これは、脱Excelの話。

この資料が公開されるといいなと思う。