Redmineを使いこなせてチームに対するアドバイス
興味深いTwitterがあったのでメモ。
Redmineを有効に運用出来ていないチームに対するポイントは3点ある。
1・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」
2・「各トラッカーのステータスがどういう状況を表すか定義する」
3・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」
ポイント1は、チケットファーストの原則。
プロジェクトにある全ての作業はチケットから始まる。
そのためには、チケットは成果物単位、つまりWBS単位である方が担当者も作業範囲が明確だし、管理者も成果物の進捗から、プロジェクト全体の進捗を測定できるようになる。
駄目なチームは、チケットのアウトプットが不明確だから、担当者も作業の目的が分からないし、管理者も進捗が分かりにくい。何よりもアウトプットの品質も悪くなる。
ポイント2は、作業の状態を明確化すること。
駄目なチームは、コミュニケーションのキャッチボールが悪い。
SEが設計書を作ったらPMががレビューするとか、PGがバグ修正したらテスターが検証する時には、各担当者の作業状態をチケットのステータスに関連付けると運用しやすい。
自然なペア作業になる。
二人の目を通すことによって、自然に品質が向上する。
ポイント3は、ワークフロー管理によってPMBOKやITILの言う変更管理プロセスを実現出来ること。
バグ修正と問い合わせのワークフローは全く違うのに、一つのワークフローですべての作業を制御しようとするのは、所詮無理がある。
また、顧客の要望を受けた場合、リリース範囲に含めるか、別のイテレーションに回すのかという判断、あるいは、誰がその要望を調査して分析するのか、その担当を決定するのが重要になる。
その場合、きちんとワークフロー管理しておかないと、何故システムに実現してくれないのか、何故放置されたままなのか、というクレームが顧客から来る。
だから、自分のプロジェクトでどんな業務があるのか、どんなワークフローが必要なのか、業務分析しておくのが重要。
実はSIer自身が、自分たちの業務範囲、自分たちの特徴、自分たちのワークフローを理解していないという現実がある。
実際は、朝会やふりかえりなどで、現場の開発者と試行錯誤しながら、自分たちのワークフローを作っていくのが現実的だと思うし、その方が自分たちの環境にフィットする。
パッケージ製品のお仕着せのプロセスを適用してもダメなのだ。
これがプロセス改善と呼ばれるものになる。
| 固定リンク
「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)
コメント