【軟件工程】團隊過後分析

軟件工程團隊項目終於告一段落，而咱們「葫蘆娃」團隊也實現了VisualPytorch項目從0到1的轉變，6月22日晚，咱們彙集在大運村1公寓507宿舍內，召開了一小時左右的會議，你們共同總結了一下這將近一學期的項目經歷。具體會議記錄以下：

設想和目標

• 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

咱們的網站所要解決的，就是爲deep learning初學者或徹底未接觸過deep learning的人提供一個能夠直觀進行拖拽編程的平臺，幫助他們快速、直觀地理解pytorch，並進行簡單的練習。典型用戶與典型場景在網站設計階段都已明確，具體連接以下：VisualPytorch功能規格說明書

• 咱們達到目標了麼？原計劃功能作了幾個？按照原計劃交付時間交付了麼？

核心功能是所有實現了的，如：拖拽搭建模型、生成代碼。但優先級沒那麼高的功能實現上稍有出入，如：本來計劃實現論壇功能，讓用戶能夠在網站上進行發帖、回覆，從而能夠討論解決本身的問題，但後來以爲這個功能並非十分必要，就沒有完成。取而代之的，咱們完成了用戶搭建的模型能夠保存在本身的帳號中，下一次使用時能夠調用再進行修改；生成的代碼下載到本地的功能，咱們以爲這些功能可能更符合用戶的需求。咱們所作的功能均按照原計劃的時間交付了。

• 原計劃的用戶數量達到了麼？用戶對重要功能的接受程度和咱們事先預想的一致麼？

咱們的目標是1000的訪問量、400的生成模型數，200的用戶註冊數。而截至2019.6.22，網站的訪問量爲170九、生成模型數爲491，用戶註冊數爲142，能夠說幾乎達到了原計劃的。爲了更好地讓用戶體驗咱們的所有功能，咱們寫了較爲詳細的幫助文檔，也提供了樣例模型，但根據推廣之後的用戶反饋來看，即便如此，對於沒有deep learning基礎或沒怎麼接觸過編程的用戶來講，仍然不是很好上手，由於即便咱們解釋了每一個參數的意義，他們仍是不太知道每一項是作什麼的。

• 有什麼經驗教訓？

經歷了Alpha階段的摸索，咱們在Beta階段和Gamma階段都作好了充足的設計，所以團隊推動效率也比較高，進展都比較順利，這也說明了一個項目想要順利推動，就必定要在設計上花足時間，印證了咱們Alpha階段的經驗是正確的。

計劃

• 是否有充足的時間來作計劃？

因爲在Alpha階段後期，開發和測試人員在工做時，PM已經開始設計Beta階段的功能，而在Beta階段的後期也是如此，因此計劃的時間仍是比較充足的。

• 源計劃的工做是否最後都作完了？

如上文所說，咱們計劃的功能稍有變更，或者說是更新，但全部功能均定期完成了。

• 有沒有發現作了一些過後看起來不必或沒多大價值的事？

咱們詢問了開發與測試人員，你們均覺着所作的工做是必要的，並未浪費精力。

• 是否項目的整個過程都是按照計劃進行，項目出了什麼意外？

在Alpha階段的初期，前端開發與後端開發溝通出現了些不暢，前端不清楚後端的具體接口，致使沒法推動。咱們在當天召開緊急會議，明確了全部的接口，並約定如出現調整，及時作好溝通，也保證了項目的順利推動。

在Beta和Gamma階段，咱們並未遇到什麼問題，整個項目過程都是按照計劃進行的。

• 在計劃中有沒有留下緩衝區，緩衝區有什麼做用？

在Beta和Gamma階段咱們吸收了Alpha階段「極限操做」的教訓，在安排工做的時候留下了充足的緩衝區，給測試人員測試、開發人員修復留足時間，同時也正由於咱們留下了緩衝區，纔可以應付像5月22日被刪數據庫這樣的攻擊。

• 若是歷史重來一遍，咱們會作什麼改進？

根據咱們目前對軟件工程的認識，咱們以爲計劃方面不管是項目設計、仍是人員分配，咱們都達到了咱們所能想到的標準，所以也沒留下什麼遺憾。

資源

• 咱們有足夠的資源來完成各項任務麼？

因爲咱們在有7位組員，所以人力上是比較充足的。而華爲雲又爲咱們提供了部署網站的服務器，所以物力上也是比較充足的。此外，咱們還聯繫了北京理工大學和天津大學的同窗幫忙推廣項目，總的來講資源方面並不緊張。

