團隊高效溝通的第一步：
📌建立「 資訊對等、透明的溝通管道 」
.
大部分會議常因為「 資訊不對等、不透明 」淪為解釋大會。
.
🚫沒有共識
.
🚫各說各話
.
🚫時間冗長
.
🚫沒有結論
.
📌如何建立「 資訊對等、透明的溝通管道 」
.
✅文件放在每個團隊成員都能取得的位置
.
✅有結論就馬上更新文件。
.
✅運用通訊軟體在頻道內即時溝通
e.g.Slack、Synology Chat、Skype、Teams...
.
✅運用專案管理軟體逐條建立項目
e.g.Jira、Trello、Evernote、Mantis....
#work #teamwork #communication #工作 #職場 #團隊 #溝通 #合作 #slack #skype #microsoftteams #jira #mantis #trello #evernote #小人物職場 #職場生存 #共識
mantis專案管理 在 [心得] 協同合作系統建制與導入- 看板Soft_Job - 批踢踢實業坊 的必吃
看到前面有人分享在 start up 做 Tech Lead 的心得,
也想來分享一些這幾年的工作心得, 比較不是技術面的,
但也是在 start up 的一些心得.
在這個工作之前, 我比較長的時間都是在做 java developer 的工作,
因緣際會, 跑去做了 SQA 的事情,
在這家 start up 做的則是 SQA Manager (黑臉/壞人) 的工作.
過程中, 遇到很多有趣的事情, 和讓人瘋狂/崩潰的故事 ....
文章描述的方法或工具, 都不是最新的,
但或許是一個拋磚引玉的分享.
文長, 有在 start up 做過, 可能會更有感覺.
PS: 如果有同事看到的話, 鞭小力力一點 XDD
線上閱讀：https://goo.gl/JDr55N
本文開始：協同合作系統建制與導入 - 以 Redmine 為例
--
我很重視團隊溝通的效率和方法, 包含問題回報, 文件表達, [會議], [工作管理],
因為 [溝通＝成本]. 以前系統沒那麼進步, 這些成本就算了, 但是現在時代那麼進
步, 還用很沒效率的方法在做事, 就很可惜. 通常系統的設計是符合一般的需求,
而且是遠大於需求, 所以導入一套系統制度, 通常要改變的不是系統, 而是人. 當
然系統也要調整, 為人來調整.
當時在導入 [Redmine][2] 之前, 我花了很多時間, Survey 過很多套類似的系
統, 一開始目的只是做 bug tracking 為主, 然後我熟悉的優先. 從安裝, 然
後試著建立 scenario, 模擬各種 role, 了解系統的需求, 如何維護, 哪些單
位需要使用 ... 等等.
當時公司內部使用的 [Mantis][4], 先前我做過的案子使用的過 [Bugzilla][5],
同仁推薦 [Jira][3], 因為看到 Jira 和 Redmine 除了 bug tracking 之外, 同
時也兼具了專案管理的功能, 甚至是文件系統, Forum ..., 另外還可以有 pluggin,
基於同樣的想法, 我又繼續找看看有沒更完整的系統, 後來找到了 [CodeBeamer][1],
也試著和台灣的代理商聯繫過.
[CodeBeamer][1] 是要錢的, 但是他對文件以及 Test Management 就有更完整的
support. 文件系統有完整的 toc (table of content) 的支援, diff, 通知等.
另外也有 DevOps, SCCM, Lifecycle, QA 等模組, 相對來說是更完整的.
[Jira][3] 也是要錢的, 它也是很有名的專案管理系統, 他有很多整合的套件,
也和 CodeBeamer 類似, 但是更專業, 有不少大的 open source project, 或者
像 Microsoft 也都在使用. 附帶一提, [Bitbucket](https://bitbucket.org/)
就是 Jira 開發公司 Atlassian 所提供的.
經過這些比較, 我歸納出完整的協同合作應該要具備以下的功能, 以及使用對象:
1. *Requirement Management* - PM / Marketing / Support Team
2. *Issue Tracker / Filter / Query* - All Members
3. *SCM / Code Association / Code Review* -- Developer
4. Test Management - QA
5. Report System - QA/PM/Leader
6. *Release Management / Baseline* – Release Engineer
7. *Document System* - All
8. *Custom Workflow / Status* - PM, System Admin
CodeBeamer 是比較完整的協同合作平台, 除了 Issue tracking, 也包含其他更多,
但是複雜度也更高. 以當時正在導入 redmine 使用的狀況來看, 不見得適合. 因為
大部份的人工作習慣改不過來, 加上公司既有的文化特性, 導入這些系統只會是專
案另一種阻礙, 除非有高層下來推動.
最後老闆選擇了不用錢的 Redmine, 敲定機器設備, 然後我負責系統規劃安裝,
執行新舊系統的合併, 導入流程, 教育訓練. 然後老闆給我很大的精神支持 XD
Redmine 我透過 Config, Plugin, 搭配一些 scripts 的方式, 針對公司文化以
及專案需求, 調整很多東西, 主要是前述需求斜體部分:
# 定義追蹤與流程 (Tracker and Process)
專案進行當中, 有很多事要追蹤管理, 這些事情統稱 **Tracker**. 依據不同的
單位以及追蹤的屬性, 我定義了一些常用的 tracker type, 包含: Task,
Requirement, Bug, Suggestion, Feature, Improvement, 其他額外還定義了
Document Publish, Release Process ... 等. 這些流程包含針對不同的角色
Roles (PM, Leader, Developer, Reporter, Release Engineer), 會有不同的
狀態和流程. 每一種 trackers * roles 會有不同的流程. 而流程的重點在於
**開始** 與 **結束** 的定義, role 和狀態的流程等. 下圖是 Bug for
developer 的流程之一：
https://goo.gl/Hza7NH
事情追蹤以大的為主, 有時候一些小事情, 或者無關要緊的, 則視狀況,
讓同仁自行決定是否建立 Tracker.
# 工作管理
上一個 Tracker 定義中有一個叫做 **Task**, 主要用來管理同仁的工作狀況
以及工作相依性. 例如一個功能經常會跨很多 component, 也會和其他很多功
能有所關連. Redmine 每一個 Issue 都具備 subtask 以及 related issue
的功能. 透過這樣的關聯, PM or Leader 就很容易將要做的工作項目, 安排
成樹狀結構, 然後清楚的設定 owner, 工作時程, 相關 issue, 文件等.
推動讓 PM 習慣用 Task 的管理, 取代過去習慣的 Microsoft Project. 在
redmine 上透過 **公開透明, 流程標準化** (這兩點很熟悉吧 XD) 的方式,
讓同仁彼此可以知道彼此的工作內容, 然後 Team Leader 可以適度的調度人
員, 掌握同仁的工作狀況以及 loading; PM 更可以有效而且清楚的知道專案
的狀況.
而 QA 和 RD 也得以透過此方法, 可以加速專案的執行狀況. 這部分也是未來
如果, 主力 project 要導入 agile, 那麼要先具備的條件. 我還在試著醞釀中,
因為目前還缺少一些必要條件與共識.
# 文件管理
文件是企業裡面很重要的溝通媒介, 也是公司重要的資產. 大部份的人習慣用
word / powerpoint, 然後存成 pdf, 檔名加時間, 透過 email 寄給相關的人,
稍微有 sense 的會開啟 word 的文件追蹤的功能. 工作這麼久, 我非常非非常
討厭這種很沒效率的方式. 所以我當時借由一個時機點, 在內部提出以下問題：
https://goo.gl/7CuzRY
現在系統已經很進步, 各種 diff 工具, 通知, change log ... 都非常完整.
所以我額外花了一點時間, 了解 redmine 能做什麼, 什麼不夠, 缺什麼, 思考
導入的可能性 .... 等. 最後做了一些內部的推動, 大概做了下面的事情:
1. 文件集中管理, 定義文件結構 layout, 階層.
2. 建立教育訓練文件, 可以提供給未來新人使用.
3. Survey redmine wiki plugin, 增加 redmine 的不足
4. 建立文件的樣板 (Template), 包含 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](https://help.eclipse.org/luna/index.jsp) 那樣的概念.
# 整合 SVN hook
達到 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.
過程中也曾經試著要導入 Git 作為版本控管, 不過這還是基於企業文化以及
決策者的決心問題, 所以後來不了了之了. 反而技術和教育訓練對我來講,
倒不是太大問題.
# 有效的 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 是要執行完畢
* 2) severity major 以上的 bug 必須全數 closed, 包含 major, critical, block.
* 3) 執行過 Regression, 超過 80% 以上的覆蓋率
* severity 有一個比較特別的是 suggestion, 用來讓同仁對產品提出建議.
SQA team 在這方面做了很多功夫, 提供很多實質且有效的建議, 也讓同仁對
於產品更有歸屬感.
> priority & severity (或者說重要性) 是時間管理的兩個軸, 也是我在內部教育
訓練時, 經常會跟同仁提及的. 我認為一個好的執行者, 必須要學習如何 [自我管理],
而自我管理的第一步就是時間管理, 了解事情的輕重緩急. 而自我管理則是人生
的課題, 已經遠在這個主題之外了.
* reproducibility: 問題的可重現性, 這也是從 mantis 參考過來的.
* highlight: boolean, 用來追蹤需要特別討論的 bug, 以縮短週會的會議時間.
通常被 highlight 的問題可能是閒置太久沒反應的, 或者是需要討論的, 這些
問題會直接請 PM push.
* TechNotes: boolean, 無法解決的問題, 通常是環境 (像是 iOS 版本) 因素造
成的問題, 通常會請 developer 提供 workaround, 然後 highlight 給 support
team.
* Reported From: 用來分析問題的來源單位. 很多戲劇小說都有一句話：沒有對錯，
只有立場不同。bug 是否是 bug, 不同單位會有不同的看法以及見解. 這是為了
分析問題以及需求的根源, 定義的有 Developmnet, Field in House, Support,
Sales/Marketing, Customer, Manufacturer, Others.
## Issue Template
另外安裝 issue template for redmine, 可以針對不同 tracker 定義常用的樣板,
讓同仁回報問題時, 可以標準化, 減少溝通的問題.
## Category and Target Version
這兩個欄位是 Redmine 預設的, 但是不是必要選擇的. 通常需要 PM 去設定才行.
在專案進行中, 很多人都搞不清楚這兩個的用途, 因為他不是必要的選項, 所以常
常空著沒選, 造成 PM 或者 QA Manager 建立 query or filter 時無法掌握狀況.
這兩個簡單說: Category 是 **邏輯** 的分類, Target Version **實體** 分類.
所有的問題一定需要有明確的修復目標, 明確要 commit 到哪裡, 所以 Target
version 我會在專案一開始就定義清楚, 同時要求同仁要確實選, 如果不知道怎麼
選, 表示不清楚問題點在哪, 那麼就要討論.
而 Category 是邏輯的定義, 一般就是指一個 function or item. 我們的專案很
複雜, 所以這部份很難定義, 目前我在專案逕行中, 用來做問題分析使用, 每一
個 phase 都回重新整理, 所以沒有強制同仁要選擇.
# Version Control and Autobuild
Target Version 牽涉到 version control 的問題, 簡單說就是如何定義版本號碼,
以利未來溝通. 我引入一般 x.y.z 規則. 也定義了個別的意義, 以及什麼時候該怎
麼跳號. version number 除了做控管, 有些邏輯也會用到, 定義清楚, compare
的邏輯就容易寫. 另外就是跳號管控方式與時間, FW 和純 software 會有所慣例
的差異, 後來我和 device team 協調統一規則, 讓溝通更精確.
我定義了一個標準的 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 ... 等, 產生報表以及通知. Build Fail 會自動通
知 developer, build 的過程會有詳細的 log 以及所有的訊息, 其實有點像是
jenkens 做的事情.
build 出來的 image 會有固定的格式, 像是:
`App.iOS-1.2.3_InHouse_b20141203-1200_r2356.ipa`
人是健忘的, svn revision 意義不大, git hash code 也是, 所以 buildId
是一個必要的資訊, 讓大家用時間追.
autobuild 這件事情間接讓 developer 和 QA 可以專業分工, QA 開的 Bug 會很精
確的描述 build 的訊息以及時間.
## Bug 的組織分析與管理
Bug 的追蹤與管理, 要善用 query / filter 做有效的 [組織與分析], 然後對
於 **人** 也必須軟硬兼施, 不疾不徐, 得以讓事情順利進行, 同時也不會造
成 RD 與 QA 的爭執. 有時候必須扮演黑臉, 有時候也需要扮演潤滑劑.
# 導入軟體開發流程 (Software development life cycle, SDLC)
前面講的都是 redmine 的功能面, 其實貫穿整個協同合作系統的精神是
**軟體開發流程**.
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, 整個流程如下圖:
https://goo.gl/R0HA0V
然後在老闆的支持之下, 將公司既有架構在 Windows 上的 Manits/SVN/trac (EasyCM),
全部轉換到以 CentOS 為基礎的 Redmine/SVN.
當然中間也花了一些時間到各個 site 做教育訓練, 以及內部的溝通與協調, 讓同仁
*漸漸了解* 軟體開發流程的重要性, 以及什麼時間做什麼事情. 了解流程之後, 同仁
就可以自發性的控制自己的工作時間, 更能專注的執行專案任務, 同時也減少不必要
的加班工時. 專案也能夠有效的控管, 準時的 release (delivery / publish /
deployment) 有品質的產品, 達到上面的要求.
這個 **漸漸了解** 其實花了我快一年半的時間.
有了流程, 有了系統, 透過教育訓練將這兩個制度連結起來, 剩下的就是看它發酵,
讓大家體驗成果. *發酵* 過程包含了各式各樣的衝突與相互了解的事件, 總之,
最後大家漸漸有了共識, 信任, 還有默契.
當然過程中我也考慮過導入現在流行的 agile, 不過產品性質 (軟硬整合)
以及公司文化因素, 主要的 project 暫時沒導入, 次要的則已經導入.
# 改進與期望
經過快要三年來的導入與調整, 目前 Redmine 有使用的單位主要是以
Software RD + SQA, 另外有 Support, 其中包含 RD 有 6 個 team, 分別在三
個 location (US, TPE, Wuhan), 人數約在 50 - 60 人左右. 不管是彈性還是
功能, 是滿足大部份的 project. 除了傳統的 waterfall 開發流程, 有另一個
web project 是使用 agile 在跑, 所以 redmine 在專案管理是可以滿足大部份的.
另外可以繼續改善的有:
1. 還是文件系統
* 有更方便的編輯器會更好, 或者支援 markdown (redmine 2.x 之後才
support markdown)
* 有 review, comment 機制更好
* 更好的輸出模組
2. code review 機制
3. 整合 slack 這種溝通系統, 讓 developer 溝通更有效率
4. 整合 Test Manamgement (我後來買了 testrail, 功能很強大, 但是我錯估
和 redmine 版本的差異性問題, 所以整合的沒有很順
5. 和公司的 IT 系統整合: LDAP or AD 一直沒有順利, 因為公司的 IT 系統複雜,
不好整合
6. 可以整合類似 Google Docs 線上協同作業的系統, 同仁可以在上面貢獻想法,
發想鬼點子 .... 這是我天馬行空的想法 XD
整體來說, Redmine 是很棒的專案管理系統, 管理者還可以配一些免費的
app (easy redmine, rougemine), 隨時掌握狀況; 使用 eclipse 的 developer
也可以搭配一些 plugin, 簡化工作流程. 但是 Redmine 在文件以及 release 方
面並沒有比較嚴謹的功能, 勉強只能算是堪用. 如果系統使用者要跨越到其他像
是 support, marketing, sales, 甚至是 end user, 就還需要做一些調整, 不過
我覺得應該是沒問題的.
除了上述列表中的, 其實我還想做幾件事情:
1. 導入 git, 取代 subversion. 不是為了趕流行, 而是希望讓 developer 能更
有彈性做事情.
2. 將 redmine 做異地備援, 也就是利用 mysql master-to-master 架構, 讓不同
地區的同仁, 可以有同樣存取 redmine 的速度. 然後也可以有備份的效果.
3. 導入 agile 以及落實 requirement management. requirement SOP 導入是困
難的, 因為這牽涉到與上層溝通的問題.
* 通常我知道台灣很多公司愈高層, 越不會用這種系統, 也越不懂它的價值所在.
而這是一種決策支援系統, 決策者沒有信賴依據, 憑感覺決策是很不可靠的.
* 如果一家公司或者政府機關的財務人事系統是用 excel, 你會期望他有什麼效率
可言嗎?
4. 將公司其他部門的文件納入管理, 因為實際上我們很多文件都是會相互參考, 但
實際上卻是到處散落.
5. 讓其他 team (Sales, Marketing, PLM, support ... ) 等, 也來使用, 讓內部
的資訊更同步.
# 結尾
系統的導入目的在於讓工作流程標準化, 公開透明 (有沒有和柯 P 的理念很像XD);
讓訊息與資源集中統一管理, 讓同仁可以透過它, 清楚明白自己的工作任務, 即時
修正; 管理者可以清楚掌握專案狀況, 資源多寡, 同仁的工作狀況; 決策者做即時
的組織與分析, 進一步做出有依據的決策; 系統的最大的目的就是: **減少溝通所
造成的成本問題**.
系統流程導入的過程, 最難推動的還是管理階層/高層. 系統的導入, 需要仰賴高
層的認同, 然後一起推動, 或者充分授權與信任, 讓執行者得以與不同的 team 溝
通, 然後重新定義流程, 使用規範等. 幸運的是, 我的老闆很支持我做這件事情,
也給予了充分的授權與支持, 所以我得以大刀闊斧地去推動這些事情; 過程中也有
幸同仁給予很多回饋, 與配合, 讓我能夠驗證這些方法的可行性.
--
::: 喝咖啡 聊音樂 :::
https://rickmidi.blogspot.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.251.92
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1423141882.A.6BA.html
工作分配是 PM / Leader 的職責, 除了定義 item 項目,
同時也要定義每一個 item 的 priority, type, 指定 owner, 評估 effort.
了解每個 item 相互的關係 (有關的, 對上對下的關係),
相依的 components, 使用 third-party api ... etc..
這點做不好, 只能仰賴有經驗的 developer, 或者看看會不會發爐 XD
我到這家公司之前, 其實原本的 developer 也裝過 redmine,
不過不知道裝來做什麼, 擺在那裡好看而已.
系統的價值, 還是怎麼去規劃以及導入,
再好的工具, 人不會用都是空談.
自己去做導入, 才知道為什麼 CMMI 導入的費用那麼貴 ...
吃過苦頭就會知道了, 我也和 developer 經歷過類似的衝突過程.
後來大家知道該怎麼做了, 沒有 issue 讓他們 tracker, 反而會不習慣.
因為歷史會開始重演, 有一些 bug 會造成 side-effect,
大家開始會感覺以前追蹤的紀錄, 很有參考價值, 時間會證明給大家看.
我以前做 developer, 就習慣用 issue 做每件事情的追蹤,
包含 design document / unit test 方法 / ut 報告 /
schedule / 相關的 component / 相關的 bug / 參考資料 ... 等,
只是不同工具而已,
以為這是 developer 該有的 common sense,
到這家公司才知道很多人都不知道, 所以造成一些衝突.
後來才知道, 很多公司專案管理, 連切票都不知道,
issue bind source control 沒聽過,
SVN / git 只是一個很高級的檔案系統而已,
也有離職的同事說, 新公司完全沒有控管, 都不到在做啥 ...
原來類似現象, 在很多公司都有 ..
※ 編輯: taliao (36.226.249.56), 02/06/2015 21:26:51
... <看更多>