1.序言，敏捷不同的開發團隊管理方法

    敏捷開發系列文章目錄

    敏捷開發在國內是否是隻是一個理想化的工做環境？

    常常有人問，大家搞敏捷開發工做量是由開發人員本身估的，而不是由經驗豐富的技術主管估的，他們本身確定會把工做量估得很是大，那何時項目才作得完？大家天天開那麼多會，怎麼不把時間放在好好寫代碼上面？一個迭代這麼短的時間既要作設計、又要編碼、還要測試，這麼急着作出的東西質量確定不高。系統設計確定得經驗豐富的老手作更靠譜。每當我聽到有人說這些問題，我就知道他確定沒有真正的認識敏捷開發，若是真的有實踐過，天然就會發現這些問題根本就不是問題，只是杞人憂天而已。

 

    敏捷開發也快搞了快一年了，以爲應該把這一過程當中的理解與經驗得好好總結一下寫下來，還有就是又有一個新團隊由傳統方法正在向敏捷轉型，因此這些經驗也能夠幫助你們學習一下。

    採用敏捷最直接的結果就是，開發產品的效率確實提高了好多倍對比傳統模式，爲何這麼說，咱們團隊10我的花了8個月時間開發完成一個系統並完成上線使用，而這個系統在一個朋友公司也有在開發，他們早一點開始，20-30我的花了2年多的時間尚未徹底搞出來，固然他們用的是傳統的開發方式。

    傳統開發方式之前工做多年也都是採用它，當初也沒以爲它哪裏很差，反正你們都這麼作的，有問題也以爲正常，你以爲他是瀑布模式又不像，我以爲應該就是做坊模式吧，一直待得也是這種不大的小公司，確實比較像東莞那邊的小廠子小做坊，不像大公司那樣有太多的制度和流程，目標就是把當前的項目作好作完。中間也在外包工做作過幾個月，很是不適用，第一感受就是太不自由了，連網都不能上就是按照文檔碼代碼就好了，並且要碼得一絲不苟，當初就以爲這種開發模式確定不適合國內的軟件公司的。

    什麼機會接觸到敏捷了，就是去年去了新公司，上市公司，自己是不作軟件的，準備從設備生成轉到行業服務，須要更多的藉助互聯網、IT數據，因此新成立的團隊來作，原本就是從零開始嘛，沒有歷史包袱，並且上市公司又多金認識高國際化，因此直接把國外敏捷開發的理念引進過來，就請了有名諮詢公司幫助團隊創建起敏捷開發，因此就有幸開始接觸了最早進與最原滋原味的Scrum，爲何說是原滋原味，由於後來也接觸了一些國內其它的敏捷諮詢團隊，好多都是根據國內狀況本地化了，因此不是原滋原味了，好比改良後的敏捷沒有了估點的過程，而是直接按工時進行估算。

    剛開始接觸敏捷時候就以爲這種方式不靠譜，由於太理想化，好比說老闆接了一個項目規定在固定時間必須完成，否則這個項目確定就沒戲，按照項目的工做量的話在正常狀況下確定是完不成的，按照傳統的方式就是老闆動員你們在這段時間你們拼一拼，多加加班仍是有可能完成的，固然也有多是完不成的，那就得繼續加班到完成爲止。而按照敏捷的方式就不是這樣處理了，按照團隊的速率估算結果完不成，那就得必須告訴老闆，要麼增長迭代週期，要麼減小功能，由於給我這麼多量，但個人飯量就只有這麼大，那麼開始以前就必定得說清楚，並且只能這麼作，不能加班，由於長期加班會破壞團隊的習慣。因此在當時想來哪一個老闆會跟你討價還價，直接就壓下來了，這真的是一種理想方法而已，在團隊中是行不通的。

    本身也是一直都有參與一線編碼的工做，我一直認爲開發程序是一種腦力智慧，應該是一種頗有樂趣的事情，並且剛開始也是體會過這種樂趣，後來工做久了深陷一個又一個的坑中，爬都爬不出來哪來的樂趣可言，程序員變成了碼農。後來嘗試敏捷後，就是它會營造一種環境，讓你又從新回到以前對於編程的那種樂趣。因此敏捷與傳統最大的區別就是工做時的環境徹底不同，傳統是讓你忍過了一個煎熬，接着又要迎接下一個煎熬，而敏捷就是讓你感覺到編程的樂趣，迴歸到讓你用編程智慧來解決問題，而不是頭痛各類項目帶來的坑。

    說道編程樂趣得好好說一下，從畢業實習出來到公司上班，一直從事醫療軟件開發至今已經10來年了，因此除了這份工做可以養家餬口以外，本身對於編程也是出於熱愛，否則也堅持不到如今。這麼多年來，半路轉行的同窗同事大把。剛從學校出來就立刻投入一線編碼，讓本身開發的功能客戶立刻就能用到是很興奮的事情，本身編寫的代碼可以賣錢，系統商業化，以爲本身太牛逼了。可以加入公司一開始就能參與核心功能的開發也是進入公司的時機巧，咱們一塊兒8個同事入職是因爲公司遇到分拆的危機，雖然公司只有幾十我的，可是技術老總帶着一批骨幹跑出去單幹了，致使公司一會兒空缺一批開發人員，而後就把咱們招了進來，進來後就每人分配一個子系統，半個月來熟悉系統，而後去醫院支持上線，記得當初接觸第一子系統就是門診醫生站。那時候的人仍是單純些，咱們8個新入職的同事一塊兒研究代碼、討論代碼、修改代碼，基本那段時間都是很晚纔回家，可是沒有以爲很辛苦或不值得。由於你們都是新來的，因此沒有什麼新老員工的隔閡，交流起來沒什麼顧慮，玩玩一些問題能夠討論半天，本身弄懂了一個什麼控件、什麼功能立刻分享給你們，因此在很短期內你們的進步都很快。如今招聘一個新人培養半年都不必定可以承擔起系統，可是不到一個月的時間各自都能鎮守一方。有時候想一想到底什麼緣由，是如今的小朋友太笨？確定不是，人家比咱們當前可靈泛多了。我以爲一是樂趣主導那種學習環境，再就是恰好遇到大量老員工出走的情形。如今的新人來到公司，確實感受不到一點編程的樂趣，沒有學習的樂趣那麼他進步慢那就必然了。爲何環境會變成這樣，就是由於原來的老人們以爲本身走來遇到的問題太多，而後就制定一堆制度來解決這些問題，慢慢的這些制度原來越多就造成了一種呆板壞境，而失去原來本該有的樂趣。好比如今新人進來通常都不會直接把新功能分配給他，由於沒有經驗擔憂寫的代碼不行，到時候仍是得重寫。甚至碰到極端公司，把開發任務像工廠流水線作鞋同樣，拆分紅不少個部分，而後讓新手對着填空，並且每一個任務都精確到小時，這樣按小時來覈算你的工做量，月底工資績效跟這個工做量掛鉤，你說你在這種環境下工做還有什麼樂趣而言。而站在公司的角度確實控制了項目風險、控制了人力成本，但這家公司也就變得沒有創意、沒有衝勁，也不可能作得更大。後來加入的全部公司基本上都走入了這個怪圈，直到嘗試了敏捷開發一段時間後，才感受到你們纔有了一些編程的樂趣。敏捷這種思想不是一會兒就改變了你認識，而是慢慢的慢慢的改變了你的習慣，讓你衝破以前的枷鎖，一點一滴的體會到編程的真正樂趣，從而讓團隊進入一種狀態、創建一種默契。說得確實有點玄，作到確實也不容易，並且個人這條路徑也不必定適合你，因此我就只是把個人故事講出來，做爲一個引線讓你思考，從而找到你本身的方法。

 

    說到公司對待新人的方式，傳統團隊和敏捷團隊確實有很大的差異，傳統模式爲了讓新人更快的上手，通常會給新人安排一個師傅帶着，讓師傅給新人制定學習計劃指導人家，因爲師傅手上原本就有作不完的工做，通常頭個把月都是丟一堆文檔代碼讓新人看，而後試着給他安排幾個簡單的功能作作，最後發現新人作出來的東西不行，還得本身從新修改一遍，師傅就以爲帶人太麻煩了沒有幫到本身的忙，反而佔用本身更多的時間，因此就搞得老人通常都不太願意帶新人，就算公司出政策給帶新人的師傅額外的補貼，但這種方式也是解決不了根本問題，新人的學習週期仍是很長，基本上一年半載都難獨立承擔開發任務。而敏捷團隊不會這樣，沒有師傅徒弟，也不講究新人老人，你們在團隊中都是平等的，新人剛加入團隊就會跟你們一塊兒進入迭代開發，根本沒有說先熟悉一段時間，只是說在領用故事的時候，新人只算一半的點數用來下降這個迭代失敗的風險。這樣新人一進來就有開發任務，一會兒就進入一個主動學習的狀態，會主動向團隊成員的學習，團隊成員也會主動幫助他，由於他完不成，那就是整個團隊的迭代失敗，由於敏捷只考核團隊不會針對我的進行考覈。這樣新人在這種環境下，通常通過2,3個迭代就會成長起來，適用團隊的開發節奏，若是3個迭代尚未適用的話，那就是這我的可能不適合這個團隊。還有一個問題就是怎樣保證新人開發的功能不會出現質量問題，致使返工，好比新人不熟悉業務功能設計考慮不夠周全，不太熟悉開發框架代碼編寫不夠規範等，這些問題都會影響產品的質量，而敏捷開發最重要的目標就是保證產品質量，因此這些問題在敏捷過程當中都有對應的解決辦法，好比設計問題會有設計評審，代碼問題有代碼評審，團隊裏的成員會在這些環節裏幫助你把關，總之你在團隊產生的東西都不是一我的的東西，都是整個團隊的東西，人人都會關心。

    敏捷開發系列文章目錄