Alpha 過後諸葛亮（團隊）

---

所屬課程	軟件工程1916|W（福州大學）
做業要求	Alpha 過後諸葛亮（團隊）
團隊名稱	待就業六人組

1、團隊信息

• 團隊名稱：待就業六人組
• 團隊描述：同舟共濟揚帆起,乘風破浪萬里航
• 隊員信息：

隊員學號	隊員暱稱	我的博客地址	備註
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/	組長

2、設想和目標

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

   軟件想要解決的問題：想要改變目前福州大學校園招聘信息只能經過網站單項發佈，傳播不廣，缺少互動的現狀，提供一個對等的信息發佈平臺，企業能夠發佈、審覈招聘相關信息，用戶能夠獲取信息、報名應聘。一個平臺，把以前繁雜的步驟化繁爲易，讓招聘變得更加高效、快捷。

   團隊對於軟件定義清楚，對典型用戶和典型場景有充分且清晰的描述：詳見選題報告之真實用戶調研和用戶場景分析

2. 咱們達到目標了麼（原計劃的功能作到了幾個？)

   原計劃Alpha階段完成功能：詳見需求規格說明書博文之預期計劃，在十天的Alpha衝刺中，咱們完成了原定計劃中全部功能。團隊合格的完成了Alpha衝刺。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

整個衝刺階段進展還算順利，若是歷史重來一遍，咱們會把項目文檔寫得更加詳細。

3、計劃

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

   alpha衝刺以前，通過了選題報告、需求規格說明書、原型設計、系統設計和數據庫設計等階段，咱們對alpha作了詳細的規劃。

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

   舉手表決

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

   作完了，畢竟五一假期團隊成員，犧牲了假期，全程在開發。

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

   沒有

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

   沒有

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

   因爲明確的分工，合理的計劃安排，整個過程都按照計劃進行了。

   沒有什麼風險是前期沒估計到，後面才發現的。

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

   衝刺的十天裏，前六天都在上課，白天基本沒時間用於開發，後四天在五一假期，部分組員回家，往返學校都須要時間。這些應該都是緩衝區。

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

   每一個人都應明確緩衝區的具體時間段，不要在緩衝區之外的時間仍在休息

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

若是歷史重來一遍，咱們會讓安卓開發的組員，更早的對安卓開發進行學習。

4、資源

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

   硬件資源充足，團隊成員開發環境衝刺第一天所有完成搭建。

   人力資源充足，團隊成員基本擅長Java，其中有3我的開發過安卓應用。咱們團隊是爲數很少的有女生的團隊（並且有兩個），女生在UI開發方面比較有優點。

   學習資料：github上有不少開源的項目能夠學習和借鑑，另外助教也很熱心提供各方面的解答。

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

   咱們將每一個功能劃分爲UI,交互和接口三個部分，分別由UI設計人員，安卓開發人員，後端開發人員進行開發。根據每一個任務的難度和類型分配給每一個人，最後肯定每一個任務的完成時間及其資源。

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

   測試時間不足，此次的alpha衝刺過程，由於一大半時間在上課，一大半時間在假期，每一個組員都有本身的事情，全部對於項目的開發，團隊幾乎全程在趕進度，在測試時間上時間並不充分。

   美工設計和文案很重要，在原型設計的時候，咱們沒有特別的重視，此次的alpha衝刺，界面主要是根據原型開發，在答辯的過程當中，廣泛被評論UI能夠繼續美化。

4. 你有沒有感到你作的事情可讓別人來作（更有效率）?

   此次團隊分工主要是：

   221600307 負責原型UI設計和測試

   221600306 和 221600327 負責學生端APP開發

   221600329 負責企業端APP開發

   221600315 負責Java後端接口開發

   221600319 負責Java後端算法設計

   雖然221600307 和 221600327 沒有安卓開發經歷，可是我仍是把他們放在了安卓開發上，由於每一個組員的能力都不一樣，每一個人擅長的也不一樣。但不能由於一我的作事更有效率，就把每件事都交他作。並且原本Learning by doing 這個思想就貫穿在咱們此次軟工實踐當中，這樣的安排可能會促進他們學習。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

團隊繼續增強溝通，增強互助，任務分配明確且儘可能均等，避免有人任務太重，有人悠閒。

5、變動管理

1. 每一個相關的員工都及時知道了變動的消息?

   溝通的渠道很是多，天天的會議，QQ羣及時聊天等，並且咱們團隊成員四個男生宿舍鄰近，兩個女生也在同一個宿舍，若是變動的消息，都能及時通知到每個人。

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

   根據實現難度和每一個功能相互的關係，好比沒有登陸註冊功能，那其餘功能有什麼用？沒有崗位信息發佈功能，那對崗位的簡歷投遞功能有什麼用？而後經過開會討論共同商議決定的。

3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

   在需求規格說明書中有詳細的說明

4. 對於可能的變動是否能制定應急計劃?

   沒有，緊急狀況全靠加班。

5. 員工是否可以有效地處理意料以外的工做請求？

   在alpha衝刺階段沒有遇到意料以外的工做請求

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

提早制定好變動應急計劃。

6、設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

   系統設計和數據庫設計是在需求分析作完以後開始的。由組長牽頭，全組人共同完成的。

   是合適的時間，合適的人選。

