| 所屬課程 | 軟體工程1916|W（福州大學） |
|---|---|
| 作業要求 | Alpha 事後諸葛亮（團隊） |
| 團隊名稱 | 待就業六人組 |
一、團隊資訊
- 團隊名稱：待就業六人組
- 團隊描述：同舟共濟揚帆起,乘風破浪萬裡航
- 隊員資訊：
| 隊員學号 | 隊員昵稱 | 個人部落格位址 | 備注 |
|---|---|---|---|
| 221600306 | XRK | http://www.cnblogs.com/XR-K/ | |
| 221600307 | Yellye | http://www.cnblogs.com/CloudLong/ | |
| 221600315 | 黎煥明 | http://www.cnblogs.com/lihuanming/ | |
| 221600319 | Litm | http://www.cnblogs.com/litm/ | |
| 221600327 | oirving | http://www.cnblogs.com/oirving/ | |
| 221600329 | supermingjun | http://www.cnblogs.com/supermingjun/ | 組長 |
二、設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
軟體想要解決的問題：想要改變目前福州大學校園招聘資訊隻能通過網站單項釋出，傳播不廣，缺乏互動的現狀，提供一個對等的資訊釋出平台，企業可以釋出、稽核招聘相關資訊，使用者可以擷取資訊、報名應聘。一個平台，把之前繁雜的步驟化繁為易，讓招聘變得更加高效、快捷。
團隊對于軟體定義清楚，對典型使用者和典型場景有充分且清晰的描述：詳見選題報告之真實使用者調研和使用者場景分析
- 我們達到目标了麼（原計劃的功能做到了幾個？)
原計劃Alpha階段完成功能：詳見需求規格說明書博文之預期計劃，在十天的Alpha沖刺中，我們完成了原定計劃中所有功能。團隊合格的完成了Alpha沖刺。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
整個沖刺階段進展還算順利，如果曆史重來一遍，我們會把項目文檔寫得更加詳細。
三、計劃
- 是否有充足的時間來做計劃?
alpha沖刺之前，經過了選題報告、需求規格說明書、原型設計、系統設計和資料庫設計等階段，我們對alpha做了詳細的規劃。
- 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
舉手表決
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
做完了，畢竟五一假期團隊成員，犧牲了假期，全程在開發。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有
- 是否每一項任務都有清楚定義和衡量的傳遞件?
- 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
由于明确的分工，合理的計劃安排，整個過程都按照計劃進行了。
沒有什麼風險是前期沒估計到，後面才發現的。
- 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
沖刺的十天裡，前六天都在上課，白天基本沒時間用于開發，後四天在五一假期，部分組員回家，往返學校都需要時間。這些應該都是緩沖區。
- 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
每個人都應明确緩沖區的具體時間段，不要在緩沖區以外的時間仍在休息
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
如果曆史重來一遍，我們會讓安卓開發的組員，更早的對安卓開發進行學習。
四、資源
- 我們有足夠的資源來完成各項任務麼?
硬體資源充足，團隊成員開發環境沖刺第一天全部完成搭建。
人力資源充足，團隊成員基本擅長Java，其中有3個人開發過安卓應用。我們團隊是為數不多的有女生的團隊（而且有兩個），女生在UI開發方面比較有優勢。
學習資料：github上有很多開源的項目可以學習和借鑒，另外助教也很熱心提供各方面的解答。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
我們将每個功能劃分為UI,互動和接口三個部分，分别由UI設計人員，安卓開發人員，後端開發人員進行開發。根據每個任務的難度和類型配置設定給每個人，最後确定每個任務的完成時間及其資源。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試時間不足，這次的alpha沖刺過程，因為一大半時間在上課，一大半時間在假期，每個組員都有自己的事情，所有對于項目的開發，團隊幾乎全程在趕進度，在測試時間上時間并不充分。
美工設計和文案很重要，在原型設計的時候，我們沒有特别的重視，這次的alpha沖刺，界面主要是根據原型開發，在答辯的過程中，普遍被評論UI可以繼續美化。
- 你有沒有感到你做的事情可以讓别人來做（更有效率）?
這次團隊分工主要是：
221600307 負責原型UI設計和測試
221600306 和 221600327 負責學生端APP開發
221600329 負責企業端APP開發
221600315 負責Java後端接口開發
221600319 負責Java後端算法設計
雖然221600307 和 221600327 沒有安卓開發經曆，但是我還是把他們放在了安卓開發上，因為每個組員的能力都不同，每個人擅長的也不同。但不能因為一個人做事更有效率，就把每件事都交他做。而且本來Learning by doing 這個思想就貫穿在我們這次軟工實踐當中，這樣的安排可能會促進他們學習。
團隊繼續加強溝通，加強互助，任務配置設定明确且盡量均等，避免有人任務過重，有人清閑。
五、變更管理
- 每個相關的員工都及時知道了變更的消息?
溝通的管道非常多，每天的會議，QQ群及時聊天等，而且我們團隊成員四個男生宿舍鄰近，兩個女生也在同一個宿舍，如果變更的消息，都能及時通知到每一個人。
- 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
根據實作難度和每個功能互相的關系，比如沒有登入注冊功能，那其他功能有什麼用？沒有崗位資訊釋出功能，那對崗位的履歷投遞功能有什麼用？然後通過開會讨論共同商議決定的。
- 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
在需求規格說明書中有詳細的說明
- 對于可能的變更是否能制定應急計劃?
沒有，緊急情況全靠加班。
- 員工是否能夠有效地處理意料之外的工作請求？
在alpha沖刺階段沒有遇到意料之外的工作請求
提前制定好變更應急計劃。
六、設計/實作
- 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
系統設計和資料庫設計是在需求分析做完之後開始的。由組長牽頭，全組人共同完成的。
是合适的時間，合适的人選。
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
沒有遇到這種情況，團隊開會之後都能确定下來方案。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
團隊運用了單元測試、UML等工具幫助實作。
有效。單元測試有效地幫助驗證了程式中的每一項功能的正确性，UML通過用例驅動，幫助我們把現實中的問題抽象成面向對象的解決方案，以便進一步的編碼。
在需求分析之後，根據老師和助教的建議，我們更新了部分的UML類圖。
- 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
在履歷建立和投遞功能産生的bug最多，主要是因為資料庫對時間的資料類型，接口傳回的時間的資料類型，安卓APP中所使用時間的資料類型，不同，導緻頻頻出現類型轉換等錯誤。
在答辯的時候，發現學生端擷取的崗位資訊中的标簽和企業釋出的崗位資訊的标簽有出入，原因是企業端和學生端所使用的的标簽資料版本不一緻，導緻部分标簽序号沒有對應上。後面将統一從伺服器擷取最新的标簽表，來解決這個問題。
- 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審由審查者評審代碼的格式、風格、命名是否符合規範。
因為我們的代碼規範是根據阿裡巴巴Java編寫規範制定的，是以我們給idea裝上阿裡巴巴的規範plugin，進行檢測。
我們學到了如何用測試工具輔助設計和實踐。
如果曆史重來一遍，我們會多應用自動化工具進行代碼的測試和複審。
七、測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
有
- 是否進行了正式的驗收測試？
- 團隊是否有測試工具來幫助測試？
有。具體使用工具可在測試篇部落格檢視。
- 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
開發時在Android Studio上進行了實時的性能監測，開發完成後也使用Jprofile對代碼性能進行了測試，itest對手機安卓端應用進行了性能測試。
- 在釋出的過程中發現了哪些意外問題？
釋出最新版本後由于一個日期解析錯誤是以點選求職意向子產品就閃退，後來加急搶修了。有驚無險。
我們學到了什麼? 如果重來一遍, 我們會做什麼改進?
實時對子產品進行測試和最終進行內建測試非常必要，可少走很多彎路。如果重來一遍會更早開始制定測試計劃，提前開始進行測試工作。
八、團隊的角色，管理，合作
- 團隊的每個角色是如何确定的，是不是人盡其才？
在分工的時候，充分考慮了團隊成員每個人的優勢，比如221600319喜歡爬蟲，221600315熱衷Java，221600306、221600329都有安卓開發經曆，221600307有美工基礎等等。
- 團隊成員之間有互相幫助麼？
有，因為部分成員對一些技術是新學習的，團隊一些大佬會經常為他們解惑。特别的，我們有一個小組成員221600315，較熟悉github相關操作，出現github相關問題，他都會熱心幫助，作為組長，我感覺現階段我們團隊的氛圍良好~
- 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
沒有出現相關問題，如果出現，會開會集體讨論解決。
- 每個成員明确公開地表示對成員幫助的感謝 ：
221600329 ： 我感謝K哥對我的幫助，因為他是我們組的中流砥柱，一個人撐起了後端的一片天。
221600306：我感謝K哥對我的幫助，在寫前後端互動的時候有不懂的地方都可以問他。然後Git版本控制自己不是很熟悉，對于有沖突的地方就很手足無措，都是K哥教的好，現在都可以自己解決沖突分支 了！
221600307：和其他隊友一樣，我也要感謝K哥對我的幫助，作為團隊中名副其實的大佬，他在團隊中起到了很大的作用，對我的幫助也不言而喻。另外就是我的室友小榕，我們倆經常在一起，遇到困難一 般都是問她，總能幫我解決問題。
221600315：和大家一樣，我也要感謝K哥，感謝他給我的幫助，以及感謝各位團隊成員齊心協力，才能完成本次作業，希望大家在β沖刺依舊能夠齊心協力取得更好的成績。
221600327: 首先還是感謝K哥，他教會了我很多，基本有自己解決不了的問題都會跟他探讨。還有就是感謝團隊成員的一起努力和了解，團隊氛圍真的是很重要的東西，很幸運能跟這麼棒的同學在一個團隊。
221600319: 我感謝k哥對我的幫助，github之前幾乎沒有用過，這一次開始用的時候
九、總結
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
輸入可重複級(Repeatable)檔次。
2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合-->規範
3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
團隊成員間可以更好的配合和協作。
十、讨論的照片
十一、隊員交換情況
任務交接
- 此前我（221600307）在組内負責的工作是用戶端UI設計和測試，原計劃是β階段優化界面，在隊員搭建的界面結構的基礎上盡量還原UI原型，使頁面更加美觀，并繼續完成測試工作。是以對于新隊員的學習建議是：
- 學習簡單的測試和Android開發，對Android界面編寫盡量熟悉，并仔細檢視之前的文檔和原型。
- 組内很多同學對于Android開發很熟悉，由于不清楚新成員對Android的掌握程度，是以希望比較擅長的同學能帶着新成員一起學習。
培養計劃
- 原成員是UI設計和測試人員，是以我們對新成員制訂了下面的學習計劃。
- 學習基本的安卓六大布局。
- 帶領新成員閱讀文檔、編碼規範和原型設計。
- 讓新成員了解接下來的Beta階段的功能需求，使其加快融入小組
- 原成員帶領新成員學習簡單的測試，使其能夠做好原成員的測試工作。