無論是 台灣 還是 大陸的工程師，都會覺得說 寫程式是低階的人在幹的！
所以往往都會覺得要往上爬就是要往管理階段走！ PG—>SD—>SA—>PM 等等… ( 中間還有其他角色我們省略 )
而，當然 高層也不是幹假的！即然要這樣子的話！
最後就很容易變成！「一人專案」
放心！從專案時間規劃到程式開發！絕對都可以碰得到！
名義上好聽的是 讓你可以獨立作業、可以讓你操控整個專案！
實際上卻是一人當三人用！
7、8 年前時小弟以前的主管不知去那裡看到的「一條鞭」的管理方法 ( 很怪！這個到現在還是很流行 )
硬是套在「軟體開發」的團隊中，而且覺得就是要一個人搞到底，因為這樣子可以節省溝通成本
所以呢！硬是把 一個團隊共同在維護的專案 ( 同時有 5 個 ) 拆散給 5 個不同的工程師 ( PG )
當然最後的下場很慘！原因有很多！因為 並不是每個人都有辦法可以同時要做 規劃 又要開發、又要顧品質 ( 當然 老闆覺得即然溝通時間省掉了！那麼上線的時間也可以濃縮一下吧！ )
導致某些專案客訴問題特多！
因為很容易弊端！比如 原本某些功能測試明明就是有問題，卻硬是要上線！
這個是不是好方法？
小弟覺得這跟本無法解決問題！因為校長兼撞鐘 怎麼可能「忠實地」反應問題出來呢？？
所以 一人專案真的不太適合在 軟體的開發作業上 ( 某些神人等級例外 ，各位都知道小弟在說啥 )
無論是自已實作過的團隊 或是 MSF 上所說 真的最少是 三個人
分別是
PM 負責時程規劃、客戶需求
PG 負責程式開發 / 設計
Test 負責產品的品質
也許就會有人說「不行！我們的人力資源有限，不可能因為 10 個案子我們就要統統乘以三 」
沒關係！換個角度想！可以讓 這三個人同時負責 三個專案 不就解決了嗎？？ ( 當然會依 數量、性質、人員 的差異而有所不同 )
若是所有的專案都已經進維護階段 且 產品的性質都是一樣 又有 OO 架構的話！ 3 個人同時維護 10 個案子也不是不可能的！
而在這裡面最重要的是
如何讓 這三個人可以共同作業、又不會干擾到對方！
這個問題也是困擾了我好久！
比方說 只要一有 bug ，我就要被測試人員 打斷 我開發中的工作，因為他要跟我說發生了什麼 bug
所以，即使是小團隊 也不能忽視這個問題
建置團隊自已的溝通平台是很重要的！
所以 Team Foundation Server 在這個部分幫節省很多建置平台的時間
PM 用 Excel / project 進行管理 和 客戶之間的需求 並且 隨時掌控進度 以便讓其他人員可以專心做份內的事
PG 在 VS 2010 中將這些需求 分幾個大的項目來決定 要執行那些工作 並 將開發好的程式碼可以連結到 需求
Test 依據 PM 所談好的需求 使用 Lab Management 規劃 測試案例 並在每一次 版本測試所找到的 Bug ，開立 Bug 單並記錄發現過程 以便讓 PG 日後可以找得到
爾後，即使團隊需要老闆 增加人手時 也可以很容易讓 新成員 上手 ，因為所有的開發經驗 通通都會在 TFS 中！
所以，並不是小團隊就不需要 開發流程！而是 更需要重視它！因為 人變少了就代表 做事的效率要提高！
( 事情不會變少 )
Orz
轉載自 http://www.dotblogs.com.tw/franma/archive/2010/01/24/13262.aspx
沒有留言:
張貼留言