我: Tech Leader

團隊：團隊成員分布在兩個城市，我所在的城市包括我有4個成員，另外一個城市包括SM有7個成員。另外由于我們的BA離職了，我暫代IT 的PO 職位.PM和我在一個城市，但他不參于敏捷的運作里面.

迭代: 雙周

主要會議: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.

現在有名外部敏捷教練在帶著我們實施敏捷,不過從sprint3開始，外部教練基本上沒有看我們的狀況，由我指導著團隊和遠程的SM進行敏捷活動。

－－－－－－－－－－－－－－－－－－－－－－－－－以上是基本背景－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

周五公司有很多培訓講座的，有同事提出回顧會要不要推遲開，但由于昨天演示會的不成功，我還是堅持要開這個回顧會。

參加者：Scrum團隊所有成員

開始時間: 3:30 PM

持續時間: 3 hours

主持: 遠程的Scrum Master

步驟一：宣讀敏捷宣言， 這次由廣州的一位不怎么交流的同事讀，半推半就，后來還是堅持讀了。(明天回去問一下他的感受)

步驟二：Scrum Master總結一下這次Sprint，巴拉巴拉的說了一通，總的來說，講好的居多，可能報告做多了，出口都是積極性的東西。我由于對此次Sprint不滿意，個人還是感覺這個總結不是很到位的，在廣州的幾位同事也和我一樣的感覺。

步驟三：一如既往，這個環節還是很受團隊歡迎，大家都表現得非常積極，兩個城市的成員都有互相感謝的。這里我重點講三位同事，一位是QA，他是獲得最多認同的，我們的QA盡管每天都會抓同事的bug,還天天催成員們提交代碼，從角色上來說，可以說QA和開發人員是對立的，但他還是獲得了多位同事的認可的，可見，團隊的氣氛還是融洽的；另一位是遠程的另外一位開發人員，也是我感謝的其中一位，他是唯一一位在寫完自己代碼后繼續寫junit test的成員，而且前一天晚上還加班準備這周末的部署上線，雖然后來我們取消了這次上線（周五早上收到高層的郵件取消這次上線，原因是此次的項目改動對業務沒有很大關系），他的責任心，承諾，質量，態度都體現了出來；另外一位是上周日回到公司加班解決一個關于導出excel亂碼的問題的同事，由于這個UAT的bug已經持續了7天了，我也是下命令在周一前解決掉，所以他周日回公司加班了，他的承諾和責任心也體現了出來，但由于這個bug拖了這么久，我沒有選擇這位同事，在這里我感謝一下他吧。

最后我觀察一下，在最近兩個sprint里，我身邊的同事都沒有互相感謝的，在第一個sprint里有，不過那時我出差到了遠程的城市去了，沒有看到，希望下次sprint我可以看到本地的成員有互相感謝的情景。

再說一次，感謝環節里，感謝的兩個人在致感謝辭時要四目相對，并握手，最后擁抱結束。

步驟四：團隊成員每個人思考10分鐘，總結一下這次sprint，然后以寫紙條的形式，分成兩部分，一部分寫團隊做得好的地方，一部分寫做得不好，需改進的地方，但寫的紙條必須是具體的事例，不要寫抽象性的東西，例如，　寫我們這周開始有了代碼審查，而不要寫我們的質量提高了。代碼審查是具體的一項活動，而質量提高了，則很難表述清楚怎么樣提高了，具體體現在哪里。

寫出來的紙條還是和大家預料的一樣，有問題的地方，需改進的紙條占了大多數，這方面還是體現了我們團隊還是敞開心菲，敢于大膽說出來的。

寫完之后，我們每一條都過一遍，誰寫的誰解釋，然后進行歸類，我們歸出來7個分類，分別是團隊反饋，流程規則，管理，技術設計，需求評估，計劃，溝通，最后每個人對分類進行投票，

然后我們針對前三個分類進行總結并提出改進計劃，我們的前三是技術設計，計劃和溝通。

關于技術設計，從一開始階段，我們確實沒有怎么做系統設計，由于我們做的系統也比較簡單，所以遠程SM和我都沒有重視這一塊。遠程SM有10幾年的java經驗，普通架構師級別問題不大，我8,9年java經驗，系統設計也沒問題，就我們倆有能力干這事，我們倆都是大忙人，所以忽視了，這次團隊提出來，我們倆個也很同意去改進，改進的方案是重新review一下代碼的包結構，api的設計，前端的封裝，因為我們倆都沒寫代碼，所以我們決定采取pair的形式展開，并且創建一些技術story，寧愿犧牲一下進度（其實我們項目也沒進度壓力，都是我自己想出來的）。

計劃，這方面我覺得主要是在做計劃的時候，沒有考慮到還沒有完成上一個sprint的story,導致團隊成員評估過于樂觀，而且由于沒有做好設計這一塊，團隊成員在趕story的時候比較急，急于完成功能模塊，忽視了代碼質量，做起來更加不順暢，還有就是SM沒有將團隊完成的東西可視化出來，比如應該將成員做上一個sprint的工作量可視化出來，這樣大家就可以知道團隊沒有完成這個sprint的東西是因為有一些時間是在趕上一個sprint的東西。改進方案，完善可視化，粗暴的將評估放大1.5倍，為設計預留時間。

溝通，這個是團隊投票最多的一塊，技術人員不善溝通在這里很好的體現出來了，明明需求寫得不清晰，就是沒有人提問，真急死人。我個人提出強制性解決辦法，對于簡單的story，個人解決，對于復雜一點的story,實行結對編程。在提出結對方案時，當時團隊還投過票，50%贊成，但我還是強制要求試一下，因為我個人還是認為結對能解決溝通的問題，當然我們可能會犧牲一點速率，但是否真的會犧牲速率，未知，我希望嘗試一下，第二，結對以后，質量會提高，在這一點上，團隊都一致這樣認為。

最后總結一下，在第3個sprint里，可以說我們開始遇到了敏捷普遍可能會遇到的問題，

1. 沒有文檔了，不用設計了，或者是設計的問題怎么做？

我們確實沒有做很詳細的設計，但我們在第1個sprint是有搭建框架的，但功能的設計確實沒有做，我們交給了團隊成員去做，我們的團隊成員大多數是三年經驗以下的，1個畢業兩年，2個今年畢業，1個去年畢業，這樣的團隊搭配不是很合理，我們的解決方案是，一要給設計預留時間，二是對于初級工程師來說，實行結對的方式來進行，讓高級的和初級的結對，三是對于復雜一點的設計要進行review。

2. 上一個sprint的story完不了怎么辦？下一個sprint的工作量可以減少嗎？

這個問題其實不可以簡單的回答可以還是不可以，要看具體情況，我覺得對于這樣的情況，我們應該可視化出來，有一個報表可以體現團隊完成的story point,否則PO或者PM只會一味的埋怨。

我的看法還是能做多少算多少，但一定要可視化出來。

?

好吧，就寫到這里吧，下周要實行結對了，看看我們的情況吧。

?

轉載于:https://www.cnblogs.com/even-ctit/p/5794148.html

總結

以上是生活随笔為你收集整理的敏捷转型历程 - Sprint3 回顾会的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。