Beta以後的想法

軟件工程若是沒選實踐，單純在理論課上面對教條化的理論，這些理論都是頗有指導意義的，但沒有實踐課帶來的切實的多人團隊合做開發項目的實際體會，很難能領會到其中的深意。知行合一，才能發現軟件工程裏的知識都是有用的經驗之談。

不要認爲一切將運做良好

缺少合理的進度安排是形成項目滯後的最主要緣由……它反映了一種不真實的假設：一切都將運做良好

軟工的工做量確定是大學以來最大的一個實踐課，須要選課的同窗端正本身的態度，若是想要實打實地完成一個質量尚可的項目，要投入的精力確定是不能少的。軟工不是寫寫程序這麼簡單，這門實踐課設計了一系列的環節，好比組隊、立項報告和調查、資源規格說明書、UML繪製、現場團隊編程、兩次衝刺、展現答辯。能夠發現寫程序佔比並很少（這和真實的軟工過程也是類似的），一些在軟工課以外絕對不會去作的事項，正是幫助你瞭解現實狀況下的多人合做軟件開發。

每個環節想要作好，都須要去真正地投入精力。最開始的博客做業會問你，每週打算投入多少時間。其實這個問題就是讓你作好準備，由於這是一個硬指標，不投入較多的時間確定只能作出平庸的結果。拿團隊組隊選人舉例子，尋找一個合適的團隊是極其重要的，最後沒組到隊的人被迫造成一個小組，這個組的結果通常方方面面都不會使人滿意。我一開始也不知道要怎麼尋找隊友，尋找怎樣的隊友比較合適。因而我詢問了學長學姐這方面的經驗，而且花時間寫了一個招聘文件，最後組建了一個至關不錯的團隊。

在立項、資源規格說明書、UML的繪製中，整個團隊對於腦海裏想要作的軟件的構想會逐漸清晰，但這裏要注意的是團隊的成員必定要加快學習的進度，儘早開始寫代碼、產出產品代碼，儘早開始迭代、測試、發佈產品。

計算機編程基於十分容易掌握的介質，編程人員經過純粹的思惟活動——概念以及靈活的表現形式來開發程序。……咱們期待在實現過程當中不會遇到困難，所以形成了樂觀主義的瀰漫……而咱們的構思是由缺陷的，開發也總會遇到bug的。

團隊在討論的時候，經常會出現這種狀況：「這個功能很簡單的啦，建一張表，有XXX字段，到時候查表就好了」、「這裏我就構造一個json發送給你你到時候接着就好了」。就是腦中構思程序邏輯並不困難，但實際開發中總會碰到這樣那樣的問題。我想了下，這實際上是一種客觀現實，咱們應該理解並學會接受。能作到的只有提前開始學習相關知識，提前開始開發。由於是必定要遇到困難、遇到bug的，留足學習的時間，提前開始，纔不會趕deadline，才能夠從容不迫。

人月

跟書名同名的經典理論，在這裏簡單複述一下——人月做爲衡量工做的規模是有欺騙性的神話，向進度落後的項目添加人手只會使進度更加拖延。這條理論十分有名，致使我在上軟工課以前都提早去了解了一下。

通過團隊現場編程的磨礪，讓我明白了這條理論在多人團隊合做中有一個背後的意義。書中所說，添加人手所增長的負擔在於培訓和相互交流成本，任務不能徹底分解給參與人員而不增長他們之間的交流成本。能夠得知，培訓、相互交流、合理地分配任務在軟工中扮演極其重要的位置。

培訓：大多數同窗都沒有實際的開發經驗，因此須要熟練工或者學習能力比較強的同窗帶領你們在項目初期的時候開啓有效的學習、實踐。由於初期你們都是小白，儘快學習知識，使大多數團隊成員從小白成爲能夠產出代碼的項目組成員，這十分有意義。在我看來，這確定是軟工實踐區別於其餘實踐課的一點。1、之後你們走上工做崗位，將來的軟件開發團隊，也確定有leader，每一個人技術有高低之分。若是本身是leader，如何帶領你們前進？若是本身實力較弱如何提升本身的學習能力？都頗有意義。2、學校裏其餘實踐課能夠存在抱大腿的行爲，軟工是一個可讓你們真正體驗爲一個目標共同努力的過程。你們水平有高有低，但通過個人努力，後端組全部成員均可以上手寫代碼並commit，這是我很是自豪的一點。

交流：交流的成本是很大的，因此初期要謹慎地考慮分工。到了項目真正開展的時候要考慮一下團隊的結構，好比，有沒有技術leader？團隊成員怎麼分組？PM怎麼和不一樣的開發人員交流？使用什麼手段來使團隊成員有效地交流想法和問題？

