敏捷開發的形和神
敏捷開發已在公司內部推行了有四五個月了，開始檢查各個團隊實行敏捷開發之后的效果，以檢查團隊是否真的敏捷了。按說這是好事，引入一種新的開發模式，是要定期檢查一下，以便使這種新的模式能夠按照正常的軌道來走，而不至于跑偏了。但現實情況往往是很多的，評估小組就真的能領會到敏捷的精神么？
通過一段時間的敏捷開發執行，確實發現了其好的地方，對于互聯網這種需求變化非常頻繁的行業，敏捷開發確實比較合適，能更好的適應需求的變化，更快的完成項目的開發和測試進度。內部也樹立了幾個敏捷開發的標桿團隊，供大家模仿參考，但我之前也說過，單純的照搬模式并適合每個團隊，況且你得允許人家吸納敏捷開發的優勢為己用，然后找到適合自身團隊的敏捷開發方法。關鍵就在這個適合自身上，每個團隊在敏捷的過程當中，摸索的過程都是不一樣的，執行的人也不一樣，這注定不會使每個團隊都有相同的敏捷模式。
光有敏捷開發的形能起作用么？
我不知道是否有標準的敏捷模式或者規范來告訴我們敏捷開發的第1，2，3步該如何去走，大致上的使用方法肯定是有的，細節的東西肯定也都是前人所摸索出來的。采用過敏捷模式的人都知道敏捷開發的一些標簽：backlog，站會，迭代計劃，迭代總結會議等等，這些其實都沒什么問題，關鍵在執行之后的效果上，拿backlog的維護和站會模式來說。
Backlog就是以前的user story，這個維護一般是要產品經理來完成的，需要在每個迭代開始之前將該迭代所需完成的部分backlog根據優先級一一維護好，以便開發和測試團隊執行。最早制定的模式是每個backlog都必須能在2-3天里面完成，后天發現不行，有些backlog達到所要求的功能確實時間會較長，且無法再拆分，后來變成每個task必須在2-3天里面完成，每個backlog必須在一個迭代里面完成，一個迭代是兩個星期。按照這個方式，一個開發周期超過兩周的項目必須得拆成好幾個backlog，也就是說項目是允許跨迭代執行的，然后按照backlog的優先級原則，優先級高的會先行進入開發。咋看之下是沒什么問題的，但一旦同時進行的項目變多了，很多backlog擠在一個需求池里面的時候，問題就來了。
首先是backlog管理的混亂，按照優先級原則開發，部分項目中的部分backlog確實優先級高，業務價值高，先行開發是對的，但幾個迭代下來之后，維護這個需求池就比較的吃力了，產品經理確實能看到每個backlog的完成進度，但是每個項目的完成進度看不了了，因為已經拆的七零八落，且有的完成有的還在等待排期，或許一段時間內都排不上了，非常不利于項目的管理。
其次是開發測試人員的混亂，剛進入某個項目，做完一小部分功能后立馬投入到另外一個項目中，做一小部分功能然后又去另外一個項目，思維轉變來轉變去，到最后在理解業務需求的時候發現都串了，特別是幾個項目之間有關聯性的時候，我終于明白為什么迭代計劃會議要開那么久了，就是為了讓開發測試人員轉變思路的。
站會是敏捷特有的形式，就是每天早上大家面對面站成一圈，各自花1分鐘講述一下過去一天都完成了什么，有什么問題，接下來今天要干什么，有什么需要協助的地方。這種形式其實挺好的，是一種高效的開會模式，能在短短十幾分鐘完成每個人都發言且形成決議（站會報告），日常的會議組織肯定沒有這么高效。前提是整個團隊都在一個辦公地點，實在不行分兩處視頻或語音開會也是可以的。有人說這種模式雖然有點奇怪但習慣了就好，但就是習慣不了啊。
站會模式應該是外國人搞出來的，其實國人在這方面確實不像老外那么收放自如，特別是我們的程序員，大都沉默寡言的，本身坐著發言話都很少，別說一群人站著面對面了，別提多別扭。當然開過幾次之后會好一些，然后最后的效果是大家都習慣了快速的敷衍了事，趕緊把自己那點講完，可能還帶了很多程序的術語，至少產品經理是不大聽得懂的，不過團隊成員之間熟悉了之后確實好了很多。
再就是產品經理一般都要趕趟，如果負責的產品線夠多的話，一早上的站會就得參加好幾次，所以理想中的一個產品經理一個團隊的做法，在現實當中也比較難實行，大多數公司都是恨不得把一個人拆成幾個人用的。
敏捷開發的神是什么呢？
簡單的說，敏捷開發是一種以人為核心，迭代、循序漸進的開發方法。在敏捷開發中，項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中系統一直處于可使用狀態。敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。關鍵點出來了，就是提高開發效率和響應能力，擁抱需求變化。
雖然說除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的理解敏捷開發。但是光有模式也不行，還得掌握其核心目的。我們所說的目標導向，就是這個意思。既然敏捷開發的目標是提高開發效率和響應能力，那是不是只要能實現這個目標的一切方法都是敏捷開發呢？
顯然問題的反問就不是肯定的答案了，因為敏捷開發模式的出來，比然已經經過了很多人的傳承才會引起大家的廣泛認可，有這樣的基礎在，就證明其有一些特性化的東西是不可磨滅的，比如說站會。那是否可以在引進的模式基礎上做適當的轉化呢？個人覺得完全是可以的，取其精華去其糟粕嘛。
雖然說沒有預先的模式照搬，不會得出后面的神，就像國家的社會主義革命一樣，也都是先經歷了錯誤才走到正確的道路上。但是我們已經知道了這樣的歷史，那就得借鑒歷史的教訓，結合自身的實際情況，取其精華即可。一個真正實行敏捷開發的團隊，絕對不應該有條條框框的東西去束縛他們的手腳。
敏捷開發的形神兼備
Backlog的問題可以通過另外一種方式來解決，即每個項目只建立一個backlog，然后在這個backlog下建立子任務，每個子任務設定優先級和工作量占比，子任務完成后backlog也能顯示出一個完成百分比，這樣的話首先各個項目的進度能一目了然，其次不會遺漏項目中的既定需求。這樣也滿足了整個需求池的管理，只不過層級從backlog層移到到了子任務層。
開發人員的思維轉變問題，一是通過迭代總結會議和迭代計劃會議來緩沖，二是如果開發資源不緊張的話，可以在保證緊急需求的協同開發前提下，盡量安排個別開發單獨跟進某個項目的需求，來達到項目的連貫性。
站會問題考慮到中國國情，完全可以坐著開，當然時間上可能就稍微要延誤一點了。至于趕趟的問題，這個一時半會沒辦法解決了。
其實總的來說，敏捷開發還是一種非常好的模式，只是在應用的過程當中，或多或少都會碰到一點問題，照搬照抄一直都不是我們的風格，哪怕大到社會主義革命這個層次，也是建立了中國特色的社會主義。因此我們有必要把原有國外的敏捷開發模式做一些轉化，建立起具有中國特色的敏捷開發。
