在公司上過軟體外包管理的課程 2

作者: sniffer (again) 看板: Soft_Job
標題: Re: [請益] 有公司用這種開發方式嗎?
時間: Sun Nov 13 23:50:41 2011

※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: ※ 引述《sniffer (again)》之銘言：
: : 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
: 基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
: 譬如：
: 規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
: 但比較學院派的人作法，是比較接近物件導向分析與設計
: 譬如，會從使用者案例開始玩起
: 就使者案例來說，除此需求之外
: 還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
: 或者，使用者連續第一個按鈕，會不會出什麼問題？
: 或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
: 程式是否要通知使用者或更新書面
: 每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
: 如果做得好，不會等到程式實作差不多後才發現
: 如果使用者怎麼做，會有大問題，所以要改架構
: 如果系統這時網路斷線，會有大問題，所以要改架構
: 做完使用者案例，還要做系統架構分析、物件分析
: 要達成每個案例，系統該包含哪些物件，有什麼責任
: 再根據每個物件
: 理論上，這都是 SA 、SD 的人要做的
: 但是，台灣只有 PM 提出要做什麼（還很不明確），
: 然後 RD 要身兼 SD、SD、PG
: : Boss, HW bug, OS bug 都會引起各種架構變化,
: 基本上，每種因素都會引起各種架構變化
: 因此：
: 一、當設計的時侯要儘量有彈性，這也是 SA、SD 要有足夠能力

現實中的程式, 必須要顧慮效能, 也要顧慮時效性,
最好效能的架構不會有彈性, 最快寫好的程式(例如perl)也往往最難維護,
但是最好維護從來都不是大多數程式的第一優先, 也不應該是優先:
1. 效能好的程式節能減碳, 這對server, driver或embedded system這類程式非常重要,
因為這些程式擁有最多的執行時間, 少用一個clock就少砍很多樹, 電池多活很久
2. 如果facebook慢慢做系統分析, 慢慢研究使用者行為, 慢慢推敲架構會不會DoS,
那他就不會成功, 先做出來才是重點

: 二、就風險管理的角度，儘管有一百種各式各樣的因素導致架構變化
: SA、SD 還是要能儘管可能掌控各種因素，譬如其中的九十種
: SA、SD 不能因為還有十種因素不能掌控，所以連那九十種因素都不掌控
: : 而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
: 照比較正規的作法（學院派），可能規格書真的比較 code 多
: 不過要考慮一個因素，是因為這種規格書比較因素比較多，所以才會比較厚
: 至於所謂的 SA自己寫全部code還比較快
: 基本上，這純粹是規模問題：
: 譬如要蓋一間狗屋，應該不會有人大材小用還給出一個規格書
: 當然是先動手做再說
: 但如果要蓋一棟高樓大廈，
: 總不會說規格書會太厚
: 設計師自己去蓋房子說不定還比較快

蓋房子設計師無法自己搬一棟樓的磚, 但是規格書裡面的流程假如比code還多,
SA直接用這個時間自己寫, 都已經做好了

一個很"正規"的例子, 世界前三大某IC豬屎屋, 他們的SDK就是在印度寫,
採用"正規"作法, 裡面每個模組都帶有比code還多的規格書, 測試報告,
其實這個產品全部的code只有幾MB, 但是拆成一百多個模組,
於是當我要修改電路板某個clock, 問他們的人會影響哪裡,
這件事情沒有人能告訴我, 所有的programmer都沒有辦法知道整個架構,
一點小小地修改都要找一群人開會, 大約要等二周,
或者自己看海量的文件, 找出所有用到這個clock的模組

文件比code還多的時候, 所謂的好維護根本只是為了以後可以告訴你,
他文件"有"寫到, 在編號E1046875r467文件的677頁120行....

找文件不會比找code方便, code至少是100%文字檔, C也比英文有結構

