讀《軟體工藝》的心得體會

1. 對於乙個少於100人年的專案，沒有必要採用軟體工程的方法，那樣只是會浪費太多的時間，採用軟體工藝的方法可能會更快、更高效的完成任務。 2.

在乙個專案開始之前，應該先考慮軟體工程是否適用。 3. 做乙個「足夠好」的軟體，是自己在給自己找做乙個低質量的軟體的藉口。

在乙個軟體裡面不可避免會有bug，但是這不能使我們放鬆對測試的要求，測試的目的是找到盡可能多的錯誤並加以改正。 4. 軟體工藝提倡的是從前的那種作坊式的開發模式，也就是乙個人要負責一塊，所有的調查、分析、設計以及最終的編碼都是由乙個人來完成的。

但前提是這個人一定是乙個非常優秀的人。 5. 軟體開發的分工帶來最大的問題就是導致了時間的浪費，因為交流成為了其中最重要的乙個障礙。

而且在交流的過程中還會造成很多的誤解，導致錯誤的發生。 6. 當前的軟體開發者是太多了，而不是太少了，因為優秀的人實在是太少了。

7. 單純增加人數是不可能完成任務的，因為優秀的人需要花費更多的時間來帶領新人，花費的這些時間都能夠讓其自己完成任務了，而且質量也會很高。所以說，5個優秀的人的開發能力要比加上20個新手的開發能力高很多。

8. 乙個人在專案中應該通過學徒到技師再到高手的途徑，但是時間不是一定的。只要具備了一定的技能就可以公升級了。

9. 作對日外包的工作，最終導致的後果就是所有的人都是最底層的學徒，沒有乙個技師，這樣的企業怎麼可能有成功呢？ 10.

作為乙個企業，應該將錢花費到最有用的地方，而不是作為乙個培訓班。 11. 學徒應該做的是看著技師如何工作，並從中學習，而不是要技師手把手的教。

12. 不要讓乙個人在學徒階段就因為工作的壓力而沒有時間學習新的知識，因為學徒學習的新的知識可能正是技師沒有時間學習的東西。 13.

如果在敏捷程式設計的過程中，能夠使乙個人帶另乙個人一起做，就可以充分發揮出各自的長處。乙個人有足夠的經驗和必要的技巧，而另乙個人有好奇心和懷疑而非形成定式的頭腦，那樣一定會有更好的結果。 14.

使用軟體來自動生成**而代替程式設計師的工作，只不過是乙個夢想，是永遠都不可能實現的。 15. 在軟體開發的過程中，最重要的乙個因素就是人，如果每個人都能夠做到全力以赴的進行開發，而且有很好的經驗和技巧，那麼就一定會是乙個成功的專案。

16. 乙個人在設計的過程中可能都要經過這樣的過程：不會->會一種方法->會多種方法->不會.

17. 極限變成成功的原因一方面在於搭建能夠大部分的時間用在實際的工作中，以及相關的測試中，而不是在紙上談兵。編寫過多的文件，只會造成在交流的過程中過多的浪費。

18. 人力資源經理應該是公司中乙個極為重要的角色，他的任務是為公司雇用少量的優秀人才，而不是大量的庸才。 19.

在編寫的軟體中簽上自己的名字是非常必要的，但是前提是所有的工作都是由乙個人來完成的，不僅僅是編碼。這樣才是公平的。 20.

在教學過程中，如果能夠根據自己的經驗，帶領學生對乙個專案的**進行深入的分析和理解，效果可能會比簡單介紹書本上的內容要好得多。