Redmineを使いこなせてチームに対するアドバイス
興味深いTwitterがあったのでメモ。
Redmineを有効に運用出来ていないチームに対するポイントは3点ある。
1・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」
2・「各トラッカーのステータスがどういう状況を表すか定義する」
3・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」
ポイント1は、チケットファーストの原則。
プロジェクトにある全ての作業はチケットから始まる。
そのためには、チケットは成果物単位、つまりWBS単位である方が担当者も作業範囲が明確だし、管理者も成果物の進捗から、プロジェクト全体の進捗を測定できるようになる。
駄目なチームは、チケットのアウトプットが不明確だから、担当者も作業の目的が分からないし、管理者も進捗が分かりにくい。何よりもアウトプットの品質も悪くなる。
ポイント2は、作業の状態を明確化すること。
駄目なチームは、コミュニケーションのキャッチボールが悪い。
SEが設計書を作ったらPMががレビューするとか、PGがバグ修正したらテスターが検証する時には、各担当者の作業状態をチケットのステータスに関連付けると運用しやすい。
自然なペア作業になる。
二人の目を通すことによって、自然に品質が向上する。
ポイント3は、ワークフロー管理によってPMBOKやITILの言う変更管理プロセスを実現出来ること。
バグ修正と問い合わせのワークフローは全く違うのに、一つのワークフローですべての作業を制御しようとするのは、所詮無理がある。
また、顧客の要望を受けた場合、リリース範囲に含めるか、別のイテレーションに回すのかという判断、あるいは、誰がその要望を調査して分析するのか、その担当を決定するのが重要になる。
その場合、きちんとワークフロー管理しておかないと、何故システムに実現してくれないのか、何故放置されたままなのか、というクレームが顧客から来る。
だから、自分のプロジェクトでどんな業務があるのか、どんなワークフローが必要なのか、業務分析しておくのが重要。
実はSIer自身が、自分たちの業務範囲、自分たちの特徴、自分たちのワークフローを理解していないという現実がある。
実際は、朝会やふりかえりなどで、現場の開発者と試行錯誤しながら、自分たちのワークフローを作っていくのが現実的だと思うし、その方が自分たちの環境にフィットする。
パッケージ製品のお仕着せのプロセスを適用してもダメなのだ。
これがプロセス改善と呼ばれるものになる。
| 固定リンク
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
コメント