02组团队项目-中期总结
一、Alpha沖刺鏈接
| Alpha 1/6 | https://blog.csdn.net/Tranquil12138/article/details/127741839 |
| Alpha 2/6 | https://blog.csdn.net/Tranquil12138/article/details/127778974 |
| Alpha 3/6 | https://blog.csdn.net/Tranquil12138/article/details/127814545 |
| Alpha 4/6 | https://blog.csdn.net/Tranquil12138/article/details/127839139 |
| Alpha 5/6 | https://blog.csdn.net/Tranquil12138/article/details/127875802 |
| Alpha 6/6 | http://t.csdn.cn/cF0P9 |
二、團隊名片（5分）：
- 隊長博客鏈接：https://bbs.csdn.net/topics/609422542
- 團隊Logo：
-
團隊ID號與團隊名稱：02_父老鄉親同舟共濟
-
團隊現場答辯總結：
-
我們小組不太幸運抽到了倒數第三個答辯，在座的同學們都已經比較疲憊了，不過在我們小組上場答辯時，大家還是提起了精神，可以看出大家看到我們小組錄制的真人情景劇后又感到很新鮮了。根據柯老板以及同學們的評價，我們的項目確實讓人耳目一新，PPT制作精美可愛，匯報層次分明，最后也有升華，答辯環節我們也完美的回答了同學們的提問，整個答辯氛圍很nice。但我們在拍照識別功能的實現上確實還有很大的不足，我們可能把過程想得太過復雜化，柯老板建議我們不用搞清具體原理，先去找相關開源代碼運用即可，所以這個問題我們也在全力解決中。
-
團隊討論的真實照片：
-
以表格形式展示團隊中每個人在本次作業中的具體分工和各自得分比例。（得分比例之和為*總人數100%**，例如3人團隊得分比例可以為95%、100%、105%）
| 歐希賢 | 博客的撰寫 | 150% |
| 萬遙 | PPT的制作以及視頻的制作、答辯宣講 | 240% |
| 劉向民 | 視頻的拍攝 | 110% |
| 徐昊 | 博客的部分撰寫 | 50% |
| 朱智浩 | 博客的部分撰寫 | 50% |
| 常文杰 | 博客的部分撰寫 | 50% |
| 蔡冀鴻 | 博客的部分撰寫 | 50% |
| 張芯月 | 視頻的制作、用戶界面設計 | 200% |
| 劉金柱 | 博客的部分撰寫 | 50% |
| 李超洋 | 博客的部分撰寫 | 50% |
三、總結思考（45分）
3.1 設想和目標（5分）
3.1.1我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述 ？
我們的項目主要立足于人文關懷，助力于構建一個人貓和諧的校園環境。由我們初期調研的數據我們可以知道，福大校內貓貓的數量是較多的，而校內人員與貓貓們的接觸也是相當頻繁的，但由于互相的不了解有時人與貓之間會造成不恰當的接觸，為了讓人們更好的關愛貓貓，我們團隊決定開發此款小程序。我們以貓貓為中心，為貓貓打造專屬信息庫并賦予此款小程序社交屬性，將其發展為以貓貓為中心的人貓和諧社區。此定義明確。此款小程序的典型用戶為校內愛貓人士以及潛在的愛貓人士，面向用戶包括但不限于每一位熱愛生活熱愛生命的校內人員，典型場景包括遇見不認識的貓貓對其進行識圖以獲取此貓貓的信息、想某只貓貓了查看貓貓的相冊以及相關動態、被某只貓貓可愛到了發動態記錄一下等等與貓貓有關的場景。
3.1.2我們達到目標了么?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?)
基本上是實現了我們在本沖刺階段的基本目標，原計劃的功能已基本實現或實現了大半。接下來的部分便是后端與前端的對接以及用戶內測與交互上的完善。交付時間相比原計劃需要往后延時，尚未投入使用，所以還未確定既定用戶數量。
3.1.3用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
由于在小程序正式上線之前用戶僅為開發人員與小部分內測人員，故功能的接受程度與事先預想基本一致。在大家的團結協作之下，我們離目前越來越近了。
3.1.4有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
最大的經驗教訓還是由于開發經歷不足所導致的前期分工不明以及對接困難。如果歷史重來一遍的話，在前期準備工作方面會下更多的功夫以到了具體開發階段能夠更加理解自己的分工以及讓對接更有效率。
3.2 計劃（6分）
3.2.1是否有充足的時間來做計劃?
在選題制定之后有較多時間做出計劃，已經非常清晰地描繪出了我們團隊想做什么、要做什么、以及怎么做的大概框架，在開發過程中隨著我們對項目的熟悉也對計劃與分工進行了合理的調整與修改。
3.2.2團隊在計劃階段是如何解決組員對于計劃的不同意見的？
在遇到不同意見時團隊內部會首先溝通了解對方的出發點，再分析每個意見的可行度，最后再討論出最適合總體計劃方向的意見。
3.2.3原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?
在此沖刺階段我們原計劃的工作基本完成，但由于開發過程中所遇到的阻礙，還剩余后端部分的完善以及與前端的對接部分。
3.2.4有沒有發現做了一些之后看來沒必要或沒多大價值的事?
團隊計劃較完善，未發現有做了但現在看來價值不大的事。
3.2.5是否每一項任務都有清楚定義和衡量的交付件?
在項目初期，每一項任務其實并未完全清晰，但隨著項目的推進以及團隊對項目的了解，我們的任務分配也越來越清晰，我們做了盡可能詳細規劃，對于所有功能的實現通過類圖做了清晰的設計，同時原型的設計也早早完成。故每一項任務都有清晰的定義與衡量的交付件。
3.2.6是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
我們團隊在項目的整個過程都按照計劃進行，沒有出現任何無法挽回的意外，除了有的時候莫名其妙的bug除外，但這也是意料之中。風險是存在的，我們的拍照識別功能推進緩慢，由于大家以前都沒有接觸過這方面的學習，開源代碼也沒找到合適的，所以這個功能對于我們來說還沒有做得很完善，在完成度上面存在一定的風險。
3.2.7在計劃中有沒有留下緩沖區，緩沖區有作用么?
根據原計劃我們給項目留下了約三天的緩沖區，但由于對接上出現的一些困難，導致我們緩沖區的實際時間為兩天，這兩天的緩沖也讓我們可以對項目及時進行合理調整。
3.2.8將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
未來的計劃中我們會重視緩沖區的作用，在合理分工的情況下盡量延長緩沖區，緩沖區實際上對我們團隊而言是一次重要的自檢。在后續的計劃中，團隊的重心也會向后端靠攏，盡快完成任務，盡量避免不必要的加班，
3.2.9學到了什么? 如果歷史重來一遍, 會做什么改進?
在這次團隊沖刺中，我們團隊協力完成了Alpha版本的發布，在這一過程中，我們不僅在各自研究的前后端領域學到了全新的知識，還認識到了好的計劃調度和團隊合作對整個項目進度的重要性。如果歷史重來一遍，我們會事先做好更加完善的計劃，可能會更早確定選題的方向和所要完成功能，這樣能更好的協調組內分工細則，計劃也會更加明確。
3.3 資源（6分）
3.3.1我們有足夠的資源來完成各項任務么?
其實資源并不夠用，首先大家其實并沒有什么開發經驗，對于小程序開發，其實大部分人都是從0開始學習。而小程序開發其實有許多需要自己實踐探索區理解以及需要足夠多的試錯以積攢經驗的，所以大家在前期的進度都相對較慢，而小程序本身其實沒有很完整的教程，需要足夠多的實踐去探索，只能說感謝大家的努力我們的項目才得以穩步推進。
3.3.2各項任務所需的時間和其他資源是如何估計的，精度如何?
根據大家的開發基礎以及協作水平去估計項目所需的時間，但精度其實一般，實際開發所遇到的困難有時是難以估計的，而且大家許多都是從0開始做起。
3.3.3測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?
大部分資源是不足夠的，在此沖刺階段大家也是花了許多時間精力去盡力完成任務，為了預留出緩沖時間，大家也是爭分奪秒，有時會感覺到人手不足，在圖像識別功能的開發中，遇到了一個功能需要跑兩個小時的狀況。對于不需要編程的資源并未低估難度，也是全力完成。
3.3.4你有沒有感到你做的事情可以讓別人來做（更有效率）?
我們小組都沒有這種想法，在分工上較合理。
3.3.5有什么經驗教訓? 如果歷史重來一遍, 會做什么改進?
經驗教訓大概是前期其實沒有做好充分的準備才導致起步階段有一些慌亂。如果重來一次的話，前期會花更多的時間去了解相關知識。
3.4 變更管理（6分）
3.4.1每個相關的員工都及時知道了變更的消息?
每次有變更消息，都會讓組員們在群里收到回復，保證每個相關組員都能夠及時知道變更的消息。
3.4.2我們采用了什么辦法決定“推遲”和“必須實現”的功能?
在計劃中我們有決定出基礎功能與附加特色功能，此決定是基于小程序基本的定位以及小程序的主打功能，故在決定“推遲”和“必須實現”的功能時，我們采取的也是此標準。
3.4.3項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
項目的出口條件的定義為：基礎功能實現，用戶交互感良好，附加功能實現。
3.4.4對于可能的變更是否能制定應急計劃?
可制定應急計劃，我們團隊先以基礎功能為重點，后期再附加功能為重點，如遇突發情況，會加快完成基礎功能以實現保底。
3.4.5組員是否能夠有效地處理意料之外的工作請求？
我們團隊的組員會在需要的時候去學習新的知識以處理意料之外的工作請求。
3.4.6學到了什么? 如果歷史重來一遍, 會做什么改進?
此次沖刺學到了將工作中的任務按重要性合理安排。重來一遍的話，會根據實際需求結合開發難度去做更加合理的安排，在意外發生時要盡快交流，達成共識并做好解決措施。
3.5 設計/實現（6分）
3.5.1設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
UI設計工作主要由張芯月同學在項目初期時完成，項目初期確立的原型設計為后來我們的開發方向做出了指導，是合適的時間與合適的人選。
后端的設計主要由團隊內在項目初期討論得出，并以此分配工作，是合適的時間與合適的人選。
3.5.2設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有遇到模棱兩可的情況，主要由相關負責人主導、對內討論解決，討論的基調為初期確立的設計的大方向。
3.5.3團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
使用了uml來幫助設計和實現。工具是有效的。
3.5.4比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
區別較大，隨著項目的推進，團隊的項目的理解也越來越細致。需要更新UML文檔以更好地輔助開發工作。
3.5.5什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
動態打卡功能產生的Bug最多，主要是由于對后端開發以及數據庫開發不熟悉導致的。目前未遇到重要的bug。產生Bug是因為我們在設計階段時并沒有掌握有關動態打卡的知識，所以上手后有一定的知識空白。
3.5.6代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
對統一命名提出要求后對代碼進行粗略閱讀，后再次進行二次判斷。較嚴格執行代碼規范。
3.5.7學到了什么? 如果歷史重來一遍, 我們會做什么改進?
學到的太多了，無論是設計能力、語言知識還是開發的能力都獲得了進步，也能夠更加理解初期設計的重要性以及基礎知識的重要性。如果歷史重來，大概率會提前去適應這種開發模式以及學習知識的模式。
3.6 測試/發布（5分）
3.6.1團隊是否有一個測試計劃？為什么沒有？ 是否進行了正式的驗收測試？
有測試計劃，在初期計劃進行開發人員間的內測，而在之后會推行非開發人員的內測。正式的驗收測試還未開始。
3.6.2團隊是否有測試工具來幫助測試？
有利用測評工具來測試圖像識別算法的耗時。
3.6.3團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
在內測過程中收集體驗報告并對功能體驗進行評價以此測量并跟蹤軟件的效能。從軟件實際運行的結果來看，這些測試工作確實對軟件的完善提供了不少寶貴的建議。改進可以考慮對軟件的性能進行可視化的測試。
3.6.4在發布的過程中發現了哪些意外問題？
偶爾會出現請求時延。
3.6.5學到了什么? 如果歷史重來一遍, 會做什么改進?
學到了軟件測試的方法以及體會到了測試對軟件的重要性。如果重來一遍，會更加重視對軟件功能各個階段的測試。
3.7 團隊的角色，管理，合作（5分）
3.7.1團隊的每個角色是如何確定的，是不是人盡其才？
團隊的每個角色由個人擅長方向、功能開發要求以及個人意愿分配。基本上是人盡其才。
3.7.2團隊成員之間有互相幫助么？
哐哐互相幫助，沒有大家已經堅持不下去了嗚嗚嗚嗚嗚。
3.7.3當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
遇到問題哐哐討論，大家交流比較積極，最終我們都會得出讓團隊滿意的結果。
3.7.4每個成員明確公開地表示對別人幫助的感謝 （寫在各自的博客里）：
我感謝 ___徐昊__對我的幫助，因為:在他的推薦下我決定了要使用的教程。
3.8 總結（6分）
列出團隊所有成員Alpha沖刺階段后的心得。
歐希賢總結1：
感覺開發過程中沒有什么東西是容易的，很多東西實戰與理論其實存在著較大差別，學習過程中也讓我更加能夠沉下心來去做事情。學到了很多吧，初次開發小程序確實是磕磕碰碰的旅途，感謝大家都有盡力去做自己負責的部分。答辯完之后的夕陽挺好看的。
張芯月總結2：
這次沖刺的優點就是首先都讓大家動起來了，就促使大家快速的分工和完成任務。感覺小組合作更互補了，體會到了小組合作的意義。定時定點的匯報讓每個人都對自己的學習計劃有個安排，這點我感覺挺好的。我對微信小程序也有了更深的了解。總體來說這次沖刺我也學會了很多東西，又累又充實也很快樂。希望我的第二輪Beta沖刺可以表現的更好，學到更多知識。希望我們小組的合作也越來越完美！
萬遙總結3：
讓我感受到了團隊真正的意義，不僅僅是因為個人精力有限完不成才需要團隊，而是在共同完成項目的過程中，互相鼓勵互相學習，苦中作樂一起進步。因為速成學習，基礎不牢，知識體系不夠好的緣故，學習時間真的很長。因為沒有一個指導我們方向的大佬，大家都是小白，在摸索中學習。其實軟工理論中，并沒有規定那么具體每個人要如何編程，這都需要我們去親身實踐，親身嘗試，這也再次印證了軟件工程是一門需要實踐的學科。要善于在網上去尋找資源，代碼什么的可以在網上找到一些比較類似的，要慢慢去看著學習。
常文杰總結4：
在最開始得知Alpha沖刺這一任務的時候，我的內心是相當抗拒的。畢竟最近幾周的任務很多，而且多個課程的大作業截止時間都在11月底、12月初的時段，如果還要額外花時間去寫階段性博客，只會讓本就不富裕的時間更加雪上加霜。事實上也是如此，雖然每次博客的內容不多，但也需要花費一定時間去完成，在任務繁重的時候令人格外的煩躁。
但凡事有壞也有利，沖刺博客雖然給我們增加了時間上的負擔，但也很好地督促了組內各個成員穩步推進進度，避免了擺爛拖延、不務正業的現象，從某種意義上也為我們節約了時間。
整個Alpha階段，我們完成了前端大部分的工作，后端數據庫和圖像識別的進度也在穩步推進，可以說階段性博客功不可沒。
在這次的Alpha沖刺階段，我也是一改以前拖延的習慣，早早地開始進行UI界面的建造，在這期間我也是遇到了不少的問題，例如、界面和不同機型如何匹配、如何適應更多的機型、導航欄及滾動界面的制作，等等。
這些問題不算難，但很需要花時間去試驗和解決（可能是因為我能力不足吧）。好在最后問題都被我一一解決了，雖然很累，但收獲也很多，自己在這個過程中也學到了不少新知識，也希望自己在Beta沖刺階段再接再厲、做的更好！
劉向民總結5：
第一次參加團隊編程，其實開始有點慌，畢竟自己會的不多，在此階段，自己做的事不多，希望在下個階段，能走出舒適圈，多做一些實質性的貢獻。
朱智浩總結6：
第一次做這么大的工程捏，第一次接觸后端，接了后端組的任務后剛開始覺得應該和前端一樣簡單，然而隨著事情的發展，我發現我錯了。后端所需掌握的知識遠比我想象的要多得多。剛開始啥也不懂哐哐學nodejs，學完發現還是做不出來，果斷放棄，另尋出路，這次方向對了，但是要學的內容好多，嗚嗚。總的來說，從啥也不懂的小白，成功入門微信小程序，雖然這個不算后端，取了點巧。了解了web，小程序開發的步驟，制作開發這些東西要學習什么了，以后學習目標就會清晰一些，不會盲目亂竄了，嗚嗚。
劉金柱總結7：
由于自身編程能力不夠強，在Alpha沖刺階段中花費大量時間去進行學習相關的知識，沒有參與代碼編程任務當中，還有之前對于自己要干的事情還不是很清晰，浪費了大量的時間，以至于學到的東西沒有多大的用處，在這次Alpha沖刺中，最后**有了明確的方向，能參與到團隊任務中還是比較有體驗感的，**但是自己對前后端的交互不太行，云開發做起來也比較吃力，希望在Beta能更進一步。
李超洋總結8：
前端的東西很容易上手，但是真的很不容易深入；知識很零散、細碎，真的很要耐心。
前后端的交互，以及數據庫、接口的搭建也并不像大家想象的那么簡單。
對于一整個項目的架構沒有較好的認識，這對我們的開發規劃影響很大。
有很大一部分知識，在開發中并沒有用到，但是仍然花費了我大量的時間和精力去學習；這是一個比較值得思考的問題。
蔡冀鴻總結9：
本次Alpha沖刺一開始的思路是進行圖像識別相關知識的學習，然后運用知識實現圖像識別。但是這思路不對。后來才得知正確做法是直接拿現成的用（雖然現成的也不好找就是了）。從軟工的第一份作業開始，一切的起點都是從頭學一個新的東西，這是個“不成文的規矩”，如果誕生了拿成品套用的想法（雖然成品也確實沒那么能找到），甚至應該要為之感到羞愧。于是進度噌噌噌地停在那兒。體會就是，這確實不是人干的事兒。圖像識別這東西，都夠拿來當一門必修課了吧，在本來就有課要上，有其他作業要完成，有其他事要做的情況下，兩周搞定？這可不是什么水課啊喂。總之就很艱難，雖然毫無成果沒什么資格說話。
徐昊總結10：
AI真難，不是我等輕易便能掌握的。很遺憾直到快完蛋才想起去找開源代碼，算是一個教訓吧。因為在現場編程與團隊編程中，我的各種無法完成需求的情況，大家都給予了很好的包容與鼓勵，讓我沒有過分自責，得以繼續前進，團隊協作真的很重要。
總結
以上是生活随笔為你收集整理的02组团队项目-中期总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iOS系统回退教程
- 下一篇： linux_bash/zsh ls(di