敏捷開發(fā)系列文章目錄

    敏捷開發(fā)在國內(nèi)是不是只是一個理想化的工作環(huán)境？

    經(jīng)常有人問，你們搞敏捷開發(fā)工作量是由開發(fā)人員自己估的，而不是由經(jīng)驗豐富的技術主管估的，他們自己肯定會把工作量估得非常大，那什么時候項目才做得完？你們每天開那么多會，怎么不把時間放在好好寫代碼上面？一個迭代這么短的時間既要做設計、又要編碼、還要測試，這么急著做出的東西質(zhì)量肯定不高。系統(tǒng)設計肯定得經(jīng)驗豐富的老手做更靠譜。每當我聽到有人說這些問題，我就知道他肯定沒有真正的認識敏捷開發(fā)，如果真的有實踐過，自然就會發(fā)現(xiàn)這些問題根本就不是問題，只是杞人憂天而已。

seo優(yōu)化培訓,網(wǎng)絡推廣培訓,網(wǎng)絡營銷培訓,SEM培訓,網(wǎng)絡優(yōu)化,在線營銷培訓

 

    敏捷開發(fā)也快搞了快一年了，覺得應該把這一過程中的理解與經(jīng)驗得好好總結(jié)一下寫下來，還有就是又有一個新團隊由傳統(tǒng)方法正在向敏捷轉(zhuǎn)型，所以這些經(jīng)驗也可以幫助大家學習一下。

    采用敏捷最直接的結(jié)果就是，開發(fā)產(chǎn)品的效率確實提升了好多倍對比傳統(tǒng)模式，為什么這么說，我們團隊10個人花了8個月時間開發(fā)完成一個系統(tǒng)并完成上線使用，而這個系統(tǒng)在一個朋友公司也有在開發(fā)，他們早一點開始，20-30個人花了2年多的時間還沒有完全搞出來，當然他們用的是傳統(tǒng)的開發(fā)方式。

    傳統(tǒng)開發(fā)方式以前工作多年也都是采用它，當初也沒覺得它哪里不好，反正大家都這么做的，有問題也覺得正常，你覺得他是瀑布模式又不像，我覺得應該就是作坊模式吧，一直待得也是這種不大的小公司，確實比較像東莞那邊的小廠子小作坊，不像大公司那樣有太多的制度和流程，目標就是把當前的項目做好做完。中間也在外包工作做過幾個月，非常不適用，第一感覺就是太不自由了，連網(wǎng)都不能上就是按照文檔碼代碼就行了，而且要碼得一絲不茍，當初就覺得這種開發(fā)模式肯定不適合國內(nèi)的軟件公司的。

    什么機會接觸到敏捷了，就是去年去了新公司，上市公司，本身是不做軟件的，準備從設備生成轉(zhuǎn)到行業(yè)服務，需要更多的借助互聯(lián)網(wǎng)、IT數(shù)據(jù)，所以新成立的團隊來做，本來就是從零開始嘛，沒有歷史包袱，而且上市公司又多金認識高國際化，所以直接把國外敏捷開發(fā)的理念引進過來，就請了有名咨詢公司幫助團隊建立起敏捷開發(fā)，所以就有幸開始接觸了最先進與最原滋原味的Scrum，為什么說是原滋原味，因為后來也接觸了一些國內(nèi)其它的敏捷咨詢團隊，好多都是根據(jù)國內(nèi)情況本地化了，所以不是原滋原味了，比如改良后的敏捷沒有了估點的過程，而是直接按工時進行估算。

    剛開始接觸敏捷時候就覺得這種方式不靠譜，因為太理想化，比如說老板接了一個項目規(guī)定在固定時間必須完成，不然這個項目肯定就沒戲，按照項目的工作量的話在正常情況下肯定是完不成的，按照傳統(tǒng)的方式就是老板動員大家在這段時間大家拼一拼，多加加班還是有可能完成的，當然也有可能是完不成的，那就得繼續(xù)加班到完成為止。而按照敏捷的方式就不是這樣處理了，按照團隊的速率估算結(jié)果完不成，那就得必須告訴老板，要么增加迭代周期，要么減少功能，因為給我這么多量，但我的飯量就只有這么大，那么開始之前就一定得說清楚，而且只能這么做，不能加班，因為長期加班會破壞團隊的習慣。所以在當時想來哪個老板會跟你討價還價，直接就壓下來了，這真的是一種理想方法而已，在團隊中是行不通的。

    自己也是一直都有參與一線編碼的工作，我一直認為開發(fā)程序是一種腦力智慧，應該是一種很有樂趣的事情，而且剛開始也是體會過這種樂趣，后來工作久了深陷一個又一個的坑中，爬都爬不出來哪來的樂趣可言，程序員變成了碼農(nóng)。后來嘗試敏捷后，就是它會營造一種環(huán)境，讓你又重新回到之前對于編程的那種樂趣。所以敏捷與傳統(tǒng)最大的區(qū)別就是工作時的環(huán)境完全不一樣，傳統(tǒng)是讓你忍過了一個煎熬，接著又要迎接下一個煎熬，而敏捷就是讓你感受到編程的樂趣，回歸到讓你用編程智慧來解決問題，而不是頭痛各種項目帶來的坑。

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

