軟工網絡15團隊做業7——Alpha衝刺之過後諸葛亮

設想和目標

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

• 解決大學生利用碎片化時間來學習英語單詞，備考相應英語等級考試。
• 微信程序的b名字叫「背背佳」，裏面MVP功能就是單詞學習，輔助功能也是圍繞單詞學習，因此是定義的很清楚。
• 咱們的典型用戶就是大學生，典型場景就是大學生在本身的課餘時間等碎片化時間，能夠隨時拿起手機進行單詞學習。

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

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

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

• 相比咱們alpha初期定下的目標，咱們是有不少功能沒有實現的，原計劃有4部分，以下圖。由於功能太多，能力和時間有限，最後只實現了主要功能，和部分輔助功能。
  

• 原計劃是達到30個用戶量。目前截至5月15日有14個用戶。不過從統計圖看，5月16日用戶量有所增長。
  
  

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

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

計劃

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

• 有充足的時間來作計劃，由於剛開學的前幾周，老師就已經把她本學期的教學計劃告訴咱們了，並且咱們住的比較近，因此就很方便討論計劃。

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

• 若是有小組成員跟團隊大部分紅員的意見不一樣的話，咱們就會採起先讓該成員分析一下她的這個見解的優勢在哪裏，而後咱們說一下咱們見解的優勢所在，最後你們一塊兒討論，作到取長補短。

你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

• 最後咱們的計劃大部分是作完了，還剩下好友PK以及遺忘曲線尚未實現，這是由於在初期的時候，咱們錯誤的估計了時間，致使最後任務很是多，老師也有在博客下面評論建議咱們先作主要功能，因此咱們最後討論決定，先實現學習模塊與打卡的功能，剩下的在Beta階段實現。

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

• 有，就是單詞本文件，當時咱們在前端和端都有放置單詞文件，最後實現的時候發現前端根本沒有必要放，由於直接從後端調用便可。

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

• 不是，由於咱們有時候遇到什麼錯誤可能會當即修改，這樣就可能致使跟剛開始商量的不同，因此不是每一項都有清楚定義和衡量的交付件。

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

• 項目出現最大的之外就是數據庫的問題，衝刺開始的幾天，負責後端的咱們就開始糾結與數據庫的問題，沒有成功，最後使用的是文件。
• 沒有預料到的風險就是小程序的發佈，體驗版發佈後，電腦上運行是正常的，可是在手機上頁面卻跳轉不了。至於爲何沒有估計到，是由於這個風險就是個意外，咱們都沒有想過竟然還有這種結果。

在計劃中有沒有留下緩衝區，緩衝區有做用麼?

• 有啊，由於衝刺階段咱們有一個體測，緩衝區的做用就是給予隊員調整本身和決定接下來如何肯定學習計劃的做用。

未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

• 有修改，團隊討論後決定把PK這個功能去掉，新增一個收藏單詞的功能。接下來的衝刺，咱們應該仍是會留有必定的緩衝區的，由於若是沒有緩衝區真的太累了，這學期課程比較多，每一個人還須要爲本身接下來的實習或者其餘事情作準備。至於要不要加班，這個是彈性的，效率高的話就不用，萬一哪天太拖沓了，那就知道加班了。

資源

咱們有足夠的資源來完成各項任務麼?

• 從技術上來講，咱們所學的java，數據庫的語言的基礎能夠方便咱們去看懂微信小程序專門的開發語言WXML等
• 從工具上來講，咱們使用了微信開發工具專門的平臺，同時用微信程序開發教程資源，方便咱們學習和研究。
• 從人員上來講，咱們有6我的，分工明確，各有所長，各司其職，配合度高。

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

• 各項任務所需的時間是從我的的能力，以及分配模塊的難度來估計的。
• 從此次開發過程當中，仍是因爲能力時間有限，沒有能和設想的同樣實現的很完美。由於須要學習一個新的語言，再去開發。因此精度不是很高。但後面通過調整，助攻主要功能，效率一下就提上去了。

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

因爲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的目的之一就是爲了用戶羣體能簡單操做，因此咱們在架構模型的時候，就很簡單的只分爲三大模塊，其中只有一個模塊爲主要功能，儘量的保持模型的簡單。
②擁抱變化：主要功能不變，但是附加功能能夠有所改變，因此在「個人」界面中咱們保留了幾處空白爲了以後進行開發，用戶需求是一直持續並會改變的。
③不管團隊內外，面對面交流始終是最有效的溝通方式：教師佈置的任務中就有一個每日站立會議，這個會議雖然用時不長，你們都把每日任務簡要陳述，可是也就這十分鐘左右的會議讓你們都知道了今天的主要進展會到哪一步讓你們都清楚整個項目的進程。

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

成員貢獻

名字	角色	團隊貢獻排序	可驗證的貢獻
曾藝佳	PM	1	主要框架支撐者
徐璐琳	PL	2	分擔PM開發指定與跟蹤
祁澤文	PL	3	分擔PM開發指定與跟蹤
王 興	PL	4	分擔PM開發指定與跟蹤
吳 玲	MDE	5	項目產品模塊設計者
郭琪容	MDE	6	項目產品模塊設計者