過後諸葛亮（團隊）

項目名稱

實驗室督勤管理系統

隊名

三隻松鼠

小組成員

朱宏韜 180320079
古 越 180320075
張星海 180320077

設想和目標

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

本系統的目的分爲兩個方面：其一是記錄學生考勤信息，並圍繞考勤信息造成一系列評價標準，以此督促學生養成良好的學習生活習慣，提升學習工做效率；其二是幫助管理員記錄相關信息，並提供參考評價標準，從而簡化管理員的工做。
咱們認爲咱們的定義已經十分明確，也將詳細的用戶場景記錄在需求報告中了。

2. 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？)

通過alpha衝刺階段，咱們基本完成了原定目標，只是遺留了一些細節沒有處理（好比界面不夠美觀）。項目的提交也遇上了原定的交付時間，因此雖然一路上有些磕磕絆絆，可是最後咱們仍是完成了目標。

3. 是否有充足的時間來作計劃?團隊在計劃階段是如何解決對於計劃的不一樣意見的？

咱們有充足的時間來作計劃，但是因爲沒有開發經驗，因此咱們初始的計劃十分不全面，以致於咱們不得不在以後的衝刺階段不斷的對計劃進行調整。至於團隊意見，咱們通常會各自闡述本身的想法，意見不一樣的時候咱們會好好爭辯一番，若是最後意見不能統一，就少數服從多數。

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

最大的教訓天然是要在項目初期作出更加完善的計劃，更合理的分配時間，分配工做。同時對會遇到的難關也會有足夠的重視，不會到緊要關頭才發現本身先前對這個問題太太小看，以致於沒法按時完成當天的工做。若是歷史能夠重來，咱們會作出更加詳盡的計劃，遇到問題是也會更快的找到解決方式。

計劃

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

原計劃的功能咱們都成功實現了，要說沒作完的就是咱們兩種計算補貼的方式是按照本身的想法設計的，不知道各位實驗室管理員真實的計算補貼的方法是什麼，因此可能對各位管理員提供的參考價值還能夠繼續提升。

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

因爲項目開發的總體時間並不長，因此咱們在作好計劃以後就當即開始學習相關技術，邊學邊進行開發，拼命實現相關功能，努力對各方面進行完善，因此能夠說作的都是有價值的事。

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

咱們對每一項任務都有定義，可是衡量的標準不夠清晰。由於雖然咱們對項目都有清晰的設想，可是在具體的功能實現以前，誰也不知道最後能達成什麼樣的效果，你們都想着先把東西作出來，以後再看看跟預期有什麼出入。因此咱們可能沒有具體的評價標準。

4. 是否項目的整個過程都按照計劃進行？

總體上是按照計劃在進行。初期由於對相關技術不熟悉，因此落下了不少進度，以後快馬加鞭的遇上了，中途有對計劃進行一些細微的調整。

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

咱們確實想要在開發途中留下必定的緩衝區，好進行修整並作好下一步的安排，可是由於所給的開發時間實在過短了，從頭至尾都是在趕工，因此遇到問題的時候也只能讓相關人員及時解決或做出調整，省得項目最後沒法交付。

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

系統的主要功能大致都實現了，可是系統內部還有一些邊邊角角須要完善，也要着手美化界面。會盡可能留出緩衝區，由於以前alpha衝刺的時候已經有很多熬夜的經驗了，因此以後有須要的話也會繼續加班。

資源

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

1、硬件資源，三臺筆記本是夠的；2、軟件資源，開發軟件均可以在網絡上下載，因爲組長是正經科班出身，在軟件、開發平臺方面給了小組成員很大幫助；3、時間資源，由於對軟件開發的不熟悉，咱們小組各成員花了比較多的時間在數據庫，mybatis框架，java代碼等方面。

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

在整體方面咱們劃分了環境搭建，創建數據庫，編寫系統各模塊代碼三大部分；編寫系統各模塊代碼是其中的最主要部分，這一部分咱們根據模塊功能來劃分任務量。咱們爲預計的每一個項目分配合理的工做量，根據工做量的多少來計劃天天須要完成的工做。每一天根據前一天完成的狀況再製定當天的工做任務和工做量。

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

測試的時間遠遠不夠，特別是前期由於咱們對項目的各類方面都不熟悉，對數據庫的使用，開發平臺的使用等等尚存在一些問題，在完成任務上就花費了很大功夫，致使留給測試的時間不多，使得測試僅限於很初級的層次，由於代碼、模塊、ppt、文檔都是分擔到每一個人手上，因此分配很差，工做量很大。

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

我以爲針對文檔分工一塊，有些組員對畫圖比較熟練，有些組員對文字內容比較擅長，這個分配若是合理的話會比較有效率。

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