seo優(yōu)化培訓,網(wǎng)絡推廣培訓,網(wǎng)絡營銷培訓,SEM培訓,網(wǎng)絡優(yōu)化,在線營銷培訓

 

    說到公司對待新人的方式，傳統(tǒng)團隊和敏捷團隊確實有很大的差別，傳統(tǒng)模式為了讓新人更快的上手，一般會給新人安排一個師傅帶著，讓師傅給新人制定學習計劃指導人家，由于師傅手上本來就有做不完的工作，一般頭個把月都是丟一堆文檔代碼讓新人看，然后試著給他安排幾個簡單的功能做做，最后發(fā)現(xiàn)新人做出來的東西不行，還得自己重新修改一遍，師傅就覺得帶人太麻煩了沒有幫到自己的忙，反而占用自己更多的時間，所以就搞得老人一般都不太愿意帶新人，就算公司出政策給帶新人的師傅額外的補貼，但這種方式也是解決不了根本問題，新人的學習周期還是很長，基本上一年半載都難獨立承擔開發(fā)任務。而敏捷團隊不會這樣，沒有師傅徒弟，也不講究新人老人，大家在團隊中都是平等的，新人剛加入團隊就會跟大家一起進入迭代開發(fā)，根本沒有說先熟悉一段時間，只是說在領用故事的時候，新人只算一半的點數(shù)用來降低這個迭代失敗的風險。這樣新人一進來就有開發(fā)任務，一下子就進入一個主動學習的狀態(tài)，會主動向團隊成員的學習，團隊成員也會主動幫助他，因為他完不成，那就是整個團隊的迭代失敗，因為敏捷只考核團隊不會針對個人進行考核。這樣新人在這種環(huán)境下，一般經(jīng)過2,3個迭代就會成長起來，適用團隊的開發(fā)節(jié)奏，如果3個迭代還沒有適用的話，那就是這個人可能不適合這個團隊。還有一個問題就是怎樣保證新人開發(fā)的功能不會出現(xiàn)質(zhì)量問題，導致返工，比如新人不熟悉業(yè)務功能設計考慮不夠周全，不太熟悉開發(fā)框架代碼編寫不夠規(guī)范等，這些問題都會影響產(chǎn)品的質(zhì)量，而敏捷開發(fā)最重要的目標就是保證產(chǎn)品質(zhì)量，所以這些問題在敏捷過程中都有對應的解決辦法，比如設計問題會有設計評審，代碼問題有代碼評審，團隊里的成員會在這些環(huán)節(jié)里幫助你把關，總之你在團隊產(chǎn)生的東西都不是一個人的東西，都是整個團隊的東西，人人都會關心。

http://www.cnblogs.com/kakake/p/7205425.html