這是《研發範圍和時間的「資訊透明化」》的第二部分，主要闡述基於redmine
確保資訊透明的協作和流程，關於研發範圍和時間的基本概念及其在
redmine
這一特定平台上的表現形式請參考第一部分《
研發範圍和時間的「資訊透明化」之redmine
統一平台》。
一. 關於協作和流程
研發範圍和時間的透明來自於團隊的相互協作，這些協作需要以一定的流程和模式作為基礎。
1. 角色和資料流
要想做到資訊透明，個人認為首當其衝的是要明確團隊角色和職責。研發團隊中通常包含的核心角色有：
dev和
qa的角色比較好區分和理解，這裡說明一下
dev一般分成表現端和伺服器端兩種細分角色，分別以
c-dev
和s-dev
表示。
pm和po
的角色所擔負的需求開發和管理部分工作有時候比較難劃分界限，而且可能在一定場景下兩者是同乙個人，但即便是同乙個人，其工作範圍是需要明確區分的：
pm的需求面向使用者（使用者需求），而
po的需求面向產品（產品需求），也即
dev通常是跟
po進行需求方面的溝通，而不是和pm，
po作為專案線和產品線的介面人最終把控產品的方向。團隊協作的流程圖如下，大家可以看到pm和
dev之間沒有直接互動：
2. issue狀態
團隊成員和角色都已明確，po
手上也已經有了研發的需求說明，也就是範圍，po和
dev就可以使用分解技術將這個範圍分解成
issue
（包括feature
和task
）；後續隨著測試工作的展開，
qa也需要對
bug和
defect
在redmine
上進行統一維護，每個
issue
的狀態以及狀態之間的轉換參考：
以上狀態可能各個團隊會有所不同，大家可以靈活新增、刪除或修改名稱，但需確保狀態從「新建」到「已關閉」形成乙個閉環。
3. issue與角色
issue的狀態轉換和角色是乙個強對映，即
issue
的每個狀態的轉變都需要有明確的角色執行。狀態轉換是乙個端到端的過程，
上圖角色對映的乙個基本原則是：po
是面向使用者功能的負責人，而伺服器端
s-dev
是系統內部服務的提供者，這兩個角色分別負責
feature
（面向使用者功能）和
task
（面向內部服務）的建立。因為面向使用者功能最終需要由
qa進行測試，所以
feature
將由qa
關閉；而
task
用來在dev
之間進行開發資訊的傳遞，對po和
qa是透明的，故由
dev自身關閉即可。
4. 範圍和時間的組合
下面是範圍和時間組合的象限圖，大家會選哪個？
首先排除，範圍和時間都固定不現實，而範圍和時間都可變也就無所謂資訊透明了。關鍵是b和
c，個人認為都是合理的，但需要根據具體場景具體分析。本文結合第一部分中時間要素中的版本概念，認為c
是進行研發範圍和時間透明化時的最佳組合選擇。
5. 版本從何而來？
有了「範圍可變、時間固定」的組合，我們就可以確定版本。本文第一部分中提到」一定時間」加上」一定活動」就等於版本，現在時間固定，所以「一定時間」有了（可以考慮以一周為單位進行短週期迭代），「一定活動」通常需要團隊進行協商和討論以達成最終在範圍和時間上的統一認識。版本等式以及版本中包含的範圍和時間的確定方式參考下圖：
二. 工作流
乙個完備的工作流程運轉需要三方面：步驟內容、責任人和時機。圍繞redmine
平台進行研發範圍和時間管理的主工作流如下，該主工作流程圍繞乙個目標版本內容進行展開，通過控制
redmine
上issue
狀態轉換推動流程的運**
下面我們對該主工作流進行拆分，從po
、dev和qa
三個核心角色的視角出發圍繞日常開發工作進行工作流梳理。
1. po工作流
po是產品需求的負責人，日常工作流程包括以下幾個方面：
其中需求會議是po
需要主持的主要流程性會議，需求會議召開方式如下：
需求會議的產出是乙份研發團隊成員都認可的產品需求。
2. dev工作流
dev泛指產品的開發團隊，日常工作流程包括以下幾個方面：
其中設計/
計畫會議是
po需要主持的主要流程性會議，設計
/計畫會議召開方式如下：
設計/計畫會議的產出是根據系統的設計方案以及根據該方案所進行的開發計畫。
3. qa工作流
qa是產品質量的負責人，日常工作流程包括以下幾個方面：
qa與dev
之間的互動基於上圖中描述的一次完整提測流程，
qa通過以下兩個方面進行資訊的透明化管理：
三. 小結
1. 關注我的工作台和最近版本
示例圖如下：
2. 使用統一檢視
下圖是redmine
上使用task board
進行團隊資訊同步的效果圖，
redmine
平台為我們進行資訊透明化管理提供了一些外掛程式和功能，關於checklist
功能、eclipse
與redmine
整合方法以及更多
redmine
外掛程式可參考我的部落格：《
工具系列之redmine
外掛程式與工作效率》
3. 技巧和注意點
本文中提交的思路和理念是通用的，但具體的工具平台、工程實踐等可根據具體的團隊現狀和研發管理水平做調整，以找到研發團隊的最合適工作流程。
研發專案管理的應用範圍
研發專案管理面臨的主要問題 專案管理五大過程 ipd整合產品研發體系 研發專案管理智慧型化的必要性和建設目標 imis pm研發專案管理業務藍圖設計 imis pm架構和優勢 imis pm產品特色 專案模板管理 wbs仸務分解結構 精細化專案過程管理 事前計畫 事中控制監督 事後總結分析 人性化便...
Mysql 日期和時間 範圍
date 日期。支援的範圍為 1000 01 01 到 9999 12 31 mysql以 yyyy mm dd 格式顯示date值，但允許使用字串或數字為date列分配值。datetime 日期和時間的組合。支援的範圍是 1000 01 01 00 00 00 到 9999 12 31 23 59...
Mybatis的時間範圍查詢
在專案中避免不了要用到時間範圍查詢，接下來就介紹如何在ssm專案中使用mybatis 的時間範圍查詢 首先是js部分 varstartime startime val if startime undefined startime varendtime endtime val if endtime u...