有時各組員協同工做，若是沒有事先約定好一些內容，那麼彙總時發現各人的風格、想法不同，爲了總體的統一，咱們又得花大功夫去整改，這就違反了分工的的初衷。但現實的狀況是，缺少經驗的咱們沒法預知咱們的合做應該事先約定什麼，或咱們的合做會遇到什麼樣的問題能夠經過事先約定來避免，因此經驗只能經過失敗以後的默契來得到，豐富的失敗經歷纔會成就更簡潔更順利的成功。

變動管理

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

咱們團隊有三人，兩人在2號樓，一人在四號樓，因此前期交流都是在二號樓的祕密基地進行，三我的在一塊，互通消息，面對面地交流，快速有效，簡單簡潔。後期四號樓的組長實驗室搬到了二號樓，交流更加通暢了，或實驗室，或深夜食堂，或圖書館，溝通方便。

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

咱們針對系統的主題，優先實現系統的必需功能，且遇到的有難度的功能必須保證明現。對在系統中起輔助做用的功能模塊好比相關管理幾大模塊，消息中心模塊內的功能，儘量實現其主要功能，對實現起來比較難，比較耗時的功能，咱們會根據項目進度、時間、人力等因素考慮其存在必要性。

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

作好了是能夠實現基本功能，能夠知足平常使用須要的強度。

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

對可能的變動，在不改變當前數據庫結構，數據表的狀況下，增長功能是能夠實現的。

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

對於意料以外的工做請求，咱們會對其進行評定，該請求是不是應該考慮到需求裏而被咱們當前的開發忽略了的，或是是一個不合理的請求。對於前者，咱們會努力改變咱們的數據、系統來達到該請求內容、功能。

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

變動實際上是一項很考驗咱們軟件結構的操做，若是咱們的軟件結構合理，那麼對於新增長的功能是比較友好，容易改動的。如果結構不夠獨立，那麼有可能牽一髮而動全身，傷筋動骨一百天，那個滋味確實很差受。
若是歷史重來一遍的話，咱們的代碼多少會有些優化的。

設計/實現

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

項目的設計工做是十一月中旬左右開始的。項目最初的點子是張星海同窗提出的，由於他自己就當任本身實驗室的管理員，因此對實驗室管理員的繁瑣工做深有體會。以後由咱們三個小組成員共同商討項目細節以及具體要實現的功能，因爲是三我的共同設計，咱們每一個人都對這個項目有本身的期待，幹起活來天然更起勁，因此這個設計的人能夠說是合適的。

2. 工做實現過程當中有沒有碰到不能解決的問題，團隊是如何解決的？

開發途中遇到的難以解決的問題，咱們通常是本身網上查找解決方法，以後組內討論，還不行的話會向相關的技術大佬請教，最後總能找到出路的。

3. 比較項目開始的UML文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

開始的UML文檔和如今的狀態確實有些微的差異，由於開發初期計劃的不合理，以後在實現的時候不得不對原先的設計作出一些改動，隨着工做的進行，咱們慢慢的解決了遇到的問題，也消除了由於設計的不合理而帶來的負面影響。

4. 在發佈以後有沒有發現bug? 咱們在設計/開發的時候爲何沒有想到這些狀況?

確實有發現一些bug。由於咱們對相關的技術不熟悉，在開發途中都是現學現用，而且對各模塊之間的相關性認識不夠準確，因此沒有預想到這些bug的存在。好在咱們的bug對系統的主要功能不會產生影響，只要管理員操做正確，這些bug甚至不會暴露出來。咱們的學習之路還很漫長。

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

一次完整的項目開發讓咱們學到了不少，好比更加深入的認識到開發項目遠遠不僅是敲代碼而已，項目成員之間的合理溝通能夠有效的促進項目的進行，一個好的計劃能夠節省大量的開發時間等等。有趣的是由於屢次在一塊兒熬夜，咱們發現了多條在晚上數計學院關閉以後從數計學院院樓逃生的通道。
若是歷史能夠重來，咱們會作出更加完善的計劃，更加合理的時間安排，更適合每一個人的分工。固然，要儘可能避免熬夜。

測試/發佈

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

有的，咱們的測試分爲單元測試和系統測試兩種，單元測試是安排在每一個功能完成時由負責該模塊的同窗進行測試。系統測試是項目接近結束或者項目結束後對整合的系統進行系統且全面的測試。

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

是的，在項目的驗收前有測試安排

4. 團隊是如何測量並跟蹤軟件的效能的？

咱們在項目開發過程當中有程序員對模塊的初步測試，在項目開發的中後期，由團隊成員對項目進行交叉測試、重複測試、覆蓋系統的所有已實現功能。在測試中發現系統中可改、可不改的內容，發現系統中有錯誤和無錯誤的內容，發現系統中存在的不合理邏輯等。

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

