一個開發(fā)團隊，無論使用什么方法論萝毛，CMMI也好项阴，Agile也好，基礎的工程方法都是非常重要的笆包。
我在給客戶做敏捷轉型過程中环揽，團隊對Agile的方法與理念非常有熱情，每天按時開站會庵佣，每周一個Sprint歉胶，每周頻繁梳理自己的Product Backlog，PO巴粪、SM以及團隊都明確自己的職責通今，似乎一切都很順利。
然而培訓后的一天验毡，我觀察他們的源代碼衡创，大吃一驚。我發(fā)現(xiàn)他們竟然沒有單元測試晶通！原來，他們一直都不寫單元測試的哟玷。于是我緊急跟團隊與SM溝通狮辽，讓他們了解單元測試的重要性一也。
如果我們把開發(fā)軟件看成是蓋房子的話，那么單元測試就是保證每塊磚頭是符合質(zhì)量要求的手段喉脖。如果磚頭都不合格椰苟，怎么能保證房子是穩(wěn)當?shù)哪兀繜o論架構是不是合理树叽、無論流程有多么的科學舆蝴，都不行！
其中的開發(fā)人員跟我說题诵，項目時間緊啊洁仗，我們沒那個時間去寫單元測試。我沒有說話性锭。
之后我觀察到一個現(xiàn)象：該開發(fā)人員每隔一段時間編譯成功后赠潦，就把成功的代碼拷貝一份，放在一個特殊的目錄下草冈。我問他這是在做什么她奥，他說他在做備份，以防止每次修改代碼后發(fā)生意外怎棱，不能快速找到出問題的代碼段哩俭，所以用這種方法快速恢復。
于是我告訴他拳恋，如果他有完整的單元測試携茂，每次運行一下單元測試，馬上就能定位哪幾個方法出了問題诅岩，快速而有效讳苦。結果開發(fā)人員很是興奮，馬上對單元測試有了興趣吩谦。
這件事又一次驗證了我的想法鸳谜，好的方法也要用能夠解決問題的角度去切入，這樣就能夠達到事半功倍的效果式廷。
當下咐扭，很多做敏捷轉型的顧問過度關注流程的變革，忽視基礎的軟件工程方法滑废，其實應該更多地關注軟件工藝蝗肪，引入更先進的工程工具與方法。比如TDD蠕趁、自動化測試薛闪、持續(xù)集成等。
后來俺陋，我們?yōu)樵搱F隊引入了TDD豁延、自動化測試與持集成等工具與方法昙篙。我跟他們說，這跟Agile無關诱咏，這其實是基本功苔可，這是不管用什么項目管理方法都應該做的事情。
