對軟件工程M1/M2的總結。

　　我在團隊里面的職責為PM，這學期一路走下來，對于一個工程項目的制作運營、團隊任務的分配管理、項目進度的控制有比較深刻的體會。

　　在嘗試去開始一項工程時候，我們需要去明確自己的目標和需求，這是整個工程能否完成的基礎，也是程序的基本目標。一個明確的需求能讓開發減少很多不必要的麻煩，這也是我們團隊在M1時做得不太充分的地方，雖然后面修正了，但也浪費了很多不必要的時間。當然，在M2階段，我們做的第一件事就是去明確用戶的需求。這讓我們在M2階段少走了很多彎路，直達目標所在。

　　在明確的需求指導下，可以設計出各種任務，我在M1剛開始的時候是把任務分配成幾個大任務，讓團隊人員以結對編程形式去完成。但我在后來發現一個問題，就是有的人編程能力強，能很快完成任務，但有些人并不是能力不行，就是比較懶，這是我沒有考慮進去的因素，導致中期有些任務進度比較慢。后來在M2階段，我讓結隊的組合改變了一下，讓一個能力強的帶上一個比較懶動手的，相互督促，能讓項目完成速度加快。

　　在M1階段，我對TFS和燃盡圖不太熟悉，并不覺得它有什么特別大的用途，老師讓我每天去操作和寫博客，我也只是去照規定做，感覺還是一知半解。在M2時候，再一次在TFS建立起任務，感覺比起M1要熟悉不少，后面把燃盡圖的模板換成老師一直想讓我們貼的那個，燃盡圖就變得好理解了。任務的進度和項目的狀態能很好地反映在燃盡圖上，我也理解了為什么老師需要我們項目的燃盡圖，的確能夠從燃盡圖中獲得很多項目進展的情況和信息，也能看出項目進行時候的問題所在。

?

以前提問題的博客鏈接：http://www.cnblogs.com/Linhs/p/4027274.html

• 對于問題2：PM在一個工程項目中需要做的事情很多，是團隊中的樞紐， 雖然看著阿超他們間的對話簡單，但在實際中PM需要兼顧的事情應該有哪些？該如何溝通團隊形成整體？

　　自己想回來這個問題，還真是巧合，自己當上了PM，對這個問題也有自己的理解了。我在項目中的形象可以說是一座橋梁，建立用戶或其他團隊與我們團隊的開發人員之間的聯系，需要兼顧的事情有許多，包括將用戶的需求反映為我們的任務需要，并把任務分配給開發人員。同時了解每個任務進展以及整個項目的進度情況，考慮需要和團隊成員情況、任務進度等因素增減修改任務。像我這個學霸項目，多個團隊合作，我還需要提供需求，讓爬蟲團隊進行實現。基本是開發和測試外的所有事情都需要你去接觸。

　　至于與團隊溝通，其實并不難，團隊的隊員都是比較熟悉的人，交流并不困難。不過pm需要不斷督促開發人員工作，不然你會發現他們的任務速度都是慢悠悠的。

• 對于問題3：敏捷開發的到底是什么呢？

　　敏捷開發，可以說我們在整合階段遇到許多問題都是用敏捷開發來解決的，站在我的角度上，當我獲得了用戶的新需求或需求變更，我只按照用戶所給予需求去做這個項目，去新建或修改任務，不會想著去設計一些其他的功能擴展，這只會徒增開發人員負擔而且減緩開發速度。當用戶有新的需求，我再去滿足，迅速修改項目任務。這便是敏捷開發，追求的是開發速度，也就是快速開發。其實這樣對于我們開發和設計人員要求也是蠻高的，我們要快速響應需求，在原有的代碼基礎上作出修改，所以我們在開始的設計和開發的時候都需要為后續的修改做好準備，代碼的規范化，模塊化，面向對象，高內聚低耦合都是需要貫通整個項目的思想。

• 對于問題4： 關于團隊開發時，注釋是必須的，但是注釋量應該如何衡量？是否應該考慮團隊中人員的理解能力？

　　對于這個，我們團隊也曾經討論過，注釋一般是書寫在自己修改和開發的模塊之中，需要保證在一些特別設計的新變量或者新方法的地方說明其含義和效果。

?

?新問題：

　　1.如果用戶在臨近發布時候提出的一些新需求，我們應該怎么對待？

　　　　（這種情況也是有出現過，我們一般的考慮是小需求趕工完成，大需求留作下階段解決。）

?

　　回頭看之前所讀的幾篇文章，也能在我們項目中找到一點影子。其實我們在上一屆的代碼基礎上做修改，其中就有一兩個大泥球，雖然比較難懂，但是它能工作，也能用，所以我們也沒去怎么動它，讓它遺留了下來。這也許是不足之處，但我們也沒辦法，因為沒什么人喜歡讀，更沒人想去改，只是寫了些注釋上去，修飾了一番讓它好看了一些。現在想想，這種大泥球的確是比較惡心人的地方。同時也更加說明了文檔和注釋的重要性，任何程序員在看到一份沒有任何注釋的代碼都會產生一種厭惡的感覺，注釋和文檔是程序的重要組成部分，雖然寫起來麻煩，但是為了后續的測試和維護，這是必不可少的。

?

做了一學期的PM，我學到了這些階段知識點：

需求：需求分析要做好，之前我也提到過了，這是我們在M1階段學到的東西，比較深刻。

設計：設計要讓用戶方便使用并盡量滿足需求。

實現：實現要高內聚低耦合，能快速修改和擴展。

測試：測試需要盡可能覆蓋代碼，并參照模塊設計方案考慮盡量多的錯誤情況。

發布：發布及時，盡量能在定下的時間內發布，因為這也是用戶想看到的。

維護：留下盡量詳細的文檔，方便以后的維護人員理解程序代碼。

轉載于:https://www.cnblogs.com/Linhs/p/4214796.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的个人阅读作业3的全部內容，希望文章能夠幫你解決所遇到的問題。

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