合理地分配任務：這學期因爲棟哥跑路，本來三個班的選課人選擠到了兩個班，致使每一個組人都會變多。人變多了，交流的成本就會變得更高。還有一個額外的問題就是，做爲在學校裏的軟工項目，其實你們作的事情不會差異特別大，但人多了，要保證每一個人的貢獻度，要如何分配每一個人都有合理的任務量能夠作呢？這是一個須要考慮的問題。

外科手術隊伍

能夠說咱們在實踐中基本採起了這種團隊模式。

隊伍成員	《人月神話》中的描述
外科醫生（首席程序員）	首席程序員，親自定義功能、設計程序、編制代碼、書寫文檔、測試
副手	外科醫生的後備，詳細瞭解全部的代碼，能完成任何一部分工做。
管理員	外科醫生的老闆

PM就是管理員，他除了PM常見的職責以外（負責組建團隊、劃分工做、督促進度、保持和團隊成員的溝通）。他還常常參與先後端、數據庫的開發，雖說他不負責核心開發工做，但能夠說PM真的對整個項目有至關程度的瞭解和把控做用。能夠說是十分合格的PM。

在外科手術團隊中，外科醫生和副手瞭解全部的設計和所有代碼，並確保概念上的完整性。

在傳統的隊伍中你們是平等的，出現觀點的差別時，不可避免須要相互討論和妥協讓步。但在外科手術團隊中，不存在利益的差異，觀點的不一致之處能夠由外科醫生單方面來統一。

概念的完整性要求設計必需要由一我的或者很是少數、互相有默契的人來實現。……對於大型項目，將設計方法、體系結構方面的工做和具體實現相分離時得到概念完整性的強有力方法。

外科醫生是前端組和後端組分別有兩個leader，兩位leader能夠保證代碼的產出效率。我是後端的leader，後端組4名成員中有一個得力副手，剩餘兩位在項目初期的時候處於較緩慢的學習進度中，但通過努力均可以真正地產出代碼或文檔，或進行測試。PM在開會時常會討論需求；全體成員能夠一塊兒討論初步接口、數據庫、代碼邏輯等構思，但最後通常都是PM和Leader統一敲定，給出正式和清晰的定義；PM和leader對任務進行合理的劃分，其餘的成員執行PM和leader交付給他們的任務；每一個人都要承擔本身的義務，PM和leader要確保你們不拖延和妥協。

從項目結構上和合做方式上說能夠說這是一個很是良性的團隊。這是在項目衝刺時天然而然地造成的，不得不說軟工的理論確實仍是很是有道理的。

文檔、編程手冊

我以爲本身作的最有意義的一件事情就是在項目過程當中造成的學習文檔。後來重看《人月神話》在第七章才發現其實這個叫「工做手冊」：

• 工做手冊是外部規格說明、接口說明、技術標準、內部說明和管理備忘錄。
• 「將來產品」的高質量手冊，將誕生於今日的備忘錄。正確的項目工做手冊，能保證爲阿里的文檔結構的規範而不是雜亂無章。
• 工做手冊是每個編程人員應當瞭解的全部材料。
• 工做手冊的實時更新是很是關鍵的。

貼幾張圖展現一下：

在過後讀《人月神話》看到對應的內容，這代表了我在事先不知情的狀況下作了一件實際上是符合軟工理念的事情。但最讓我高興的是「alpha過後諸葛亮」時，個人隊友對我表達的感謝。這讓我感覺到了本身作的事情是很是有意義的，我體會到了什麼是真正的合做，什麼是真正的軟工。

（王源）我感謝趙暢對個人幫助， 由於某個具體的事情: 共同爆肝編程解決了從部署到接口邏輯到代碼的諸多問題。他提出並一直在努力維護的技術文檔也爲我和其餘成員省下了許多debug的功夫。

（展瑞）我感謝趙暢對個人幫助， 由於某個具體的事情: 帶領我進去後端框架的學習，而且幫助我梳理了整個後端框架，以及postman的工具使用；在我自閉的時候積極鼓勵我。

Beta吐槽

Beta衝刺過程當中團隊成員出現了必定的懈怠狀況。

1. alpha衝刺過了快一個月，你們緊繃的神經放鬆了下來。還有就是隔了一個月發現本身忽然不會打代碼了
2. beta期間存在着考試，複習的安排，以及畢竟已經有了alpha版本，對於將來的新功能不是特別的着急了。這也符合歷年課程中你們認爲alpha環節對本身提高最大的狀況。
3. 其實本身的動力也是降低了吧，其實明明本身構想好了很cool的功能沒有去作，因爲沒有像去年棟哥那樣強制佈置推廣給真實用戶，因此咱們目前沒有推廣給真實的食堂店鋪店主使用，其實也是本身沒有去推進作這個事情，（如今要準備考試也不打算去作）能夠說是一個遺憾。