專案組採用
xp的實踐開發已經有乙個多月了，主要是採用了測試驅動開發，重構，結對程式設計，還要引入持續整合。經過這麼長時間的實踐，我覺得組建敏捷團隊，開始敏捷開發的最關鍵問題是要統一價值觀。
測試驅動開發
我發現實際上掌握這些實踐其實並不是最困難的，比如測試驅動開發，雖然我也是個初學者，但是我知道，只要經歷乙個學習和實踐的過程，我們就能掌握這項技術。我們使用
junit
測試，最開始將整個
spring
框架和hibernate
一起都測試了，後來發現這樣做是不對的，單元測試應該不依賴於框架。於是我們改了。這個很容易改。
可是我發現比較難改的是大家編寫測試的習慣。雖然使用著
junit
，但是他們依然會在產品**編寫完之後寫測試，而非在其之前；他們依然是寫了大量產品**之後寫測試，而非寫一點測試，寫一點產品**。起初我覺得是因為大家不明白測試驅動開發的好處，因為先寫測試有以下幾個好處： 1
、單元測試是需求說明書 2
、單元測試是使用者手冊 3
、幫助設計 4
、有助解耦 5
、觀測效能 6
、界定特性是否完成 7
、系統整合出現問題便於排錯 8
、是重構的保護傘 9
、在大多數情況下不需要除錯，只需要測試，節省時間 10
、提高產品質量
應該還可以舉出很多好處，這些在很多著作，討論中都已經重複千萬遍了，不必細說，重點是，我發現即便人們都明白所有這些，但是依然會回到過去的方式。我覺得其根本問題在於對於敏捷背後的兩個價值觀他們是不認同的：重視質量和小步前進。他們並不認為質量對於系統的開發會有怎樣的作用，認為質量是無關緊要的。質量的重要性其實已經不需要說了，
fowler
等人的論述已經夠多了，可是他們依然還是堅持自己的觀點，這類人有以下幾個表徵： 1
、認為測試驅動開發會增加成本。因為他們覺得測試驅動開發時編寫的測試是多餘的，如果不採用測試先行，這些測試是可以不編寫的。這實際上是對質量的不重視。 2
、認為測試指令碼和測試資料是難以編寫的。因為他們覺得使用完整的一套測試資料來進行測試是不可行的，而在我看來這是必須的，使用者必須提供平時他們使用的典型資料來進行測試，以保證質量。 3
、認為有了整合測試和使用者測試，就不需要單元測試，這樣做是非常冗餘的。
誠然，qa等級和軟體成本是掛鉤的，但是單元測試保證的質量應該是必須的。
如果上述觀念無法達成共識的話，
tdd中所說的，當遭遇失敗時，首先寫乙個測試，對於他們而言就更是天方夜譚了。
重構
雖然我們使用eclipse內建的重構工具完成一些典型重構，比如抽取介面，rename，move，提取方法等，但是為什麼要進行重構的價值觀卻很難建立。具體現象是：
1、在**很混亂的情況下繼續新增新的**，而不是考慮先將**重構
2、認為重構會降低開發效率
我覺得其背後隱藏的依然是對於敏捷價值觀的不認同：重視質量和簡單。
他們通常覺得只要能執行就不要去破壞它，質量問題是最後要考慮的問題（有一部分人還會將重構和效能調優畫上等號）。
重構可以獲得乙個簡單的設計，而簡單設計意味著沒有重複，有充分理由的依賴關係和繼承體系。可是我發現，沒有重複這樣一件事情，就很難達成共識，有的人認為重複**是**重用的一種方式。
結對程式設計
結對程式設計的有效進行也對於提高質量和使設計簡單有同樣的好處，這個不必細說。
問題還在於大家是否對於這兩個價值觀認同。
以人為本
在fowler的《新方**》中，fowler認為敏捷最重要的兩個特性之一就是以人為本，而非以過程為本。如果聽到下列言論，我覺得意味著你的組織文化可能不是以人為本的：
1、隨便找幾個人進行簡單的培訓（這些人只使用過vb開發過課堂作業程式），就可以很好的程式設計了
2、制定乙個執行步驟規範，人手一本，只要按照上面一步步操作就可以了
3、誰離開了，馬上找乙個人來就可以來替換他的工作。
我覺得這已經表明老闆認為程式設計師只不過是生產線上可替換的零件了。
我覺得不以人為本的團隊，也體現了對於如下幾個價值觀的不認同：
1、信任。程式設計師不值得信任，並不是像fowler所說的程式設計師是擔負責任的專家。
2、溝通和反饋。雖然通常他們會強調溝通的重要性，但是他們很少強調反饋的重要性。他們所謂的溝通是單向的下命令，而非互動式的。
3、尊重。團隊中其他人的工作是不值得尊重的，架構師可以有一萬個理由瞧不起編寫**的程式設計師，在這樣的團隊中，架構師通常都是不參與程式設計的。
迭代，小步前進
我非常喜歡kent那個開車的比喻，可是領導認為每天總結（站立式會議）或者每隔一段時間進行總結都是沒有必要的。
設立短小的、可控的計畫是無用的。
還有乙個最根本的
我覺得敏捷開發最根本的乙個觀念就是實事求是，也就是kent在《解析極限程式設計》中所說的，xp就是將有益的事情做到極致。所以敏捷方法都是一堆實踐原則的集合。
johnson講的循證框架也是在強調這點。我們可以籠統的說自己在實踐敏捷開發，或許不是那麼純粹的xp，kent的說法也是建議循序漸進的使用xp，但是覺得有用，可以解決你遇到的問題，又不會有很大的***，那麼就把它引進來，即使這個方法是cmmi陣營的。
我認為每件事都要經過科學的論證，而不是猜測，可是這一點也得不到認同。
敏捷叫停
我們的團隊請了乙個日企的強調使用v模型，嚴格文件驅動的顧問，意味著我們的敏捷之旅結束了。
我想我們之所以沒有沿著敏捷的道路走下去，並不是因為實踐的問題，也不是因為原則的問題，而是價值觀的問題，總結如下：
1、我們的老闆覺得程式設計師就是可替換的零件
2、質量不重要
3、開會就是下達命令
4、簡單就是把所有的**都寫到乙個檔案裡
5、對於大家不信任
6、個性不應該被尊重，服從命令是第一位的，海軍陸戰隊風格
7、實事求是
kent說，如果你的團隊的價值觀是與xp牴觸，那麼就不要使用xp。
我覺得透過種種敏捷實踐的實施不力，其背後隱藏的其實是價值觀的難以統一，至少我覺得我在專案中推行敏捷，掙扎了乙個半月終於要擱淺，原因就在於實在難以在價值觀上達成共識，最困難的是難以說服老闆改變觀念。
ps：我是研究生一年級的學生，我們的專案很大，可是人不多，我覺得非常適合使用xp。我認為xp是非常好的天才的想法，可以解決很多問題，可是今天來給我們做指導的那個日企的人說在大公司做大專案都是要聽話的，不會用敏捷之類的新方法。可是我看到的那些軟體開發大師的書，和論壇上各位的討論，都覺得這個方法應該是經過很多大型專案的驗證了，可是我們導師詢問了幾個公司裡的人，卻都沒有用過，他們也覺得tdd很好，但是就是沒用過。
我是作為我們團隊的技術主管，其實就是矬子裡面拔大個，但是這是我接觸敏捷1年來，並且在這個專案前期時使用敏捷的想法，或許我的所有觀點都很幼稚，所以還請各位有工作經驗的多多指點~
思路與心態是SEO最重要的事情
最初接觸seo的時候認為技術很重要。過於側重技術，就會導致盲目的去關注一些技術層面的細節，比如乙個頁面裡關鍵字密度應該是多少 幾個關鍵字的效果比較好之類的。但是實際操作中，思路更重要，只要整體思路是正確的，小範圍的技術失誤並不影響整體。很多人在接觸seo一段時間後會發現，seo技術含量並不高。除了技...
關於敏捷開發的一些事情
說的敏捷開發不得不提之前一直流行的 瀑布式 開發，所謂瀑布式開發 就是所有的專案開發過程都是按部就班的進行，先要需求調研有需求文件然後設計文件再後就是開發文件等等，之後就是 的編寫 測試上線，所有的整個過程都是按照一定的先後順序來進行的。瀑布式開發的好處在於管理人員可以對整個專案進行很好的掌控，專案...
乙個人最重要的是要有目標
乙個人最重要的是要有目標，哪怕很多人覺得你不合適這個目標，或者這個目標不被認同或者不被支援，近10年的工作經驗告訴我，只要你想，盯著這個目標去努力，你就一定會達到這個目標，不論你來自什麼學校，以前是做什麼的。無論是專業水平，自我認知感還是待遇，通常都會達到，雖然它不一定會在一家公司實現。上次溫昱來做...