先來說下短迭代的好處。
1、快速交付特性，更加靈活的應對變化和突發(fā)情況，很好的應對外發(fā)版本；
2、減少每個版本發(fā)布的質(zhì)量回退風險。
但是之前的項目中也多次試圖試行短迭代。然而開發(fā)反饋，迭代太快根本沒時間做質(zhì)量活動，測試反饋，版本發(fā)的太頻繁無法進行深入的測試。整個團隊都處于焦慮之中。而對于項目管理者來說節(jié)奏也非常難以掌控，因為有太多的“意外”事件出現(xiàn)，打亂原先的計劃。
直到上個項目嘗試了精益看板的方式，并成功做到了基本上的周迭代之后，才慢慢體會出短迭代比長迭代難以執(zhí)行的原因，就是當出現(xiàn)這種”意外”事件之后，短迭代幾乎毫無回旋余地。
項目想要真正做到短迭代必須要遵循兩個重要的宗旨。
一、顯式呈現(xiàn)所有潛在的任務
我們原來習慣呈現(xiàn)迭代計劃的時候是這樣的：
而我們在實際執(zhí)行迭代的時候，情況是這樣的：
當?shù)鷷r間比較長的時候，這些未被列出的“隱藏”任務因為存在相對較長的緩沖時間，有能力消化在本迭代。但是如果迭代時間變成一周，這些“隱藏”任務相對計劃任務耗時比將會顯著提升，迭代回旋余地十分有限，由于計劃和實際執(zhí)行情況不符，節(jié)奏很容易打亂，團隊也會非常疲憊。
不呈現(xiàn)所有任務，還有另外一個壞處，當需要做的事情沒有被呈現(xiàn)的時候，就會被團隊視為“額外”任務，項目一緊，比如及時的輕量級的代碼重構(gòu)，復雜方案的提前驗證這些本來能提前降低后續(xù)風險，對質(zhì)量非常有好處的舉措都變成了“額外”工作，要么會無人提及，要么第一個被放棄。
那為什么安排計劃的時候不能按照實際情況來呢，顯式的呈現(xiàn)所有潛在的任務，把所有“隱藏”的風險，都變成顯式的工作量的風險，迭代才不會遇到那么多“意外”。
二、自動化持續(xù)集成
關(guān)于版本發(fā)布太頻繁，測試無法進行深入測試的問題，咨詢了華為內(nèi)部六級測試專家，他給的答復一個是縮減迭代的范圍，我理解就是顯式的呈現(xiàn)所有的任務，另外就是采用持續(xù)集成的方式每天對全量版本進行測試，迭代轉(zhuǎn)測只做新增特性的測試。
現(xiàn)在如果讓我來理解什么是敏捷，我覺得就是兩點：
首先，敏捷字面上的意思無非就是靈活、反應快，怎么才能反應快呢，就是不斷要丟掉一些之前必須背負的“包袱”， 丟給誰呢，丟給工具，丟給機器，丟給持續(xù)集成，丟掉這些“包袱”，自然就敏捷了。
其次，敏捷實際上就是把需求進行端到端的解耦，原來瀑布模式，先收集一個大的需求包，然后通過交接棒的形式，不斷交給下一個環(huán)節(jié)，直到全部變成軟件功能交給客戶，敏捷類似縱向切片，就是無論給一個還是幾個需求，都能直接變成軟件功能交付給客戶。現(xiàn)在一些流行的技術(shù)“特性端到端解耦”，“微服務”其實都是為了更好的做到需求的端到端解耦。
從以上兩個點出發(fā)，我們就能很好的理解，敏捷中我們需要做什么，敏捷的力度我們需要如何掌握。
想要實現(xiàn)短迭代，可能還有一些其他的因素，但是“顯式呈現(xiàn)所有潛在的任務”和“自動化持續(xù)集成”是短迭代得以執(zhí)行的兩個關(guān)鍵要素。
