Postmortem報告

Postmortem報告

1、每一個成員在beta階段的實踐較alpha階段的改進：

陳修遠：

所謂軟件工程，相比於普通的編程來講，是一個功能衆多，內部邏輯複雜的工程項目。經過一學期的現代軟件工程實踐，我發現想作好一個好的軟件，清晰的產品模型規劃是十分重要的。在開發前必定要想清楚，須要開發的一個項目是怎樣的。對整個項目進行怎樣的刪改都會對代碼形成極大的影響。能夠不須要想清楚每個細節，可是涉及軟件核心的邏輯與功能必須想清楚，不然，後患無窮。

 

傅詠淦：

我我的關注較多的仍是技術層面吧。我的以爲技術選型之於軟件工程是很是重要的一部分，選用的開發工具最好容易上手但能有必定的深度，最好還能有好的開發文檔和社區。這樣說來咱們先後端所用的工具都是特別好的，讓咱們的開發如虎添翼。

 

李浩冉：

在數據庫方面，咱們發現alpha階段的數據庫創建的過於冗雜，其實使用flask自帶的sql庫對數據庫操做很簡便，讓數據表及元素增長並非一件很好的事，因此在beta版咱們減小了表和元素的數量。在代碼的實現方面，咱們增長了id與token，在先後端對接時增長了安全性與保密性。

齊天浩：

本學期軟件工程的團隊項目經歷了alpha版本和beta版本兩個階段，這兩個階段的開發過程給我留下的感覺是大相徑庭的。由於在alpha階段在考試周附近，因此咱們僅僅是在較爲集中的幾天以內進行項目的開發，雖然咱們的beta階段也是在必定的時間內集中進行開發，可是咱們的開發週期相對來講比較長（畢竟暑假期間的事情相對較少）；並且，咱們在開發時沒有後顧之憂，不用擔憂考試的影響，能夠全身心地投入到項目的開發之中。此外，alpha版本的先後端交互相對較少，beta版本涉及到了更多的交互，所以，更須要組內成員的交流與溝通，這無疑對咱們組是很大的挑戰（三人是美國時間，三人是北京時間），然而，這並無影響咱們項目的進度，各位成員都或多或少地爲了項目犧牲了本身的休息時間，這讓我感到很欣慰，我對各位隊友也很感激。

徐楠青：

我以爲一個很明顯的改善就是你們使用GitHub的次數也上升了很多，使得咱們的代碼管理獲得了大大提高。還有一點是前端的分工更加細化，目前採起製做界面—完備功能—美化—測試等步驟，讓前端的工做更加高效有序。

尹童欣：

我在β階段主要是負責界面美化工做。在α階段咱們組由於界面不美觀失分較多，因此就由我和美工一塊兒負責界面美化。經過一系列的努力，再加上網絡上豐富的資源做爲參考，咱們組成功完成了對界面的美化。

 

2、團隊在beta階段吸收alpha階段的經驗教訓

首先，好的界面是成功軟件的一半。Alpha階段咱們前端繪製的界面雖然具備基本的功能，可是美觀程度不忍直視。在beta階段咱們在美工同窗和組員的合力下將界面的美觀性大大提高。

其次，咱們在alpha對於GitHub的使用不積極使得代碼的交流，更新，修改變得不方便，而且有着較大的隱患存在。在beta階段中，小組成員系統學習了git的使用方法，並且規範了代碼的交互流程，使得小組開發的效率有了顯著提升。

再次，咱們在先後端交互方面顯著增長了交流的次數。使得先後端可以更爲流暢地進行對接。不只如此，咱們還對先後端的某些接口進行了封裝，在簡化操縱流程的同時也方便了對於出錯的調整。

 

3、敏捷開發原則中團隊作的最好&最差的兩點

首先細數敏捷開發的十二條原則：

（1）咱們最重要的目標，是經過持續不斷地及早交付有價值的軟件使客戶滿意。

（2）欣然面對需求變化，即便在開發後期也同樣。爲了客戶的競爭優點，敏捷過程掌控變化。

