第一部分 調研，評測
評測：
功能評測（黑箱測試）
BUG
目前來說，確定的功能性Bug確實是沒碰到，不確定的有一個：在下面測試的第二部中代碼檢查嘗試了許多方式無法讀取到代碼文件，未確定是我的操作錯誤還是存在Bug。
但另一點用戶體驗上有個想吐槽的地方，所附的軟開雲Demo文檔內容中，1.4子賬號注冊的界面，在我注冊登陸之后找了半天沒有找到在哪里，點了登陸后第一個頁面右上角用戶欄內的管理控制台，對應的並不是文檔中的控制台，看了一下文檔的更新日期是11.06，想到應該不會是正好在這么短短的時間里更新了界面，最后在底下的一堆“免費體驗”產品中點進一個才進入到文檔所示的界面，如下：
點擊了代碼管理的免費體驗后進入：
個人感覺是否是demo文檔未描述詳細，當然也可能是我沒有理解到位。但我覺得從底下具體的某一個體驗產品看起來比較像廣告而不是一個正式的功能入口，所以用戶會比較難在短時間根據文檔去找到。更何況現在普通用戶看文檔的習慣並不普遍，不看文檔可能需要更久的操作，所以希望可以改進一下。
1、代碼管理
目前我以使用Github的習慣，並且參照了軟開雲的一些幫助文檔完成了git的相關功能，整個過程還是很流暢的，文檔介紹很詳細，另外看到直觀的中文說明真的是心里有說不出的感動和舒服。以下是使用過程：
新建倉庫
設置SSH密鑰
克隆倉庫到本地
以及十分方便的直接在網頁上拖動文件上傳代碼，但是響應有一些慢（此外還有體驗良好的創建目錄、創建文件等功能，同樣響應速度不理想）
成功在命令行下pull
總結：華為軟件開發雲的代碼管理初體驗確實是讓我非常驚艷，倍感驚喜，感覺發現了新大陸，一是界面友好，二是操作流暢絲滑沒有阻滯感，要我自己說如果我未來工作能決定我的團隊用Github還是華為軟開雲，我會選擇華為。但同時也希望可以退出像“Github for Windows”這樣的可視化界面進行代碼推送和pull，個人比較喜歡github桌面版的簡單操作。
2、代碼檢查
很遺憾我仍未搞懂代碼檢查應該如何使用，雖然可以理解各種規則集，以及大致理解（自我感覺）這個界面（見圖1）的各種條目是什么意思，但是我嘗試了幾種方法仍然不能讓系統檢測到我的代碼（見圖2），而實際上該文件夾下是有.c文件的（見圖3）
圖1
圖2
圖3
文檔中也沒找到相關說明，所以希望還是可以解答下代碼檢查的正確使用方式。
3、測試
華為軟開雲的測試個人感覺像是類似Issues的測試管理，我在上面找到了熟悉的添加TASK，添加標簽，並且有更加詳細的設置事件狀態功能
測試狀態變更
在設計與驗收中顯示出了狀態
此外軟開雲貼心的有郵件提示測試任務分配，第一時間就收到了任務消息，很實用
4、聯動的Android端
軟開雲的安卓端十分簡便，只能只有任務管理的功能，當然手機上也不太可能進行什么復雜的代碼操作，這里我測試添加了一個任務
軟開雲立刻同步到了WEB端，我將它設置為關閉
在軟開雲自帶的看板上直接以視圖給出了各種信息，比如迭代
趨勢圖也更新了
數據形式的分析
可以說十分的完備，不需要像github借助第三方的burnchrt，且功能也不如華為的強大
5、關於其他功能
華為軟開雲還有許多強大的功能，但限於水平有限，有些功能我完全不了解作用如何，怎么使用，所以也難以評測，比如說構建。還可以直接進行項目的部署，配置主機等等，配合軟開雲一體化的服務器平台、代碼平台，可以很便捷的完成整個項目的工作，因為我沒有申請服務器，所以也就沒有進行進一步的部署測試。
假設你們團隊需要開發這套系統，需要注意哪些方面。
（還是很難想象我或者我的團隊可以完成這么偉大的任務）
需要注意的方面：
1、我覺得這樣的一個系統的開發應該采用增量模型，因為各個模塊相對獨立，可以進行單獨的划分模塊開發，在后期添加新的增量。
2、代碼管理平台的可視化與交互性十分重要，目前github在CS的大學生間並不足夠流行除了顯而易見的第一點語言障礙外，就是上手困難，更多的功能我覺得要放在可視化界面上完成，而不是密密麻麻的指令行。
3、代碼檢查的規則集應該具有高度的擴展彈性，軟開雲的可自添加規則集我覺得非常棒。
建議：
1、比如像添加代碼檢查的規則集那樣的形式，增加各種真正可以直接進行代碼測試的模塊，如單元測試等。
2、軟開雲已經有了一套完整的項目生產流水線，但我覺得可以再加上一條，項目發布后的推廣，不論是推行測試版本還是直接發布推廣，能夠形成真正從零到運營的無縫銜接就行。
采訪：
采訪對象介紹
福州大學2015級數學專業信息計算科學方向學生，目前主修C++與計算機網絡，過去未曾使用過華為軟件開發雲或類似產品。
除了現有的功能，是否有其他的需求
以前是不知道還有這種平台的，聽完介紹感覺很實用，以后和同學合作做一些作業會嘗試使用一下。現在用起來感覺挺好的，因為我也只算個編程新手，說不出太專業的，就我自己感覺這個平台已經十分全面了。APP端的話我覺得可以更強大點，直接在APP上查看上傳上去的文件之類的。
采訪對象使用華為軟件開發雲：
用戶使用這個產品的過程,
1、因為用戶未接觸過此類產品，所以一開始是不太清楚我要讓他體驗什么，所以我花了相當一段時間進行解釋。好在用戶也是編程學習人員，理解的並不困難。接下來進入正式的使用，當然還是配合着我對每個頁面、功能進行講解。
2、首先是嘗試了一下創建倉庫以及秘鑰的對接，並且在指導下將倉庫同步到本地，再進行修改文件，同步至雲倉庫。這個過程沒有什么困難，對經驗不多的用戶來說，因為市面上雲產品不缺乏，可以理解代碼存儲至雲端的概念。
3、接下來嘗試了手機APP上的任務添加，並且在WEB端操作了一下任務修改，改為完成和關閉兩個狀態分別觀察了一下圖表的變化，對用戶而言可視化圖表的體驗很不錯。
4、最后進行了代碼檢查，但因為碰到我上述也未解決的問題，所以沒能成功。但用戶可以理解檢查大概的機制是如何的。
用戶的問題解決了么
已解決。對於這樣一位只有簡單的代碼管理需求的用戶，可視化的代碼上傳，修改等操作已經幾乎完全解決了他的需求。
軟件有什么優缺點？
優點：界面很簡潔直觀，有各種數據可以參考。
缺點：明顯有時候反應比較慢，直傳會卡頓一段時間。
用戶體驗方面有問題么？
在文檔的幫助上沒有問題
用戶對產品有什么改進意見？
建議直接在APP上查看上傳的文件
結論：
正如我上文所說的，如果未來工作中我可以決定團隊使用哪個平台，我會選擇華為軟件開發雲。綜合用戶的反饋，評價也較為不錯。
所以我給出的結論是：非常推薦！
第二部分 分析
此項目完成時間估計（團隊人數6人左右，計算機大學畢業生，並有專業UI 支持）
假設：
團隊的六人對於項目開發所需的技術都基本熟悉
預計：
需求分析階段：90；對於代碼管理，已經有前身十分成功的Github，在此需求上進行改進的需求收集花費的時間較少。但由於平台不僅希望整合代碼管理，還有包括代碼檢查、構建、部署等模塊，所以每個模塊進行需求分析預計使用90小時，進行現有資源的用戶意見收集、分析結論等等。
編碼階段：720；因為我假設團隊的6人對於相關技術都熟悉，預計中間需要學習所用的時間在平均每人十小時以下，大約每人的平均編碼時間在110小時左右。這里因為所做的開發項目，對於每個熟練編程的成員來說它的功能應當是比較明晰了解的，因為在大學期間編碼必然要接觸到代碼管理、復審、測試、構建等等，而部署則是一個相對較為簡單的部分，因此顯然不能簡單的將實際時間Y=X+-X/N中的N視為0，而視為1較為合適，所以實際時間Y=0~1440小時。
軟件目前優劣分析
因為這個領域的老資格是Github，所以不妨將該項目與其相比。
軟開雲優勢：
1、擁有比Github更加完善的可視化分析界面，將數據直觀呈現給開發者。
2、界面整體的交互性比Github優秀，可以直接可視化進行文件操作，UI更加精美
3、項目流水一體化，一個項目所需要進行的每個階段幾乎全部涵蓋，做到了一個平台就夠用
4、代碼廣場的構想令人贊不絕口，軟件開發將越來越容易
5、（對於中國程序員而言）中文的交互性明顯更加舒心
軟開雲劣勢：
1、擁有完整的整體開發體系在某些情況下或許也會是軟開雲的劣勢，Github是一個精簡的代碼管理平台，做到純粹的代碼管理。一個團隊或許僅僅需要這點，而不需要在平台上測試、使用華為的服務器，對於他們來說多余的功能也許會造成麻煩，而選擇更為輕便的Github。
2、雖然添加了更強大的可視化操作，但響應速度有所下降，不如Github迅速。
3、沒有桌面版的軟件，許多核心功能還是通過命令行操作。APP也不像Github的APP那樣功能強大，可以進行Code Review等操作。
團隊在軟件工程方面可以提高的一個重要部分。
團隊應該重視測試項目，高效使用軟開雲所具有的這樣的測試模塊，提高測試水准與效率。
功能邏輯框圖（框內下標數字左為重要度，右為完成度）
維度評分（單項滿分10分）
用戶體驗方面：7.5
UI界面美觀度：8
核心功能：9
第三部分 建議和規划
如果你是項目經理，如何提高從而在競爭中勝出？
碰巧我正好是軟件工程實踐團隊中一支隊伍的PM，對於這個問題我覺得可以從我帶隊的這半個學期來談。
首先軟工給我帶來的最大一個感觸是，一個產品要有競爭力，首先應該有吸引人的創意。我們團隊的“好記”項目在我看來每一個階段其實都做的較為出色，但並不能得到同學們包括老師比較好的認可，這就是源於我們的軟件不具備創意，日程管理是一個很普遍的概念，已經被無數的團隊開發過，所以當你需要做一個被“玩爛”的東西時，勢必要再創新，拿出特色。好在軟開雲並不算是一個無創意的產品，雖然它的各個分模塊在市面上可能已經能找到成功的典例，但將這些概念結合，就成了一個新的東西，然而我覺得還不夠。這個新東西目前來看就是一個比較完善的開發流水線，雖然完善，但特色不明顯。軟開雲有代碼管理、團隊合作，Github也有，並且目前Github上開源的優秀代碼倉庫肯定遠超軟開雲；軟開雲有直接可部署的華為服務器，我用阿里雲騰訊雲之類更早起家的會不會更讓我放心呢？有代碼測試，但實際上測試仍要通過其他工具完成，這個部分雖然有實用之處，但不足以成為賣點。所以我覺得特色的牌應該要打出來，然后圍繞着這個特色再去告訴用戶：不僅如此，你在使用我們這個特色產品的同是還可以方便的用到代碼管理、檢查等等工具。所以我的想法如下：
1、我所認為應該着重打的特色牌是“代碼廣場”，也就是應該將這個目前並未有真正成功先例的產品做着重推廣（即使是Github在類似功能上也沒有做的很好，搜索的代碼就像是零散在地上的各種小玩意，夾雜着一些值錢的東西，但並不容易發現）。
2、顯然現在的軟件開發都在往“越變越容易”的方向走，各種功能在網上都能找到多多少少的開源模塊包，所以代碼廣場是一個越來越重要的需求，越來越多的程序員會去使用，至於管理、檢查、測試，難以去撼動早已在這些領域做得很優秀的平台，習慣使用Github的團隊至少一時半會不會開始使用華為，對於一個大公司來說更是如此。
3、UI還需要改進，不僅是界面要更好看美觀，還需要有突出的特色，目前產品官網的界面我個人在第一次點進登錄后主頁的時候就感覺像貼滿小廣告的牆，產品是有一大堆，但並沒有讓我對哪個產生興趣，至少不能第一遍瀏覽還以為這個平台只是賣服務器的。
目前市場上有什么樣的產品了？
代碼管理：Github
雲服務器：阿里雲、騰訊雲
你要設計什么樣的功能？
功能上其實我比較抗拒再去添加新的大模塊功能，因為我的理念一直是“簡單化”，太多的功能入口可能會讓用戶找不到一些我們真正的賣點，也就是殺手級功能，而目前這個平台的功能已經較為完整。所以在功能上我只提兩個改進想法：
1、在現有的測試模塊上進一步添加可直接進行代碼測試的功能，而不是任務表分配的形式。
2、看板界面增添更多類數據分析樣式，初始顯示燃盡圖等較為常用的默認視圖，可由用戶點擊按鈕選擇其他更多的分析模式查看。
為何要做這個功能，而不是其他功能？
1、任務分配的測試形式較為雞肋，結合實際可用的測試功能將不止成倍的提升這個模塊對用戶的吸引力
2、目前看板一股腦的把所有數據圖都顯示出來，確實可行，但我覺得可以加入對於更多數據進行分析的圖，比如每個團隊成員的代碼量、上傳日期等等的數據圖，當數據圖較多時，就可加入選擇功能進行切換。
為什么用戶會用你的產品/功能？
顯然我的功能對一個團隊來說是100%實用，直接分配測試任務，在平台上就可以測試，基本不用第三方工具，極大簡便了測試過程，不論對於個人還是團隊PM都是夢寐以求的功能。
你的創新在哪里？
N（Need）：目前的軟件測試使用工具繁多，每種開發平台可用的測試方式又不同，測試過程較為復雜，需要一個更加的的測試平台。
A（Approach）：在測試模塊直接集成可用的測試功能，可以增量的形式逐步添加更多測試。
B（Benefit）：簡化測試流程，減少測試渠道，節省用戶時間，並且測試前后可以更快的進入測試、更快開始測試完成后的工作。
C（Competitors）：競爭主要就是各種專業化的測試工具，我們是否能做到比肩這些在單項上足夠讓程序員長期使用的工具。
D（Delivery）：因為我提出的功能是集成在軟件開發雲這個大平台中，所以實際上主要的推廣途徑應該是對平台推廣，但如果真的能實現這個具有挑戰性的任務，完全可以作為同“代碼廣場”一般的賣點進行推廣，並且與代碼廣場結合，可以馬上將代碼廣場中的采用的代碼進行功能測試，得出是否使用的結論，效益也是不止成倍增長。
如果你來領導這個團隊，會有什么不一樣？
作為一個經驗尚淺，相對於原開發團隊PM來說大概僅僅相當於零基礎的新人來說，回答這個問題真是十分慚愧。我覺得如果我來領導這個團隊，不一樣之處將有：
1、產品將以其中1~2個模塊作為主推核心功能進行重點開發和推廣。
2、軟件的功能及UI將進一步精簡，甚至可以刪除一些現階段較為雞肋的小功能項。
3、盡量減少功能入口，突出產品的側重點
如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
因為美工與開發的工作可以並行，不需要在短時間內大趕進度，所以一名美工足夠，開發人員進度更快可以在需要用到美工作品的地方先用空白代替，等美工完成后在進行調用。而測試則是類似標量流水線的並行方式，當開發完成第一個模塊后，開發人員就可以進行下一項開發，測試人員同時可以對第一個模塊測試，測試的功能應該是小於開發的，並且開發人員還要解決測試出的問題，所以測試人員也只需要一名，剩下三名人員進行開發。
綜上所述，人員分配：
開發：3人；
測試：1人；
美工：1人。
描述你的團隊在16 周期間每周都要做什么，才能在第16周如期發布軟件，大小里程碑績點設定。
第一周：需求分析，撰寫相關文檔，創建項目，分配工作
第二周：搭建產品及后端框架，美工並行
第三周~第八周：編碼完成具有核心功能的Demo版本
第九周：Demo版本測試、Debug，收集用戶測試意見，進行進一步編碼的分析
第十周~第十五周：根據分析結果進行計划的調整，完成正式版
第十六周：正式版測試，Debug，發布
項目發布后，項目該怎么部署
應用服務器配置：8核16G4
后端服務器配置：8核16G8
關系型數據庫：SQL Server/Oracle/MySQL 3，讀寫分離2，備份*1
緩存數據庫：Redis *2
網站安全性：DDOS，WEB應用防火牆，WEB漏洞掃描，數據庫安全
關注存儲代碼的安全與保密性。