• 測試的時間、人力和軟硬件資源是否足夠？美術設計和文案等難度是否低估？

在Alpha階段，測試人員是在最後兩天進行測試的，而這也致使工做積攢的不少、壓力很大。在Beta和Gamma階段，咱們改變了測試模式，讓測試人員隨着開發人員的進度進行測試，開發人員交付一部分代碼，就對其中的接口進行測試，這樣使得壓力就小了不少。文案方面，Alpha階段須要些的文案較多，壓力也比較大；在Beta和Gamma階段就不須要寫功能規格設計書之類的了，但須要編輯技術博客，但總的來講壓力還好。

• 有沒有感到本身作的事情可讓別人來作更有效率？

詢問了各位成員，你們均覺着本身較適合本身的工做，安排仍是較爲合理的。

變動管理

• 每位相關的員工是否都及時知道了變動的消息？

咱們平時的研究、商討會採用開會或在微信上交流的形式，比較重大的決定或變更，會在github上發佈issue，所以若是有變化你們均可以及時知道。

• 咱們採用什麼方法來決定「推遲」和「必須實現」的功能？

對要實現的功能作優先級排序，而後肯定在當前階段哪些功能是相對而言優先級較高的。好比在Alpha階段，因爲須要學習等等，因此優先實現核心功能：搭建模型和生成代碼；而在Beta階段和Gamma階段，則是實現一些輔助用戶、改善用戶體驗的功能，如能夠保存模型、下載代碼、樣例模型等等。

• 項目的出口條件（Exit Criteria）有清晰的定義麼？

在Gamma階段，咱們的目標是在以前的基礎上，加入導航欄的高亮顯示，參數框的右邊欄固定以及幫助文檔的細化和代碼的具體解釋。所以，咱們將這一版本的出口條件設置爲：

實現參數框的轉移，導航欄連接鼠標放置或點擊時高亮，幫助文檔簡單易懂，生成的代碼解釋清晰

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

對於突發狀況，咱們小組成員都是比較積極的，誰手頭沒有很急的任務，且可以解決突發狀況，就會主動承擔下。

設計/實現

• 設計工做在何時，由誰來完成的？

Alpha階段的設計工做是在Alpha階段初期，團隊成員開會共同討論完成的，Beta和Gamma的功能設計工做主要是由兩位PM協商擬定方案，而後詢問你們意見完成的。

• 團隊是否運用單元測試、測試驅動開發，或者其餘工具來幫助開發？

在項目初期，咱們畫了了原型圖，來更好地幫助前端設計。在Alpha階段，咱們沒有很好地完成單元測試，但在Beta和Gamma階段，咱們調整了測試模式，讓測試人員隨着開發人員的進度進行測試，大大提升了測試質量，也很好地完成了單元測試。

測試/發佈

• 團隊是否有一個測試計劃？

Beta階段和Gamma階段咱們都有測試計劃，以便於測試人員能夠隨着開發人員高質量地完成測試任務，並若是發現bug，也能夠及時反饋給開發人員。

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

由測試人員完成了正式的驗收測試。

• 有哪些測試工具來幫助測試？

pycharm、postman、fiddler

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

並無什麼意外發生。

總結

• 代碼管理的質量具體如何提升？代碼複審和和代碼規範的質量應該如何提升？

1. 在Alpha階段的總結中，咱們但願在Beta階段要把代碼的管理碎片化，咱們組的開發人員習慣完成一大塊功能統一進行commit，但這樣並不利於開發，下一階段咱們會統一要求開發人員在天天進行工做後，哪怕是很小的一個功能，也要進行commit。而這一點咱們在Beta階段和Gamma階段都作到了。
2. 同時咱們也嚴格按照代碼規範執行，由於已經撰寫了相應的文檔，咱們會按照文檔進行代碼規範的管理。

• 整個程序的架構如何具體提升？如何經過重構等方法提升質量？

咱們組認爲經過重構的方法來提升工程質量，是一種不得已而爲之的方式，耗時耗力，還會大幅度地延緩項目進度。局部的重構是能夠接受的，但項目總體的框架，是一開始就設計好的。

• 其它軟件工具的應用，應該如何提升？

咱們組目前開發在使用：pycharm、sublime和postman，測試在使用：pycharm、postman、fiddler，這些工具都足以支持咱們開發和測試。

