協同合作系統建制與導入 - 以 Redmine 為例

我很重視團隊溝通的效率和方法，包含問題回報、文件表達、會議、工作管理，因為溝通＝成本。以前系統沒那麼進步，這些成本就算了，但是現在時代那麼進步，還用很沒效率的方法在做事，就很可惜。通常系統的設計是符合一般的需求，而且是遠大於需求，所以導入一套系統制度，通常要改變的不是系統，而是人。當然系統也要調整，為人來調整.

2018/12/13 更新：這篇文章寫作的時間是在 2015/01，內容描述的時間約 2012/03 ~ 2015/01 (3y)，當時的團隊是 IoT，分別在台北、武漢、珠海、米國加州 Fremont 四個地點，產品是軟硬整合的居家安控系統。

這篇文章的重點在於 團隊協作 ，工具則是 Redmine 為核心，文章內容包含以下：

導入前的探索與定義
開發流程
整合與實作
議題管理
導入成效

實際上，也與需求管理、軟體生命週期管理、持續交付、文件管理 .. 等有關係。

註記：本文介紹的的重心擺在如何有效地管理軟體開發與交付的流程，使用的則是 Redmine。談的較多的是管理心法，而非技術上的著墨，像是 Redmine 系統安裝、管理、Git 與 Redmine 整合、CI/CD 等部分。相關技術文件請參閱底下文章整理：

寫在介紹 Redmine 之前

Redmine 安裝篇：Redmine 4.0.x on Ubuntu 16.04

Integrate GIT in Redmine

Redmine Plugins and Themes

Issue Tracking in Redmine

導入前的探索與定義

導入工具之前，了解需求是很重要的。工具要符合現場需求，從角色、流程、任務三個面向分析。

需求的探索歸納

當時在導入 Redmine 之前，我花了很多時間，研究過很多套類似的系統，一開始目的只是做 bug tracking 為主，然後我熟悉的優先。從安裝，然後試著建立 scenario，模擬各種角色 (PM/Dev/QA)，了解系統的需求、如何維護、哪些單位需要使用 … 等等。

我在之前的工作，用過很多類似的 project management system，或者 bug tracking system，包含 IBM 內部的 CMVC、Rational 的 ClearCase / CleaRquest、Bugzilla、RTC (Rational Team Concert) … 另外曾經分析過 MES (Manufacturing Execution System, 製造執行系統) 流程、模組以及系統架構，搭配 Open source ERP (ADempiere)，所以對於 系統配置、程序、流程、架構 的駕馭很有感覺.

當時 (2013) 公司內部使用的 Mantis，先前我做過的案子使用的過 Bugzilla，同仁推薦 Jira，因為看到 Jira 和 Redmine 除了 bug tracking 之外，同時也兼具了專案管理的功能，甚至是文件系統、討論區 (Forum) …，另外還可以有 pluggin，基於同樣的想法，我又繼續找看看有沒更完整的系統，後來找到了 CodeBeamer，也試著和台灣的代理商聯繫過。CodeBeamer 是要錢的，但是他對文件以及 Test Management 就有更完整的 support。文件系統有完整的 ToC (table of content) 的支援、diff、異動通知等。另外也有 DevOps、SCCM、Lifecycle、QA 等模組，相對來說是更完整的.

Jira 也是要錢的，它也是很有名的專案管理系統，他有很多整合的套件，也和 CodeBeamer 類似，但是更專業，有不少大的 open source project，或者像 Microsoft 也都在使用。附帶一提，Bitbucket 就是 Jira 開發公司 Atlassian 所提供的.

經過這些比較，我歸納出完整的協同合作應該要具備以下的功能，以及使用對象:

*Requirement Management- - PM / Marketing / Support Team
*Issue Tracker / Filter / Query- - All Members
*SCM / Code Association / Code Review- – Developer
Test Management - QA/PM
Report System - QA/PM/Leader/Ops
*Release Management / Baseline- – Release Engineer
*Document System- - All
*Custom Workflow / Status- - PM，System Admin

