設想和目標

我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

• 解決大學生利用碎片化時間來學習英語單詞，備考相應英語等級考試。
• 微信程序的b名字叫“背背佳”，裏面MVP功能就是單詞學習，輔助功能也是圍繞單詞學習，所以是定義的很清楚。
• 我們的典型用戶就是大學生，典型場景就是大學生在自己的課余時間等碎片化時間，可以隨時拿起手機進行單詞學習。

和上一個階段相比，團隊軟件工程的質量提高了麽？ 在什麽地方有提高？具體提高了多少？如何衡量的？

• 相對個人階段，結對編程階段，軟件工程的質量提高了很多。比如說：
  1.最突出的就是我們有一個項目可以上線，有一定的用戶量。雖然只用MVP功能，還不夠完善。
  2.有體系化的編程規範文檔。
  3.有最後的BUG分析，功能測試，來完善我們的項目。、
• 提高了一大截，以上的3點都是衡量標準。

我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)

• 相比我們alpha初期定下的目標，我們是有很多功能沒有實現的，原計劃有4部分，如下圖。因為功能太多，能力和時間有限，最後只實現了主要功能，和部分輔助功能。
  

• 原計劃是達到30個用戶量。

用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?

找了幾個試用者進行訪問。對主要g功能的接受度和我們預想一致，但是我們還希望這個單詞微信小程序有幾處不同於其他單詞程序的亮點，目前還沒有實現（輔助功能），用戶也很期待。我們離目標更近了。

計劃

是否有充足的時間來做計劃?

團隊在計劃階段是如何解決同事們對於計劃的不同意見的?

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?

有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

是否每一項任務都有清楚定義和衡量的交付件?

是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?

在計劃中有沒有留下緩沖區，緩沖區有作用麽?

將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）

資源

我們有足夠的資源來完成各項任務麽?

各項任務所需的時間和其他資源是如何估計的，精度如何?

測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?

由於Alpha階段沖刺時間較短，我們花大量的時間在開發上，所以測試時間安排的不夠。對於美工設計，我們並沒有低估它的難度，也知道我們做的遠遠不夠好。

你有沒有感到你做的事情可以讓別人來做（更有效率）?

沒有。我們團隊的每個人都是不可缺少的一份子。

變更管理

每個相關的員工都及時知道了變更的消息?

是的。因為我們團隊成員住的比較近，而且我們在社交網絡上的聯系也很緊密，一有變更信息，我們或是面對面通知，或是及時討論組通知。

我們采用了什麽辦法決定“推遲”和“必須實現”的功能?

我們預期想要實現的功能有好友pk，但是技術難度較高，且聽從老師建議，決定推遲實現。而我們小程序的核心就是單詞學習，所以詞庫的引入單詞的學習是必須實現的。

項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?

• 點擊單詞的時候具備語音播放功能
• 復習統計功能要完善
• 增加單詞本中的向上按鈕
• 添加設置功能，比如可以清除緩存

對於可能的變更是否能制定應急計劃?

有。還沒搭建服務器的時候，將詞庫放在前端，服務器搭建完後，就將詞庫轉移到後端。

員工是否能夠有效地處理意料之外的工作請求？

能。當我們隊員出現沒辦法解決的問題的時候，我們都會積極協作幫忙，盡量做到在最短的時間內解決問題。

設計/實現

設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？

設計工作在敏捷開發前的就做了原型設計。後期實際開發時，前端根據需求對負責的頁面進行修改。因為開發人員是最後實現軟件界面的，所以是比較合適的人。後端的結構設計也是由實際後端開發者設計的。

設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

最初設計時包括單詞pk的模塊，後來實際開發時才估計出時間不夠，考慮要不要先放棄這個功能。後來團隊開會討論，最後隊員一致贊成先做好MVP功能，砍掉pk功能。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？

小程序java後端運用了單元測試（jnuit）來幫助設計與實現。能確保能正確獲取前端數據，和提取存儲的單詞。

什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?

