走在 ALM 技術尖端的 MS TFS

作者: AmosYang (Zzz...) 看板: GameDesign
標題: Re: [請益] 關於AGDP的 Road Map
時間: Mon Sep 17 04:51:30 2012

※ 引述《moremusic (要去愛)》之銘言：
: 我自己覺得最重要的
: 是這個團隊有沒有辦法不斷累積在遊戲程式設計的能力與成果
: 這個計畫不管有沒有商業價值
: 只要確確實實去做
: 遇到問題努力去解決進而提升能力
: 就是最大的收穫了

完全同意

: roadmap?
: 有那麼重要嗎?
: 一堆專業的遊戲公司也搞不太定進度規劃問題(看那精美的D3)
: 搞定進度問題的也不保證能賺到錢
: 要求一個業餘團隊辦到
: 我覺得沒必要

我想到一個老笑話: “為什麼要寫作業?”
寫了作業的確不保證能畢業結婚找到工作有個親生兒子孝順且會乖乖寫作業
不寫作業也不一定就不能畢業結婚找到工作有個親生兒子孝順且會乖乖寫作業

聽起來，花時間思考 road map 也像是沒什麼用處的事
但事實上並非如此

藉由審視 road map, 可以推測這專案目前領導人的 PM 能力
大家從書上讀過都知道 waterfall model 與 spiral model 的分別

  http://en.wikipedia.org/wiki/Waterfall_model
  http://en.wikipedia.org/wiki/Spiral_model

但帶團能力不像技術能力有個 editor + compiler 就可以自己勤練練起來
要能帶一個團走上述任一個 model 去累積經驗之前，就得先作 PM 的作業

: 還有
: 打個廣告啦
: http://garfstudio.blogspot.tw/

我也打個廣告
http://tfspreview.com/

廣告說詞: 全世界最強大最好用的 ALM 方案 [1;30;40m之一

以微軟 DevDiv 為例，其開發方向開始從以(數)年為單位的 major release
轉變成以季為單位的 rapid release

而走在 ALM 技術尖端的 MS TFS 從 2003 到現在花了九年, 經過了 4 個 major release
可以讓一個 200+ 人的團隊 *每三週* 就釋出新的 feature

  每天數以百計的 source commit
  其 P0 functional quality 可以掌握到 each single commit 的程度
  其 P1 functional quality 可以掌握到每 8hr 的程度
  其 performance/scalability 可以掌握到每一週的程度

  從 source snapshot 到 CTP build 出貨，一週就可以完成測試與 verification

這就軟體開發(ALM, application lifecycle management)來說是不得了的成就
許多地方是過去有錢也買不到的 productivity

這是 MS TFS [1;33;40m以戰練兵的成果
(Microsoft Team Foundation Server ， MS ALM 的旗艦產品
 以戰練兵的方式是讓 MS DevDiv 底下數千 SDE, SDET, PM 直接 dogfood TFS
 不好的地方就改)
TFS 在 enterprise ALM 市場把原先的強者 (IBM) 打爆
逼得 IBM 去 reboot 其 ALM solution...
[1;33;40m靠得不只是戰技，而是戰術與戰略


看到這裡，讀者大概也想到了

  當手上只有釘槌時，每個問題看起來都像釘子
  在做 ALM 的人的眼中，每個問題看起來都是 program management 的問題...

Yes, guilty as charged XD

就今日豐富的教學資源來說，單兵戰技的入門門檻很低
有書有編輯器有編譯器有網路有範例有(英文)文件, 花時間練就可以了

但要練戰術執行與戰略眼光的機會卻少得可憐
在我還是學生時，一般資工學院也不重視這一塊
台灣的環境似乎也不如美國提倡 internship 的風氣, 提供練兵的機會

今天這個團隊的主導權在他們自己手上，沒人能強制要求他們什麼
只是看著他們兵行險著覺得危險、可惜而已

: ※ 引述《damody (天亮damody)》之銘言：
: : 大家好，我個人是第一次做開源project所以有些問題想問大家：
: :                                    目前
: : 目前是打算 做出遊戲引擎半成品 =>    開始找美術
: :                                  一邊完成遊戲引擎
: : => 請美術畫完畫 做出一個 game centent 這時的網路功能可能還不完整
: :    我們做完整合
: : => 將網路功能完整後 用舊的 game centent 直接可以變成 MMO ATG
: : 補充：企劃在哪裡，給其中一位美術跟程式一起當，
: : 主要原因是，這樣才有寫程式與畫畫的動力。
: : 希望達成目的：
: : 一．台灣學生的 C++ 水準能提升，業界都比學生強，不考慮
: : 二．希望幫助有興趣做 MMO ATG 且會畫畫的人做出遊戲來
: : 三．找到設計系學生參加新一代展
: : 喔，對，忘了問問題，人真的老了，
: : 請問這個 road map 的可行性大家覺得如何？
: : 有什麼需要改進的地方嗎？
: : 有關於七個學生，我對我們的程式實力算是很有信心，
: : 我也是找了好幾年找到都讀研究所了，
: : 才看到像黑子的籃球一樣的奇蹟的世代。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 98.26.14.35
※ 編輯: AmosYang        來自: 98.26.14.35          (09/17 05:00)
※ 編輯: AmosYang        來自: 98.26.14.35          (09/17 05:06)
※ 編輯: AmosYang        來自: 98.26.14.35          (09/17 05:07)

再來多唸一些

這前兩天看到這篇(2006的舊)文章

  http://bokardo.com/archives/the-delicious-lesson/

這文章整理出一個重點:

  "Personal Value Precedes Network Value"

易言之，這點出了我們常常會對 crowdsourcing 有一廂情願、
不切實際的期望, 而最常見的例子之一，就是把 open source 神化
以為只要是 open source, 就能利用(tap)全世界開發者的潛在能量

事實上，在使用者感受到切身的好處之前，就算只是舉手之勞的動作,
也只有極少數人會去做

以上述 MS TFS 以戰練兵的例子來說
之所以能發動 MS DevDiv 下幾千人來當白老鼠，
是因為這個決策當年是一路從 Brian Harry (MS TFS PUM) 到
 Jason Zander (MS Corporate Vice President) 都有背書才能強制執行
不然的話眾人大概還是會去用 Product Studio + SourceDepot
今天 MS TFS 也不會有問鼎 enterprise ALM solution 霸主的能力

前幾篇文裡也有提過， Epic 這公司也是主動帶頭用 UnrealEngine
作出各款 unreal 系列大作來展現 UnrealEngine 的價值以吸引使用者
而不是被動地期待 third party 來作東西為 UnrealEngine 打響名氣

Windows Phone 今天的苦戰也是一樣，一般消費者不會為“產品技術”
買單；消費者要的是(感受到的/perceived)產品價值。

是故，人是很現實的，不要對任何與 crowdsourcing 沾上邊的決策
抱不切實際的期望 :D
※ 編輯: AmosYang        來自: 98.26.14.35          (09/17 05:44)