: : 每個函式都要定出來, 是用在程式模組之間的介面,
: : 不是要SA把程式架構裡的每個函式都弄出來,
: : programmer越高段, 模組就可以越粗略, 自行發揮就好,
: : 無法自行發揮的, 回去賣雞排啦
: : 無法理解程式運作的人, 同時也等於無法debug的人,
: : 能分工寫出來卻不能debug, 這算什麼分工
: : 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: : 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: : 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: : 只會更沒效率, 更多咖啡工程師抱怨賣肝
: 所以說，是台灣不重視 SA 、 SD
: 否則，為什麼只有幾個人負責設計？
: 只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
: 那是因為，在台灣， RD 要身兼 SA、SD、PG
: 如果是原作者說的那種玩法
: 那就要有數十位以至數百位 SA、SD，是公司最重要的資產
: 然後 PG 找工讀生或外包

這樣的架構, 一旦要改bug, 換規格, 反應非常慢, 大家時間都花在溝通,
programmer本來就應該有能力自己規劃模組的實踐, 自己為自己的程式負責,
而不是中間分出一大堆所謂SA/SD來, 架構的人沒在寫程式, 也沒有run程式,
寫的人只知道自己的一堆超簡單code block, 卻要找出整個程式哪裡掛了

: : 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: : 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
: 改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
: 儘可能設計到有彈性，使得之後的改變最小化
: SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 112.105.197.233
推 oomusou:spec比code還多是很正常的吧                              11/13 23:54
→ oomusou:花時間在溝通本來就很正常，pg不應該自己規劃模組          11/13 23:55
→ oomusou:sa/sd應該完全掌控整個模組才對                           11/13 23:56
推 codemonkey:不過對於要切割專案、同時面對很多外包商的PM或是SA，   11/13 23:57
→ codemonkey:寫規格書的確比較輕鬆，畢竟在制式文件格式下，發出去   11/13 23:58
→ codemonkey:的東西可以同時開始實作，如果是自己寫則有模組大小、   11/13 23:58
推 thinkniht:我覺得SA/SD的工作 要做好很難                          11/13 23:58
→ codemonkey:難度不一，實作速度 != 寫文件速度的情況               11/13 23:59
推 oomusou:通常spec破百頁很正常，真的寫起code來可能可能只有一點點  11/13 23:59
→ thinkniht:覺得很多資深又說懂OO的人 做的SA\SD內容其實沒那麼OO    11/14 00:00
→ thinkniht:當然 我覺得我做也不會做多好啦XD                       11/14 00:00
→ codemonkey:(SA動手寫程式？拜託～我說的是台灣軟體慘業吶，我還講  11/14 00:00
→ oomusou:SA/SD就是因為很難 所以拿的錢比PG多不為過啊              11/14 00:00
→ codemonkey:那個SA寫完文件就要負責PM了)                          11/14 00:01
→ oomusou:SA/SD要寫程式是有難度，畢竟他們不熟個平台API與tools     11/14 00:01
→ thinkniht:我說的是"做好" 要是大部分都是"做好"的話               11/14 00:02
→ codemonkey:不過既然規格書格式在公司都統一了，怎麼沒人弄個填表   11/14 00:02
→ thinkniht:就不叫軟體"慘業"了啊XDDD                              11/14 00:03
→ codemonkey:工具，填完規格就自動產出基本的IPO圖、方塊圖...多好   11/14 00:03
推 oomusou:通常SA/PG/Tes的時間比例是6:1:3，SA花時間並不為過        11/14 00:04
→ codemonkey:不過要是專案切割、分包太細，就又回到寫文件的惡夢了   11/14 00:05
→ codemonkey:真的，SA有做好，SD這邊切系統、做需求對應比較輕鬆     11/14 00:06
→ codemonkey:不過很多老闆的指令都是：先動工，以後都可以改，但是   11/14 00:08
→ codemonkey:文件要寫好 .........                                 11/14 00:08
推 oomusou:那是你們老闆不上道喽，我們都是spec要很確定後PG才會開動  11/14 00:09
→ oomusou:spec不夠清楚，還會被PG退回，等到SA弄得夠清楚才會寫code  11/14 00:10
→ oomusou:SA/SD拿的錢比PG多這麼多，PG當然不會輕易放過spec         11/14 00:12
推 codemonkey:大公司真好，中小企業通常都是{{PM,SA},{SD,PG}}        11/14 00:14
→ codemonkey:沒事退件給自己幹嘛～～                               11/14 00:14