一. 敏捷轉型之初，scrum團隊可能會想基於發布來規劃迭代週期
在前幾天與某個團隊進行交流時，scrummaster說想在未來幾周內規劃乙個為其一周的小迭代以開發和交付乙個小規模的需求。我建議仍然採用為期2周的迭代，可以在迭代內規劃乙個發布版本來完成這個需求的開發和發布。
這是乙個非常典型的現象：在剛開始實施scrum時，許多scrum團隊可能會想要根據發布版本來調整迭代週期。當迭代時間盒已到達而發布內容還差少許未能全部完成時，scrum團隊可能會想要把迭代延長幾天——以便在本迭代內完成所有發布內容的開發和測試；而當發布版本工作量偏少、無需乙個標準迭代週期就能完成時，scrum團隊又會想要把迭代週期縮短——以便本迭代能剛好完成這個小版本的開發和測試工作。
二. 敏捷倡導「按節奏開發、按需發布」
敏捷方**中倡導「按節奏開發、按需發布」——這裡的「節奏」就是指固定的迭代週期。也就是說；開發應該是有規律的，應該按照固定的週期來進行迭代開發，每個迭代都應該完成一批需求的開發和測試工作；發布是業務上的事情，應該根據業務需要來規劃發布版本和發布時間點，發布工作既可以在迭代結束時進行，也可以在迭代過程中進行。
三. 為何要採用固定的迭代週期
那為何要採用固定的迭代週期呢？或者說，固定的迭代週期能帶來什麼好處呢？一般來說，固定迭代週期能夠帶來以下幾點好處：
1 固定迭代節奏能大大簡化內外部的協作管理
由於迭代週期是固定的，所以需求梳理、迭代計畫、迭代評審、迭代回顧等關鍵事件在時間上都變得有規律。這樣一來，團隊內外部干係人就可以提前在自己的工作日曆上計畫這些事件。反之，如果迭代週期是變動的，就必須臨時預約內外部干係人來參與這些事件，這就使得內外部協作變得更加複雜。
而對於需要多個團隊協作完成的解決方案，如果能夠以相同的迭代節奏來統一各團隊的開發工作，無疑能大大簡化跨團隊的依賴管理和解決方案的整合管理。
所以固定迭代週期，能夠大大簡化內外部的協作管理。
2 固定迭代節奏使得大版本的規劃和跟蹤變得更加容易
當迭代週期固定且團隊相對穩定時，每個迭代能夠完成開發和測試的需求量也是相對穩定的，scrum團隊可以度量每個迭代交付的需求量——即「迭代速率」。迭代速率會在一定範圍內波動，我們可以統計其平均值。
當我們需要發布乙個里程碑版本時，我們可以基於平均迭代速率來規劃大概需要花費幾個迭代能完成這個發布版本。例如，假定某史詩故事的故事點數是480，而團隊的平均迭代速率是100，那麼我們就可以規劃5個迭代來完成這個史詩故事的開發和交付。
在版本開發中，我們還可以基於迭代來繪製版本燃盡圖（如圖1所示），以量化跟蹤版本的開發進度、平滑工作強度和盡早暴露進度風險。
3 固定迭代節奏有助於團隊的產品和過程的持續改進
在迭代節奏固定的情況下，團隊可以例行地收集外部反饋意見，並以此來改進自己的產品，以及例行總結本迭代的經驗教訓，並應用於下一迭代。
在迭代節奏固定的情況下，團隊可以度量迭代產能、質量和進度資料，並且以這些資料來牽引團隊的改進方向和驗證改進效果。
四. 您有何經驗
請問你知道為什麼關係型資料庫要叫關係型資料庫嗎？
我一直在使用mysql進行資料庫的增刪改查等操作，也知道mysql叫資料庫，卻沒有深入的 一下mysql是什麼型別的資料庫，還有什麼型別的資料庫，以及這些資料庫的區別和特點是什麼，雖然其他資料庫去深入學習和了解可能只能在工作以後才有機會接觸，但是事先進行了解，我想還是有一定必要的。首先mysql資料...