對軟件工程M1/M2的總結(jié)。

　　我在團(tuán)隊(duì)里面的職責(zé)為PM，這學(xué)期一路走下來，對于一個工程項(xiàng)目的制作運(yùn)營、團(tuán)隊(duì)任務(wù)的分配管理、項(xiàng)目進(jìn)度的控制有比較深刻的體會。

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

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

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

?

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

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

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

　　至于與團(tuán)隊(duì)溝通，其實(shí)并不難，團(tuán)隊(duì)的隊(duì)員都是比較熟悉的人，交流并不困難。不過pm需要不斷督促開發(fā)人員工作，不然你會發(fā)現(xiàn)他們的任務(wù)速度都是慢悠悠的。

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

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

• 對于問題4： 關(guān)于團(tuán)隊(duì)開發(fā)時(shí)，注釋是必須的，但是注釋量應(yīng)該如何衡量？是否應(yīng)該考慮團(tuán)隊(duì)中人員的理解能力？

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

?

?新問題：

　　1.如果用戶在臨近發(fā)布時(shí)候提出的一些新需求，我們應(yīng)該怎么對待？

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

?

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

?

做了一學(xué)期的PM，我學(xué)到了這些階段知識點(diǎn)：

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

設(shè)計(jì)：設(shè)計(jì)要讓用戶方便使用并盡量滿足需求。

實(shí)現(xiàn)：實(shí)現(xiàn)要高內(nèi)聚低耦合，能快速修改和擴(kuò)展。

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

發(fā)布：發(fā)布及時(shí)，盡量能在定下的時(shí)間內(nèi)發(fā)布，因?yàn)檫@也是用戶想看到的。

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

轉(zhuǎn)載于:https://www.cnblogs.com/Linhs/p/4214796.html

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。