經過基本的使用,發現了一些優勢以及不足的地方。android
點擊訪問web
當切換頁面時要加載好久,大概有 1-2 秒,和 Android 端同樣。網絡和設備性能都沒有問題,因此必定是網頁的性能問題。只切換一個頁面就要加載那麼長時間,會影響用戶體驗,使用中出現一些中斷,雖然時間很短,可是思路會中斷,影響效率。數據庫
Android 端在發送語音以及圖片的界面,長按應該是進入選擇刪除的界面。可是當長按圖片時,不只會顯示氣泡右上角的刪除按鈕,還會打開預覽圖片的界面,如圖:
這樣應該是判斷響應方式的問題。雖然是很小的錯誤可是應該是開發的時候沒有考慮到,最好糾正一下。編程
我認爲出現這些 bug 的緣由仍是測試的不夠。開發的時候有不少內容,一會兒可能考慮不到,在性能以及一些操控的邏輯方面可能有欠缺。我認爲應當在開發的時候多讓開發人員之外的人來測試,來避開開發人員的思惟定式,發現一些問題。另外性能方面是 Android 端和 Web 端共同存在的問題,我以爲問題應該在服務器,多是服務器帶寬的問題,也多是性能的問題。服務器
採訪對象背景和需求:網絡
福州大學大三學生,正在完成軟工實踐的團隊做業,對團隊協做工具備必定的需求,在使用 GitHub。
讓採訪對象使用華爲軟件開發雲:
採訪具體過程:架構
Q:描述用戶使用這個產品的過程, 用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?你在使用的時候有什麼體驗呢?
A:上手以爲這個軟件還勉強算美觀,要花點時間才能搞明白怎麼使用。
Q:那這個軟件解決了你開發中的問題麼?
A:使用起來並不方便,仍是會使用 Github。
Q:你以爲這個軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗如何?
A:功能較爲全面,能夠說是保姆級輔助開發,可是雜七雜八的功能過多,反而會以爲累贅。用戶體驗的話還好,乍一看找不出什麼大毛病。
Q:你有什麼改進的意見嗎?
A:我認爲能夠把一些核心功能作的完善一些,少修飾那些不怎麼用到的功能。運維
通過這麼多工做,你必定有充分的理由給這個軟件下一個評價,請選擇一個結論:
通常。勉強能用,可是絕對不會有很大的幫助,甚至有時候會成爲負擔。微服務
估計這個項目作到這個程度大約須要多少時間: 若是隻有6人,而且是大學畢業生的話,全力作這個項目的話可能須要5-6 個月。
分析這個軟件目前的優劣以及提升的部分:工具
若是你是項目經理,如何提升從而在競爭中勝出?
這個軟件有不少能夠提升的部分。首先在交互的體驗上能夠進行不少優化,包括加載速度,界面的美觀性,還有部分控件的一些小問題,均可以進行更正來讓開發者得到最佳的體驗。另外最重要的仍是核心的功能,要多向實際的開發者徵集意見,多從實際使用中得到一些反饋,抓住使用者的痛點。目前的項目略有雞肋的感受,並非很須要,很難讓團隊長久而且穩定的使用。其次要改進部分交互邏輯,有一些功能略顯繁雜點進去有些不知因此,並不能起到團隊協做的做用。
你要設計什麼樣的功能?爲什麼要作這個功能,而不是其餘功能?
在團隊項目中溝通和交流很重要,我但願在在項目中加入更多可視化的交流,好比提供功能樹的可視化功能。另外在使用 Github 的時候同步代碼很麻煩,我但願作出 Android Studio 和 Visual Studio 上的插件,隨時更新同步代碼,而且加入方便直觀的版本控制功能,讓開發者能夠在 IDE 中實現大部分操做,不須要分心去其餘頁面來實現一些操做。我認爲這是我最須要的功能,能極大地提升開發效率。
若是你來領導這個團隊,會有什麼不同?
我領導團隊的話可能不會容忍那些小問題吧,另外美觀的問題要解決一下。
另外有些功能不必能夠砍掉,有些過於累贅了。
描述你的團隊在16 週期間每週都要作什麼,才能在第16周如期發佈軟件,大小里程碑績點設定。
週數 | 任務 | 里程碑 |
---|---|---|
1-2 | 用戶調研及需求分析等肯定功能及分工 | |
3-11 | 進行 α 階段編程,完成最第一版本 | α 階段 |
12-15 | 在 α 階段的基礎上進行修正和補完,進行 β 階段編程 | β 階段 |
16 | 確認項目沒有問題,進行最後的修正,測試 | 完成最終版 |