• 項目管理有哪些具體的提升？

以前咱們發佈的issue還不夠十分具體，有些issue工做量較大，在Beta和Gamma中，咱們將issue分割成了一個個工做量較小且大體相同的小任務，方便你們完成並close任務。

• 項目跟蹤用戶數據方面，計劃要提升什麼地方？例如如何知道每日活躍用戶等。

咱們是在一個統計頁面展現天天的訪問量，但咱們發現咱們的網站在推廣的日子訪問量能夠達到400+，但在平日訪問量可能只有10左右，咱們分析緣由多是咱們的產品對用戶而言壽命並無那麼長，用戶嘗試過就不會再去使用，這也是咱們須要反思的問題之一，如何才能使得用戶習慣、依賴本身的產品。

• 項目文檔的質量如何提升？

咱們認爲要隨着項目推動，設計和開發的進行，不斷地更新文檔，一方面是爲了可以記錄項目的變化，另外一方面若是之後有別的團隊來接手咱們的項目，有了詳細的文檔也更方便別人理解項目。

• 對於軟件工程有什麼心得體會或不一樣意見？

• 大娃：

  Beta階段是代碼量相對較多的階段，因爲一開始設計的緣由，致使Beta階段的大部分代碼不得不重寫，以及不少代碼從軟件工程的角度來說都很不規範因此進行了重構。而在Gamma階段，新加入的代碼主要是有關注釋以及修正之前存在的若干bug。總的來講，經過這兩個階段，讓我明白軟件工程最重要的東西仍是設計層面，一個合格的項目其設計必定要完美考慮可擴展性和兼容性，這點我這部分的代碼一開始沒有想清楚因此繞了不少彎路，因此還算是收穫頗豐吧。

• 二娃：

  在Beta階段咱們處理了不少Alpha階段遇到的問題，包括進行人員的調整、對任務進行了更加明細的分工以及單元測試跟進開發過程等，雖然表現出來對團隊開發任務的不熟悉，可是在Beta階段咱們已經作出了很好的調整，團隊之間的協做能力也是大大地提升了。咱們在Beta階段有明確的須要實現的功能和完成的目標，也有在此基礎上若時間剩餘進一步的優化發展，同時小組成員們若是有問題均可以提出召開例會，在Beta階段咱們開發過程的效率比Alpha階段提升了不少，同時因爲不是最後才進行測試任務，測試人員的工做壓力也不是積累到了最後一週，狀況好了許多，所以Beta階段的完成度是很高的。

  在Gamma階段，咱們有了更加成熟的方法，小組成員們都有本身在此階段想要添加的功能，所以咱們聽取了各個成員的建議來分配工做，在Beta階段的基礎上作了許多優化方面的功能，同時也但願讓初學者可以更快的入門咱們的網站，作了許多引導性的優化內容。開發任務和測試任務的工做量都不是很大，可是卻極大地優化了用戶的體驗，所以咱們也意識到時間要用在刀刃上。

• 三娃：

  Beta和Gamma階段的項目推動總的來講走上了正軌，你們都循序漸進地完成好本身的任務，節奏比較舒服。

  值得一提的是在5月22日的那次數據庫被入侵，慘遭刪庫、只留下一個warning勒索信，並要求支付0.1比特幣來恢復數據庫。咱們的解決辦法是最簡單的從新搭一遍數據庫，但過後咱們分析，畢竟咱們只是一個小團隊的小項目，且不是盈利的，而若是在公司裏出現了這種狀況，那怕是隻能花錢消災了，這也引發了咱們對安全的重視，引入了郵箱驗證功能。

• 四娃：

  Beta版本進行了功能的拓展，整體上比較順利。Beta版本最大的問題，是拓展了功能的狀況下，如何保持接口設計的完整性與功能上的完備性。除此以外，Beta版本中文檔更新不特別及時。不過Beta版本中，對於代碼風格的管理以及用戶權限的管理作的仍是比較不錯的。

  Gamma版本工做量比較小，咱們作的比較多的工做在於宣傳和整理完整的教程。Gamma版本中較大的改善了用戶體驗，反向較好。

