成員
基本準則
全體成員
1.準時完成issue對應的任務，並在github上進行登記
2.如無特殊情況，按時參加小組例會，如實匯報進度
3.如果遇到實現上的困難，需要及時和pm或同組開發者進行溝通
4.有權對貢獻分評價結果提出異議
前端1.保證架構設計能與後端進行合適的對接
2.完成開發的同時，進行基本的測試
後端、爬蟲
1.兼顧與前端和教務系統的對接，制定合適的介面規範
2.完成開發的同時，進行基本的測試
pm1.完成所有文件和部落格的撰寫 ，以及會議記錄的整理
2.掌控專案進度，進行合理規劃，督促組員完成，對組員進行打分
3.完成後端、爬蟲的環境配置和部署，負責伺服器相關任務
4.遇到特殊困難時，及時在例會上提出和大家協商
下述**適用於前端、後端、爬蟲開發者的評分，基礎分數為50分，在此基礎上進行增減。
打分週期為每個小階段一次。
類別程度
加減分準時性
提前完成
+0
按時完成
+0延後完成，遲交時間一天內或未延誤進度
-2延後完成，遲交時間一天以上或延誤進度
-4質量
質量較高，可讀性好，可擴充套件性好
+2質量過關或者bug極其微小
+0質量較差，有非架構設計上的功能性bug
-2質量差，且修復較困難，甚至延誤專案進度
-4bonus
協助他人完成因拖延或技術難題而未完成的工作
+2完成額外的開發任務
+2說明：
「準時」是最基礎的要求。提前完成任務之後進入摸魚狀態不會有獎勵，如果提前完成之後，能幫助其他同學完成任務，或者完成額外的任務，則會有較多的貢獻分。
初期對工作量的估計只是乙個大概，如果在執行過程中發現工作量確實有較大差異，則會進行任務調配或者分數的再分配，由組員商討決定。
所有打分由pm進行，pm需要公示每一階段的打分項，有異議需要聯絡pm。
pm由於工作性質較為特殊，所以不參與以上打分。pm若在實際開發階段中參與了開發，則可適用bonus相關的規則。pm的分數將由剩下的所有同學，在團隊專案驗收結束後進行統一打分。打分模板如下。如果該模板不夠詳細，可進行進一步細化。
評價分數
非常盡職盡責，積極性強
+4較為盡職盡責，比預想的好一點
+2一般，只是做了該做的事情
0不太盡職盡責，對日期和任務不敏感
-2非常不盡職盡責，有些pm的本分工作甚至需要開發者來提醒
-4
軟工頂級理解組 Alpha階段團隊貢獻分評分
下述 適用於前端 後端 爬蟲開發者的評分，基礎分數為50分，在此基礎上進行增減。類別程度 加減分準時性 提前完成 0 按時完成 0延後完成，遲交時間一天內或未延誤進度 2延後完成，遲交時間一天以上或延誤進度 4質量 質量較高，可讀性好，可擴充套件性好 2質量過關或者bug極其微小 0質量較差，有非架...
軟工頂級理解組 無人轉會申請
我們是軟工頂級理解團隊，經過長達乙個月的alpha階段緊張刺激的開發，我們希望能夠提交無人轉會申請，其理由如下 下面我們將詳細闡述我們的申請條件。人員崗位 職責喬璽華 單彥博 張藝璇 前端進行android軟體介面開發 胡彬彬 李嘉鋮 後端進行伺服器互動邏輯 編寫 杜博瑋爬蟲 負責從教務獲取學生資料...
軟工頂級理解組 Beta階段事後分析
目錄和上乙個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？使用者量，使用者對重要功能的接受程度和我們事先的預想一致麼？我們離目標更近了麼？有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？團隊在計畫階段是如何解決同事們對於計畫的不同意見的？你原計畫的工作是否最...