開發團隊擴充注意事項

這篇文章寫的清楚. 我一直是單機版的狀態, 協同工作其實問題很多. 擴充性 是指架構, 但架構變大了,人手也要變多才能處理,  但各人的背景,知識,能力,表達方式都不同. 協同就會有差異 就會有問題,  這作者看事情有一定高度.

  • 盡量避免集中化的資料庫操作,如此一來,就可以降低資料庫操作成為瓶頸的機會,只要系統中沒有成為瓶頸的組成,系統就容易具備規模可擴充性

人也是如此.  不要有大神,不要有明星球員, 太強的人會吸收大多數工作,是負擔,是瓶頸.

但也不是鼓勵平庸, 協同應該要讓成員的知識拉到同一水平,共享知識, 共讀一些書與理論, 觀念和能力產生交集為止.  我也一直相信, 人多不一定好辦事,

  • 且新加入的成員,往往只能負擔一些比較外圍的功能開發,至於原先的主體及核心,可能還是由大神辛苦地承擔著.

像這些問題 需要很專業有經驗的人資及研發才能釐清問題.

“就和軟體系統一樣,只要有了特定的集中化組成,就會導致這個集中化組成傾向,成為瓶頸,而瓶頸的存在,就會接著造成規模無法再擴展上去’

這句話真是寫的太好了: ‘工作負載不均衡,效率無法最佳化"

這是一個管理的問題

  • “開發的規模可擴充性的意義,並不在於每個開發者可以開發得有多快,而是在於,即使團隊的開發者開發速度,都不像大神那麼快,但是,透過增加新的開發者,可以讓開發的整體生產力提高。想要得到開發的規模可擴充性,最關鍵的因素,還是要消除瓶頸的存在"

這作者表達很清楚.

如果真實情況裡,主管或老闆能把團隊原理解釋清楚,讓人了解心服口服, 對協同運作幫助會很大.

廣告
新文章
發表留言

發表迴響

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

WordPress.com Logo

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

Twitter picture

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

Facebook照片

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

Google+ photo

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

連結到 %s

%d 位部落客按了讚: