閱讀《構建之法》

這個作業屬於哪個課程

這個作業要求在**

/homework/11813

這個作業的目標

讀《構建之法》，提出問題

學號20188400

是蟲子（bug），還是肉芽？不同的人有不同的答案。軟體行業也有一句著名的笑話：這不是缺陷，這是乙個功能！ ————p17

「任何乙個問題的產生，本身是沒有好壞之分的，但是為什麼會有的就不被care，甚至還會很喜歡，而有的會被吐槽呢？根本原因是因為產生了利益損失。」對於這個問題我深有體會，在我玩的遊戲中我也體驗到了很多bug，但誠然，有些並不影響到遊戲勝負的bug，並不會遭到玩家的反感。相反，有趣的bug也會增加遊戲別的方面的樂趣，不然從何得來「卡bug」這一說法呢？所以我覺得bug的存在是不可避免的，但我們程式設計師要做的，就是減少一些影響「遊戲體驗」的bug。

程式設計師小飛原計畫三天完成某個任務，他說服了同事，堅持採用自己獨特的實現方法。現在是第三天的下午，他馬上就可以做完。但是在實現功能的過程中，他越來越意識到自己原來設計中的弱點，他應該採取另乙個辦法，才能避免後面整合階段的額外工作。但是他如果現在就改弦更張，那就意味著公開承認自己的設計不好，並且會花費額外的時間，這樣他的老闆、同事也許會因此看不起他。如果他按部就班地按既定設計完成，最後整個團隊還要花更多時間在後續整合上，但那就不是他個人的問題了。怎麼辦?

我覺得小飛應該修改自己的設計，跟團隊隊員們交流自己的設計思路。要知道乙個團隊專案不是只需要靠乙個人，**整合階段才是最重要的。「現代軟體產業經過幾十年的發展，乙個軟體由乙個人單槍匹馬完成，已經很少見了，軟體都是在相互合作中完成的。——=《構建之法》」記得大二的時候我們分組進行課程設計，整個過程都很完美，但因為隊員之間的電腦型號，導致資料傳出來差強人意。答辯的時候老師也說非常可惜，可是若是推倒重來的話也是很費時間的。

所謂極限程式設計，就是把一些認為重要和有效的做法發揮到極致，在這層意義上，「極限程式設計」應該叫「極致程式設計」。

極限程式設計是一種軟體工程方法學，是敏捷軟體開發中最富有成效的幾種方法學之一。如同其他敏捷方法學，極限程式設計和傳統方法學的本質不同在於它更強調可適應性而不是可**性。xp的支持者認為軟體需求的不斷變化是很自然的現象，是軟體專案開發中不可避免的、也是應該欣然接受的現象；他們相信，和傳統的在專案起始階段定義好所有需求再費盡心思的控制變化的方法相比，有能力在專案週期的任何階段去適應變化，將是更加現實更加有效的方法。極限程式設計的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中，系統需求是在專案開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更—而這樣的需求變更在一些發展極快的領域中是不可避免的—將導致開發成本急速增加。

「本質上來說，pm其實就是乙個輪詢器：識別所有的專案風險，然後不斷跟進。專案風險可能是技術風險，比如某個技術上壓根搞不定的問題。也可能資源風險，比如人手不夠，或者開發者很多，但是沒有足夠的設計師協助，這些風險都會導致專案無法按時交付。乙個客觀事實是，所有專案都會變化，從售前到需求分析結束，專案的需求都在持續變化，如果不對**做相應的調整，極有可能會虧本。」pm要憑藉自己的能力，把使用者的需求展現成其他成員能夠理解和執行的語言，從而贏得同伴的信任和尊敬。

其實作為乙個軟體行業的專案經理來講不懂技術其實就是乙個最大的風險。對於軟體專案來說，每一步都需要確認，並且一定要做好範圍的控制，對於原型和ui，思維導圖之類的全部要做好記錄，這個是後面驗收的重要保證。

關於任務的劃分，確定可見性的交付物為里程碑，每次里程碑的交付物應該和客戶，自己的高層一同確認，記錄意見不接受意見。

然後專案開始對於研發必須完成今天的工作，這個也是最難的地方，如果說不懂技術的話，你會非常難把控現在研發的進度，這個時候需要你們公司研發部門的幫助。同時在專案一開始就要求所有人都加班吧，千萬別想著後面專案緊在加班，那就離死不遠了。

最重要的一件事情，管好產品經理，管好產品經理，管好產品經理。團建只是一方面，最關鍵的地方是控制需求，別讓產品帶著你們走，一開始就要確定什麼樣子的產品，過程中需求變更的處理才是保證專案是不是能正常上線的必要性。

閱讀《構建之法》

閱讀《構建之法》

閱讀 《構建之法》

快速閱讀《構建之法》 構建之法閱讀筆記01

相關推薦

閱讀《構建之法》

快速閱讀《構建之法》構建之法閱讀筆記01