讀《移山之道》&《現代軟體工程講義》

件工程的個人閱讀作業，然後我就把鄒欣老師的《移山之道》和《現代軟體工程講義》讀了，還是有些體會的，這裡說一下。作為大學生，沒有真正的軟體工程實踐，必有目光短淺，言語欠缺之處。。

我主要想說敏捷這一部分，還有一些關於團隊角色的問題

敏捷

先說敏捷，英文是aglie，是一種現在十分流行的開發模式。敏捷開發的價值觀和之前的軟體工程的價值觀不同，如下：

Individuals and interactions over processes and tools
個人和互動 重於 過程和工具

Working software over comprehensive documentation
可用的軟體 重於 完備的文檔

Customer collaboration over contract negotiation
和客戶協作重於 合約談判

Responding to change over following a plan
響應變化 重於 遵循計劃

從其價值觀可以看出，敏捷開發強調變化和交流重於計劃和工具。這並非是否認計劃的重要性，而是敏捷更關注於前者，認為在開發過程中的變化對於軟體最終品質的影響，要大於項目起始階段就定下的各種條條框框；認為開發人員之間的交流商討，比單純的依靠優秀的工具更能提升軟體產品的品質。

那麼，如果一個軟體決定採用敏捷的開發模式，是不是就要完全地遵循敏捷的步子呢？這裡，鄒欣老師在講義中講到了兩種敏捷，其一是We follow an agile process，另一是We follow the Agile process。前者的意思是團隊比較靈活，而後者則是完全遵照敏捷的“章程”去行事。顯然，後者應該被捨棄，正如敏捷一詞的本意，靈活而快速，如果完全地遵照一個“章程”，何談靈活和快速？重在本質而非表象，不僅僅是在敏捷這裡如此，在其他地方有何嘗不是如此。

說了這麼多，敏捷的特點在哪裡？我以為，其最大的特點就是快速的迭代以及對於改變的包容性。在多次的迭代過程中，不斷修正問題，解決問題，應對變化，從而逐漸產生了一個優品質的軟體產品。

什麼樣的團隊可以使用敏捷模式呢？從《移山之道》和《現代軟體工程講義》中，以及自己的一些看法，我認為，團隊人數不多，成員之間相互熟悉、配合默契，技術上無大困難，成員負責任，成員瞭解敏捷的精髓等。

敏捷是萬能的嗎？顯然不是，而且顯然，對於軟體工程而言，不會出現silver bullet，任何方法都會有其長處和短板。這一點鄒欣老師已經在他的部落格中闡述了。在這裡，我有一個問題，這同時也是在鄒欣老師的部落格評論中，爭議最多一個問題——敏捷是否意味著可靠性低？“不高，容忍經常出錯”是部落格中鄒欣老師對于敏捷的一個看法，但是顯然下面的一堆評論對於這一點有很大的異議。還有就是，其應用範圍是什嗎？什麼樣的工程絕對不能使用敏捷的方法，而什麼樣的工程最適合于敏捷的方法？

對于敏捷，還有不少人對於其本身的理念就提出了質疑，比如@左耳朵耗子陳皓老師，自稱敏捷開發恐怖分子，他的一些文章比如《多些時間能少寫些代碼》寫出了一些他的看法。

角色

我這裡說的就是PM、Dev和Test。在這裡，我只是有幾個問題，希望能得到解答，至於體會，因為自己沒有經驗，單純的靠讀，說出的東西可能也只是一些沒有營養的東西。。

關於PM：負責溝通協調，掌握項目進度，PM的好壞對於軟體的品質有重要的影響。

關於Dev：團隊中最重要的一群人，在一個無老闆的團隊中，Dev應該是有權拍板的人（豬、雞、鸚鵡中的豬）。負責代碼編寫，並對自己的代碼進行單元測試，盡量不出Bug。

關於Test：負責找出項目中的Bug。現在，我有個問題，在我們當前的項目中，六個人，如果只有一個Test，那麼這個Test是不是應該對項目的整體都應有一個比較清楚的認識？正常Test按理說應該負責模組測試和整合測試，但是我們的項目的各個模組是不能整合在一起的（做後端的各個功能，不做介面），這是應該怎麼去做整合測試，還是說不做了？

就到這裡了。