【事前公開】【第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年)に公開したアンチパターン集はコチラ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント