軟體産品案例分析

第一部分 調研，評測

功能分析

• 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下載下傳平台，完成釋出工作。另外，在開發階段，我們已經準備好了配套裝置，比如伺服器（用來後端和前端使用者互動）、核心算法（自己開發的雖然現在無法使用，也有網上提供的接口作為備選）