單詞的讀取和調用接口翻譯顯示功能的Bug最多。因為這塊涉及的數據傳遞較多，小程序的接口調用比較嚴格，數據傳遞時後期發現開發時小程序在開發工具上調試成功，但是實際真機調試時數據傳遞跟微信開發工具顯示的結果卻不一致。設計/開發前沒考慮到，真機調試會和微信開發工具結果不一致，手機調試結果也會跟上傳體驗的版本不一致，只能邊做邊發現問題。

代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

代碼復審主要是檢查各行代碼，添加註釋，刪除無關代碼，比如後期未用到的方法等，增加可讀性。代碼規範我們遵循了四格縮進，“{ }”字符的放置位置等都執行了代碼規範。

測試/發布

團隊是否有一個測試計劃？

有，但是沒有很規範。

• 功能測試：邀請用戶體驗小程序的功能並反饋
• 易用性測試：用戶界面的直觀易用性
• 兼容性測試：在幾種Android和ios版本上進行兼容性測試
• 安裝測試：邀請微信用戶通過搜索或掃碼形式安裝體驗小程序

是否進行了正式的驗收測試？

是，有邀請同學等作為用戶和測試隊員對軟件整體的功能在發布平臺上進行測試。

團隊是否有測試工具來幫助測試？

有，可以利用微信開發者工具測試，後端利用junit單元測試。但是壓力測試工具在linux平臺安裝後無法正常使用。

團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？

我們通過邀請室友、朋友或者假扮用戶來測試並跟蹤軟件的效能，因為是微信小程序，從授權開始，到每個功能都體驗一遍，並詢問反饋或得出結論，再根據這些來繼續改進完善。這些測試工作是有用的，在做之前覺得可能不會有什麽明顯的效果，但是真的去測試後發現要改進的還是很多，有一些還是之前沒有發現的。而我們找到的改進有：界面不夠完善/功能有所欠缺/用戶操作有時有誤差

在發布的過程中發現了哪些意外問題？

我們團隊在發布小程序時，因為是第一次操作，所以最開始會一直卡在證書方面，後面查閱了很多也問了其他已發布程序的團隊。後來發布好了後，發現不能通過關鍵字查找小程序，但是可以通過完整的名字查找小程序。

總結

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

CMM/CMMI一共分為五個等級，(1)初始級(initial)；(2)可重復級(Repeatable)；(3)已定義級(Defined)；(4)已管理級(Managed)；(5)優化級(Optimizing)。
而我認為我們團隊目前狀態屬於第4和第5級之間。

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

我認為團隊目前處於規範的狀態；雖然已經有了一個有了主要功能的英語單詞學習小程序出來，但是還需要調和整理一下之前所做過的，把之前所做過的規範好，以方便新功能的開發。

你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?

對於團隊來說，大家的凝聚力要比前一個裏程碑時強很多，自覺性、自主性、學習能力都有所提高。
對於項目來說，改進很大，因為上一個裏程碑時我們只有形沒有狀，經過了ALPHA階段後，我們把狀的架構支撐起來了，就有了一個較完整的結構體。這應該是最大的改進了。

你覺得目前最需要改進的一個方面是什麽?

目前最需要改進的方面應該是對於小程序的附加功能。現在我們的小程序可以背單詞，但是其他附加功能還不夠完善，我們是希望做出一個滿足大多數用戶需求的微信小程序。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

①主張簡單：我們做微信小程序而不是APP的目的之一就是為了用戶群體能簡單操作，所以我們在架構模型的時候，就很簡單的只分為三大模塊，其中只有一個模塊為主要功能，盡可能的保持模型的簡單。
②擁抱變化：主要功能不變，可是附加功能可以有所改變，所以在“我的”界面中我們保留了幾處空白為了之後進行開發，用戶需求是一直持續並會改變的。
③無論團隊內外，面對面交流始終是最有效的溝通方式：教師布置的任務中就有一個每日站立會議，這個會議雖然用時不長，大家都把每日任務簡要陳述，但是也就這十分鐘左右的會議讓大家都知道了今天的主要進展會到哪一步讓大家都清楚整個項目的進程。

項目管理之事後諸葛亮會議照片

成員貢獻

軟工網絡15團隊作業7——Alpha沖刺之事後諸葛亮