CodeBeamer 是比較完整的協同合作平台，除了 Issue tracking，也包含其他更多，但是複雜度也更高。以當時正在導入 Redmine 使用的狀況來看，不見得適合。因為大部份的人工作習慣改不過來，加上公司既有的文化特性，導入這些系統只會是專案另一種阻礙，除非有高層下來推動。

最後老闆選擇了不用錢的 Redmine，敲定機器設備，然後我負責系統規劃安裝，執行新舊系統的合併，導入流程，教育訓練。然後老闆給我很大的精神支持 XD

Redmine 我透過 config / define workflow、issue status、tracker type、定義一些 custom field、安裝 Plugin、搭配一些 scripts 的方式，針對公司文化以及專案需求，調整很多東西，主要是前述需求斜體部分。

2018/12/16 Updated: 上述的需求，可以在現在 Azure DevOps (VSTS) 的左欄看到類似的結構。

定義追蹤與工作流程 (Tracker and Workflow / Process)

專案進行當中，有很多事要追蹤管理，這些事情統稱 Tracker。依據不同的單位以及追蹤的屬性，我定義了一些常用的 tracker type，包含: Task，Requirement，Bug，Suggestion，Feature，Improvement，其他額外還定義了 Document Publish，Release Process ..。等。這些流程包含針對不同的角色 Roles (PM，Leader，Developer，Reporter，Release Engineer)，會有不同的狀態和流程。每一種 trackers x roles 會有不同的流程。

而流程定義有幾個重點：

開始 與 結束 的定義：流程一定要有頭有尾
角色 (Role) 的定義：哪些人？PM、Dev、QA、Ops
狀態 (State) 的定義：狀態是 名詞 或 形容詞
狀態改變：從狀態 A -> B 中間的改變，是 動詞，也就是做了怎樣的動作
- Bug：Dev 把 Bug 從 Open 改變成 Accepted 或者 In Progress，表示接受一個 Bug
- Bug：Dev 把 Bug 從 Open 改變成 Returned 或者 Rejected，表示不接受一個 Bug
- Bug：QA 把 Bug 從 Resolved 改變成 Closed 或者 Reopened，表示 Bug 通過驗證、或者驗證沒通過。
每一種流程定義，會給予一個名稱，例如 Bug、Defect、Feature … 每一種流程稱為：Tracker

下圖是 Bug 這個 Tracker，Role 是 Developer (藍線)：

其他根據不同 Tracker 和 Role，都有對應的流程定義。事情追蹤以大的為主，有時候一些小事情，或者無關要緊的，則試狀況，讓同仁自行決定是否建立 Tracker.

Redmine 叫做 Workflow，VSTS 叫做 Process。基本上就是 有限狀態機 (Finite-State Machine) 的概念。

類似的說明參閱：Issue Tracking in Redmine

任務類型管理 (Issue Type / Work Type)

上一個 Tracker 定義中有一個叫做 Task，主要用來管理同仁的工作狀況以及工作相依性。例如一個功能經常會跨很多 component，也會和其他很多功能有所關連。Redmine 每一個 Issue 都具備 Subtask 以及 related issue 的功能。透過這樣的關聯，PM or Leader 就很容易將要做的工作項目，安排成樹狀結構，然後清楚的設定 owner，工作時程，相關 issue，文件等.

推動讓 PM 習慣用 Task 的管理，取代過去習慣的 Microsoft Project。在 Redmine 上透過 公開透明，流程標準化 (這兩點很熟悉吧 XD) 的方式，讓同仁彼此可以知道彼此的工作內容，然後 Team Leader 可以適度的調度人員，掌握同仁的工作狀況以及 loading; PM 更可以有效而且清楚的知道專案的狀況.

