軟件產品案例分析

第一部分 調研，評測

功能分析

• 1、華為軟件開發雲首頁
  

首頁展現了該租戶下的所有項目以及工作項進度，右側包括企業成員管理和項目最新動態消息，整個界面來看，比較簡潔、而且所有工作項，包括進度的查看，拖拽改變相應的進度，也方便管理人員對所有任務的掌控和跟蹤；

---

• 2、看板
  點擊單個項目卡片，左側是開發雲所有端到端的功能菜單，右側上方是以敏捷開發的理念內置測3個迭代周期，開發人員和項目經理可以根據自己的需求更改相應的迭代時間（一般為2-4周，系統會自動內置三個迭代），右側下方是幾個多維度報表，包括燃盡圖、趨勢圖、工作項完成率、項目需求統計、遺留缺陷統計和項目成員管理；

燃盡圖，以迭代周期為橫軸，工作量的數目為縱軸，繪制整個項目的進展趨勢；

---

• 3、工作項

新建工作項，填寫具體的字段，工作項類型可選需求或Bug ,同時系統內置了需求和缺陷模板。

可以對新建的工作任務進行細致描述，並確定其在各項工作中的優先級

卡片顯示方式下，可以手動拖拽到不同進度；

---

• 4、代碼倉庫
  

同樣可以通過SSH（需設置）或者HTTP進行訪問

進入倉庫后，與github類似，可以查看里面的源代碼文件，以及團隊中新提交的請求。

---

• 5、檢查
  

這部分主要功能就是檢驗代碼，是否合乎團隊要求，新建檢查任務時，可以根據不同需求，選擇不同的檢查規則

具體檢查界面（風險指數、有效代碼行等）

---

• 6、流水線
  

我記得前段時間的團隊開發，有一項作業就用到了流水線工具，將其整合到軟件開發雲中，的確想的很周到。

---

項目管理服務的優點和缺點：

• 優點：
  1.從項目規划到工作項的創建和分配，包括拖拽式的進度控制，全流程清晰明了，易於管理人員操作和掌控；提供個人級、項目級看板，直觀呈現進展與風險；樹表、任務牆視圖滿足不同用戶的使用習慣。

2.整個流程基於敏捷開發的理念，采用小步快跑的迭代形式，取代傳統的瀑布模式開發模式，快速應對多變的需求。

3.項目文檔可以系統開發、輕松共享，狗狗做任務討論結果自動歸檔，有效記錄工作事項。

• 缺點：
  新建工作項，填寫具體的字段，工作項類型可選需求或Bug ,系統內置了需求和缺陷模板，暫時不支持自定義導入模板，同時該文檔也無法被導出，只能在雲上查看。

---

敏捷開發的基本原則：

1.我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意

2.即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

3.經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。

4.在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。

5.工作的軟件是首要進度度量標准。

6.敏捷過程提可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。

7.每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。

---

采訪（並未采訪真人，摘取網絡測評資料）

• 華為軟件開發雲（以下稱為Devcloud）平台的看板、迭代、多項目需求、缺陷管理等功能支持敏捷的開發模式，加強團隊成員之間的協作和溝通，使項目成員更專注於業務本身，而非文檔的管理；另外Devcloud貫穿於軟件開發的全生命周期，基於Devops的開發理念，自動化的集成構建，運行和維護、使得團隊可以快速交付一個可獨立運行的項目，快速應對市場和需求的變化，讓整個開發流程更加的簡單高效。

• 目前來看，Devcloud的項目管理服務仍然有繼續改進和升級的地方，但是敏捷開發、devops等理念是整個軟件行業的大趨勢，Devcloud也在踐行這樣的理念，讓這些理念真正落地。

• 至於未來軟件開發模式的發展方向，很難說敏捷開發是未來的主流模式，但是未來的需求、市場是多變的，做好功能的同時，做好用戶體驗，快速推陳出新，快速試錯和迭代，才能保證產品的良性發展。

• 通過對華為軟件開發雲代碼檢查服務的評測，總體上來說，開發者的代碼質量、管理者的管理效率都有顯著的提升；

• 使用截圖：

打開具體的任務詳情界面，可以看到一系列的多維度報表，報表從風險指數、未解決問題、圈復雜度問題、代碼重復率、注釋占行比等等一系列維度進行統計，最后給出代碼總體的質量星級；該報表可以作為項目經理評判組內成員代碼質量和績效的依據。

---

采訪建議：

• 1.自動化的修改代碼：用戶檢查完畢后，針對已出現的錯誤增加一鍵修改功能，只要用戶認可開發雲提出的修改意見，用戶就可以點擊一鍵修改，省卻了到代碼倉庫手動更改的操作；

• 2.可擴展的檢查規則：目前華為軟件開發雲只提供了華為的經驗集合，除此之外，每個公司都有自己的規則和檢查集，希望后續代碼檢查服務可以提供開發接口，各公司能夠自行開發適合本公司的檢查規則；

• 3.提供IDE插件：希望代碼檢查服務能夠提供IDE插件，這樣用戶在編寫代碼的時候，就可以參考提供的修改建議，讓錯誤和不規范代碼被扼殺在搖籃中；

• 4.自動檢查語言類型：目前需要用戶手動選擇需要檢查的語言類型，然后搜索對應的語言類型的文件進行檢查，希望未來用戶對語言類型不做判斷，服務自動判斷項目都包含哪些語言類型，然后針對不同語言對應的修改建議；

• 5.自我學習能力：目前代碼檢查對邏輯層面的分析不足，希望未來的代碼檢查功能可以自主學習用戶的代碼邏輯，通過學習和分析邏輯，給出更完善更高效的反饋和建議；這一點暫時比較難以實現，但願可以實現此功能；

綜合來說，還是比較推薦使用本款軟件的。

---

第二部分 分析

• 按照所給環境來說，我認為完成同樣功能軟件，並發布，有效工作時間大概在2~3個月左右吧。

• 整體來說，本款軟件可能推廣度還不如github，但是，對於國人來說，的確界面更加友善，是一個絕對的優勢。

---

第三部分 建議和規划

• 如果我是項目經理，我認為必須實現功能全面且細化，比如上文提到的華為雲將流水線功能囊括之中，無需再去另外的地方找工具。

• 為我們熟知的同類產品是github，同時也是我們在做團隊作業不可或缺的工具之一，當然之所以我們熟知，源於學校老師的推薦。

• 如果我能給這款軟件添加功能，我比較希望添加自動修改代碼功能，畢竟，這也是我在開發過程中，比較厭煩的問題之一。

• 我們的產品創新，一方面對於現有功能盡可能細化，並希望添加流水性、UML系統設計所需的工具。

• 5個人，4個月時間，那我覺得必然安排絕大多數參加后端開發，可能會有3個人；另外就是前端一到兩個人，美工一到兩個人，團隊中總有人需要作為機動。至於軟件測試，內部成員都會參與測試，並且交給周圍朋友一起參與測試環節。

• 16周之前一定要完成功能的實現，並排除所有已知BUG；在16周期間做好宣傳，並發布到APP下載平台，完成發布工作。另外，在開發階段，我們已經准備好了配套設備，比如服務器（用來后端和前端用戶交互）、核心算法（自己開發的雖然現在無法使用，也有網上提供的接口作為備選）