軟件項目開發總結，假如歷史能夠重來

TD學生助手——release版發佈

1.設想和目標

---

 1.咱們的軟件要解決的問題

　　TD學生助手的主要核心思想就是幫助學生安排他們忙碌的學校生活。主要是經過如下幾個方面

 　　1.經過學生的須要進行分類（考試，實驗，發博客等等），添加日程，保存日程到數據庫中，將日程模塊化管理；

　　2.用月視圖和周視圖，日視圖三個視圖來管理添加進去的日程，讓日程管理起來更加直觀，方便，加強用戶體驗。

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

　　咱們作計劃主要是在Sprint計劃剛開始的時候進行計劃，並在之後實施計劃時進行調整，可是因爲咱們的敏捷開發的經驗不足，不知道如何控制任務的進程，給每一個人分配的功能在規定的時間內也沒法按時完成，因此到開發的後期制定的計劃對咱們的開發反而沒有什麼用了。

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

　　咱們組在討論TD學生助手主要功能設計時，常常出現分歧，由於每一個人對用戶體驗的想法都不一樣，咱們就讓持不一樣意見的寫個詳細的調查報告，分析這個功能的可行與否，用戶體驗是否會良好。

 

1.1用戶量

---

 

1.用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

　　咱們的重要功能就是能讓用戶直觀，簡潔的看到本身一天，一週，一月要完成的事情，並對添加的日程模塊化管理，關於這個主功能咱們作的還算完善，基本功能都有，可是在用戶體驗上離真正的目標還尚有必定的距離，咱們會在beta版的發佈時進行大的改進。相信用戶量會是咱們預想的那樣的。

 

假如歷史重來。。決定換一個軟件作。。這個太繁雜，不會寫，一個功能一個坑。

2.關於計劃

---

 

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

　　在整個敏捷開發階段咱們總共作了兩次sprint計劃，每次Sprint計劃咱們都有沒有完成的功能，而且還有決定要放棄的功能，這些功能在之後的日子發現也沒有太大的用處。可是不少東西與其不斷地爭論有些事情有沒有必要，還不如作了再說。

 

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

　　有。如今算起來兩個計劃中用不着的功能有一些，好比GPS導航功能，去除它有兩點緣由。1.這個軟件主要是管理學生生活的，跟GPS沒有直接和太大的聯繫；2.作起來太複雜，最後爲了保證Sprint計劃正常進行，咱們去除了這個功能。

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

　　有。咱們在每一次Sprint初始階段的會議中會根據每一個人的編程水平分配一些功能給團隊中的成員，並把他們綁定在一塊兒結對編程，並且功能和功能間有交叉的就進行互相聯繫，避免只敢本身的事情，無論團隊總體進度。每一項功能咱們也制定了最終要達到的效果以及能夠衡量的標準和演示狀態。

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

　　整個項目基本上都是按照計劃進行的，主要也是團隊成員比較給力，可是有些時候因爲PM制定計劃的失誤，致使整個項目在一段時間內偏移他真正要到達的目的，但最後咱們仍是迴歸在軌道上。

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

　　有。咱們的加班主要是集中在衝刺快要結束的後兩天，爲了保證Sprint計劃順利完成，團隊到最後都會加班加點，保證主要的功能定期完成。

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

　　咱們已經完成了Sprint2計劃的內容，最後一次衝刺也就是Sprint3計劃，咱們要作不少事情，在制定計劃的時候要充分考慮用戶的體驗和軟件的實用性。

 

 

3.關於資源

---

 

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

資源整體來講仍是挺充足的，網上有各類模板和代碼，還有各類教學視頻。

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

任務所需時間一開始時是儘可能給予充足的時間，以避免發生突發情況；任務精度一開始時只是肯定大方向，隨着項目的進行和任務的加劇，各類小功能被細分出來，再根據狀況分派任務。

3.用戶測試的時間，人力和軟件/硬件資源是否足夠?

此類資源都不欠缺，足夠了

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

沒有，由於本身的工做本身最熟悉，也是專門學習的有關此方面的程序設計及代碼編寫，每一個人都有本身的專攻，若是交給別人，可能會致使工做進度延遲或完不成，甚至乎影響整個項目的開發進度。

 

4.變動管理

---

 

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

由於咱們的團隊天天都會有站立會議，並且還專門創建了一個項目開發討論羣以便你們進行討論，因此各類消息都會及時知道。

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

咱們會根據項目的核心功能及各項功能實現的難度及複雜度來決定哪項功能必須實現那項功能推遲。

3. 項目的出口條件（Exit Criteria）是否獲得清晰的定義?

你們都不太懂「出口條件」是什麼，通過這一個項目以後，稍稍清楚了一些。可是說實在的，在這個項目裏面咱們沒有用到太多。

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

能，第一次衝刺結束後，組長感受各項功能及界面太過粗糙，因此從新編寫，各個組員積極配合兩天完成。

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

可能會臨時給某個組員增長一些任務，組員也會積極配合，儘快完成。

 

5.設計/實現

---

 

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

此類工做有本團隊中專職人員（靜姐，葉姐，嬌哥）完成，因爲是三人專職負責次部分設計因此設計上，時間上不會出現太大誤差，基本都能按時完成。

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

不少，你們都不知道如何解決。就看具體執行的人是如何解決的，有的解決得好，你們並不知道出過問題；有的常常拿出來討論，但可能會出現分期或多種結論，那就投票吧。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

 沒有使用這些工具，不會用，也不必

4. 什麼功能產生的Bug最多，爲何？

 日曆時間處理，導入數據庫，讀取數據

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

這個方面要求不是太嚴格，可能你們都感受太繁瑣，因此要求不是太苛刻，但你們在寫時會注意書寫。

 

 

6.測試/發佈

---

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

測試計劃是有的，這個方面你們仍是作的比較好的，因此階段測試及後期測試時比較翻遍明白，就是有點繁瑣。

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

正式驗收時有些bug還未解決，因此說驗收是不成功的

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

有。效果仍是很明顯的。

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

TFS 仍是頗有用的，至於改進，有這樣一些建議：

（a）經過不斷的想像用戶體驗

（b）做用仍是很好地工做方便，快捷

（c）吧錯誤提示改爲漢語好很差

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

有些功能不還不太理想，沒有達到預期目標，而在實際運行時還存在一些bug。

 

7.這一階段咱們作了什麼

---

 

1.用戶量

這是在百度網盤上的數據，下載量，感謝這段時間支持咱們的朋友，還有親愛的組員們

 

2.新增的功能

鬧鐘

學校課程查詢和修改