工作管理有一個很重要的目的: 知道範圍。如果無法釐清每個 item 範圍、item 之間的關聯性、priority、ownership、評估 effort，基本上這個產品是不會有品質可言的。而越能把範圍交代清楚，產品輪廓也就越清楚，developer 更能專心做事，品質自然隨之而來。

爛的產品規劃，會 create 很多 developer 職缺，寫 code 習慣 / 基本功不好的 developer，會 create 出很多 QA 的職缺; 沒有 sense 的 QA 會 create 很多內部溝通的問題，消耗 developer 的時間.

而 QA 和 RD 也得以透過此方法，可以加速專案的執行狀況。這部分也是未來如果，主力 project 要導入 agile，那麼要先具備的條件。我還在試著醞釀中，因為目前還缺少一些必要條件與共識.

Redmine 叫做 Issue Type，VSTS 叫做 Work Type.

文件管理

文件是企業裡面很重要的溝通媒介，也是公司重要的資產。大部份的人習慣用 word / powerpoint，然後存成 pdf，檔名加時間，透過 email 寄給相關的人，稍微有 sense 的會開啟 word 的文件追蹤的功能。工作這麼久，我非常非常討厭這種很沒效率的方式。所以我當時借由一個時機點，在內部提出以下問題：

現在系統已經很進步，各種 diff 工具，通知，change log … 都非常完整。所以我額外花了一點時間，了解 redmine 能做什麼、什麼不夠、缺什麼，思考導入的可能性 … 等。最後做了一些內部的推動，大概做了下面的事情:

文件集中管理，定義文件結構 layout、階層.
建立教育訓練文件，可以提供給未來新人使用.
Survey redmine wiki plugin，增加 redmine 的不足
建立文件的樣板 (Template)、view。包含 RD、QA、PM、Support、Marketing 等.

導入過程我花了不少時間去做 說客，因為要說服一個既定的習慣，是很不容易的，特別是老闆。以身作則是我覺得最好的方式，所以我就自己去做，包含: 幫忙把很多既有的文件 (word) 轉入 redmine (wiki)，試著定義 template，改變 wiki 的樣式，讓他看起來更正式 (header / footer)，然後透過內部教育訓練方式，教大家怎麼寫 wiki，推動用 wiki 寫 design document.

雖然 redmine 的 wiki 還有很大的改善空間，但是勉強讓同仁有一致性的參考點.

但是針對: 輸出 (Export as pdf/html)，撰寫方式 (WYSWYG)，文件結構等部分，其實還有很大進步空間。我也提出一些建議方式可以改善，執行上是可行的，可以利用 third-party 的 plugin，或者自己寫，總之，要一些額外的 resource.

整體而言，文件管理這部分，我覺得還有很多討論的空間，我也持續在 survey 一些更好的方法或系統，目標是希望可以做到像 eclipse help center 那樣的概念.

但是原則上不輕易安裝其他 standalone 的 wiki system，因為會 create 更多整合以及管理的問題.

Updated 2018/12/14: 最近我又再找類似的系統，可以配合 CI/CD 流程自動發布，目前找到的有 mkdocs
Updated 2019/03/17: 文件管理普遍的問題不在系統本身，在於 文件寫作能力 與閱讀能力的培養，而文件是最適合的方法。讓文件一致性則是透過文件的持續交付的手段達成。

導入軟體開發流程 (Software development life cycle，SDLC)

前面講的都是 redmine 的功能面，其實貫穿整個協同合作系統的精神是 軟體開發流程 (SDLC)，大的輪廓是底下這張圖：

2012/04 到這家公司發現很多讓我覺得很不可思議的事，就是這裏：

沒有流程控管的概念
不清楚事情先後相依關係
不清楚角色定義以及工作流程
不做專案控管，沒有停損
沒有 release 概念
沒有 development、release、deployment、production 等認知
對於測試更是完全沒概念，更別提 自動化測試。

關於自動化測試的經驗談，請參閱我的怨念文: 軟體自動化測試常見的問題

