我的博客做業_week14

1. M1/M2階段總結

• 我在M1階段負責後端代碼的開發，以及協助PM，在M2階段負責PM，在爲期將近一學期的團隊軟件開發過程當中，我深入體會到了團隊協做的重要性，以及合理分配任務的重要性，沒有一個好的時間規劃是不能達到高效開發的。
• 同時，我也體會到了軟件開發中各類方法的必要性，好比：結對編程。之前一直以爲代碼一我的寫一部分，單獨完成，這樣效率是最高的，由於每一個人的思路都不同，代碼風格也不同，兩我的一塊兒寫，你肯定不是在逗我？這樣的話，兩我的不打起來就不錯了，怎麼可能完成任務呢，仍是高效完成？後來通過幾回的結對編程，我慢慢發現原來這是有很大的科學依據，以致於到最後階段，時間特別緊張的時候，咱們都會自覺的採用這種編程方式，能使咱們的進度大大提升。之前一直以爲這種方式只有弊端，卻不知，正由於兩我的的思路不同，因此，想法更多，遇到問題也就更快解決，最重要的是，一我的寫，一我的看，這樣犯的語法錯誤比較少，後期調試也會少不少，還有，兩我的一塊兒寫，能夠相互鼓勵，相互監督，你們都很差意思偷懶，也更容易集中注意力，大大的提高效率。
• 我還深入體會到的一點，就是隊員的重要性。必定要和靠譜、肯幹的隊員組隊，這也算給下一屆學弟學妹一點忠告，有一幫靠譜的隊員，每個人只要負責本身的那一塊就好了，最起碼不會心累，我如今是真的心累...

　2.學期初的問題

• 連接：http://www.cnblogs.com/hongzs/p/4830863.html
• 其中第一個問題：如何避免在產品開發後期不斷有重大修改，對於這個問題，我深有體會，由於咱們在M1階段對上一屆代碼進行了重構，全部界面從新寫，可是在M2階段的時候，因爲要四組合一，統一後端，因此咱們本身的服務器不用了，全部的前端的接口都要重寫一遍，這個工程量是有點大的，因此，咱們是有重大修改的，因此，我認爲要避免這種狀況的發生，必定要提早溝通好，不管是團隊內部，仍是團隊之間，都要作好充分的溝通之後，再開始進行開發工做。
• 第二個問題：查閱資料，Bartle分類法，將遊戲玩家分爲四種類型，分別爲殺手，成就者，探索者，社交者；殺手：干擾遊戲世界的運做或其餘玩家的遊戲活動；成就者：經過克服遊戲世界的挑戰，不斷積累聲望等；探索者：探索控制和運做遊戲世界的系統；社交家：與其餘玩家溝通交流遊戲內容，從而造成社交關係。
• 第三個問題：我目前以爲衡量軟件工程的質量就是看代碼的運行效率以及單元測試的覆蓋率，以及所採用的算法結構，代碼風格，代碼行數；
• 第四個問題：協調團隊之間的任務分配，應該充分考慮團隊裏每一個人的能力以及學習能力，以及出現問題，怎樣及時修正，使其回到預約的時間表上；
• 第五個問題：團隊的親密度，是基於你們都在高效的完成既定任務的基礎上的，若是某一個隊友的任務完成質量不高，或者效率過低，又或者根本就沒作，這種狀況一而再的發生，那麼這就不是一個合格的隊友，這個團隊的任務完成狀況確定也是不容樂觀的，那麼親密度確定不高。

    3.在軟工中學到的：

　　我深入的體會到了是什麼叫「作中學」，感受全部的東西都是自學的.....有一個建議：之後軟工的編程任務已經很重了，博客做業或書面做業能夠減小一點，不少時候，你們寫這個是很痛苦的.........

    4.在項目中學到的：

• 需求階段：當時需求階段，學長學姐已經給咱們最好了不少，因此這一塊並無走多少彎路，可是最好仍是在前期進行一些用戶的問卷調查；
• 設計階段：一個用開發經驗的隊友是很重要的，能給咱們不少的幫助；
• 實現階段：結對編程真的很重要，效率也很高；
• 測試階段：儘可能多考慮一些邊界狀況；
• 發佈階段：必定要熟知每一個應用平臺的一些發佈規定，提早了解，就不會像咱們在發佈的時候，有各類曲折；
• 維護階段：後端代碼很重要，必定要有詳細的文檔說明。