目前公司的團隊開發問題

目前公司的團隊問題

到公司也快一個月了,來整理一下目前的問題與建議好了。

軟體架構面

有做SA但是卻沒有做SD。導致各模組內部都亂做,外加上責任區分不清,支援時也沒有好好整理問題,導致各開各的介面,在系統層缺乏統一規劃。支援的工作者僅看到眼前的問題,所以寫的程式只能解決該問題,缺乏觀察全局的能力。

承上

雖然有在寫文件

是有比沒文件來得好了,但是好像沒有搔到癢處。可能是跳過需求文件就直接寫規格文件的問題。

工作安排上

僅看到一個禮拜的量,也就是似乎狀況很緊急,都在解決一個禮拜內的問題。這不是一件好事,因為緊急,所以各人都以解決眼前問題為優先,導致缺乏長遠規劃,要解決的問題也沒有充分討論就急著進行。

為了表現,認領工作時似乎都以小時計,這點我極度存疑,完成不代表完成,幾乎都會造成日後的地雷。

因為沒有長遠規劃,工作展開後自然就會發現新的問題,導致整合上一直新的問題出現要解決,反而一直虛耗人力。

主程式

有自己的模組要寫,導致花太少時間做好管理整合的環節,也就是過分放任(過分放心)其他軟體工程師實做,沒有好好設計與規範。整合時就會發生有新問題要解決,造成時程再增加的問題。

由於出現問題時都是點對點平行的溝通,可能有重要人士沒有參與到,導致有設計遺漏的現象。

比較大的建議:

  1. 重新檢視時程,安排修正設計問題的時程,否則未來(切換底層,或新專案時)這系統一定會需要全部重寫。
  2. 重新檢視時程,把工作的時程安排再拉長一點,團隊還沒這麼厲害,不適合這麼緊湊的時程安排。
  3. 導入daily meeting,強迫主程式了解其他人的進行狀況。
  4. 安排工作時開始先寫需求。由發派工作的人寫。而不是由接工作的人寫,因為接工作的人多半是不清楚全局的。
  5. 程式設計的功力提升必須重於完整測試。就算有完整測試,建築在沙堆之上也對開發幫助有限。
  6. 導入doxygen的註解格式,導入以檔案為基準的責任區分,開始教育開發者寫註解。減少互相支援時的問題。
  7. 導入bug tracking與測試規範,建立測試窗口,不要仰賴開發者的主動提報。把模組責任分清楚,由適當的實作者來解決問題。而不是為了緊急投注人力反而浪費了時間寫了多餘的東西。
  8. svn的資料夾規劃就要開始以未來的開發為設想,不要做一步算一步。
  9. 開始資源的管理,不要讓無用的檔案一直出現與蔓延。
  10. 同樣地,不需要的程式碼趕快移除,減少使用mark及if 0的方式來撰寫程式。不要再使用程式碼內的人員及日期註解。取而代之的是對實做的描述註解。
廣告

2 thoughts on “目前公司的團隊開發問題

  1. Good points,
    Is there anyway I could know you better other than your Blog ?
    Please add my FB and I think we could exchange some of the thoughts about doing a project. (facebook.com/selfish995)

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s