Re: [閒聊] 你在開發程式時，是重視績效還是品質

[duer ()]

想偷渡這個話題
順便回應另外一個話題有關於coding可以到多老

以下的開發流程
可以說明公司一個team為什麼需要有新人跟老鳥的原因存在

Junior Engineer/feature owner 就是要跟時間競賽
再有限的開發周期裡面 盡量把所有的bugs都解掉
同時也要維持程式的可讀性(但至少架構要好)
同一個時間內 部門當中對於整各建構都比較熟悉的senior engineer/lead
就必須對程式思考如何最佳化 並且盡量讓程式能夠可重複使用
或者整各架構是針對未來的產品的架構而修改

所以你看到的完整開發週期應該是
1. 用最短的時間完成新feature #1的prototype
2. 發現新的feature可行性 開始規劃架構或者如何整合入目前的產品架構
3. 程式開發
4(a). 修bug
4(b). 程式架構再優化 同時另外一個project的feature #2 prototyping..
4(c). 如果遇到重大bug 考慮其他方法(不一定只有一個其他方法)
      (feature #1 using another implementation)
5.RTM之前 決定哪些bug要被postpone, 哪些被歸類為wont fix
  決定Feature #1要用(1) 或者4(c)...
6. sustaining team接手 core team繼續另外一個輪迴(默)

同時間 daily test run
RTM 產品上市 有了feature #1
然後#2 開始進入另外一個開發周期
然後視市場需要 4(c) 的部分component可以被拿去改一改變成另外一個feature拿去賣

但我想這個產品開發流程也許只能套用在部分的產業而已
以我們自己為例(framework/component/device)

但是你可以看到
1. 可以是新人 or 老鳥
2. 老鳥
3. 新人 + 老鳥
4(a) 新人主要
4(b) 老鳥
4(c) 新人 + 老鳥
5. 主管/老闆/PM

nice to have 就是 3 4(a) 4(c) 針對部分問題解決
2跟4(b)需要能力 跟時間 還有經驗才有辦法達到

至於效果嗎? 至少我們team的code quality再整各大group裡面是最好的
產品release 幾乎沒有重大的bug...

我知道在台灣有些公司可能沒有辦法做到這樣的規模
不過 上面有很多步驟都不是在真正的開發流程所必須
很多都是主管自己私底下花時間規劃人力去完成
然後有了新的規劃又可以demo 提供給部門作為之後新的feature的idea..




--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 205.248.102.84
→ duer:Orz po文很累.. 有頭沒尾 但大概就是這樣啦 有問題再討論
推 qrtt1:很棒的切入角度
→ nomina:中英混用太嚴重 看得眼睛都要花了...
推 qrtt1:這樣用很正常啊。不像一些簡體文，都硬翻成中文更看不懂呢！
→ duer:我已經盡量很注意了 但還是變成這樣 @_@....
→ qrtt1:不過這個流程，看起來得對版本控制運用能掌握才能順暢。
推 chrisho:nice to have 是啥 @@?
→ TonyQ:nice to have 是 issue tracking 的術語，
→ TonyQ:一般我們會把要一個工作項目分成必要(must have)，跟可有可
→ TonyQ:無(nice to have)。
→ TonyQ:有些分的比較細的，可能還會有 minor （小的/可忽視的）。
→ TonyQ:像我現在工作的專案是分成 P1 ~ P4 ( Priority 1 ~ 4)
→ hik0301:你是在t社嗎? 台灣能做到這樣的軟體公司沒幾間
推 gname:不是有些公司耶,是能有多少公司做到這樣?
推 glob:推 實用!