老師布置的閱讀任務雖然是附加的作業，但是對我來說是個很好的學習機會。軟體工程主要是對工程的開發進行學習，畢竟在學校老師教了那麼多的知識，我們課下做了那麼多的練習並沒有提高我們做乙個工程的能力。乙個專案乙個工程不僅僅是編寫**，除錯，簡單的測試，通過閱讀《移山之道》這本書我對開發專案有了乙個全面的了解。
因為之前接觸的程式設計的書不是很多，有很多東西不熟悉，讀了這本書以後有很多的收穫。也是通過這本書我才了解到開發乙個軟工專案的團隊中原來需要這麼多人員的協調，並不簡單的是有人寫**有人測試就行了。對於乙個產品，團隊需要有pm
建立乙個使用者和開發者之間的橋梁進行溝通，使用者說出自己的需求，開發團隊才能根據需求完成相應的任務。團隊的每個人之間的聯絡也是
pm或者說是
leader
建立起來的，沒有乙個好的管理者乙個團隊是無法完成任務的。而開發團隊中的程式設計能力強的人不少，但是他們之間的合作是能否高效完成任務的關鍵，遇到問題時是否能冷靜下來處理問題而不是堅持自己的意見不退讓，對於合作專案中的**，是否有
share
的思想，可以客觀的分析出自己**中的問題。
我產生的疑問：
1.pm不熟悉現階段專案用到的技術，無法準確控制開發的時間和進度，
dev leader
懂技術懂**但是隊員的水平參差不齊，有些事情只有
leader
能解決，這時候該怎麼辦？
答：我認為這時候解決問題的最好方法是leader
在對專案工程進行一些問題修復的時候讓全隊旁觀，相當於每次的工作都是一次教學，畢竟大家的磨合才能使團隊進步。如果水平的不足是既定的事實了，那麼只好尋找方法去彌補。
2.如果團隊裡遇到了技術很牛但是合作精神逐漸才發現很糟糕的人該怎麼辦。如果此時找不到任何能接替他的技術人員了，是放棄他還是放棄專案？
3.複審的意義是什麼？對於一些牛人的**，是否還有必要進行複審？
答：人無完人，再牛的人在編寫**的時候都有可能會犯一些細小的錯誤，讓別人複審不是對於程式編寫人員的不信任，而是希望對方能夠完善自己的程式，從中發現自己在編寫**時的問題，避免今後錯誤再犯。
提出這些問題的原因是我在看到很多團隊專案的實踐過程中，技術已經不是完成乙個專案的阻礙了，乙個團隊之所以會出現各種各樣的問題多半是因為每個人的性格不同，不能互補或者協調而造成了矛盾。團隊的合作不僅是技術上的互補更是每個人性格的協調，這樣才能使1+1大於2.
讀《移山之道》 dcc
最近終於完成了周欣老師的 移山之道 這本書，說一下自己的一些感受吧。首先，不得不說的是這本書的書寫風格，以前我印象中關於計算機方面的專業書籍肯定是枯燥乏味的，如果你讀著一本關於計算機的著作而沒有睏意，那麼這本書寫的就相當不錯了，但是 移山之道 這本書卻不是這樣，最初讀到引子的時候我有點兒摸不著頭腦，...
《移山之道》讀後感
移山之道 讀後感 老師布置的閱讀任務雖然是附加的作業，但是對我來說是個很好的學習機會。軟體工程主要是對工程的開發進行學習，畢竟在學校老師教了那麼多的知識，我們課下做了那麼多的練習並沒有提高我們做乙個工程的能力。乙個專案乙個工程不僅僅是編寫 除錯，簡單的測試，通過閱讀 移山之道 這本書我對開發專案有了...
有源則至清 我讀《移山之道》
引子 還沒想好怎麼個調整法子，書就到了手上 還沒看到第一頁，書就被同事搶去了。有些事往往如此，來也沒個準備，去也沒個準備。不過這被同事搶走的事實，讓我知道 無論如何，這一定是一本受歡迎的書。一 vsts之源 msf 問渠哪得清如許，為有源頭活水來。書的開篇便解了我久久以來的疑惑 如何把一本書寫清楚。...