軟體開發中如何保證軟體質量是很關鍵的乙個問題，但是乙個產品又要保證按時能夠上市。這明顯是乙個互相矛盾的問題，怎麼解決。在保證質量的前提下如何按時的完成產品的開發。書中提到了現在軟體開發中很多專案的乙個普遍方法，就是制定乙個周密的計畫，假定到某個日期必須完工，這種開發存在於許多軟體公司。有句話說「存在即合理」，所以這種開發模式肯定有它的道理，比如說產品要搶占市場，客戶要在某個時候使用等等。那麼這樣的軟體質量如何那？一般會有兩個結局，第乙個在質量合格的情況下按時的上市。還有乙個就是漏洞百出的軟體也及時的上市了。這裡不能按時出來產品，這個結局往往是人們無法接受的，這裡也就不說了。那麼第乙個結局是在什麼情況下出現的哪？首先做這個產品的公司，必定已經做過很多類似的產品，積累的豐富的經驗，並且開發這種產品的工程師們，必定也對這個產品瞭如指掌。這種專案計畫成功自然就不足為奇。第二個個結局往往是出現在一些規模比較小的公司，同時這個產品是一款創新的產品，並且該公司幾乎沒有開發過此類產品的經驗。最關鍵的是工程師們也沒接觸過此類產品的開發，甚至連這種產品需要的開發工具和開發語言都不熟悉。那麼針對第二種情況，傳統的開發方式勢必會影響軟體的質量和上市的時間。
不管是軟體工程領域，還是其他任何工程領域，都不能把一些傳統的理論奉為圭臬。俗話說盡信書不如無書，做任何事情都要因地制宜，實事求是。針對一些創新軟體的研發，搬照傳統軟體的開發方式往往會功敗垂成。那麼照這樣講，開發這些創新型的軟體，就不要制定時間了，當然也不是，否則這個專案將會遙遙無期，任何公司也不會對乙個遙遙無期的產品投入任何精力的。書中就提到了這種產品只能及時的完成，不能按時的完成，所謂的及時就是在合理的時間，軟體質量達到乙個合理的要求時開發出這個產品。那麼要達到這種及時完成，我們又該怎麼做那。下面就結合書中的理論，談談自己的一些想法。
如何做擺在了面前。有些人就會想，既然對開發這種型別的軟體產品不了解，那麼拿到需求就開始編碼麼，先做出來乙個原型再說。然後出來了原型再在上面進行迭代，這種極限開發方式現在的很多小公司都在採用。但是可以想象這樣的軟體出來的質量會是如何？別說質量，極有可能你在迭代的過程中，軟體的**根本就沒辦法再重構或者利用了怎麼辦？一些目光短淺的產品經理，看到手下的程式設計師一拿到需求就開始編碼，心理感覺很好，覺得員工工作都很賣力。但是看到一些員工在看一些其他方面的書籍，或者即使是和產品相關的書籍，但是沒有投入這個產品的開發中，就認定這種員工沒有責任心，時間這麼緊迫還要幹其他的事情。可想而知這樣的產品經理是根本不會花時間，來培訓手下的工程師，即便是讓他們熟悉常用的開發工具的時間都不給。一開會必定是談論產品什麼時候能出來，產品計畫制定的如何？這種產品經理要麼是不懂軟體技術開發的，要麼是腐朽型的古董經理，讓他們與時俱進真的很難。他們不願意在提高軟體質量上做任何投入，但是他們往往會這樣說一定要保證軟體質量的情況下，按時交付產品，真***的天方夜譚。
前面說了這麼多，每條基本都是錯誤的路線，那麼正確的方法又是如何那？乙個有遠見的產品經理，拿到了這種創新型軟體的需求時，肯定不會一上來就跟自己的手下，談論專案什麼時候完成，而會讓工程師們自己看，同時讓他們討論下開發此產品可能遇到的風險。這時的產品經理起到的就是裁判的作用，只做最後的決定，其他時間就是聽。不管最後決定什麼時候敲定，但是這樣的產品經理第一步肯定就是讓工程師們學習、培訓，他很樂意花時間和精力來培訓他們的工程師們，不管是開發的環境還是開發用到的語言，都要很細緻的學習。因為這樣的產品經理知道這是保證軟體質量的根本，必須要做。這裡提一下，在軟體工程領域，如何學習新的技術和開發工具，在人間集這本書中也有詳細的講解。等下在後面的段落裡也會提到。這裡只是提一下，現在言歸正傳。那麼在工程師學習的過程中，自然就會間接的解決了產品中的一些技術問題。這時可以下結論了麼？當然沒有定論，但是這是的結論就**不離十了。這時就自然可以用xp（極限程式設計）的開發模式進行開發，這樣開發出來的產品，才能在原型的基礎上進行迭代，進行重構。否則只是在浮沙上築高台。只有這樣，開發出來的產品才能保證軟體質量，並且能夠及時的上市。這裡的「及時」可能是原型的第一代也可能是第二代，這就要看市場的需求了。
最後說下如何快速有效的學習，這裡又是乙個矛盾，要快速怎麼有效。其實我們這個世界就是乙個矛盾的世界，關鍵是我們怎麼合理的處理這些矛盾。那麼軟體領域怎麼快速的學習，第一，傳統方法不能放棄就是閱讀書籍，但是軟體領域又有它的特殊性，其中google，論壇都是這個領域獨特的學習地方。通過傳統的方法結合這些特殊的方法，相信自然比其他的領域學習要快速。那麼怎麼有效那?我覺得這本書中有句話講的非常的經典：「理論只是把東西簡單化，其實實踐起來是很複雜的」。這句話我深有體會，特別看一些程式設計方面 的書籍，比如拿物件導向的思想，看這些理論很簡單，不就是把現實中的物體，物件抽象成程式中的類麼？有什麼難那？對很正確，是這個道理。但是如果你真動手起來程式設計可沒有那麼簡單。所以實踐太重要了，千萬不要眼高手低，什麼東西一看覺得這麼簡單，你要時刻提醒自己，理論只是把複雜的東西簡單化了，親手做吧，裡面的難點還很多。小到乙個簡單的工作，大到乙個決策的制定。都是這個道理。這裡抨擊一下中國的大學教育。中國的大學教育存在嚴重的眼高手低的現象，覺得很多理論很簡單不就是這麼回事麼？所以根本不注重實踐。說到底，理論只是用來指導實踐的，所以為何說理論簡單那，就是因為他只是給你指明了乙個大的方向，就像紅軍長征一樣，目的地是有了，但是你要走下去可不是一件容易的事情。所以說，要用理論指導實踐，學習任何東西都要遵循這個原則。現在想想高中時學習那些數學，物理理論那麼的簡單，還整天不停的練習，不停的做題目。但是到了大學數學和物理的理論變複雜了，我們的人，反倒是沒人願意練習和做題目了。這就是為何在學術界，國內很少有人能在世界上有影響力的原因了。其實講了這麼多，自己能做到又有幾點那？所以自己今後也要加倍的努力。
讀「人件集」有感
軟體開發中如何保證軟體質量是很關鍵的乙個問題，但是乙個產品又要保證按時能夠上市。這明顯是乙個互相矛盾的問題，怎麼解決。在保證質量的前提下如何按時的完成產品的開發。書中提到了現在軟體開發中很多專案的乙個普遍方法，就是制定乙個周密的計畫，假定到某個日期必須完工，這種開發存在於許多軟體公司。有句話說 存在...
人件有感1
看 人件 這本書，發現書中基本沒有涉及到任何軟體技術，但作者精闢的 了專業軟體團隊管理這一非常專業的話題。怎麼把團隊做好，這是乙個大問題。只有做好團隊，才能做好軟體。我看書上說大多數管理者坦承，他們對於人的擔心，更甚於對技術的擔心。在這方面作出努力，只是總是以關注技術為主。從事新技術的人，總是以為自...
人件有感3
今天繼續分享讀人件的想法，人件 提到了軟體管理中的七個不真實期望，我覺得總結的很到位，舉其中幾個來說。1 有使你的生產力劇增的新訣竅，你已經錯過了 沒有什麼是錯過的其實是他不存在的，是一種營銷的手段說法罷了 2 其他經理的成效是正100 200 或者更多 就想我們經常自己恐嚇自己別人的學習效率是自己...