2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

   沒有遇到這種狀況，團隊開會以後都能肯定下來方案。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

   團隊運用了單元測試、UML等工具幫助實現。

   有效。單元測試有效地幫助驗證了程序中的每一項功能的正確性，UML經過用例驅動，幫助咱們把現實中的問題抽象成面向對象的解決方案，以便進一步的編碼。

   在需求分析以後，根據老師和助教的建議，咱們更新了部分的UML類圖。

4. 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

   在簡歷建立和投遞功能產生的bug最多，主要是由於數據庫對時間的數據類型，接口返回的時間的數據類型，安卓APP中所使用時間的數據類型，不一樣，致使頻頻出現類型轉換等錯誤。

   在答辯的時候，發現學生端獲取的崗位信息中的標籤和企業發佈的崗位信息的標籤有出入，緣由是企業端和學生端所使用的的標籤數據版本不一致，致使部分標籤序號沒有對應上。後面將統一從服務器獲取最新的標籤表，來解決這個問題。

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

   代碼複審由審查者評審代碼的格式、風格、命名是否符合規範。
   由於咱們的代碼規範是根據阿里巴巴Java編寫規範制定的，因此咱們給idea裝上阿里巴巴的規範plugin，進行檢測。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學到了如何用測試工具輔助設計和實踐。
若是歷史重來一遍，咱們會多應用自動化工具進行代碼的測試和複審。

7、測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

   有

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

   有

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

   有。具體使用工具可在測試篇博客查看。

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

   開發時在Android Studio上進行了實時的性能監測，開發完成後也使用Jprofile對代碼性能進行了測試，itest對手機安卓端應用進行了性能測試。

5. 在發佈的過程當中發現了哪些意外問題？

   發佈最新版本後因爲一個日期解析錯誤因此點擊求職意向模塊就閃退，後來加急搶修了。有驚無險。

咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

實時對模塊進行測試和最終進行集成測試很是必要，可少走不少彎路。若是重來一遍會更早開始制定測試計劃，提早開始進行測試工做。

8、團隊的角色，管理，合做

1. 團隊的每一個角色是如何肯定的，是否是人盡其才？

   此次團隊分工主要是：

   221600307 負責原型UI設計和測試

   221600306 和 221600327 負責學生端APP開發

   221600329 負責企業端APP開發

   221600315 負責Java後端接口開發

   221600319 負責Java後端算法設計

   在分工的時候，充分考慮了團隊成員每一個人的優點，好比221600319喜歡爬蟲，221600315熱衷Java，22160030六、221600329都有安卓開發經歷，221600307有美工基礎等等。

2. 團隊成員之間有互相幫助麼？

   有，由於部分紅員對一些技術是新學習的，團隊一些大佬會常常爲他們解惑。特別的，咱們有一個小組成員221600315，較熟悉github相關操做，出現github相關問題，他都會熱心幫助，做爲組長，我感受現階段咱們團隊的氛圍良好~

3. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

   沒有出現相關問題，若是出現，會開會集體討論解決。

4. 每一個成員明確公開地表示對成員幫助的感謝 ：

   221600329 ： 我感謝K哥對個人幫助，由於他是咱們組的中流砥柱，一我的撐起了後端的一片天。

   221600306：我感謝K哥對個人幫助，在寫先後端交互的時候有不懂的地方均可以問他。而後Git版本控制本身不是很熟悉，對於有衝突的地方就很手足無措，都是K哥教的好，如今均可以本身解決衝突分支 了！

   221600307：和其餘隊友同樣，我也要感謝K哥對個人幫助，做爲團隊中名副其實的大佬，他在團隊中起到了很大的做用，對個人幫助也不言而喻。另外就是個人室友小榕，咱們倆常常在一塊兒，遇到困難一 般都是問她，總能幫我解決問題。

   221600315：和你們同樣，我也要感謝K哥，感謝他給個人幫助，以及感謝各位團隊成員齊心合力，才能完成本次做業，但願你們在β衝刺依舊可以齊心合力取得更好的成績。

   221600327: 首先仍是感謝K哥，他教會了我不少，基本有本身解決不了的問題都會跟他探討。還有就是感謝團隊成員的一塊兒努力和理解，團隊氛圍真的是很重要的東西，很幸運能跟這麼棒的同窗在一個團隊。

   221600319: 我感謝k哥對個人幫助，github以前幾乎沒有用過，這一次開始用的時候

9、總結

1.你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

輸入可重複級(Repeatable)檔次。

2.你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

磨合-->規範

3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

團隊成員間能夠更好的配合和協做。

10、討論的照片

11、隊員交換狀況

任務交接

• 此前我（221600307）在組內負責的工做是客戶端UI設計和測試，原計劃是β階段優化界面，在隊員搭建的界面結構的基礎上儘可能還原UI原型，使頁面更加美觀，並繼續完成測試工做。所以對於新隊員的學習建議是：
• 學習簡單的測試和Android開發，對Android界面編寫儘可能熟悉，並仔細查看以前的文檔和原型。
• 組內不少同窗對於Android開發很熟悉，因爲不清楚新成員對Android的掌握程度，因此但願比較擅長的同窗能帶着新成員一塊兒學習。

培養計劃

• 原成員是UI設計和測試人員，因此咱們對新成員制訂了下面的學習計劃。
• 學習基本的安卓六大布局。
• 帶領新成員閱讀文檔、編碼規範和原型設計。
• 讓新成員瞭解接下來的Beta階段的功能需求，使其加快融入小組
• 原成員帶領新成員學習簡單的測試，使其可以作好原成員的測試工做。