敏捷的關鍵點:時間如何平衡的藝術

　　敏捷，會提到一個典型的實踐，時間窗(timebox)，這個實踐我們做的如何呢?

　　有時候會聽到這樣的聲音，我們敏捷了，甚至說超敏捷了。我們沒有專職測試了，開發同學自測保證;我們每天有晨會，我們有單元測試，我們有持續集成等等。深入一問，你們的交付周期或交付頻率是?會得到一個讓你想不到的回答，沒有固定周期或頻率。有時1周，有時2周，有時項目大了1-2個月。

　　敏捷的典型實踐中還有，持續穩定交付價值、團隊自主性調整適應、快速反饋機制，如果缺失了時間窗這個基本的典型的實踐，其他的實踐如何做?

　　關于交付頻率，關于節奏，你會聽到的回答：團隊新人多，團隊能力不足或產品特殊，所以無法達成周期固定，往往只能通過瀑布或者沒有固定節奏的迭代或迭代分化為開發迭代與測試迭代等方式來補足，找了一個規避措施而不是解決根因的方法，造成的局面就是其他相關實踐的有效性大打折扣或失效，從而認為敏捷沒有效果或者衍生出具有特色的項目流程。時間窗這個實踐，我們真的無法完成嗎?我看不見得，是我們不想去適應和改變，固定思維在作祟而已。

　　持續穩定交付價值：因為時間窗(TimeBox)的實踐前提無法達成，貌似我們可以做到“持續”、“穩定”的交付啦，甚至每天都可以交付、發布。實際上，每輪迭代的完成不是真正意義上的完成，心理預期總達不到;隨著需求的變化，發布時間變得不可控，延遲、bug多等問題出現。導致管理者、開發、測試同學信心不足。

　　團隊自主性調整適應：多好的一個實踐，也是圍繞時間窗這個實踐進行的。如果時間窗這個實踐做不到(不管是工作量超標、工作流存在浪費，還是能力不足造成的質量問題等原因)，如何調整適應到大家默契的程度，就成了團隊的大問題;或快或慢、或緊或松的方式都會導致團隊成員的吐槽，一旦不好的聲音出現，團隊就會遇到大麻煩。通過小步快跑，穩定的節奏，讓團隊成員知道什么時候該停下來，磨磨刀，然后繼續砍柴。達到磨刀不誤砍柴工，那時就是團隊上路的時刻。

　　快速反饋機制：以上幾個關鍵性特征前提的不滿足，導致本實踐特征的優先級被弱化，為什么這么說?持續集成的實時(提交)構建進入不了團隊的重點工作、回顧會議取消、狀態墻的弱化、結對無法持續開展、阻塞的事務得不到支持、資源搶奪式推動等等現象，促進問題快速反饋的功能都被其他更重要或更高優先級事務給取代了，忘本后只記得以上動作需要執行時被動的動一動。

　　面對時間窗，我們如何調整?

　　1.如果開發節奏過于密集，你會精疲力竭的。一般來說，當與其他團隊合作時，你需要減慢開發節奏。

　　2.有規律的開發節奏，會讓你有時間和精力去發現問題，并找到解決辦法，或者暴露到你的團隊中借助集體的力量解決問題，而不是因為趕進度而總是用臨時方案解決問題。

　　3.以固定、有規律的長度運行迭代。也許剛開始你要調整迭代的長度，找到適合團隊最舒服可行的時間值，但是之后就必須要堅持。

　　4.不要搞的經常加班。

　　5.在每天結束的時候，測試代碼，提交代碼，沒有殘留的代碼。

　　6.就像是減肥一樣，一點點的成功也是一個很大的激勵。小而可達到的目標會讓每個人全速前進。慶祝每一次難忘的成功。

　　最典型的節奏就是迭代周期，例如在scrum里面，就是一個sprint的周期，一般是1到4周的時間。不管你的迭代周期是多少，都應該堅持——確保每個迭代周期的時間相同很重要。運用有規律的開發節奏，會更容易達到目標，并確保項目不停的前進。

　　理想的效果： 開發過程有一致和穩定的節奏。編碼，測試，代碼review，持續集成，然后發布。 如果知道什么時候開始下一個節拍，跳舞就會更加容易。

　　綜述，我的觀點：沒有固定的研發節奏千萬別說自己敏捷了。因為這個時間窗是我們進行調整、進行適應的過程;暴露、解決問題的最佳閉環;通過團隊成員的快速反饋讓團隊更健康，通過穩定持續的交付，讓用戶的反饋更快速，讓我們的產品更健康。

　　時間窗，堅持用，更健康。

原文轉自：http://kan.weibo.com/con/3537019464842462?_from=feed_wenzhang