敏捷開發(fā)中有幾個不同的周期，從投資級的周期，到Scrum和看板周期，再到持續(xù)集成周期。鐘沛專家李老師指出，根據(jù)你使用的敏捷框架的不同，工作的側(cè)重點也都有些許不同。看板所強調(diào)的24小時周期在運營團隊里比較流行。而采用Scrum敏捷流程的開發(fā)團隊，Scrum周期通常是2到4周。在大規(guī)模敏捷框架（Scaled Agile Framework）中，長周期也非常普遍，稱為項目增量( Program Increments)，可以持續(xù)數(shù)個Scrum Sprint周期。

DevOps要能夠支持這些周期更好地運轉(zhuǎn)。在DevOps的思想下這再正常不過了：在敏捷的企業(yè)中跨部門協(xié)作。

DevOps在短周期中能帶來明顯的實質(zhì)效益，而這些效益會讓長周期變得更有效率。俗話說不積跬步，無以至千里；不積小流，無以成江海。

下面是一些敏捷周期可以從DevOps獲益的例子. DevOps工程師維護的部署系統(tǒng)，讓Scrum周期最后的交付更快、更有效。而交付每2到4周就會周期性地發(fā)生。

在經(jīng)常手動部署的企業(yè)里，部署一次可能需要好幾天。像這樣在部署上沒有效率的企業(yè)可以從DevOps觀念中獲益良多。

。  看板的周期是24個小時，所以很顯然如果我們想要在看板方法上取得成功，部署的周期需要快得多。

一旦代碼提交到代碼庫，取決于變更集的大小，一個設(shè)計良好的持續(xù)交付流水線

大約只需要幾分鐘就可以把提交的代碼部署到生產(chǎn)環(huán)境。

敏捷不只是形式

由于在量子物理上的成就，Richard Feynman在1965年獲得了諾貝爾獎。他注意到科學家中的一個普遍現(xiàn)象，那就是他們覆蓋了科學的全部邊界，可是就偏偏漏掉了一些關(guān)鍵性因素。他把這種現(xiàn)象稱為“草包族科學( cargo cult science)”。這來源于美拉尼西亞南部海島上的草包族（cargo cult）。草包族這個說法是在第二次世界大戰(zhàn)時，因島上的土著居民觀察到飛機給他們送貨而產(chǎn)生的——戰(zhàn)爭結(jié)束之后，貨物就不再送來了。土著們便開始模仿以前觀察到的美軍的行為，比如修建模擬機場，幻想飛機能因此再次回來。

如果我們只是早上站個會，喝點咖啡，聊聊天氣，這并不是敏捷或者面向DevOps的方式。如果我們的Puppet只有運維團隊才知道怎么用，這也不是DevOps流水線。

我們是否正在做正確的事？是否還在正確的路上？時刻關(guān)注我們的目標并經(jīng)常問自己，是件非常重要的事情。這是敏捷思考的中心。然而，在實踐中顯然非常困難。很容易以草包族的方式而告終。

每當構(gòu)建部署流水線的時候，舉個例子，留神我們?yōu)槭裁匆诘谝粫r間構(gòu)建它們。最終目標是讓人們可以更快、更容易地和新系統(tǒng)交互。它幫助不同角色的人們更有效率地溝通，而不用改變太多。

雖然沒有科學根據(jù)，但值得記住的是敏捷周期，比如Scrum的sprint周期，一般都會有辦法來應(yīng)對這種狀況。Scrum里，這種辦法被稱為sprint回顧會議。在會上，團隊一起討論在上個sprint大家什么做得好以及什么可以做得更好。在這上面花點時間來保證你每天的工作都是在做正確的事情。

一個常見的問題是，spring回顧會議的結(jié)果并沒有真正地被執(zhí)行。很不幸，這可能是由于你和企業(yè)的其他部分溝通不暢的問題導(dǎo)致的。所以，這些問題在回顧會議上虐你千百遍，但是從來沒有得到解決。

如果你意識到你的團隊正處于這種情況，你將會從DevOps方法中獲益，因為它強調(diào)企業(yè)內(nèi)部的協(xié)作。

總結(jié)一下，嘗試使用敏捷方法提供的機制。如果你正在使用Scrum，請使用sprint回顧會議機制來捕獲潛在的改進空間。話雖如此，這些方法不是教條，找出適合你的方法。

想了解更多IT資訊，請訪問中培偉業(yè)官網(wǎng)：中培偉業(yè)