敏捷開發系列文章目錄敏捷開發在國內是不是只是乙個理想化的工作環境？
經常有人問，你們搞敏捷開發工作量是由開發人員自己估的，而不是由經驗豐富的技術主管估的，他們自己肯定會把工作量估得非常大，那什麼時候專案才做得完？你們每天開那麼多會，怎麼不把時間放在好好寫**上面？乙個迭代這麼短的時間既要做設計、又要編碼、還要測試，這麼急著做出的東西質量肯定不高。系統設計肯定得經驗豐富的老手做更靠譜。每當我聽到有人說這些問題，我就知道他肯定沒有真正的認識敏捷開發，如果真的有實踐過，自然就會發現這些問題根本就不是問題，只是杞人憂天而已。
敏捷開發也快搞了快一年了，覺得應該把這一過程中的理解與經驗得好好總結一下寫下來，還有就是又有乙個新團隊由傳統方法正在向敏捷轉型，所以這些經驗也可以幫助大家學習一下。
採用敏捷最直接的結果就是，開發產品的效率確實提公升了好多倍對比傳統模式，為什麼這麼說，我們團隊10個人花了8個月時間開發完成乙個系統並完成上線使用，而這個系統在乙個朋友公司也有在開發，他們早一點開始，20-30個人花了2年多的時間還沒有完全搞出來，當然他們用的是傳統的開發方式。
傳統開發方式以前工作多年也都是採用它，當初也沒覺得它**不好，反正大家都這麼做的，有問題也覺得正常，你覺得他是瀑布模式又不像，我覺得應該就是作坊模式吧，一直待得也是這種不大的小公司，確實比較像東莞那邊的小廠子小作坊，不像大公司那樣有太多的制度和流程，目標就是把當前的專案做好做完。中間也在外包工作做過幾個月，非常不適用，第一感覺就是太不自由了，連網都不能上就是按照文件碼**就行了，而且要碼得一絲不苟，當初就覺得這種開發模式肯定不適合國內的軟體公司的。
什麼機會接觸到敏捷了，就是去年去了新公司，上市公司，本身是不做軟體的，準備從裝置生成轉到行業服務，需要更多的借助網際網路、it資料，所以新成立的團隊來做，本來就是從零開始嘛，沒有歷史包袱，而且上市公司又多金認識高國際化，所以直接把國外敏捷開發的理念引進過來，就請了有名諮詢公司幫助團隊建立起敏捷開發，所以就有幸開始接觸了最先進與最原滋原味的scrum，為什麼說是原滋原味，因為後來也接觸了一些國內其它的敏捷諮詢團隊，好多都是根據國內情況本地化了，所以不是原滋原味了，比如改良後的敏捷沒有了估點的過程，而是直接按工時進行估算。
剛開始接觸敏捷時候就覺得這種方式不靠譜，因為太理想化，比如說老闆接了乙個專案規定在固定時間必須完成，不然這個專案肯定就沒戲，按照專案的工作量的話在正常情況下肯定是完不成的，按照傳統的方式就是老闆動員大家在這段時間大家拼一拼，多加加班還是有可能完成的，當然也有可能是完不成的，那就得繼續加班到完成為止。而按照敏捷的方式就不是這樣處理了，按照團隊的速率估算結果完不成，那就得必須告訴老闆，要麼增加迭代週期，要麼減少功能，因為給我這麼多量，但我的飯量就只有這麼大，那麼開始之前就一定得說清楚，而且只能這麼做，不能加班，因為長期加班會破壞團隊的習慣。所以在當時想來哪個老闆會跟你討價還價，直接就壓下來了，這真的是一種理想方法而已，在團隊中是行不通的。
自己也是一直都有參與一線編碼的工作，我一直認為開發程式是一種腦力智慧型，應該是一種很有樂趣的事情，而且剛開始也是體會過這種樂趣，後來工作久了深陷乙個又乙個的坑中，爬都爬不出來哪來的樂趣可言，程式設計師變成了碼農。後來嘗試敏捷後，就是它會營造一種環境，讓你又重新回到之前對於程式設計的那種樂趣。所以敏捷與傳統最大的區別就是工作時的環境完全不一樣，傳統是讓你忍過了乙個煎熬，接著又要迎接下乙個煎熬，而敏捷就是讓你感受到程式設計的樂趣，回歸到讓你用程式設計智慧型來解決問題，而不是頭痛各種專案帶來的坑。
說道程式設計樂趣得好好說一下，從畢業實習出來到公司上班，一直從事醫療軟體開發至今已經10來年了，所以除了這份工作能夠養家餬口之外，自己對於程式設計也是出於熱愛，不然也堅持不到現在。這麼多年來，半路轉行的同學同事大把。剛從學校出來就馬上投入一線編碼，讓自己開發的功能客戶馬上就能用到是很興奮的事情，自己編寫的**能夠賣錢，系統商業化，覺得自己太牛逼了。能夠加入公司一開始就能參與核心功能的開發也是進入公司的時機巧，我們一起8個同事入職是由於公司遇到分拆的危機，雖然公司只有幾十個人，但是技術老總帶著一批骨幹跑出去單幹了，導致公司一下子空缺一批開發人員，然後就把我們招了進來，進來後就每人分配乙個子系統，半個月來熟悉系統，然後去醫院支援上線，記得當初接觸第一子系統就是門診醫生站。那時候的人還是單純些，我們8個新入職的同事一起研究**、討論**、修改**，基本那段時間都是很晚才回家，但是沒有覺得很辛苦或不值得。因為大家都是新來的，所以沒有什麼新老員工的隔閡，交流起來沒什麼顧慮，玩玩一些問題可以討論半天，自己弄懂了乙個什麼控制項、什麼功能馬上分享給大家，所以在很短時間內大家的進步都很快。現在招聘乙個新人培養半年都不一定能夠承擔起系統，但是不到乙個月的時間各自都能鎮守一方。有時候想想到底什麼原因，是現在的小朋友太笨？肯定不是，人家比我們當前可靈泛多了。我覺得一是樂趣主導那種學習環境，再就是剛好遇到大量老員工出走的情形。現在的新人來到公司，確實感覺不到一點程式設計的樂趣，沒有學習的樂趣那麼他進步慢那就必然了。為什麼環境會變成這樣，就是因為原來的老人們覺得自己走來遇到的問題太多，然後就制定一堆制度來解決這些問題，慢慢的這些制度原來越多就形成了一種呆板壞境，而失去原來本該有的樂趣。比如現在新人進來一般都不會直接把新功能分配給他，因為沒有經驗擔心寫的**不行，到時候還是得重寫。甚至碰到極端公司，把開發任務像工廠流水線做鞋一樣，拆分成很多個部分，然後讓新手對著填空，而且每個任務都精確到小時，這樣按小時來核算你的工作量，月底工資績效跟這個工作量掛鉤，你說你在這種環境下工作還有什麼樂趣而言。而站在公司的角度確實控制了專案風險、控制了人力成本，但這家公司也就變得沒有創意、沒有衝勁，也不可能做得更大。後來加入的所有公司基本上都走入了這個怪圈，直到嘗試了敏捷開發一段時間後，才感覺到大家才有了一些程式設計的樂趣。敏捷這種思想不是一下子就改變了你認識，而是慢慢的慢慢的改變了你的習慣，讓你衝破之前的枷鎖，一點一滴的體會到程式設計的真正樂趣，從而讓團隊進入一種狀態、建立一種默契。說得確實有點玄，做到確實也不容易，而且我的這條路徑也不一定適合你，所以我就只是把我的故事講出來，作為乙個引線讓你思考，從而找到你自己的方法。
說到公司對待新人的方式，傳統團隊和敏捷團隊確實有很大的差別，傳統模式為了讓新人更快的上手，一般會給新人安排乙個師傅帶著，讓師傅給新人制定學習計畫指導人家，由於師傅手上本來就有做不完的工作，一般頭個把月都是丟一堆文件**讓新人看，然後試著給他安排幾個簡單的功能做做，最後發現新人做出來的東西不行，還得自己重新修改一遍，師傅就覺得帶人太麻煩了沒有幫到自己的忙，反而占用自己更多的時間，所以就搞得老人一般都不太願意帶新人，就算公司出政策給帶新人的師傅額外的補貼，但這種方式也是解決不了根本問題，新人的學習週期還是很長，基本上一年半載都難獨立承擔開發任務。而敏捷團隊不會這樣，沒有師傅徒弟，也不講究新人老人，大家在團隊中都是平等的，新人剛加入團隊就會跟大家一起進入迭代開發，根本沒有說先熟悉一段時間，只是說在領用故事的時候，新人只算一半的點數用來降低這個迭代失敗的風險。這樣新人一進來就有開發任務，一下子就進入乙個主動學習的狀態，會主動向團隊成員的學習，團隊成員也會主動幫助他，因為他完不成，那就是整個團隊的迭代失敗，因為敏捷只考核團隊不會針對個人進行考核。這樣新人在這種環境下，一般經過2,3個迭代就會成長起來，適用團隊的開發節奏，如果3個迭代還沒有適用的話，那就是這個人可能不適合這個團隊。還有乙個問題就是怎樣保證新人開發的功能不會出現質量問題，導致返工，比如新人不熟悉業務功能設計考慮不夠周全，不太熟悉開發框架**編寫不夠規範等，這些問題都會影響產品的質量，而敏捷開發最重要的目標就是保證產品質量，所以這些問題在敏捷過程中都有對應的解決辦法，比如設計問題會有設計評審，**問題有**評審，團隊裡的成員會在這些環節裡幫助你把關，總之你在團隊產生的東西都不是乙個人的東西，都是整個團隊的東西，人人都會關心。
敏捷開發系列文章目錄
不一樣的敏捷開發實踐
簡介 這是乙個真實的故事。故事中，我作為乙個專案的負責人，因為初期過於迎合客戶，而放棄了對一些基本原則的堅持，最終導致專案進行中被迫進行大改動。而改動過程中，通過引入敏捷開發而將損失降到了最低。2006年年初，一位客戶聯絡我的公司，希望能夠為其企業建立乙個企業 專案。根據客戶的簡單描述，這個專案本質...
不一樣的敏捷開發實踐
簡介 這是乙個真實的故事。故事中，我作為乙個專案的負責人，因為初期過於迎合客戶，而放棄了對一些基本原則的堅持，最終導致專案進行中被迫進行大改動。而改動過程中，通過引入敏捷開發而將損失降到了最低。2006年年初，一位客戶聯絡我的公司，希望能夠為其企業建立乙個企業 專案。根據客戶的簡單描述，這個專案本質...
不一樣的敏捷開發實踐
簡介 這是乙個真實的故事。故事中，我作為乙個專案的負責人，因為初期過於迎合客戶，而放棄了對一些基本原則的堅持，最終導致專案進行中被迫進行大改動。而改動過程中，通過引入敏捷開發而將損失降到了最低。2006年年初，一位客戶聯絡我的公司，希望能夠為其企業建立乙個企業 專案。根據客戶的簡單描述，這個專案本質...