整個工作模式完全是傳統的硬體代工思維，不難想見當時做出來的東西是長得什麼樣.

2012 下半年，我和一群我招募的年輕 QA 工程師，還有辛苦的 RD 們，大家憑著一股熱忱 (怨念?)，透過原本公司是既有的 Mantis 追蹤問題，大家天天加班加到昏天暗地，硬是把東西做出來，雖然依舊只是堪用的東西而已，但至少比先前好很多.

後來我花了很多時間，把以前在 IBM 做 projects / products 的流程和經驗，加上過去半年來對這家公司文化的了解，做了適度的調整與安排，然後說服老闆 (這很重要)，取得對應的資源 (IT/權限/Server …)，讓我對內部做了完整的教育訓練，導入了一般 軟體開發流程 (Software development process，SDLC): 瀑布模式 (Waterfall)，內容引用 IBM development lifecycle 部分的名稱與方法，同時將開發流程整合到系統，讓流程系統化，導入 autobuild，整個流程如下圖:

這張圖是整個心法，完整的 slide 快要一百頁，包含每個 stage 的工作重點，以及 release engineering、release process 等。然後在老闆的支持之下，將公司既有架構在 Windows 上的 Manits / SVN / trac (EasyCM)，全部轉換到以 CentOS 為基礎的 Redmine / SVN.

這張圖後來的演進與想法，參閱：Software Development Lifecycle

當然中間也花了一些時間到各個 site 做教育訓練，以及內部的溝通與協調，讓同仁 漸漸了解 軟體開發流程的重要性，以及什麼時間做什麼事情。了解流程之後，同仁就可以自發性的控制自己的工作時間，更能專注的執行專案任務，同時也減少不必要的加班工時。專案也能夠有效的控管，準時的 release (delivery / publish / deployment) 有品質的產品，達到上面的要求.

這個 漸漸了解 其實花了我快一年半的時間.

有了流程、有了系統，透過教育訓練將這兩個制度連結起來，剩下的就是看它發酵，讓大家體驗成果。發酵 過程包含了各式各樣的衝突與相互了解的事件，總之，最後大家漸漸有了 共識、信任、還有默契.

當然過程中我也考慮過導入現在流行的 agile，不過產品性質 (軟硬整合) 以及公司文化因素，主要的 project 暫時沒導入，次要的則已經導入。

這段要換成 Agile Development 也是可以的，概念上都可以套用。

整合與實作

這個部分描述如何實際利用 Redmine 整合協作、工作流程。

整合 Issue 與 Source Code

達到 commit code 必須綁定 issue 和 issue status，達到有效追蹤管理。當然這會額外帶給 developer 一些 overhead.

專案進行中，依照 stage 狀況，完整控制 source code status。通常是進入 RC (Release Candidate)，會進入 code freeze 狀態狀態，然後讓 QA 能夠 focus on Regression。但是也會保留彈性，放行 must fix 的 issue，當然風險就要審慎評估.

配合 redmine 本身的 repository + change assication，可以很方便的 diff code change，通知相關人員 (developer or QA) code change.

相關設定參閱：Integrate GIT in Redmine

持續整合

包含 Semantic Versioning 和 Artifact 兩部分。Semantic Versioning 我當時用 Version Control 來稱呼，Artifact 則是自行實作 Build Agent，稱為 autobuild.

Version Control (Semantic Versioning)

Redmine 的 Issue 有個定義：Target Version，是個一對一個關係，每個 Milestone 可以有一個 Target Version。所以我把它當作是實體產出的版本概念使用。Target Version 牽涉到 Version Control 的問題，簡單說就是如何定義版本號碼，以利開發過程可以精準溝通。

當時引入一般 x.y.z 規則，其實就是 Semantic Versioning。也定義了個別的意義，以及什麼時候該怎麼跳號。version number 除了做控管，有些邏輯也會用到，定義清楚，compare 的邏輯就容易寫。另外就是跳號管控方式與時間，FW 和純 software 會有所慣例的差異，後來我和 Hardware / Device Team 協調統一規則，讓溝通更精確.

