【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集~WBS駆動からチケット駆動へ #redmineT
第7回redmine.tokyo勉強会で予定している講演資料を事前に公開します。
勉強会のオープンディスカッションの元ネタになるので、参加される方は事前に読んで頂いて、自分なりの意見を持参してくれると嬉しいです。
【元ネタ】
第7回勉強会 - redmine.tokyo
【1】議題にしたいテーマ
第7回redmine.tokyo勉強会のテーマは「Redmineのアンチパターン集」です。
披露するアンチパターンは、私が過去6年、Redmineをいろんな現場で導入して運用した時、こうやればもっとうまくできたのに、と後で気づいたノウハウです。
おそらく他の人も同じように頷いてくれるアンチパターンがあると思います。
【1-1】前提条件は、以下の3つです。
前提①:自分でRedmineサーバーを立ち上げられる
前提②:チーム運営やプロジェクト運営の経験が少ない
前提③:前作のアンチパターン集以外の事例(2011/7)を出す
つまり、講演のイメージとしては、プログラマ上がりのプロジェクトリーダーがRedmineを使ってプロジェクト管理を始めようとした時、Redmineを使いこなせずに失敗した事例を集めてみました。
【1-2】アンチパターンの観点しては、以下の3つです。
・5人の小規模チーム x 20人の複数チーム
・自社開発 x オフショア開発
・大規模な受託開発案件 x 小規模な保守案件
今回は私は、チームや案件の制約条件(Force)によって、チケット管理を微妙に変える手法を議論したいと思います。
例えば、開発者3人のチームリーダーと、3つのサブチームを管理するプロマネの立場では、管理手法が違います
また、自社のフロアにメンバーが全員揃っている場合と、協力会社の開発メンバーとフロアやビルが違う場合、中国へオフショア開発している場合では、管理手法が異なります。
さらに、大規模な受託開発案件と、小規模なシステム保守をたくさん抱えている保守案件では、管理手法が全く違ってきます。
それぞれの前提をおいて、Redmineの運用方法について考えてみると、Redmineの使い方も大きく違ってきます。
Redmineを導入したがうまくいかない、という人は、特に、チームや案件の制約条件とRedmineの機能へのフィットギャップ分析を事前に行なっておらず、Redmineの豊富な機能を使いこなせなかったのだろう、と思います。
資料のように、「大規模受託案件のWBS駆動のプロジェクト管理」とか、消費税対応やWindowsOSのVerUp対応のような「複数システムを横断する短期案件のプロジェクト管理」は、その前提条件が全く違います。
しかしながら、Redmineの豊富な機能を使えば、利用シーンに応じて、細かい部分まで作業管理できる利点があります。
オープンディスカッションでは、参加者の現場の経験を引き出しながら、この辺りを議論してみたい。
こうすればもっと良かったはず、という失敗した経験を、暗黙知から形式知へ変換したいのです。
【2】伝えたいメッセージは3つあります。
【2-1】Redmineを利用して、プロジェクト運営能力を身に付けよう
チケット管理は、プロジェクトの問題を見える化してくれる利点があります。
こんなつぶやきにすごく同意です。
しかも、プロジェクト管理の経験が不足していても、Redmineでプロジェクト管理を実験できます。
例えば、大規模な受託開発案件の場合、小規模なシステム保守を1チームでまとめて管理する場合で、それぞれで実際にRedmineのチケット管理をシミュレーションしてもいいでしょう。
あるいは、消費税対応やWindowsXPの廃棄対応のような「複数システムを横断する短期案件のプロジェクト管理」では、チケット管理をどのようにやるべきか、事前に実験してもいいのです。
その結果、Redmineの豊富な機能を利用場面に応じて使い分けるノウハウが得られるでしょう。
逆に言えば、プロジェクト管理の経験が不足している初心者リーダーでも、RubyやRailsのプログラミングができるなら、いくらでもRedmine上で実験することで、プロジェクト管理の場数を増やすことができるのです。
今後は、自分のプロジェクト管理をもっと楽にしたい、という動機を持って、自分でRedmineを拡張してプロジェクト運営の経験を積んでいく、という人が増えていくのではないか、と思います。
【2-2】チケット管理はAgile開発を参考にしよう
チケットは「柔軟で変化に対応しやすい」特徴があります。
この特徴は、アジャイル開発のプロジェクト管理手法とすごくマッチします。
WF型開発で主流のプロジェクト管理手法である「WBS駆動のタスク管理」は変化に弱いのです。
アダプタブルWFが指摘することは、リスク管理はチケットで追跡していく方が良いというメッセージです。
【2-3】Redmineの課題の一つは「Git連携の機能強化」
但し、Redmineの機能が全ての利用状況でうまくいくわけではありません。
最近は、「アジャイル開発するならJira」という話をたくさん聞いています。
また、GitHubがオープンソース界隈における主流の開発ツールとなったように、開発環境はどんどん進化しています。
私が思うに、Redmineの課題の一つは「Git連携の機能強化」でしょう。
Git-flowモデル、プルリクエスト機能は、Redmineでは不十分なのです。
一つの試案としては、Redmine+GitLabでGitHub機能を実現するアイデアがあります。
この辺りも、オープンディスカッションで議論してみたい所です。
RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索
RedmineをGitHub化するアイデア: プログラマの思索
RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索
皆様のご参加をお待ちしてます。
【追記】前回(2011年)に公開したアンチパターン集はコチラ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント