Alpha階段終于告一段落，我們的團隊也完整經歷了從提出設想、用戶需求分析，到開發、測試，再到部署上線、推廣的流程。“葫蘆娃不想寫代碼”團隊還是較出色地完成了Alpha階段的工作，4月25日晚，我們也一起坐在新主樓F座二樓的沙發上，第一次召開了一個超過一個小時的會議。本次會議沒有瘋狂地提需求和push，大家根據課程組提供的模版，細細回想過去的兩周多時間內，有哪些做得好的或不好的地方，選出了我們的super star去完成不得不做的轉會任務，也對Beta階段的工作做了大致的規劃。具體會議記錄如下：

設想和目標

• 我們預期的功能是否都實現了？按計劃交付了么？

由于我們的學習成本較高，開發人員對django和pytorch等內容不是十分熟悉，因此我們在Alpha階段前期花了較多的時間去學習相關內容，計劃只實現核心功能——拖拽搭建模型并返回相應代碼。核心功能我們是順利實現了的，除此之外，我們還實現了網站的訪問量、模型生成量統計功能。可以說，Alpha階段我們順利按計劃交付，還超額完成了任務。

• 原計劃的用戶數量達到了么？新的目標是什么？

我們的目標是1000的訪問量、400的生成模型數，而截至2019.4.26，網站的訪問量為1078、生成模型數為398，幾乎可以說是達到了目標。

• 有什么經驗教訓？

在產品設想方面，我們小組的Alpha階段估計的還是比較準確的，抓住了用戶需求所對應的核心功能，在第一個版本提供了可用的產品，而暫時擱置了一些開發優先級沒那么高的功能，利用好了團隊資源，也希望我們在Beta版本中，繼續對功能的優先級進行精確的排序，首先開發優先級較為靠前的功能。

計劃

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

由于Alpha階段的初期，開發人員在學習相關知識，同時PM就有了較為充足的時間來做計劃。而Beta階段的計劃，在Alpha階段后期我們團隊的兩位PM就開始進行相關規劃，因此Beta階段的計劃設計時間也較為充足。

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

如上文所說，我們對Alpha階段估計較為準確，因此所有計劃中的工作均完成了。

• 有沒有發現做了一些事后看起來沒必要或沒多大價值的事？

我們詢問了開發與測試人員，大家均覺著所做的工作是必要的，并未浪費精力。

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

在Alpha階段的初期，前端開發與后端開發溝通出現了些不順暢，前端不清楚后端的具體接口，導致無法推進。我們在當天召開緊急會議，明確了所有的接口，并約定如出現調整，及時做好溝通，也保證了項目的順利推進。

• 在計劃中有沒有留下緩沖區，緩沖區有什么作用？

不得不承認我們在Alpha階段確實沒有留機動時間和資源，萬幸的是一切都按部就班的進行，才保證項目的順利完成。在下一階段，我們會考慮這個問題，留下機動的時間，以免有突發情況導致滿盤皆輸。

• 如果歷史重來一遍，我們會做什么改進？

前端如是說道：如果歷史重來一遍，會對模型進行某些處理，然后將各個部件之間的關系存在數據庫中，然后生成代碼的時候通過關系返回代碼，而不是硬編碼，直接將生成的代碼存在數據庫中。

資源

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

由于我們在有7位組員，因此人力上是比較充足的。而華為云又為我們提供了部署網站的服務器，因此物力上也是比較充足的。

• 各項任務所需的時間和其他資源是如何估計的，精度如何？

各項任務所需時間和各項資源確實就是團隊成員在最開始計劃的時候，大家一起商討確定的，并沒有什么可靠科學的方法，而這些我們也在項目開發推進的過程中實時調整。

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

是足夠的，但各項文檔的難度著實......超乎我們兩位PM的想象......確實低估了這一部分的工作量。

• 有沒有感到自己做的事情可以讓別人來做更有效率？

詢問了各位成員，大家均覺著自己較適合自己的工作，安排還是較為合理的。

變更管理

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

我們平時的研究、商討會采用開會或在微信上交流的形式，比較重大的決定或變動，會在github上發布issue，因此如果有變化大家都可以及時知道。

• 我們采用什么方法來決定“推遲”和“必須實現”的功能？

對要實現的功能做優先級排序，在Alpha階段僅實現核心功能，在Beta和Gamma階段會陸續完善其他的功能。

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

Alpha階段的出口條件就是可以返回正確的、能夠運行的模型代碼。

• 組員是否能夠有效地處理意料之外的工作請求？

對于突發情況，我們小組成員都是比較積極的，誰手頭沒有很急的任務，且能夠解決突發情況，就會主動承擔下。

設計/實現

• 設計工作在什么時候，由誰來完成的？

設計工作是在Alpha階段初期，團隊成員開會共同討論完成的。

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

在項目初期，我們畫了了原型圖，來更好地幫助前端設計。但在后面開發的過程中，確實沒有做單元測試，主要問題出在Alpha階段沒有明確好這部分工作的歸屬上，開發以為這部分由測試來完成，但測試對代碼不了解又沒法進行。在Beta階段，我們明確了由開發進行單元測試，測試人員進行綜合測試，不會再出現類似的錯誤。

• 什么功能產生的Bug最多，為什么？

• 前端：放在畫布內的組件進行拖拽時，popover彈出框會出現各種各樣的問題，比如無法跟著一起拖動，甚至出現錯誤，主要原因是框架不支持跟著一起拖動。后來我們機智的開發人員，想出了一個解決辦法，就是在鼠標進行拖動的時候，就會觸發彈出框隱藏，從而達到跟隨移動的效果。
• 后端：沒什么大的問題，開發還比較順利。

• 代碼復審是如何進行的？是否嚴格執行了代碼規范？

代碼復審并不是十分嚴格，下一階段會考慮增加相應的制度，進一步保證工程的質量。

測試/發布

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

有關單元測試確實沒有相應的計劃，原因如上文，下一版本我們會改正這一點。綜合測試的計劃還是有的。

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

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

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

pycharm、postman、fiddler

總結

• 代碼管理的質量具體如何提高？代碼復審和和代碼規范的質量應該如何提高？

Beta階段要把代碼的管理碎片化，我們組的開發人員習慣完成一大塊功能統一進行commit，但這樣并不利于開發，下一階段我們會統一要求開發人員在每天進行工作后，哪怕是很小的一個功能，也要進行commit。

同時我們會嚴格按照代碼規范執行，因為已經撰寫了相應的文檔，我們會按照文檔進行代碼規范的管理。

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

我們組認為通過重構的方法來提高工程質量，是一種不得已而為之的方式，耗時耗力，還會大幅度地延緩項目進度。局部的重構是可以接受的，但項目整體的框架，是一開始就設計好的。

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

我們組目前開發在使用：pycharm、sublime和postman，測試在使用：pycharm、postman、fiddler，這些工具都足以支持我們開發。在下一階段，如果時間充裕的話，我們還會對前端進行美化，可能還會用到其他工具。

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

之前我們發布的issue還不夠十分具體，有些issue工作量較大，在下一階段，我們會將任務拆解為工作量小一些的小任務，也便于PM及時掌握開發進度。

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

目前我們是在一個統計頁面展示每天的訪問量，但我們認為這樣不是十分美觀，我們打算在Beta階段將其改為折線圖的形式。

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

我們認為在現有的基礎上，要更加詳細地撰寫文檔，我們一起學習了紅太陽團隊的文檔，找到了自己不足之處，也會在未來一點點改正。

• 對于軟件工程有什么心得體會或不同意見？

• 大娃：首先alpha版本已經結束了，心里也是松了一口氣。整個階段完成下來，也算是收獲滿滿，印象最深的還是懂得了時間調控以及設計規劃的重要性。我參與的是后端開發，大概就是對前端返回的數組進行特定的操作然后返回。其實這是一個很簡答的事情，如果只是為了完成功能的話可能只需要一兩百行代碼就能解決，但是考慮可擴展性、可讀性以及軟工所要求的代碼規范的要求，這就變成了一個很復雜的工作。我和另一個后端開發的小伙伴計算了一下，我們花在設計和思考上的時間大概占了70%，真正完成代碼這個過程相對不是很耗時間。這是一個很重要的收獲。
• 二娃：經過一段時間小組成員們的努力，終于讓ALPHA版本的Visual Pytorch上線了。雖然這個版本還有一些缺陷，但是核心功能基本上是完美地實現了。在整個開發的過程中，我們深刻意識到了團隊協作和例會的重要性。在開發網站的過程中，前后端的交互是極其重要的一部分，每次例會的召開都可以讓我們的主PM很好的把握前后端的進度以及遇到的問題，我們會一起商量出具體的解決方案。雖然我們小組成員都是第一次合作，但是效果比預計的要好。相信我們在后續版本的開發中，會繼續努力取得更好的成果。
• 三娃：軟件工程這門課程讓我第一次對自己感興趣了很久的一個工作：PM，有了初步的了解。不出意外，確實與自己想象中有一些差距，或者說，自己想象得到的只是PM的一部分工作。PM不僅限于策劃、提需求，還要對項目有整體的把握，要對項目進度有足夠的了解，同時還要在前后端之間、開發與測試之間起到溝通和協調的工作。可以說，軟件工程讓我有了實操經驗，這是十分寶貴的。在下一階段的工作中，我會與另一位PM一起，總結Alpha階段完成的較為出色的地方，對于我們自己做的不滿意的地方，我們會想出解決辦法，爭取越做越好。
• 四娃：1、每個成員的開發能力大同小異，經驗不太一樣。
  2、盡量選取學習成本低的架構或者解決方案，但是要保證可用性和可維護性，可拓展性。
  以前端的對于每個網絡的參數設置為例，采用的是bootstrap popover插件并自己改寫了一部分，缺點是可拓展性較差。目前的代碼如果網絡層在10個左右還可以維護，當網絡層數過多時非常不好，難以維護。
  3、restful api蠻好的，雖然在開始時設計有些難度但是構造的接口無論是測試還是請求，維護都方便。
  4、git分支管理方面完成一個小模塊就應該合并到主分支一次，不要一次合并多個commit。
  5、團隊成員多交流，一個人做容易進死胡同，大家都是非常優秀的同學，吸收別人的意見還是非常重要的。
• 五娃：Alpha階段已經結束，可以說團隊已經進行了首次較為成功的合作，從這次經歷中，學到了很多知識，也發現了自己的一些不足。
  • 萬事開頭難。面對將開發的項目，眼前是迷茫的，因為很多東西都是新的，需要從頭去學習，也不知道從哪里下手。不過幸運的是我不是一個人，我可以和隊友一起努力去克服這些困難，合作的時候也許就不會感到那么難了。
  • 代碼需規范。當一個項目是以合作的方式進行的時候，不規范的代碼就會體現出很多問題了，Alpha階段我們去了解了代碼規范，并且盡量去按照要求完成開發，期間確實感覺到自己以前寫的代碼都極丑無比了（一星期后怕是我自己都不認識了）。
  • 溝通交流是良藥。合作最需要的就是良好的溝通。比如，前后端的一些約定，以文檔的形式進行有效的交流，并且有問題及時解決改進，更新文檔，這樣就盡可能的減少在代碼合成的時候出現不一致的問題。
  • 摸索前行，小步快走，及時更正，也許是十分有效的開發模式了。
  • 現在該準備下一階段開發工作了，希望我們組能做的更好，覺得有一句話說的挺有道理的：一個人也許走的很快，但一群人會走的更遠。
• 六娃：在我們團隊中，我擔任的是測試人員這一角色，這也是我第一次在一個項目中專門進行測試工作。這次Alpha階段給我最大的感受就是切身體會Learning by Doing。初次做關于網站的測試，需要學習一些關于測試的知識，隨著開發組的更新，測試工作也要齊頭并進，有時候會因為測試工作不順利而煩心，影響工作效率。在今后的工作，我會調整好心態，利用第一階段積累的經驗，做好后面的工作。通過這一階段的測試工作，我學到了一些重要的知識，通過親自動手實踐學到的知識顯得更有價值并且刻骨銘心。
• 七弟：對我來說，我是借著軟件工程這門課才第一次體會到了團隊協作編程，過去自己所做過的工程基本都是靠自己一個人完成，而這一次的工程是我們組成員通過大家的協作來完成的，工程量和難度都是之前所做過的工程所不能比擬的。其實在ALPHA階段中，我個人認為自己的貢獻比例還是相對較小的，一個原因是由于很多知識之前沒有接觸過，需要花費很多時間來學習，由于與其他開發同學的能力水平的不同步，因此只能做一些相對簡單的工作。在后續階段的開發中，自己應以將所學知識用于實踐為主要目標，以提高自己的開發能力。

轉載于:https://www.cnblogs.com/1606-huluwa/p/10777860.html

總結

以上是生活随笔為你收集整理的【Alpha】事后分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。