Autobuild and Artifact Management

我在每個 Component 定義了一個標準的 interface 描述版本控管，格式就是 key/value 的 Properties，欄位如下:

comp.name=iOS
version=1.2
fixpack=3
buildId=%TIMESTAMP%
revision=%SVN_REVISION%
buildType=dev

這個檔案我把它叫做 releng.properties，全名是 Release Engineering 的縮寫.

releng.properties 在所有 component 裏都會有，優點是透過統一個 agent 管理所有的元件，build script 有一致性的標準。然後透過我就用 python 寫了一個叫 autobuild 作為 daily build agent。透過簡單的架構以及可擴充性的設計，同時部署在數台不同機器，每天 build iOS、Android、WinPhone、JEE application、Embedded、PHP ..。等，產生報表以及通知。Build Fail 會自動通知 developer，build 的過程會有詳細的 log 以及所有的訊息，其實有點像是 jenkens 做的事情。

build 出來的 image 會有固定的格式，像是: App.iOS-1.2.3_InHouse_b20141203-1200_r2356.ipa

Autobuild 出來的結果，就是在談 Artifacts Management 的概念。

更多分享：聊聊軟體交付的濫觴談產出物管理 (Artifacts Management)

人是健忘的，svn revision 意義不大，git hash code 也是，所以 buildId 是一個必要的資訊，讓大家用時間追。裝好之後，會直接在 log 呈現 版本資訊，用來確認 server 已經好了.

autobuild 這件事情間接讓 developer 和 QA 可以專業分工，QA 開的 Bug 會很精確的描述 build 的訊息以及時間.

Updated 2018/03/20：這件事就是導入 CI/CD 的第一步、Artifacts Management。很多開發出來的東西，裝好之後，往往都不知道怎麼確認 好了。如果別人無法拿開發者開發的軟體，自行安裝，然後確認好了，那就是不敏捷的。什麼叫做好了？ 請參閱淺談系統監控與 CloudWatch 的應用 P29 的描述。

議題管理

議題管理是團隊協作過程中，很重要的一環，能夠讓團隊順利且有效的溝通，建立溝通的協議 (Protocol) 是很重要的。

有效的 Bug 追蹤與管理

我們目前專案的進行狀況，每一個 phase 從開發階段 (6w) 到測試階段 (6w)，每一個 phase 的 test stage 平均下來，SQA team 會開出大大小小約 200 ~ 300 個有效的 bug，同時這些問題跨過數個 components (cloud server / logistic / iOS / Android / WinPhone / Web / embedded devices 共有 3 - 4 種組合)，這些 component 從純 software 到 mobile app，到 web，到 embedded devices (數種 IPCam 和 Network Router) 等，要掌握 / 追蹤這些問題的狀況，同時要有效率的和這麼多 function team 的 developers 在三個地方、兩個時差、三種文化差異的溝通，提出改善建議，不是一件容易的事情。

更別提我還負責 Cloud Performance 測試部分 (模擬 App / Device 在一定的上限數量的壓力測試)，還有其他硬體的問題 (機構 / Wifi Performance / 光學 / RF / FW …).

為了有效追蹤這些 bug，達到溝通以及問題反映的需求，針對 redmine 裡的 tracker -> bug，除了重新定義 workflow (參考 “定義追蹤與流程”)，我另外定義了一些欄位，描述如下:

priority: 時間優先級，redmine 預設的，分成 low、normal、high、urgent、immediate。事有輕重緩急，加上人也會有惰性。大部份我採取信任原則，讓 developer 自己控制時間，讓 SQA 自行去跟 developer 溝通。不過有時候太久沒反應，我會適時地調整 priority，同時透過 PM / Team Leader，軟硬兼施的方式，push developer 動作.
severity: 問題的嚴重性，沿用 Mantis 的定義，分成: block、critical、major、minior、warning、suggestion 六個等級。severity 是作為達到 release 的參考準則。能夠 release 的條件如下:
- 1. test case 是要執行完畢
- 1. severity major 以上的 bug 必須全數 closed，包含 major、critical、block
- 1. 執行過 Regression，超過 80% 以上的覆蓋率
- severity 有一個比較特別的是 suggestion，用來讓同仁對產品提出建議。SQA team 在這方面做了很多功夫，提供很多實質且有效的建議，也讓同仁對於產品更有歸屬感.

priority & severity (或者說重要性) 是時間管理的兩個軸，也是我在內部教育訓練時，經常會跟同仁提及的。我認為一個好的執行者，必須要學習如何自我管理，而自我管理的第一步就是時間管理，了解事情的輕重緩急。而自我管理則是人生的課題，已經遠在這個主題之外了。

我不用數字表達 (P1, P0) 之類的描述，而採用名詞、形容詞，主要是因為人對語意比較容易掌握。數字可以精準，但是要花比較多時間訓練。

reproducibility: 問題的可重現性，這也是從 mantis 參考過來的. 下圖則是我在 VSTS 建立的欄位：
highlight: boolean，用來追蹤需要特別討論的 bug，以縮短週會的會議時間。通常被 highlight 的問題可能是閒置太久沒反應的，或者是需要討論的，這些問題會直接請 PM push.
TechNotes: boolean，無法解決的問題，通常是環境 (像是 iOS 版本) 因素造成的問題，通常會請 developer 提供 workaround，然後 highlight 給 support team。這欄位是我從 IBM 的流程裡偷來的 XD
Reported From: 用來分析問題的來源單位。
- 很多戲劇小說都有一句話：沒有對錯，只有立場不同。bug 是否是 bug，不同單位會有不同的看法以及見解。
- 這是為了分析問題以及需求的根源，定義的有 Developmnet、Field in House、Support、Sales / Marketing、Customer、Manufacturer、Others.

Issue Template

另外安裝 issue template for redmine，可以針對不同 tracker 定義常用的樣板，讓同仁回報問題時，可以標準化，減少溝通的問題。以下是當時設計的 Bug Report Template:

[Precondition] -- optional
Precondition for this issue.

[How to reprocedure the problem]
1. install APP form AppStore
2. open app with 886929168168/12345678
3. goto video view，and click the active device
4. ..

[Expected result]
The video should be transferred immediately.

[Actual result]
The exception occurs.

[Log] _optional_

<pre>
put server，app log to here
</pre>


[Environment]
# Phone brand: iPhone5，iOS 7.0.2
# server version: server_2.3.0_b20130116-1200_r23765.tar.gz

*[Spec]- _optional_
[[Wiki Title Here]]

主要就是這些項目要填：

Precondition
How to reprocedure the problem
Expected result
Actual result
Log (optional)
Environment
Spec

有些是 optional，則視狀況可以自行調整。詳細參閱：如何有效的回報問題 (How to Report Problems Effectively)

過程中，始我也試著定義了 Design Document 的 Template，不過基於職務的分權，我只是以建議的角度，理由是基於經驗的分享過去做事的方法，以及身為一個 developer 在 design / coding / unit test 應該要注意些什麼。

Category and Target Version

這兩個欄位是 Redmine 預設的，但是不是必要選擇的。通常需要 PM 去設定才行。在專案進行中，很多人都搞不清楚這兩個的用途，因為他不是必要的選項，所以常常空著沒選，造成 PM 或者 QA Manager 建立 query or filter 時無法掌握狀況.

這兩個簡單說:

Category 是 邏輯 的分類
Target Version 實體 分類

所有的問題一定需要有明確的修復版本 (Target Version)，明確要 commit 到哪個 Branch，所以 Target version 會在專案一開始就定義清楚，同時要求同仁要確實選，如果不知道怎麼選，表示不清楚問題點在哪，那麼就要討論。

