| 這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ |
|---|---|
| 這個作業要求在哪里 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ/homework/10151 |
| 團隊名稱 | <十分寵愛> |
| 這個作業的目標 | <總結軟件開發過程的經驗和教訓> |
| 作業正文 | https://www.cnblogs.com/shifenchongai/p/12045996.html |
| 其他參考文獻 | 無 |
設想和目標
1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們的軟件要解決如今養寵物的人越來越多，但是很多人養了寵物卻不了解寵物的習性的問題。它是一款主打科普萌寵知識的app。典型用戶就是寵物愛好者，典型場景就是
2. 我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)
原計划的功能基本都完成了，也按照原計划的時間交付了，但是用戶數量目前還比較少。
3. 和上一個階段相比，團隊軟件工程的質量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？
和上個階段比，大家對於軟件開發的流程和技術更為熟悉了，開發過程進行的更為流暢了，質量也提高了，在速度和質量上，通過文檔的數量和質量來衡量。
4. 用戶量,用戶對重要功能的接受程度和我們事先的預想一致么?我們離目標更近了么?有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
暫時還沒有向用戶推廣。
計划
1. 是否有充足的時間來做計划?
用於計划的時間還是比較充足的。
2. 團隊在計划階段是如何解決同事們對於計划的不同意見的？
對於不同的意見一般通過討論采用少數服從多數的規則。
3. 你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
基本全部完成。
4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
沒有
5. 是否每一項任務都有清楚定義和衡量的交付件?
項目的標准都是通過開會討論來定義衡量的，如果實現過程中出現問題會相應調整。
6. 是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
沒有完全按照計划進行。項目初期大家對於相關的開發技術工具不大熟悉，開發進程較為緩慢，后期熟練了之后效率才趕上來了。對於社區中留言的設計沒有很好的考慮到用戶的行為，出現了很多的問題。
7. 在計划中有沒有留下緩沖區，緩沖區有作用么?
有，休息，休息之后做事更有精力了。
8. 將來的計划會做什么修改？（例如：緩沖區的定義，加班）
將來希望合理規划每天的工作時間和休息時間，避免不必要的加班。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
學到了前后端的開發、交互，數據庫的搭建，服務器的部署，ui界面的設計，需求分析等
如果重來一遍，我們在需求分析會再多下點功夫，定義好用戶的需求和可實現的功能。還要合理安排好工作時間，開會時間，休息時間。
資源
1. 我們有足夠的資源來完成各項任務么?
資源基本都是夠的，后端有兩位有開發經驗的大佬，就是前端大家對於這塊都比較陌生，熟悉前端開發花了比較多的時間。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
由於大部分人都沒有開發經驗的問題，我們只進行粗略的估計，精度會稍微差點，實際時間花費的比較多。
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試是有我們組的一位大佬負責的，他做這個好像游刃有余的，對於美工設計等，我們分配的人手比較充足，所以實現過程中也沒遇到什么問題。
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
開發過程中忽略了前端開發的困難，沒有給到足夠的資源，導致拖延了軟件開發的進度，如果重來的話，會多多關注前端這一塊的資源投入。
設計/實現
1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
設計工作是現有團隊共同完成需求分析報告，然后有項目經理和美工實現ui設計，他們都做的很好，也按時完成了。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有遇到，都是在開會時討論解決的。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
有進行單元測試，這樣可以減少后期合並時的工作量。現在的uml文檔會更加明確，因為隊友的對於它的使用更為熟悉了，相互之間表達更加明確了。
4. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
動態掉bug還是有挺多的，可能是因為后期合並時太過於匆忙，以及對於測試的資源投入不足導致的。還好在后面改進了
5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
代碼復審由各部門的負責人進行，要求嚴格執行項目開始時規定的設計文檔。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
對於單元測試要再多花一些心思，尤其是后期合並時前后端的交互需，這樣可以減少bug的數量提高軟件的性能。
測試/發布
1. 團隊是否有一個測試計划？為什么沒有？
有，我們的測試工作由后端的一位同學負責。
2. 是否進行了正式的驗收測試？
是
3. 團隊是否有測試工具來幫助測試？
Visual Studio等
4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
軟件測試由測試人員進行性能測試，從軟件實際運行結果來看有一些效果，不過對於測試的投入還要更多一些。
5. 在發布的過程中發現了哪些意外問題？
改了某個頁面的小細節，突然整個頁面崩掉了。還有很多。。。過程很艱辛
我們學到了什么? 如果重來一遍, 我們會做什么改進?
對於軟件的測試可以嘗試使用更為專業的工具。
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
團隊的角色有大家自願選擇來確定的，這樣可以讓大家都在自己擅長或者感興趣的地方工作。在前期的准備工作中，編碼能力不強的同學占主要工作量。
2. 團隊成員之間有互相幫助么？
有，大家有問題都會在開會時提出討論，部分有開發經驗的同學也會幫助其他沒有經驗的人熟悉開發技術。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
出現這種問題時，一般都是通過開會討論決定的。大家也會及時到位。
組長的總結
由於產品1.0版本有很多不足，后面需要提升的空間還很多，所以在第二次沖刺中大家都很明確還有什么不足，還需要完善什么，非常有目的性。身為組長，也更加明確誰該干什么。大家在最后沖刺階段也陷入了疲軟期，但是身為厚臉皮的組長怎么能放過他們呢😼，一次次說好不肝，但每次都坐到沈茶打烊（零點），在驗收前一晚，在35號樓下肝到3點，終於成功打包處令人滿意的apk。
最后一次沖刺從功能完成度來說，沒有添加太多。這次沖刺主要在發現bu修復bug，盡量在演示的時候不要出差錯。
這次沖刺也讓大家意識到線下合作有多重要，當發現什么問題，可以面對面和隊友交流，因為有些問題在網上三言兩語是說不清楚的。
通過這次軟工實踐，我們大家感謝彼此，組長感謝各位組員的帶飛之恩，從零基礎接觸新技術的組員感謝大佬不嫌麻煩的幫助之恩，大家很幸運遇見彼此。
這是大家在沈茶肝的時候組長隨手一拍，雖然沒有包含所有人，但很真實
團隊貢獻度分配
| 成員名稱 | 貢獻比 |
|---|---|
| 林華偉 | 6% |
| 陳志超 | 14% |
| 閆佳豪 | 14.5% |
| 伍裕榮 | 11% |
| 張輝 | 7% |
| 羅愛玥 | 7% |
| 鄭學貴 | 14% |
| 胥鵬 | 6% |
| 李斯文 | 9% |
| 李享 | 12.5% |