大型公司開發軟體的流程是怎樣的？

12-25

這是一個悲傷的故事：

// actually this should be a singleton, anyway I"ve made it global Boss theBoss;

Game* MakeAGame(Manager theProducer, std::list& designers, std::list& programmers)

{ if (designers.empty()) return NULL; if (programmers.empty()) return NULL;


	Game* theGame = new (nothrow) Game(theBoss.GetALotOfMoney());

	if (!theGame)

		return NULL;
	// do the initializing work

	theGame-&>SetPlatform(theBoss.currentPhone.Platform);

	theGame-&>SetGameType(FindMostProfitableGameType());

	foreach (Designer designer : designers)

	{

		theGame-&>AddDesignDocuments(designer.docsFromElsewhere);

	}

	theGame-&>bugCount = 0;
	// the main loop (each iteration is a release cycle)

	while (true)

	{

		auto thisRelease = scoped_ptr&(new Milestone());
		int intensity = theProducer.Push(designers, programmers);
		foreach (Designer designer : designers)

 		{

			designer.Press("Ctrl", "C");

			designer.Press("Ctrl", "V");

		}
		foreach (Programer programmer : programmers)

		{

			programmer.Hack(thisRelease, intensity);

		}
		theGame-&>bugCount += thisRelease-&>bugCount;

		if (theGame-&>IsPlayableWithoutCrash())

		{

			theProducer.Broadcast("Let"s ship it!!!");

			break;

		}
		theProducer.CallForDelay();

	}

return theGame; }

如果上邊的故事太長的話，這是一個化簡版：

-----------v 1.04 修復 @蛋丁同學提到的內存泄漏
v 1.03 @程睿同學說參數太多，嗯嗯，俺虛心接受，想了想，把 theBoss 改成全局的了。
v 1.02 把傳值的 std::list 改成std::list，本來想傳常引用的，不過想想還是算了。這個捏其實也是照顧廣大還沒用上 C++11 的同學的習慣，C++11 通常是 std::move 進來就可以了。
v 1.01 修復了 @阿峰同學報的 bug，Hack() 傳入 thisRelease 應該就好了吧

有關阿里集團在打造支撐百萬用戶的分散式代碼託管平台，這裡分享一篇阿里技術協會的內部文章，本文主要介紹了阿里巴巴集團代碼服務團隊，在過去一年基於GitLab進行的代碼託管分散式改造，希望與大家進行分享與探討，為雲上開發者提供更好的代碼託管服務。

一、背景介紹

毋庸置疑，代碼是DevOps流程的起點，是所有研發流程的基礎；代碼託管為代碼「保駕護航」，確保代碼的安全性、可用性，同時提供圍繞代碼的一些基礎服務，如MR、Issue等等。

阿里巴巴集團GitLab是基於GitLab社區版8.3版本開發，目前支撐全集團數萬規模的研發團隊，累計創建數十萬項目，日請求量千萬級別，存儲TB級別，早已超過了GitLab社區版承諾的單機上限能力，且增長速度迅猛。

面對這種情況，順理成章的做法就是——擴容。然而非常不幸，GitLab的設計沒有遵守Heroku推崇的「The Twelve-Factor App」的第四條：「把後端服務當作附加資源」（即對應用程序而言，不管是資料庫、消息隊列還是緩存等，都應該是附加資源，通過一個url或是其他存儲在配置中的服務定位來獲取數據；部署應可以按需載入或卸載資源），具體體現是：

Git倉庫數據存儲於伺服器本地的文件系統之上
GitLab所依賴的三個重要組件：libgit2、git、grit也都是直接操作在文件系統上GitLab

所以GitLab社區版是基於「單機」模式設計，當存儲容量和單機負載出現瓶頸時，難以擴容！

二、面對挑戰

2015年初，阿里巴巴集團GitLab的單機負載開始呈現居高不下的情況，當時的應對方案是同步所有倉庫信息到多台機器，將請求合理分配到幾台機器上面從而降低單機的負載。然而這個方法治標不治本：

系統運行過程中的數據同步消耗資源和時間，不可能無限制擴充機器
這種方案暫時緩解了單機負載的問題，但對於單機存儲上限的問題束手無策

2015年中，團隊正式啟動了第一次改造嘗試，當時的思路是去掉對本地文件系統的依賴，使用網路共享存儲，具體思考和方案可以參見RailsConf 2016 - 我們如何為三萬人的公司橫向伸縮 GitLab。

然而由於本地緩存等問題的限制，網路共享存儲的方案在性能上出現較明顯性能問題，且大都為基於C/C++的底層改動，改造成本出現不收斂情況。而當時集團GitLab伺服器在高峰期CPU屢屢突破**95%**甚至更高的警戒值，而高負載也導致了錯誤請求佔比居高不下，無論是對上游應用的穩定性還是對用戶體驗都提出了嚴峻挑戰。

2016年8月起新一輪改造開始。

三、改造方案

既然共享存儲的方案暫時行不通（後續如果網路存儲的讀寫性能有質的提升，未嘗不是好的方式），首先明確了唯有分散式或者切片才能解決問題的基本思路。
我們注意到，GitLab一個倉庫的特徵性名稱是"namespace_path/repo_path"，而且幾乎每個請求的URL中都包含著個部分(或者包含ID信息)。那麼我們可以通過這個名稱作分片的依據，將不同名稱的倉庫路由到不同的機器上面，同時將對於該倉庫的相關請求也路由到對應機器上，這樣服務就可以做到水平擴展。

下面通過一幅圖介紹一下目前集團GitLab在單個機房內的架構。

3.1 各個組件的功能主要是：

Sharding-Proxy-Api用於記錄倉庫與目標機器之間的對應關係，可以看作切片的大腦
Proxy負責對請求做統一處理，通過Sharding-Proxy-Api獲取信息，從而將請求路由到正確的目標機器
Git Cluster由多組節點構成，每組節點內有三台機器，分別為master，mirror和backup。其中master主要負責處理寫（POST/PUT/DELETE）請求，mirror主要負責讀（GET）請求，backup作為該節點內的熱備機器

說明

master在處理完寫請求後，會同步更新此次變更到mirror和backup機器，以確保讀請求的正確性和熱備機器的數據準確
之所以沒有採用雙master的模式，是不想造成在臟數據情況下，由於雙向同步而造成的相互覆蓋

3.2 保證方案可用

如何確保切片信息準確
Sharding-Proxy-Api基於martini架構開發，實時接收來自**GitLab**的通知以動態更新倉庫信息，確保在namespace或project增刪改，以及namespace_path變更、倉庫transfer等情況下數據的準確性。
備註：這樣的場景下，等於每次請求多了一次甚至多次與Sharding-Proxy-Api的交互，最初我們曾擔心會影響性能。事實上，由於邏輯較為簡單以及golang在高並發下的出色表現，目前Sharding-Proxy-Api的rt大約在5ms以內。
如何做到切片合理性
海量數據的情況下，完全可以根據namespace_path的首字母等作為切片依據進行哈希，然而由於某些名稱的特殊性，導致存在熱點庫的情況（即某些namespace存儲量巨大或者相應請求量巨大），為此我們為存儲量和請求量分配相應的權重，根據加權後的結果進行了分片。目前來看，三個節點在負載和存儲資源佔用等方面都比較均衡。
如何處理需要跨切片的請求
GitLab除了對單namespace及project的操作外，還有很多跨namespace及project的操作，比如transfer project，fork project以及跨project的merge request等，而我們無法保證這些操作所需的namespace或project信息都存儲在同一台機器上。
為此，我們修改了這些場景下的GitLab代碼，當請求落到一台機器同時需要另一台機器上的某個namespace或project信息時，採用ssh或者http請求的方式來獲取這些信息。
最終的目標是採用rpc調用的方式來滿足這些場景，目前已經在逐步開展。

3.3 提升性能

ssh協議的替換
目前阿里巴巴集團GitLab提供ssh協議和http協議兩種方式，供用戶對代碼庫進行fetch和push操作。其中，原生的ssh協議是基於操作系統的sshd服務實現，在GitLab高並發ssh請求的場景下，出現了諸如這樣的bug：

由此產生的問題是：

ssh協議登陸伺服器變慢

用戶通過ssh協議fetch和push代碼時速度變慢

為此，我們採用golang重寫了基於ssh協議的代碼數據傳輸功能，分別部署在proxy機器以及各組節點的GitLab伺服器上。由此帶來的好處有：

機器負載明顯降低

消除上述bug

在ssh服務發生問題的情況下，仍舊可以通過ssh登陸（使用原生）伺服器，以及重啟sshd服務不會對伺服器本身造成影響

下圖是proxy機器採用新sshd服務後的cpu使用情況：

個別請求的優化和重寫
對於一些請求量較大的請求，例如鑒權、通過ssh key獲取用戶信息等介面，我們目前是通過文本轉md5，加索引等方式進行性能優化，後期我們希望通過golang或java進行重寫。

3.4 確保數據安全

一主多備
如上面提到的，目前阿里集團GitLab的每組分片節點包含有三台機器，也就是相對應的倉庫數據一備三，即使某一台甚至兩台機器發生磁碟不可恢復的故障，我們仍舊有辦法找回數據。
跨機房備份
剛剛過去的三月份，我們完成了阿里巴巴集團GitLab的跨機房切換演習，模擬機房故障時的應對策略。演習過程順利，在故障發生1min內接到報警，人工干預（DNS切換）後5min內完成機房間流量切換。
多機房容災的架構如下圖所示：
http://pic3.zhimg.com/v2-3716c090e30a9b82f147dc3659a869d6_b.png
保證准實時的倉庫數據同步是機房切換的基礎，我們的思路按照實際需求，由容災機房機器主動發起數據同步流程，基本步驟是：

利用GitLab的system hook，在所有變更倉庫信息的情景下發出消息（包含事件類型及時間包含數據等）
同機房內部署有hook接收服務，在接收到hook請求後對數據進行格式化處理，並向阿里雲MNS（Message Notify Service）的相關主題發送消息
容災機房內，部署有消息消費服務，會訂閱相關的MNS主題以實時獲取online機房發送到主題內的消息，獲取消息後調用部署在容災機房GitLab節點機上的rpc服務，主動發起並實現數據同步的邏輯
hook接收、消息消費以及**GitLab**節點機上的rpc服務，均由golang實現。其中rpc服務基於grpc-go，採用protobuf來序列化數據。
通過一段時間的運行和演習，已經確定了方案切實可行，在數據校驗相關監控的配合下，容災機房可以准實時同步到online機房的數據，且確保99.9%至99.99%的數據一致性。

3.5 如何提升系統的可用性

日誌巡檢
面對集團GitLab每天產生的大量日誌，我們使用阿里自研的監控工具進行日誌監控，對系統產生的5xx請求進行採集和報警，然後定期去排查其中比較集中的錯誤。經過一段時間的排查和處理，5xx錯誤日誌大致可以分為：

分散式改造帶來的跨分片操作的bug
GitLab本身的bug
高並發情況下帶來的系統偶發性故障
資料庫相關的錯誤等
由於用戶量大，場景多，阿里巴巴集團GitLab的使用場景基本覆蓋GitLab的所有功能，因此也可以暴露出一些GitLab自有的bug。如Fix bug when system hook for create deploy key（從此，咱也是給GitLab供獻過代碼的人了）。

伺服器監控
無論系統多少健壯，完備的監控是確保系統平穩運行的基礎，既可以防患於未然，也可以在問題出現時及早發現，並儘可能減小對用戶的影響。目前阿里巴巴集團GitLab的監控主要有：

機器cpu，內存、負載等基本指標的監控
ssh、ping等網路檢測信息（用於判斷是否宕機，後將詳述）
伺服器各個埠的健康檢查（80，90xx，70xx等等）
非同步消息隊列長度的監控
資料庫連接的檢查
錯誤請求的監控
Sharding-Proxy-Api與GitLab的數據一致性校驗
很自豪的一點是，我們經常可以根據報警信息，先於用戶發現問題。

單機故障的自動切換
雖然監控足夠完備，但誰也不能保證伺服器永遠不宕機，因此我們在同一組節點中保有一台backup機器以應對伺服器故障。會有專門的client定期通過API輪詢監控平台提供的機器監控信息，當確認機器宕機時（ssh和ping同時不通，且持續時間超過2min）自動觸發機器角色的互換，包括master與backup互換，mirror與backup互換等。通過演習，我們已經具備了單機故障時5min內全自動實現機器切換的能力。
機房故障時的切換
即前述的跨機房切換。

3.6 單元化部署

單元化架構是從並行計算領域發展而來。在分散式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作的自包含的安裝。而一個分區（Shard），則是整體數據集的一個子集，如果你用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區。單元化就是將一個服務設計改造讓其符合單元特徵的過程。

為了實現單元化的目標，我們在最初設計時就往這方面考慮。比如跨機房備份中，消息消費應用需要調用**Sharding-Proxy-Api**獲取rpc服務的地址時，儘可能做到數據在單機房內閉環。這樣在滿足單元化要求的同時，也可以在機房故障時，盡量不影響已進入隊列的消息在消費時出現數據斷流。

現在阿里巴巴集團GitLab在架構上已經基本具備了單元化部署的能力，這樣的情況下，無論是後續與阿里雲合作對外提供服務，還是當收購海外公司需要單獨搭建新服務時，都不會遇到問題。

四、未來的改進

4.1 偶發的cache大量釋放

由於GitLab有大量的IO操作，使得系統佔用cache的數值巨大，也正是因為cache，系統的性能得到保證。然而成也cache敗也cache，為了確保系統不會發生OOM，我們設定了vm.min_free_kbytes，當cache佔用過多且需要繼續申請大片內存時，會觸發cache的釋放，勢必會影響釋放瞬間請求處理能力（通過日誌分析得到，此瞬間的處理能力僅為cache存在時的1/2左右），直接後果是該瞬間的請求堵塞，甚至出現部分502。

為此我們諮詢了系統部的同學，根據他們的建議修改了部分內核參數（目前仍沒有根治），後續會嘗試升級內核的方式，也希望遇到過類似問題或對這方面問題有研究的同學，把你的秘籍傳給我們。

4.2 自動化運維

目前集團GitLab的發布主要靠手，在分散式架構下，機器勢必越來越多，全自動化的發布、擴容機制，是我們需要完善的地方。

4.3 rpc方案的最終落地

如前所述，只有最終實現了全局的rpc替換，才能將web服務所消耗的資源與Git本身消耗的資源進行分離，阿里巴巴集團GitLab的分散式改造才能算最終結束。

後續

監控及日誌數據對比顯示，過去一年中阿里巴巴集團GitLab請求量增長4倍，項目數增長130%，用戶數增長56%，在這樣的增速下，系統調用的正確率卻從99.5%提升到了99.99%以上，這些數字印證了我們方案的可行性和可用性。

接下來的時間裡，小夥伴們會為繼續代碼服務的創新而努力，「高擴展、分散式、響應式、大文件、按需下載、流控、安全、數據化、單元化」，有些我們做到了，有些是接下來努力的方向。

現在阿里巴巴集團GitLab的架構，已經足夠支撐百萬規模的用戶體量。在經過阿里工程師、開發者的千錘百鍊之下，我們有勇氣和信心通過阿里雲code（阿里雲代碼開發服務現可免費使用）為更多的開發者提供代碼託管服務，共同打造雲上的協同研發生態！

本文作者：billy.lb 屹恆

有關：阿里雲 code

這是一款從未在外面推廣過的代碼託管產品，估計很多人還不知道阿里雲有這個服務。阿里雲code旨在解決部分中小企業選擇內部自行搭建 Git或SVN ，勢必會遇到搭建、維護成本高，難於擴展和備份，數據安全和可靠性差的問題。

核心優勢——阿里雲上基於Git的分散式代碼託管，高可用、安全、高性能以及無限容量是其核心競爭力，支持svn倉庫的便捷遷移。

目前已面向個人或企業免費提供Git及SVN兩種協議模式的代碼託管服務：點擊免費使用

更多幾乎乾貨請移步：我是程序員 - 知乎專欄

像我們經常開發那些出了bug的話客戶都會過來殺了你的軟體（如SQLServer）的公司，我們的開發是很嚴格的。在保證功能完成之後，首要的一件事就是，確保軟體不會給客戶帶來破壞。因此除了敏捷開發以外，我們主要做了三件事情來讓碼農不要在開發的時候太分心搞別的。

第一件事就是你做了一個關鍵的設計之後，會有一個負責security review的小組來看你的文檔，問你問題，根據他們的專業經驗指出軟體哪裡可能是會被攻擊的薄弱環節。舉個例子，你用了XML做配置文件，如果用戶偷偷給你換了一個破壞過的XML，你的程序就會掛。一旦程序進入掛了的狀態的時候，是很危險的。如果你試圖恢復它然後繼續運行，你就得考慮大量的細節，來把你的軟體從錯誤的狀態恢復到正確的狀態。中間稍有不慎就容易被攻擊。所以我們都鼓勵說，一旦發生了這些不可逆轉的破壞，就讓程序自己出dump然後自殺。當然具體到XML這個例子，我們還有xsd文件，用Windows自帶的MSXML組件來實現驗證一下，所以還算是個小事。JSON就沒這個福利了。

第二件事情就是，我們的環境搭得特別科學。譬如說你開發SQLServer2014，那你還要給SQLServer2008打補丁。2008打補丁的時候用的SDK和開發環境可能跟2014有巨大的區別。所以我們有一個Build Team，寫了幾萬行的perl和bat腳本，來使得我們可以做到說，我們只要從2014的branch切換到2008的branch，這些工具就自動變了，譬如說cl.exe就從新的版本指向了舊的版本，庫啊什麼其他的亂七八糟的也是。如果你剛好用不上Visual Studio的話，只要你把代碼從Source Control上搞下來，運行他幫你建立在桌面上的一個快捷方式，就可以打開一個cmd，裡面的環境都配置好了，而且不會污染別的cmd。那我們就再也不怕手忙腳亂用錯工具來開發導致出現更多問題了。一個人有可能要同時在不同的版本上干不同的事情，因此這是很重要的。因此我們也會把大量的二進位文件checkin進去，因此很多組嘗試使用git最後都失敗了（啊哈哈哈

Visual Studio組跟SQLServer做法也差不多。但是因為VS要用上一個版本來開發下一個版本（譬如說2010就是用2008寫出來的），因此Source Control裡面的腳本還要負責編譯一個乾淨的、臨時使用的、不在註冊表裡面搗亂的、熱拔插的Visual Studio。你們想，如果我給2010寫的代碼出了翔，把2008的註冊表閹割了，還是把幾個文件刪了，我再也打開不了2008來改2010，這種事情能被允許發生嗎？不能！但是程序總是會出bug的怎麼辦？所以我們要有特殊的手段來解決這些問題，就是隨時編譯、checkin一個綠色的、但是功能絲毫不少的Visual Studio。當然這個東西只有Visual Studio組的人才有，而且長得跟正常的VS還是有顯著的區別的。不過這樣Source Control裡面的東西就更大了，但是微軟有的是硬碟，而且Perforce和TFS天生就對二進位文件支持的好，沒關係，跟git什麼的不一樣。

第三件事情就是制度的問題了。產品狗在我們這裡，責任很大，權力很小。原則上產品狗是管不了我們的，我們之所以聽產品狗的話，是因為我們跟產品狗都有相同的目標——把軟體做好。所以每當產品狗做了一些奇怪的決定的時候，我們可以很容易的拒絕他。他為了完成他們自己的工作指標，要麼就要來說服我們，要麼就只能改自己的決定了。因為產品狗和碼農之間沒有達成一致從而導致軟體沒按時完成的，產品狗具有很大的責任。我們還有專業的測試團隊。測試團隊的權力不小。譬如說產品狗提了一個需求，測試可以跳出來說這個功能會給測試帶來無比的困難，從而拒絕產品狗的決定。因此產品狗的每一個決定，首先要保證可以被科學的實現出來。當然產品狗自己通常可能不知道什麼是科學，所以我們要通過不斷的打他的臉來讓他明白，什麼是科學。

一背景

時間太久，不為本文中的任何一句話的真實性負責。

08年的時候剛剛加入搜狐，剛剛有工作經驗7個月，很快就開始做白社會的項目。
可以說是一個幾乎什麼都不懂新人，特別感謝琳姐帶我走入編程的世界。

那時候開心網的偷菜正火，Facebook如日中天，Twitter剛剛起步，新浪和搜狐剛剛在博客上打的熱火朝天。

同組的師兄剛剛從搜狐奧運組撤出，剛剛經歷過奧運高峰期的考驗，特地分享了架構，可惜當時才疏學淺，大部分都只能聽一個皮毛，當然現在也很菜。

方老大帶著我們做SNS，Mark帶著琳姐，吉子哥他們閉門會開了好久-據說是好久，反正多久我不知道，我是小兵兵一個，這些都是後來他們告訴我們的。

終於他們決定了，要做白社會。從他們決定做白社會開始，就決定了太多人一生命運的改變。

用我六年前的話來說，就是在白社會的時候，沒覺得有什麼，可是在現在看來，60人的團隊有條不紊，如同軍隊般整齊，條理清楚的做一個項目，是多麼難得的一件事情。

更不用說在當時的白社會裡，對於各種技術的調研和應用如雨後春筍。

這就是我經歷過的最大的項目了~跟眾多大牛比起來，大概微不足道，但是對我這種小兵兵來講，回憶起來已經是感慨萬千。畢竟當年的白社會團隊，60多個人，最菜的就是我，其他人幾乎全部是各個一線公司的CTO，副總裁，核心架構師，CEO等等等等。

我記得很清楚，要做這個項目的時候，第一次參加項目動員會，也是到今天為止最讓我受震動的一次動員會。

二啟動

熊杰那個時候是PM組的Leader（後來一個新浪的朋友說，她們在做微博的時候，那個時候其他行業都沒有產品經理這個崗位，新浪就有了。聽我有點目瞪狗呆，這麼算起來搜狐有產品經理這個崗位比新浪至少多了兩年吧？）

做的PPT很漂亮，怎麼漂亮的我不知道，反正就是講一個人，經受著各種各樣的壓力，然後早上七點起床，開始擠地鐵，上午被老闆罵，下午被客戶罵，晚上十點又要擠地鐵什麼的。

然後說他們需要一個地方，讓他們釋放壓力--雖然我到現在都沒太明白，一個單純的網站能夠釋放這麼多壓力么？

總之，一屋子大概三十，或者是四十個人，聚在一起。
嗯。在開心網偷菜，搶車位，真心話最紅火的時候，搜狐入場了SNS的領域。

然後，Mark他們定了一個很清晰的框架，這個框架，在未來半年到一年內，幾乎沒有變過。

整個網站的功能，被分解成三個模塊。FrameWork，App，Common，到現在我都在延用這種模塊結構。Framework是白社會的主要框架，Home，User什麼的都在這裡。App是預留的網站的應用，如真心話，池塘邊等。Common是公共服務，郵件啊IM啊通知啊神馬的都在這裡面。

跟著對下面的員工做了一個分組。
兩人一個組，做一個小的功能模塊。吉子和琳姐好像軍中大將，總共差不多十幾個組。每個組領命而去，兩周或者是三周交工，嗯，這是後話。

當時的目標就是，三個月左右，將白社會核心的功能做出來。包括：
用戶，好友，消息，通知，任務，推薦，Feed等等等等。

三開發

在此之前，就有了一周一次的技術分享，提前做了很多的技術儲備。白社會是一個全新的架構，所以琳姐他們也決定要做一個全新的技術體系。

首先，是在項目中正式使用maven。

我在之前的項目中，用到過一點點的Maven，琳姐給了我任務，讓我給大家講一下maven.第一次技術分享就奉獻給了白社會的團隊，還是有很多東西不太懂，可能也講不清楚，但是收到了申總的鼓勵，說我講的知識點可能不夠深，可是條理很清楚，能像我一樣把東西講清楚的人不多。

實際上，後來各個牛人在項目里用到的maven,都比我講的東西深的多。

其次，是在項目中推行敏捷開發。

在此之前，兩人一個組，需求評審，需求講解，方案評審，Demo，發布。
用Jira做Story的分解，每天早上跟著胡哥三人小組去茶水間開晨會。

當時的敏捷開發還有很多不完善的地方，但是已經給我留下了很深的印象，除了敏捷開發，我想我大概以後不會採用任何的開發流程了。

特別是需求評審的時候，我記得很清楚，琳子和吉子他們會爭的很厲害，為了一個功能要不要做，有沒有必要做，經常會吵得非常非常凶。可是我很喜歡這種氛圍，很喜歡他們思考問題的方式。

印象最深的一句話就是：琳姐說，為什麼要花費80%的工作量去滿足了1%的用戶的需求？池明想了想，說：可是用戶會因為這1%的需求得不到滿足而離開。

這個問題我到現在都在思考，雖然我現在思考的角度有了很大的不同，但是仍然會遇到同樣的問題。

嗯。特別是在做方案評審的時候，我在一周之內，為了拿出一個為用戶推薦二度好友的功能，做出了7種方案。

讀研的時候我們的老師就說，我們那個年齡，22歲~28歲，是最容易出成果的年齡，現在想想也確實是，如果再次能回到那個年齡段該有多好，如果你在看這篇貼子，如果你處在這個年齡段，好好珍惜吧~

方案評審比較隨意，不太在乎格式，只在乎能否把事情講清楚，把要做的事情列清楚。我的第一次方案評審，也是交給了搜狐。

這是一件很開心的事情，那麼多技術大牛告訴你方案中哪裡做的不合理，告訴你需要怎麼做，怎麼解決高並發的問題，怎麼去做算數據量，怎麼去估算佔用的內存大小，怎麼去利用緩存，怎麼去防止數據不同步。

Demo也是一件很開心的事情。整個搜狐的團隊，沒有測試。是的，搜狐60多人的研發團隊，沒有一個是測試。所有的程序員，自己就是測試。我們能確保，每一組工程師，做出來的程序，在Demo之後，幾乎是零Bug的。

第三是在項目中用了DAL

這是一個通用的，封裝了緩存的DB訪問框架。無數次我們都討論過開源事情，只是一拖再拖~到現在，嗯。

申總和康總負責這個框架的研發，是的，你沒看錯，在我們做項目的同時，他們只比我們早啟動了不到兩個月。

然後DAL支撐了絕大多數情況下的並發壓力，而且用起來很方便，很簡單。

也直接影響了我對於DB使用的喜好，從此以後再也無法接受聯表查詢。

第四是在項目用到了Tuscany

Tuscany是我至今仍然非常喜愛的框架，非常非常喜歡。Tuscany的設計哲學很經典，很開闊，又很簡潔。看完Tuscany之後，再看Dubbo，有點無法忍受這種山寨版的Tuscany，雖然Dubbo有他自己的優點，也是國內很多公司正在使用的東西，但是幾乎沒有什麼思想，或者說我已經掉進Tuscany的坑裡面根本不想出來了。

可惜Tuscany更新到2.0就不再更新了。

不僅僅是Tuscany的使用，Tuscany本身並不支持負載均衡。胡總神一樣的花了兩周時間，重新寫了一個Scallop的框架，用於做負載均衡。

嗯。當時還沒有Zookeeper，即便現在有了，我也更喜歡Scallop這種簡單直接明了的方案。

第五是在項目中用到了JMS

ActiveMQ確實有很多坑，我們遇到過不少的情況，折騰了好久才把他搞定。
用ActiveMQ來做解耦，也確實是讓代碼簡潔了很多。比如說用戶註冊，要算積分，要算推薦，要加好友，要初始化任務，要做很多很多事情。這些東西，用JMS來解耦是最合適的。

而且還封裝了Tuscany和JMS組件，這是我一直很佩服的地方，這些開源框架，在這些大牛手裡就是一個個可以任意組裝的玩具，三兩下就明白別人怎麼做的，然後自己要怎麼改進。

第六是在項目中用到了CometErlang

最早聽到Erlang的消息機制，進程的概念的時候還不太了解，直到後來被迫自己也要這麼做的時候，才重新溫習了一下Erlang的東西。

Erlang的語法也是真心醉了，如果不是看過一點Drools，還真的。。學不會。

白社會用Erlang來做五子棋，那時候對Comet也是一知半解，直到後來自己用Comet來做在線多人掃雷的時候，才深刻體會到重新打開Http連接是一件多麼廢時間的操作，才真正轉向到WebSocket-可惜，白社會那時候沒有WebSocket。

第七是在項目開發了自己的標記語言

馬丹是叫SML還是叫什麼來著，我不記得了。仿照Fackebook的做法，解決第三方App怎麼和我們的FrameWork交互。看到他們當時去推測和分析Facebook的技術原理的時候，福爾摩斯都不過如此。

很快，一個小的示常式序就做出來了~

第八是在項目中使用了Groovy

Groovy用在了任務上，用戶接受任務，完成，領取獎勵，這些東西是通用的，但是每個任務的完成機制不一樣，所以我們需要一個輕巧的，簡單的動態語言來解決這個問題。

嗯。後來我在我們自己的項目中，把Groovy用到了後台統計各種複雜的計算公式演算法中，可以在線編輯。

這是我記得，或者是我知道的，在當時三個月里，幾乎全部出來的新技術和新框架。
而這一切，絲毫沒有影響整個項目的開發進度，這麼多人做出來的程序，幾乎是沒有Bug的。

嗯。我一直不知道該怎麼描述。

四內測

要上線之前，蘇菲設計了一版粉紅的UI，還有一個冬天雪人的UI。我更喜歡那個雪人的設計。

他們還加了小彩蛋，關燈，老闆鍵。

先是開始內測，內測的時候，很快就發現了Feed里到處都是加好友的信息。然而，以我的感覺來看，搜狐內部其他部門對於這個產品，幾乎是帶著嘲諷的角度去看的。

並不會如我想像的一樣，大家都是搜狐的員工，出了一個新的產品都會去開開心心的用，然後開開心心的提問題，大多數都會說：這什麼鬼東西，怎麼設計的這麼爛？
因為都是同行的原因？我猜不透~也不想知道。

不過，白社會大部分的時候口碑都很好，UI的設計，交互的體驗，簡潔的功能，都是我做過的系統中最舒服的一個。

內測開始後，安全性，用戶體驗有了一波新的改進。跟著就進了公測了~

五公測

公測之後，對於絕大多數的人，白社會的口碑都很好。特別是生活在別處，特別是小白這種親切的稱呼。

後續又出來了白社會小報，池塘邊，夢幻城，綠光森林等幾款很有特色的產品或者是遊戲。

只是當時大家所談的都是一件事情，想要複製開心網偷菜應用的成功，所有的人都認為，白社會只是缺少一個殺手級應用。

他們說，當時新浪在做新浪朋友。然後搜狐搶先上線了白社會，當白社會出來之後，新浪朋友的團隊直接解散，放棄了新浪朋友，轉做微博。

嗯。我不知道具體是怎麼樣的，白社會的產品研發團隊都很贊，可是在運營上，在大的方向上或者還是差了一截。

只有北京的公交車似乎有過白社會的痕迹，搜狐主頁上曾給白社會留過一個很值錢的廣告位。
天天向上那時候也只是張朝陽大人一個人去了，似乎並未能展示白社會的團隊。

六最後閑談一下發布流程

當時，白社會也是沒有運維的，運維是胡總和洪濤兩個大神負責。每周二，每周五，半夜十二點，每一個項目的工程師，都在自己的電腦面前，完全不需要聚在一起，完全不需要在一起加班，只需要在自己的家裡，電腦面前，等著胡總說一句：發布了~檢查一下有沒有發布成功。然後開開心心的等著晚上第一個使用的用戶，檢查有沒有問題。

嗯。每次發布，白社會就會寫上一句：白社會正在進行日常衛生打掃.

現在發布一次程序，跟打仗一樣。

現在安排60個人去做一個項目，在三個月之內做出這麼多東西，又能幾乎沒有任何損耗的去有序開發，好難。

白社會戰友群，寫的是那些年，你上過的白社會。群里大概80多個人，有很多是在我離職之後才加入的，現在都混的很好很好。

最後，貼幾張截圖。

馬丹，上傳不了圖片。

多圖警告！流量黨迅速撤離現場！以下為順序步驟。

第一步我們要確定一個可行的設計方案

第二步我們要開始把框架搭好

第三步我們開始一個模塊一個模塊的完成

第四步可以拿去給測試們看了(白盒黑盒都有)

第五步我們的產品經過測試通過可以拿去給安全組檢查了

最後我們的產品就可以上線了

I make things.

----------------------下面是彩蛋----------------------------
我們是你有可能中途遭遇的無數需求變更

軟體和公司都分大型小型。對於軟體來說，針對個人的算小型，也就是桌面應用，針對企業組織的算大型。公司么，就是人多人少，有的公司是產品性公司，有的公司是項目型公司。

我比較熟悉的針對金融行業的J2EE軟體，通俗來講，就是給銀行保險公司投資公司等用的核心系統。這個領域除了互聯網金融，其實電子化率很低，銀行稍微高些，其他的保險公司也好，基金公司也好，很多中小型的，甚至真的用excel而已。原則上，和這些公司工作，流程基本上都是：

首先做售前和銷售，這個時候多少會演示下系統，有的公司還會給你幾個功能嘗試下，這個叫POC。然後簽合同，合同一般是分步簽的，這個不細談。

簽完合同，給客戶上課，把基線系統給客戶演示，然後客戶根據他們自己的需求，提功能需求，這個階段叫workshop。

然後業務人員針對客戶需求，寫功能文檔，當然，還有一部分非功能要求，叫做NFR，這是由架構師負責的，還有專門的集成部分，因為金融系統大多很多年，通常有十幾個系統互相集成，這些都寫完，開始設計。

設計階段主要分三個部分，概要設計，這個部分是看整個系統是否要大改動，比如我現在正在做一個項目，要把常用框架升級到Spring全家桶，這就在概要設計部分展開。

其次是高層設計，這個會針對每個功能點，詳細寫下什麼地方如何改動。

然後是底層設計，這個部分會寫偽代碼和功能測試用例，用來給開發中心進行編碼。

在開發中心編碼的過程當中，還要採用CI的概念進行開發質量管理，直到提交。

代碼完成了以後，提交發布，放到測試伺服器進行人工測試和自動化測試，直到符合標準。

之後是客戶SIT，這是系統集成測試，放到客戶環境，和客戶其他系統進行對接測試，看看通訊是否成功。

然後是UAT，這是客戶的最終用戶進行測試，用他們實際業務當中的行為進行操作。同時也是對他們的培訓。

之後是上線，上線之前可能還要進行凍結以便進行數據遷移。

然後是保修期，一般1到3個月，這個過程當中，免費修bug。

然後是維護合同，按照合同對軟體進行修bug和二次開發。

1，需求=&>評審
需求可能來自很多角色：客戶|市場|戰略……，產品，架構，開發，測試……
當需求被提出來以後，就是對需求進行評審，針對不同種類的需求，後續流程也不太一樣。
比如產品提的需求，可能流程就會複雜一點。測試或者開發提的需求，視不同情況走不同路徑，需要審批路徑可能會短一點。
2，設計=&>評審
比較大的需求，可能會有架構參與進來，做一個整體的設計。小的需求，可能只需要高級工程師就OK了。然後自然又是一輪的評審。從各個角度看有沒有風險和漏洞
3，開發=&>CR
這個階段最沒意思，基本上就是按照設計原樣CP。結束之後要進行N輪CODE REVIEW，講解給別人聽。接受別人的各種質詢。包括各種低級的高級的質疑，比如空指針什麼的。
4，測試=&>N輪，包括開發的測試腳本，測試的
不同的項目組有不同的做法，但是一般要求有開發的單元測試、測試的集成測試。不過著兩個環境貌似偷懶的最多。也有做的非常好的。
5，預發布=&>流控=&>正式上線
會有測試環境的驗證。算是一種集成測試，沒有問題，就生產環境上線。
流控：生產環境上線其實不算真正上線，流量其實還沒有切進來，可以一點點的將指定比例，指定要求的交易切到指定系統中，進行驗證。如有問題，可以迅速回切，回滾。
流控觀察沒有問題，開始放量，才算正式上線

這是支付寶要求最苛刻的交易系統的流程。如果不涉及到交易，其他系統相對就比較寬容

再多少一點，另外一點做的比較好的地方就是監控
硬體監控，軟體系統，流量監控，業務監控，渠道監控等……監控幾乎無處不在，並且以圖形化直觀的展示出來。可以方便的發現很多平時發現不了的問題。

比如每天天某一刻為什麼有一段圖形尖刺……都是調查和改善的有力幫助工具

公司比較大, 但是部門很小..... 因此軟體流程基本上跟小公司沒差, 雖然也有這樣那樣的龜腚.
項目怎麼來的? 不清楚...
項目給誰做的? 剛開始不清楚...
項目要做什麼? 只知道自己負責的模塊.

前期會開會,開會,開會,莫名其妙的就出來方案了. 某些設計師真是一開始就決定好了, 開尼瑪什麼會啊.
於是, 架構師將框架上傳到svn, 找到自己的模塊部分, 拉下來, 將介面插到合適的位置, 推進去. 劃清自己的地盤, 準備工作做好...
接下來調研模塊功能,
1. 在這段時間基本上將整個項目理清, 通過設計文檔, UML, 需求文檔等等.
2. 上網查各種相關知識, 及開源項目, 像海綿一樣吸收穫取...
3. 修改UML, 將自己的流程整理好, 給組長開討論會議.
討論會議結束後, 制定項目進度計劃.
正式開工, 寫程序實現功能, 完成.
然後是debug, 單項測試, 聯調, 有時會有真實環境測試.
然後丟給測試再測.
最後發布版本.

我所在的成都分部有200多號人，類似的分部全國各地有十幾處。應該算是比較大的公司了。
大致流程如下：
1、採樣、收集匯總數據，確認產品類型。
2、立項評估（demo演示,PPT/VISO/思維導圖/Axure都行）。
3、立項書撰寫與審核（包括團隊成員的確定、工期預估、經費等等）。
4、詳細設計文檔（分程序類和美術類，項目開發，策劃先行）
5、開發過程（不細說）
6、真機測試（細化、反覆修正改良，小的半月，大的3~6個月）
7、上傳審核（自家渠道可以不用）
8、上線試運營期（1～2周，沒什麼問題的話這個項目才能算完結）

會有很多不同的里程碑,分別從平台，產品等不同角度來定義需求，開發，測試等各階段的target和check list等等。

先說需求吧，理想狀況下，需求會從一頁紙的One Page Product Description（說明產品定位，賣點）開始，逐步細化成數百數千行的feature list（產品需要支持的各種特性）再『翻譯』成工程人員開發所依據的system requirement（需要的各種修改，需要過的測試、認證，需要達到的各項性能指標等）需求確定下來之後，一般會有一個milestone表示該項目需求已經lock down，再進新的需求要走change request流程，需要各個stakeholder review對本項目及同期其他項目的影響。

開發及測試的計劃方面，在細化system requirement的同時基本上也會細化開發計劃，估算每個feature需要的修改工作量，測試工作量，什麼時候拉哪個feature branch, 什麼時候merge back。什麼時候拉產品分支，什麼時候做功能測試，集成測試，壓力測試，各做幾輪等等。計劃做完後又是一個milestone,表示已經承諾delivery scope和schedule了。

日常的開發工作基本上對每個feature的開發會拉一個feature branch, 在feature branch上提交代碼基本上由開發組自己測試保證質量。每個提交都會做CI build和auto test, 保證使用該分支的所有產品都能build過，基本功能正常。如果開發持續時間較長，需要定期merge upstream。merge back回主線的時候要過事先同意的一系列merge back criteria，主要是架構一致性，兼容性，以及大量測試保證穩定等等。主線上所有的提交都需要Verification +1，Code Review +2。產品所有功能開發完畢並經過一定測試後，在產品發布前會拉產品分支，啟用白名單制度（又一個milestone）。根據bug的來源，概率，嚴重程度確定bug是不是進白名單，嚴禁fix不在白名單里的bug.

最後，產品開賣，進入維護階段（another milestone）開發項目完成會總結開發中的Lessons Learnt，下次接著犯，然後就是吃飯慶祝，互相吹捧或者擠兌什麼的。維護項目就是收集客戶反饋，修修bug，保證產品正常的生產銷售什麼的。

第一次被別人邀請唉！先嘚瑟一會兒。

樓上幾位都是官面話，照著教課書或者CMMI講一遍，等於啥都沒講。俺整點新鮮的吧！

先講瀑布式開發的。其實大部分公司，90%的開發，都不是新產品。基本都是在原來的框架上做一個新功能，比如加個統計，報表之類，或者增加一個故障的自動保護什麼的。所以基本上也就是需求，文檔，測試那一套。其實樓上說的多太虛，基本上是在公司主要流程（CMMI類似）的基礎上，具體細節千變萬化，取決於具體的產品經理、項目經理、部門經理的個人風格，就是誰吵架能吵贏，就聽誰的。產品經理吵贏了，就是客戶導向，甲方說啥就是啥，虐你千邊，待他初戀。項目經理吵贏了，就是，極度公司八股，照搬公司流程，一筆一划，慢慢來。部門經理吵贏了，就是極度工程師自由化，肩膀一拍，兄弟加個班，把丫搞定。各大公司，概不如此，從所謂嚴謹的德國公司，到自由的美國以色列公司，到土鱉的本土公司，都是一樣。只是外國公司，項目經理吵贏的時候多，本土公司產品經理吵贏的多。

做新產品，沒有框架，就很少有需求實現的那一套。一般會有幾個大牛去預研，照抄競爭對手的功能，反向工程；或者買點code（土鱉公司可能是偷點），研究一下別人的框架；或者上開源的庫，劃拉一些東西；或者策反業界成熟團隊（這個某司常用）。這個往往和公司和人緊密相關，倒是沒有什麼慣例。

再說點時髦的敏捷開發，不過只能中英混雜，可能引起不適，請自行找廁所解決。
一般來說，一個Agile Program，一般從源頭到最後的交付和驗收都是精益控制的。

1.
Program Backlog：所有的需求都會存在於一個完整的backlog,裡面把需求breakdown成一個個的user story.是執行Agile的源頭。可以作為Agile Team的輸入。產生Program Backlog的人一般是產品經理或者是一個角色在agile中叫PO(Product Owner)。這個Program
backlog要求蠻高，這個一般都是有文檔化的東西或者網站管理的。

2.
Cross functional
team planning game: 當Program Backlog is ready,　Team 在planning game meeting 中進行commit.所有的user story都會被估成story point用來衡量工作量的大小，不用man hour來衡量的. 每個Team的velocity都有一定的bench maker,這是team對PO做commit的根據。

3.
通常是time box,一個sprint持續２周或者３周。但是一般都是固定長度的sprint.

4.
當team向PO做好了commit之後,就是team
self-management的過程。一般所有的user stories 都breakdown成一個個的task貼在白板上了。採用daily stand up
meeting每天跟進，這個都是沒有文檔記錄的。

5.
當一個sprint做完以後，team要demo給PO，PO一個User story一個User story的驗收，每個User story都有驗收標準寫在Program Backlog裡面。當所有commit的User story被PO驗收通話後，這個sprint就是成功的。如果有沒有通過或者沒有做完的就是失敗的。

6.
每個sprint結束都要有retrospective meeting. TEAM 自己總結得失再制定AP做improvement.

基本上都是這樣一個來回循環的做，在Agile里沒有項目的概念，所有一個項目里的user story就要靠Program manager和Product owner 根據release roadmap去做計劃。Program manager關注team的進度和產出，Product owner關注質量和具體的scope.在整個過程中，職能經歷關注的更多的是團隊的cross
function 以及團隊的成長和穩定程度。穩定是Agile Team的前提，不能經常變來變去，為了形成固定的team
velocity.

請問以上agile日常，你看懂了嗎？你看懂了的話，肯定是我沒說清楚，你應該不懂才對！

謝邀，我當前部門的開發流程其實並不夠規範高效。
一般企業級軟體定製開發有的毛病一樣不少。。。
一般首先是銷售去賣軟體，簽合同。
然後需求調研去調研需求。
需求調研完形成需求文檔，傳遞給開發人員，再由系統架構師分析並分解需求為各個足夠小並相對獨立的功能點，分派給各個開發。
開發去寫代碼，寫完轉測試。
測試開始測試的時候，開發相互review代碼。
修改各種問題，寫各種文檔。
發布。

流程大概就是這樣，至於喜聞樂見的需求變更和產品之間相互不配合什麼的，等我下班在補。。。繼續加班

—————————————華麗麗的分割線———————————————
下班回來補上，由此可見業軟狗的苦逼。
牢騷結束。

首先，業內流行的軟體開發模式無外乎兩大類，一類叫CMMI，一類叫敏捷。
其次，這兩類開發模式無所謂優劣，只有適不適合項目和團隊當前的需要。從無一竿子打死，說XX一定比XX好這樣的事存在。
再次，從本人目前經歷過的若干項目來看很少有極為純粹的CMMI或者敏捷的實踐，多數都是因地制宜的以一種模式為主，並且加入了另外一種模式的幾個關鍵動作形成了所謂的流程。
CMMI和敏捷的共同點就是核心思想是一致的，就是持續改進，隨著團隊技能水平的提高和溝通效率的提升，逐步的優化流程，這才是管理者應該做的事，而不是天天盯著報表和文檔上的數字，彷彿進度條到頭了，項目就可以大功告成了一樣。
CMMI和敏捷不同的地方，CMMI相對來說信任過程，要求通過過程中每一步的監督和審核，來保證每個步驟都是合格的，從而保證最後結果的可控。敏捷相對而言，更基於人為出發點。個體和互動高於流程和工具（敏捷宣言第一條），所以如果在團隊的個人水平都達到一定程度以上，並且建立了相互信賴關係（為什麼我想到了ssh信任關係。。。）之後，採用敏捷的開發模式為主，能提高團隊的工作效率，並且帶來更好的工作體驗。
對於客戶來說，CMMI每一步都有可視化的輸出件來保證最後結果一定是符合合同上約束和要求的產品。敏捷則更為靈活多變，客戶合作高於合同談判（敏捷宣言第三條），響應變化高於遵循計劃（敏捷宣言第四條），能容忍更多的需求變更。（更多不是無限！無休止的需求變更是神也無法解決的問題）兩者各有所長吧。
BUT，敏捷就一定優於CMMI么？未必未必！如果你的團隊剛剛組建，團隊人員水平參差不齊，甚至不乏拖後腿和渾水摸魚之輩，相互之間也沒有經過磨合形成一定程度的默契的話。貿然採用輕量化的敏捷開發模式，很可能就是要吃虧的。畢竟敏捷的本質不是快和拋棄文檔，而是一個可以工作的軟體高於詳盡的文檔而已。（敏捷宣言第二條）如果連一個可以工作的軟體都不能按時按量輸出的話，還是先走CMMI控制住項目進度再說吧。

好長好累，滾去重構我的東西去了

大公司都是注重員工的公司，員工乾的開心，效率和質量自然都高。

Development process都是扯.

類型IBM、微軟、華為、BAT等大型公司，他們開發軟體的流程，其實就是項目管理流程要包含的軟體開發類項目管理流程，使用的方法論無非是IPD、IT-CMMI、SDL（安全開發生命周期）、敏捷項目管理等等，一般將幾種方法融合使用，在自己的項目管理平台中實現落地，將各種質量控制活動（例如評審活動，特別是對安全的審核，也就是上面提到的Security Review）融入到項目的各個階段。
項目階段的劃分，參考下圖：

利益相關：參與Janusec SDL SaaS服務設計。

說的都挺高級的

我講講自己的看法

那就是

不是在走流程，就是在走流程的路上

改一行程序……然後開始走三天流程

真的有這麼多流程啊！

有時候自己想想也覺得有趣

而且這流程也不是好走的

一行程序，有人提意見，你得來回郵件好幾天；一個回歸測試不過，你得調查好幾天

總之就是走流程就對了

有基本流程式控制制，但肯定會依據項目工期，類別的不同對已定義流程作剪裁，
一定有測試部，一定有文檔輸出。一定有需求調研。一定有配置管理。

我就說說之前實習過的某國外大型遊戲公司的開發流程。
首先一款遊戲的提出可能是任何設計師，設計師會異想天開，然後寫一些文檔，其中有劇情有玩法有設定。
然後這個遊戲的設定會組織一小波碼農、美工的小團隊做個原型，原型可能很簡陋，有的甚至拿公司現有的遊戲改出來一個小場景。
原型需要被上級審核，審核通過後，成立一個相對比較完整的小團隊，開發一個可玩的關卡。注意到這個時候遊戲還是沒有立項。
可玩關卡再拿去一般是總部審核，審核通過了，項目就有了自己的編號和對應的款子、配置。然後成立正式的開發團隊，有設計師、美工、碼農、PM等等。
這個時候基本跟軟工課本上的軟體項目一樣了，迭代模型，一個版本一個版本往上走。如果走的順利，最後能夠發布，反之也有可能在開發過程中被砍掉（很多）。
發布後還有一些更新和維護，這些也跟一般軟體類似。
這是一個完整的遊戲所走的流程，從最開始的原型到最後發布，每一步項目都有被砍掉的可能，所以市面上能見到的遊戲只是大公司開發過的很多遊戲中的一小部分，更多的是胎死腹中。
但也不是所有遊戲都是這樣的，有些有很多代歷史的遊戲項目可能會一直做下去，還有一些移植的項目可能直接成立一個組開始改開始做。所以大公司也不是都按既定流程走的，變通的也很靈活。

專門寫個答案來吐槽第一：
1、文不對題不叫不科學
2、代碼有翔不叫不科學
3、因為「測試過於複雜」否定產品需求不叫不科學
4、權責不對等不叫不科學
5、作為「有共同目標」的團隊對自己的合作夥伴報以如此蔑視的態度還能合作順利不叫不科學
6、可能我不懂什麼是科學

作為一個討厭編程的本科計算機專業畢業生，從未想過自己會去思考軟體開發這種事情。然而機緣巧合，人生中第一份工作是一家比較大的公司的PMO，剛剛入職兩個月，看到這個問題，覺得自己剛好可以回答一下，算是複習總結入職以來的收穫。（國外項目，國內的話不太了解，，）

大型公司做一個IT項目往往是包含很多小項目並行的，最終組合實現一個商業目標。項目發起的過程不得而知，個人猜測是，公司高層提出想法，論證以後確定需求，劃分若干小項目各自實現不同的目標，尋找合適的開發、管理人員開始項目，最後共同滿足最初的商業目的。

比如我現在的PMO管理的還未完成的項目共有5個，已經go live的項目有若干，這些子項目（projects）共同組成了一個大的項目（program）。幾乎每一個project產出的都是一個完整獨立的軟體，並且各個軟體之間有介面，將來可以相互配合。

大型公司一般不是自己獨立開發軟體，而是由一個甚至多個供應商（vendor）共同協作。如前所說，接觸過的小項目超過5個，包括environment，testing等輔助項目，接近十個。它們由幾個不同的軟體/諮詢公司共同協作完成。比如我來自一家小諮詢公司，專做PMO，共事的同事來自Accenture，IBM，TaTa，Cognizant等等不同的諮詢公司，可能一家公司負責一到兩個項目，也可能一家公司只負責UAT或SIT。

軟體開發不僅僅是寫代碼，個人認為Business Analyst 和 Project Manager才是項目的靈魂人物。這個program的產出將會用在亞洲許多國家，所以整個工作環境是全英文的，因此程序員們絕大部分來自印度。年輕時候總覺得程序員才是最重要掙得最多的那個，現在發現BA和PM才是，並且他們不一定知道怎麼寫程序。BA從用戶也就是我們服務的公司那裡拿需求，轉達給Developers。把需求說清楚就是他們的主要工作，也是開發過程中很重要的一環。PM管理整個項目，進度控制，人力資源分配，問題和風險的管理等等。接觸到的每個PM都來自不同的國家，不同的諮詢公司，大多有10年-20年的工作經驗。他們像是Director指明方向，程序員和BA們去具體執行。

這是我平時用的timeline，具體進度用MS project管理，這張圖給management看~ 可見designbuild佔用的時間很久但是並非項目的全部，SIT,UAT等等測試也非常重要，對於其他一些項目硬體/環境的搭建也很耗時間。這一個個過程都是PM去管理指導的。

倉促寫的，以後想到什麼再補充~

我們公司說是大公司，但是你想不到流程是怎樣的：
1、產品提出需求，需求文檔有時沒有，有的話簡單維護在wiki上
2、經理排期開發
3、開發人員開發
4、測試
5、上線
其中最苦逼是開發，首先需求不了解，需求點太模糊，要追著產品問，測試時，測試人員根據需求文檔也理解不透功能點，追著開發問，上線也是開發人員上線的準備工作，追著公司各個部門配合，看人家心情幫不幫你，上線後功能驗證也是自己來，開發在無盡的折磨與熬夜中都幾乎都選擇了離去。