目錄
調研&評測
評測
上手體驗
一打開網頁的上手體驗就是，UI挺不錯的，我很喜歡這個風格。但是使用起來好像有點復雜，功能非常多，不僅有項目管理，還有倉庫，測試，部署，發布等等一系列的功能。我同時體驗了web和Android兩個端。
功能評測
前一天在web端注冊了賬號，但是在Android端登錄就遇到問題了。注冊時雖然注冊了用戶名+手機號，但是我習慣用手機號登錄，結果發現，使用手機號+密碼無法登錄成功，只能使用用戶名+密碼登錄。
接下來登錄成功后，看到默認頭像想要修改，卻發現不能點擊-.-。
感覺Android端就是一個todollist。嘗試建了幾個項目。並且建立了幾個task。
上面的第二張，你會發現，三個項目的內容混雜在一起了，缺少分類，會導致實際使用起來有點亂。即時有搜索，搜索功能也不完善。
Scrum項目中分為了Feature/Story/Task/Bug，但是新建卻沒有Task這個選項。
Android端的使用就到這里了。
接下來是web端。
web端
界面挺好看的，我很喜歡。
還是和安卓端一樣的問題，
兩個項目的backlog混在在一起了，表示很難受。雖然點擊進入項目可以看到完整的任務分配，但是這塊還是需要改進我覺得。
點擊項目進入后，有許多的功能。一開始的看板，就有燃盡圖，story的項目統計，不錯。
一開始沒有懂Feature/Story/Backlog這些的意思，建了一個項目規划
使用起來非常方便，還可以添加文檔等。
還可以使用倉庫，我嘗試創建並且clone/push。
最后是將Android版本拿到web端進行兼容性測試，結果是
兩個都發生了阻塞，並沒有成功測試。沒有明白為什么。
bug
在上面的功能評測已經有提及，最大的bug就是多個項目的backlog會混雜在一起，而不能有個歸類。
還有一個比較難受的是，網頁刷新特別慢，經常出現白屏的狀況，有點難受。
你覺得為什么這個產品組的人沒有發現這些bug?
表示不懂，講道理有些bug產品組不可能發現不了的。。。
假設你們團隊需要開發這套系統，需要注意哪些方面(架構、部署運維、微服務等)。
首先第一個是功能，需要滿足用戶用戶的可能需求和潛在需求，這點華為雲已經做到了，並且做的非常好。其次，考慮到用戶量，在架構，部署運維方面也需要注意，當然，還有UI也非常重要。
采訪
-
介紹采訪對象的背景和需求（他們有沒有用過這個APP或類似的APP，除了現有的功能還有別的需求么）
采訪對象：15級計算機系正在進行軟工實踐同學
背景以及需求：以前有使用過github和teambition，以前在測試項目和服務器時選擇了多個平台，希望可以方便一點。采訪對象使用的是Android端。 -
讓采訪對象使用華為軟件開發雲（請上傳照片證明用戶的確正在使用，遠程采訪的同學請讓別人幫忙照相）
-
描述用戶使用這個產品的過程, 用戶的問題解決了么？軟件在數據量/界面/功能/准確度上各有什么優缺點？用戶體驗方面有問題么？
用戶反饋一般，基本需求可以解決。
數據量：看板加上代碼規范等數據量還是比較大的
界面：比較一般
功能：較為全面
准確度：還行
用戶體驗：加載速度較慢，ui不夠吸引人（Android端） -
用戶對產品有什么改進意見？
提升性能，美化app的ui界面
建議支持markdown -
結論
一般
分析
使用此軟件的大部分功能，估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，並有專業UI 支持）。 分析這個軟件目前的優劣（和類似軟件相比），並推理出團隊在軟件工程方面可以提高的一個重要部分（具體建議）。
估計時間
構建之法中給出的實際時間花費主要取決於兩個因素—對某件事的估計時間X，以及他做過類似開發工作的次數N。
沒有過這麽大項目開發經驗的我來估計項目時間，感覺非常難。（計算機大學畢業生？估計都沒有很大的項目開發經驗？）估計時間：6個月吧。。考慮到里面有非常多的功能，而且我對這些功能的具體實現沒有很好的概念。就只能憑感覺估計了。如果有些功能我知道應該怎么實現，應該會比較好估計。
優勢
- 整合了極多的功能，非常方便用戶在上面完成整個軟件工程的開發。
劣勢
- 也是由於整合極多的功能，導致整個軟件在與同功能的軟件相比，不夠專精，有些功能就做不到和其他軟件專門做一項功能來的突出。
團隊在軟件工程方面可以提高的一個重要部分
- 編碼能力
- 團隊協作能力
- 產品運維
- 測試能力
根據理解和體驗，畫出整個軟件所有功能邏輯框圖，根據重要度標識出各模塊的重要度、完成度、出發點及效果；
針對不同的維度評分，對用戶體驗方面、UI界面美觀度、核心功能，分別打分。
滿分10分。
| 用戶體驗 | UI界面美觀度 | 核心功能 |
|---|---|---|
| 8.0 | 9.0 | 8.5 |
建議和規划
-
如果你是項目經理，如何提高從而在競爭中勝出？
整個產品提供服務功能非常豐富，應該考慮把每個功能做的更好一些，並且再繼續豐富功能。 -
目前市場上有什么樣的產品了？
團隊合作上面有teambition，leangoo，代碼托管有github，碼雲。 -
你要設計什么樣的功能？
增加文檔功能（雖然目前已經可以寫部分文檔，但是可以是軟件開發中的各種文檔，包括需求說明書，接口文檔，功能文檔），並且可以自動生成文檔。
測試部分增加接口測試功能。
提供給用戶可選使用菜單，實現頁面由用戶定制化。 -
為何要做這個功能，而不是其他功能？
文檔功能是對產品進一步完善，而提供可選菜單不會使用戶覺得功能太多太復雜，只選擇自己想要使用的功能，其他功能隱藏，並且可以隨時添加使用功能。 -
為什么用戶會用你的產品/功能？
使用自定義的app，會讓極簡主義的用戶青睞，並且又能隨時拓展。
對於想要在app上進行一體開發的用戶，這個產品也完全能夠提供。 -
你的創新在哪里？
將功能選擇交由用戶來使用，而我們提供一個豐富的服務功能。相比較其他產品，我們提供的功能多並且可選，極大方便用戶。 -
如果你來領導這個團隊，會有什么不一樣？
把主要精力開發於web端和桌面端，實際上iOS/Android在軟件工程開發中並不方便。 -
如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
美工1人，開發4人。測試人員為5人（整個團隊）。 -
描述你的團隊在16 周期間每周都要做什么，才能在第16周如期發布軟件，大小里程碑績點設定。
-
|周數|任務|
|--|---|
|1|需求規格說明書|
|2|原型設計，數據庫設計，架構設計|
|3-13|開發|
|14|測試&用戶反饋|
|15-16|修改bug,根據反饋對app進行修改,最后發布| -
項目發布后，有沒有考慮過項目該怎么部署才能滿足需求。
由於項目提供功能性非常多，並且用戶分布廣泛，相比較教務處系統，數據庫配置應該更強。教務處系統考慮到選課時的壓力，估計不會超過10000+的並發，因此可以考慮分地區分布架構。
應用服務器配置:4核8G * 2
后端服務器配置:8核16G * 3
數據庫服務器: SQL Server/ Oracle/MySqI 數量:3(讀寫分離2、備份1)
緩存數據庫:Redis數量:3(主備)
網站安全性:WAF. DDOS . XSS,同時還需要考慮代碼托管的安全性。
如果不夠了，再考慮增加設備。
名詞解釋
在使用華為雲時，有些Scrum名詞的概念沒有很清晰，下面做個記錄。
-
Theme
Theme則是一組User Story(甚至是Epic Story)，這些User Story擁有共同的特征，為了更容易開發這些相關內容，通常會將這些User Story作為一組進行開發和管理。這組User Story就被稱為Theme -
Epic Story
Epic Story的規模和復雜性，要大於User Story，它首先是一個大User Story。由於它非常大，無法或不容易進行估算，因此一般會分解成為更小的User Story，進行估算和開發。關於Epic和Feature，誰的復雜性更高，誰的規模更大，則還沒有一個統一的說法，有的項目中，會定義Epic Story在Feature之下;而有的項目中則相反。因此在使用這個概念時，應該在項目中有一個明確的定義。無論Epic Story是在Feature之上還是之下，它與Feature同樣是在Release Plan的層級，一般是通過一個或多個迭代才能完成。 -
Feature
Feature是可以為用戶提供價值的東西，它代表一個產品可以做什么，或提供什么服務;是可以滿足用戶的需求，為客戶服務，為用戶帶來真正的價值的成果物的特性。由一組動賓結構的句子表達，如一個超市的交易可以描述為： 掃描條形碼， 顯示單價， 計算總價， 計算稅額。一個Feature是很難進行估算的，它需要被分解成一個個更小的單位，這就是下面的User Story，一個Feature可以分解成多個User Story，每個User Story不能單獨被使用，而是一起構成一個Feature。 -
User Story
必須是清晰的，可以為客戶增加價值，而且更重要的是能夠被估算。因此User Story通常是進行估算的基本單位，通常使用Story Point來進行估算。User Story是在迭代的層級，一個User Story要在一個迭代內完成。 -
Task
項目中可以執行的工作單位，通常就是迭代計划中項目(如Sprint Backlog中的項目)。一個User Story一般會分解為一個或多個Task，通過這些Task來實現。
他們之間的關系可以用下面的兩張圖來表示：
參考鏈接敏捷估算/計划中幾個概念間的關系