而 Category 是邏輯的定義，一般就是指一個 function or item。我們的專案很複雜，所以這部份很難定義，目前我在專案逕行中，用來做問題分析使用，每一個 phase 都回重新整理，所以沒有強制同仁要選擇.

概念就是要分析，或者區分所有權。相關概念參閱分類的哲學

Bug 的組織分析與管理

Bug 的追蹤與管理，要善用 query / filter 做有效的組織與分析，然後對於 人 也必須軟硬兼施，不疾不徐，得以讓事情順利進行，同時也不會造成 RD 與 QA 的爭執。有時候必須扮演黑臉，有時候也需要扮演潤滑劑.

詳細說明參閱 Software QA 的職能條件 - 組織與分析

導入的成果

實質效益

對整個 team 來講，減少溝通所需要的浪費時間、誤解、與衝突。對各個角色來講:

PM: 有效地控制專案的執行狀況，用數據做決策，給 Dev 明確的方向/時間/資源，然後準時 deliver，對老闆/Sales有交代
Developer: 可以清楚知道自己的工作範圍，專心寫 code，解 bug，study 有趣的東西
QA: 清楚知道每一個功能的細節，專心地找問題，同時可以提出建議，增加產品的品質
大家都可以正常上下班、排假、出國旅行.

沒有建制這套流程與系統會有什麼不一樣? 大家一樣可以工作，但是各做各的、email 滿天飛、文件到處丟、問題沒有優先次序、每天都在加班、每個人都不清楚自己的工作範圍、客戶電話接不完、整個專案是無法控制的。這種現象，在很多中小企業都有，而且都習以為常.

導入流程與建制系統這件事情，在時間管理上就是 很重要 + 不急，管理者可能都知道，但是不會有人認真去看待，或者是完全不知道 (這種管理者還真不少 …)

改進與期望

經過快要三年來的導入與調整，目前 Redmine 有使用的單位主要是以 Software RD + SQA，另外有 Support，其中包含 RD 有 6 個 team，分別在三個 location (US、TPE、Wuhan、珠海)，人數約在 50 - 60 人左右。不管是彈性還是功能，是滿足大部份的 project。除了傳統的 waterfall 開發流程，有另一個 web project 是使用 agile 在跑，所以 redmine 在專案管理是可以滿足大部份的.

201501: 因為公司組織異動，也把硬體的部分整合進來 …。所以除了軟體，硬體也來了 …。如何改變這一掛人的思維，是最大的挑戰.

另外可以繼續改善的有:

還是文件系統
- 有更方便的編輯器會更好，或者支援 markdown (redmine 2.x 之後才 support markdown)
- 有 review，comment 機制更好
- 更好的輸出模組
code review 機制
整合 slack 這種溝通系統，讓 developer 溝通更有效率
整合 Test Manamgement (我後來買了 testrail，功能很強大，但是我錯估和 redmine 版本的差異性問題，所以整合的沒有很順
和公司的 IT 系統整合: LDAP or AD 一直沒有順利，因為公司的 IT 系統複雜，不好整合
可以整合類似 Google Docs 線上協同作業的系統，同仁可以在上面貢獻想法，發想鬼點子 …。這是我天馬行空的想法 XD

整體來說，Redmine 是很棒的專案管理系統，管理者還可以配一些免費的 app (easy redmine，rougemine)，隨時掌握狀況; 使用 eclipse 的 developer 也可以搭配一些 plugin，簡化工作流程。但是 Redmine 在文件以及 release 方面並沒有比較嚴謹的功能，勉強只能算是堪用。如果系統使用者要跨越到其他像是 support、marketing、sales、甚至是 end user，就還需要做一些調整，不過我覺得應該是沒問題的.

除了上述列表中的，其實我還想做幾件事情:

導入 git，取代 subversion。不是為了趕流行，而是希望讓 developer 能更有彈性做事情.
- 會有這想法是因為我以前在 IBM 做 project，常常會有與世隔絕的感覺，所以會不自主的緊張起來，然後就自己去學了一堆有的沒的。而那些東西也在一些時機點就用上了 …。所以還是要跟外界保持聯絡.
將 redmine 做異地備援，也就是利用 mysql master-to-master 架構，讓不同地區的同仁，可以有同樣存取 redmine 的速度。然後也可以有備份的效果.
導入 agile 以及落實 requirement management。requirement SOP 導入是困難的，因為這牽涉到與上層溝通的問題.
- 通常我知道台灣很多公司愈高層，越不會用這種系統，也越不懂它的價值所在。而這是一種決策支援系統，決策者沒有信賴依據，憑感覺決策是很不可靠的.
- 如果一家公司或者政府機關的財務人事系統是用 excel，你會期望他有什麼效率可言嗎?
將公司其他部門的文件納入管理，因為實際上我們很多文件都是會相互參考，但實際上卻是到處散落.
讓其他 team (Sales、Marketing、PLM，support ..。) 等，也來使用，讓內部的資訊更同步.

結尾

系統的導入目的在於讓 工作流程標準化，公開透明，讓訊息與資源集中統一管理。

團隊可以透過它，清楚明白自己的工作任務，即時修正
管理者可以清楚掌握專案狀況、資源多寡、同仁的工作狀況
決策者做即時的組織與分析，進一步做出有依據的決策

系統的最大的目的就是: 減少溝通所造成的成本問題

我在 “溝通＝成本“ 大概描述了溝通與成本的問題，這個現象很難量化，也很難讓人很快感覺得到，但是他的的確確就正在上演。不管在企業、政府、還是家庭，每天都在演，大家心裡應該都有底，但是很少人會去面對。但我深深覺得，溝通的效率，是一個企業成功與否的關鍵因素之一.

系統流程導入的過程，最難推動的還是管理階層/高層。系統的導入，需要仰賴高層的認同，然後一起推動，或者充分授權與信任，讓執行者得以與不同的 team 溝通，然後重新定義流程，使用規範等。幸運的是，我的老闆很支持我做這件事情，也給予了充分的授權與支持，所以我得以大刀闊斧地去推動這些事情。過程中也有幸同仁給予很多回饋，與配合，讓我能夠驗證這些方法的可行性.

2018/12/16 補充

這篇文章從發佈到現在，一直是站內閱讀率非常高的。但這麼多年來其實我很少在提這篇文章的內容，或許是這年頭敏捷開發是顯學，這種傳統的方法，或者仰賴系統的概念，不再是主軸。但是經過這幾年在新創團隊裡，與敏捷教練、Scrum Master 共識後，其實我們想的內容是一樣的，都是希望可以有效地讓團隊溝通，只是用的工具與方法不同而已。

基於這些觀察，我同樣的不斷的在強調溝通成本、問題回報、會議效率、工作管理、文件等問題。因為這些問題才是讓團隊真的能否走得長久、走得順遂的關鍵因素。

協同合作系統建制與導入 - 以 Redmine 為例

導入前的探索與定義

需求的探索歸納

定義追蹤與工作流程 (Tracker and Workflow / Process)

任務類型管理 (Issue Type / Work Type)

文件管理

導入軟體開發流程 (Software development life cycle，SDLC)

整合與實作

整合 Issue 與 Source Code

持續整合

Version Control (Semantic Versioning)

Autobuild and Artifact Management

議題管理

有效的 Bug 追蹤與管理

Issue Template

Category and Target Version

Bug 的組織分析與管理

導入的成果

實質效益

改進與期望

結尾

2018/12/16 補充

延伸閱讀 (站內)

工作原則

專案管理

Redmine 系列

CI / CD / DevOps

軟體測試

延伸閱讀 (其他)

更新紀錄

Comments

About

著作

演講

Facebook

AWS Certifications