• 五娃：

  相較於Gamma階段，Beta階段的任務量稍多一些。在正式開始Beta階段前，咱們先開會討論了本階段所要實現的基本需求，而後進行了任務的分配。基本也還順利，把主要的需求都實現了，可是也有一些彈性的變換，例如最初討論的反饋功能，在實現過程當中綜合技術難點、需求迫切度、需求的必要性以及你們的時間充裕度等因素，咱們去掉了該功能，選擇去專一更重要的功能。

  到了Gamma階段，任務稍少一些，主要集中在宣傳推廣和幫助文檔的撰寫上。

  兩個階段下來，感受咱們好像是忘記了初心，在這個階段，我曾思考過咱們項目的最初目的，是要實現一個可視化的神經網絡代碼生成的網站，那麼最核心的應該是如何生成代碼，以及生成代碼的正確性，但是後面的工做好像是有些忽視了這個功能，主要集中在了功能的拓展和前端的優化上。可是轉念一下想，感受咱們這麼作又是有很大的緣由的，由於這是一門課，前端作的差，功能少，那拿什麼去展現呢，正確性好像是個看不到摸不着的東西，而所謂的用戶友好界面和功能添加倒是實實在在擺在那裏的。

  我之因此沒有在開會時說過開發重心偏移的事，是由於這個自己並很差作，我本身也許並無這個能力和精力去作，而且這是一門課，那也就更沒有提的必要了。

  要偶爾回頭看看，看看初心是什麼。

• WF：

  Beta階段是咱們的網站進階的重要階段，重點在於對初期版本的改進以及重要的功能擴展，Gamma階段則主要進行維護和相應的優化工做，工做量相對前面而言要輕一些。在這兩個階段中，本身學到了不少東西，積累了更多的經驗。

  我在Beta及Gamma階段的任務主要是對項目進行測試，在開始時，會有一些吃力，但隨着對項目的深刻熟悉，本身對項目各方面的測試工做也逐漸上手，總分體驗到了"作中學"的感受，在這一過程當中，本身對項目的細節把控和對項目的總體把控能力也獲得了必定的提高，這是一份巨大的的收穫。

  這兩個階段中，咱們各司其職也互相幫助，總的來講團隊的工做須要每一個人的付出，也離不開每一個人的相互支持。

• 七弟：

  Beta及Gamma階段的任務相比起開發階段及Alpha階段輕了許多，重點在於網站的功能擴展、維護、優化和bug修復，在這一過程當中本身積累了更多的開發經驗。我在Beta及Gamma階段的任務主要是幫助文檔的撰寫以及前端的優化，在這一過程當中，本身精進了本身撰寫文檔的能力，同時還提升了本身前端開發的能力，積累了很多的經驗，算是有必定的收穫。而在這一階段中，咱們的網站也發生了一次意外，咱們的數據庫數據曾被入侵併刪除了數據庫數據，所幸數據庫並未儲存大量數據，咱們儘早對數據庫進行了恢復，這一次事故也讓咱們明白了網站的安全維護的重要性。

• 成員之間互道感謝（23333）

• 大娃：

  感謝四娃的幫助：在如何使用git來進行代碼管理這件事情上，我之前並無這方面的意識，也是四娃在這方面給了我不少啓示，規範了本身平時的習慣

• 二娃

  我感謝四娃對個人幫助，由於在Alpha階段的時候，我有不少不太懂的事情，對PM所須要作得工做不是特別的瞭解，在先後端交接的過程當中出現過不少的問題，可是在他的幫助下，咱們團隊的項目算是比較好地完成了各個開發和測試的任務，最後他部署到了服務器上，因此我比較感謝四娃。

• 四娃

  我感謝三娃、七弟對個人幫助。三娃做爲PM和我能交流的比較多，也商討了不少實現上的流程。七弟與我一塊兒完成了前端的工做，整體上來講作的還蠻好的。

• 五娃

  我感謝四娃對個人幫助，由於在我轉去前端的時候幫助我快速瞭解前端框架。

• WF

  我感謝三娃對個人幫助，由於某個具體的事情：由於本身是新加入的，在熟悉項目上我遇到不明白的地方時，他老是耐心地給我講解說明，幫助我快速融入團隊。

• 七弟

  我感謝四娃對個人幫助，由於某個具體的事情：在開發過程當中，因爲我水平能力較差，我在前端開發的過程當中存在不理解的問題，好比後端架構的問題，他對我進行了詳細的講解，幫助我理解，來完成文檔撰寫，還有在前端開發中，好比輸入框的實時監聽問題，我難以解決的問題，他也想辦法幫我解決。