咱們在測試中學到了一個道理，或者說學會了一個認識問題的角度，那就是學會站在別人的角度思考問題，一個合格的測試或者說一個高明的測試者是會讓本身變成一個徹底的客戶的角色的，因此想象力或者說豐富的項目經驗或人生閱歷對測試是很是重要的要素。
若是歷史重來一遍，咱們願意多花一倍時間用在對前期開發的功能模塊的編寫和測試上，這樣雖然前期會多花不少時間，但對後期的工做會有很好的鋪墊，程序會有更規範的格式。

團隊的角色，管理，合做

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

在肯定角色時咱們遵循兩個原則：
(1)充分利用各個成員的特長優點；
(2)每一個成員必須參與各個方面的任務。
先由在某方面具備優點的成員開展該方面的工做，其他成員做爲該方面工做的輔助者，在進行過程當中逐漸積累經驗，當水平達到必定程度後便可獨立進行該方面的工做。是人盡其才，充分發揮每一個成員的優點。

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

有。團隊成員的互相幫助是團隊工做效率穩步提升的關鍵因素。古云：三人行必有我師焉。在平時的開發過程當中，每一個成員取他人之長，補己之短，不只提升了總體的效率，也提升了自身水平。

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

咱們天天都會開展一次以上的討論會，項目管理、合做方面的問題是咱們討論的重點，例如進度安排、管理制度等問題，咱們會把問題擺出來討論，你們分別論述本身的觀點和想法，如有意見衝突則少數服從多數，決定後當即實施。項目管理和合做分工等方面的工做都是在一次又一次的調整中不斷完善的。

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

在此次爲期近半個月的軟件工程實訓中，咱們經歷了肯定題目、需求分析、項目設計、項目實施、項目測試和項目驗收這些過程，並從中得到了很大的收益。首先是程序編寫能力和文檔撰寫能力獲得了提升，同時總結和分析問題的能力也獲得了提升。另外，對用戶需求分析和軟件測試也有了更加深入的認識。學會敏捷開發：敏捷是指可以讓團隊思考更加有效、工做更爲高效，而且作出更好決策的一組方法和相關理念，同時，敏捷也是一種思惟模式，正確的敏捷模式有助於團隊成員共享信息，從而共同做出重要的項目決策，而不是讓一我的獨自做出全部決策，在此次敏捷開發訓練中，每一個成員都有對實踐應用的發言權，每一個人都必須清楚整個項目的開工計劃、設計和改進流程，咱們深入感覺到這種新的思惟方式可以幫助咱們更加高效地工做。若是歷史可以重來，咱們會在項目的需求分析階段和功能設計階段作更加充足的工做，由於這兩個階段工做的任務能夠說是整個工程大方向的肯定，若完成質量高，有利於後續工做用更短的時間實現更好的效果。

總結

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

咱們團隊已經順利度過了磨合期，目前處於規範期。

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

(1)團隊裏各成員之間的默契程度獲得了提升；
(2)編程能力有很大的提高；
(3)對軟件測試有了更加深入的認識；
(4)較爲完整地感覺了一次軟件開發的全過程。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

(1)原則：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.（不管團隊內外，面對面的交流始終是最有效的溝通方式。） 事例：在Alpha階段咱們天天都會在一塊兒開展工做，有什麼問題立刻交流，一般很快能夠解決或者達成一致的意見。有幾回任務量較大，你們回到各自宿舍加班，有問題經過線上交流，明顯感覺到了這樣交流的效率沒有面對面交流的效果好。另外，向學長學姐和組外同窗請教時咱們也儘可能採用面對面交流的方式以得到最好的交流效果。 (2)原則： Continuous attention to technical excellence and good design enhances agility.（只有不斷關注技術和設計才能愈來愈敏捷。） 事例：在設計實現學生補助模塊時，起初計劃經過管理員直接肯定補助金額，後來發現這樣的效果不夠理想，因而咱們採用策略模式對該模塊的實現進行優化，獲得了更好的效果。 (3)原則：The best architectures, requirements, and designs emerge from self-organizing teams.(只有能自我管理的團隊才能創造優秀的架構, 需求和設計。) 事例：咱們團隊要求每一個成員對當天遇到的問題進行總結進而轉化爲經驗，而且在天天工做結束時進行組內分享。將大問題劃分紅小任務分配給每一個成員，而且每一個任務的執行者都要給出計劃完成時間，若在執行過程感受不可以按時完成需當即報備組長並說明原因，以便於總體調度。除此以外團隊裏還有其餘相關制度，要求每一個成員嚴格執行，這是咱們團隊可以不斷進步的重要緣由。 (4)原則：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.（時時總結如何提升團隊效率, 並付諸行動。） 事例：當某個成員有關於提升效率的想法或者方案時，咱們會停下手上的工做開一個短會，讓該成員分享其想法，若是是一個好點子咱們會盡快應用到工做中，盡最大可能提升工做效率。