（3）常常地交付可工做的軟件，相隔幾星期或一兩個月，傾向於採起較短的週期。

（4）業務人員和開發人員必須相互合做，項目中的每一天都不例外。

（5）激發個體的鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

（6）不論團隊內外，傳遞信息效果最好和效率最高的方式是面對面的交談。

（7）可工做的軟件是進度的首要度量標準。

（8）敏捷過程倡導可持續開發。責任人、開發人員和用戶要可以共同維持其步調穩定延續。

（9）堅持不懈地追求技術卓越和良好設計，敏捷能力由此加強。

（10）以簡潔爲本，它是極力減小沒必要要工做量的藝術。

（11）最好的架構、需求和設計出自組織團隊。

（12）團隊按期地反思如何能提升成效，並依此調整自身的舉止表現。

咱們組認爲咱們在「（6）不論團隊內外，傳遞信息效果最好和效率最高的方式是面對面的交談」和「（7）可工做的軟件是進度的首要度量標準」方面作得不是太好。前一點必定程度上是因爲組員的年級和學院不一樣形成的，不過也有一部分緣由是組內對於面對面交流不是過重視致使的。後一點一方面是由於咱們做爲軟件開發方面的小白，對於軟件開發的流程和工具的使用不很熟悉，致使進度劃分不是太清晰。另外一方面咱們在開發項目的初期階段對於進度度量的意義不太明確，使得忽視了這一方面的評估。

可是咱們組認爲咱們在「（5）激發個體的鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。」和「（12）團隊按期地反思如何能提升成效，並依此調整自身的舉止表現。」這兩點上作得至關不錯。究其緣由，有如下幾點：首先，咱們組雖然面對面交流的次數很少，可是線上交流和代碼方面的交互仍是比較頻繁的。其次，和諧融洽的團隊關係讓每一個組員在咱們組可以充分發揮本身的實力，相互信賴使得咱們可以達成更爲理想的目標。最後，時常反思（尤爲是相互之間交流本身的經驗和教訓）讓咱們組每一個成員得以及時調整本身的開發狀態，提升開發效率。

 

4、團隊開發模式和優點、劣勢品評

咱們組的開發模式基本是基於The Cathedral （大教堂）模式開發的。在優點方面，咱們可以精心地規劃咱們項目所須要的大部份內容。不只如此，咱們還可以系統地調節整個項目的進程，合理分配時間，而集市型的。在劣勢方面，The Cathedral （大教堂）模式開發的項目在開發過程當中，是很難接收到外來的意見和建議的，因此說開發過程當中踩坑比較頻繁。再者，就開發時間和成原本說，「集市」較「大教堂」更爲低廉，更適合於敏捷開發。

Eric Raymond這樣看待大教堂和集市之間的競爭：「我認爲，將來會更多地屬於那些告別大教堂、擁抱集市的人們。這不是說我的的遠見和才華再也不重要；而是在我看來，將來的成功者只是從本身的遠見和才華開始工做，而後經過有效的社區合做，將其不斷地放大。開放式的文化會最終勝利，這或許不是由於"開放"在道德上正確，或者‘封閉’在道德上錯誤，而只是由於開放式合做能夠在一個問題上投入多幾個數量級的技術工時，封閉的世界沒法贏得這樣的競爭。」

雖然業界的大師這樣看待，但咱們並不這麼認爲。開放和封閉式的開發的確沒有對錯之分，並且開放式開發有着龐大的羣衆基礎。可是現實生活中有不少項目因爲某些緣由是沒法開源的，封閉不時刻意味着保守，有些時候反卻是安全的表現。此外，咱們能夠設想，若是當某個問題上投入高出幾個數量級的人員都收益甚微時，人們將會尋求從頭精打細算的方式，將集市的磚瓦細細疊放。開放和封閉並不天生對立，二者不過是一種開發方式，在將來的軟件工程中，相信咱們會愈來愈多地看到二者混成的開放方式。畢竟咱們的目的只有一個——開發出優質的軟件。