我: Tech Leader

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

迭代: 雙周

主要會(huì)議: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.

現(xiàn)在有名外部敏捷教練在帶著我們實(shí)施敏捷,不過從sprint3開始，外部教練基本上沒有看我們的狀況，由我指導(dǎo)著團(tuán)隊(duì)和遠(yuǎn)程的SM進(jìn)行敏捷活動(dòng)。

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

周五公司有很多培訓(xùn)講座的，有同事提出回顧會(huì)要不要推遲開，但由于昨天演示會(huì)的不成功，我還是堅(jiān)持要開這個(gè)回顧會(huì)。

參加者：Scrum團(tuán)隊(duì)所有成員

開始時(shí)間: 3:30 PM

持續(xù)時(shí)間: 3 hours

主持: 遠(yuǎn)程的Scrum Master

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

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

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

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

再說一次，感謝環(huán)節(jié)里，感謝的兩個(gè)人在致感謝辭時(shí)要四目相對(duì)，并握手，最后擁抱結(jié)束。

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

寫出來的紙條還是和大家預(yù)料的一樣，有問題的地方，需改進(jìn)的紙條占了大多數(shù)，這方面還是體現(xiàn)了我們團(tuán)隊(duì)還是敞開心菲，敢于大膽說出來的。

寫完之后，我們每一條都過一遍，誰寫的誰解釋，然后進(jìn)行歸類，我們歸出來7個(gè)分類，分別是團(tuán)隊(duì)反饋，流程規(guī)則，管理，技術(shù)設(shè)計(jì)，需求評(píng)估，計(jì)劃，溝通，最后每個(gè)人對(duì)分類進(jìn)行投票，

然后我們針對(duì)前三個(gè)分類進(jìn)行總結(jié)并提出改進(jìn)計(jì)劃，我們的前三是技術(shù)設(shè)計(jì)，計(jì)劃和溝通。

關(guān)于技術(shù)設(shè)計(jì)，從一開始階段，我們確實(shí)沒有怎么做系統(tǒng)設(shè)計(jì)，由于我們做的系統(tǒng)也比較簡(jiǎn)單，所以遠(yuǎn)程SM和我都沒有重視這一塊。遠(yuǎn)程SM有10幾年的java經(jīng)驗(yàn)，普通架構(gòu)師級(jí)別問題不大，我8,9年java經(jīng)驗(yàn)，系統(tǒng)設(shè)計(jì)也沒問題，就我們倆有能力干這事，我們倆都是大忙人，所以忽視了，這次團(tuán)隊(duì)提出來，我們倆個(gè)也很同意去改進(jìn)，改進(jìn)的方案是重新review一下代碼的包結(jié)構(gòu)，api的設(shè)計(jì)，前端的封裝，因?yàn)槲覀儌z都沒寫代碼，所以我們決定采取pair的形式展開，并且創(chuàng)建一些技術(shù)story，寧愿犧牲一下進(jìn)度（其實(shí)我們項(xiàng)目也沒進(jìn)度壓力，都是我自己想出來的）。

計(jì)劃，這方面我覺得主要是在做計(jì)劃的時(shí)候，沒有考慮到還沒有完成上一個(gè)sprint的story,導(dǎo)致團(tuán)隊(duì)成員評(píng)估過于樂觀，而且由于沒有做好設(shè)計(jì)這一塊，團(tuán)隊(duì)成員在趕story的時(shí)候比較急，急于完成功能模塊，忽視了代碼質(zhì)量，做起來更加不順暢，還有就是SM沒有將團(tuán)隊(duì)完成的東西可視化出來，比如應(yīng)該將成員做上一個(gè)sprint的工作量可視化出來，這樣大家就可以知道團(tuán)隊(duì)沒有完成這個(gè)sprint的東西是因?yàn)橛幸恍r(shí)間是在趕上一個(gè)sprint的東西。改進(jìn)方案，完善可視化，粗暴的將評(píng)估放大1.5倍，為設(shè)計(jì)預(yù)留時(shí)間。

溝通，這個(gè)是團(tuán)隊(duì)投票最多的一塊，技術(shù)人員不善溝通在這里很好的體現(xiàn)出來了，明明需求寫得不清晰，就是沒有人提問，真急死人。我個(gè)人提出強(qiáng)制性解決辦法，對(duì)于簡(jiǎn)單的story，個(gè)人解決，對(duì)于復(fù)雜一點(diǎn)的story,實(shí)行結(jié)對(duì)編程。在提出結(jié)對(duì)方案時(shí)，當(dāng)時(shí)團(tuán)隊(duì)還投過票，50%贊成，但我還是強(qiáng)制要求試一下，因?yàn)槲覀€(gè)人還是認(rèn)為結(jié)對(duì)能解決溝通的問題，當(dāng)然我們可能會(huì)犧牲一點(diǎn)速率，但是否真的會(huì)犧牲速率，未知，我希望嘗試一下，第二，結(jié)對(duì)以后，質(zhì)量會(huì)提高，在這一點(diǎn)上，團(tuán)隊(duì)都一致這樣認(rèn)為。

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

1. 沒有文檔了，不用設(shè)計(jì)了，或者是設(shè)計(jì)的問題怎么做？

我們確實(shí)沒有做很詳細(xì)的設(shè)計(jì)，但我們?cè)诘?個(gè)sprint是有搭建框架的，但功能的設(shè)計(jì)確實(shí)沒有做，我們交給了團(tuán)隊(duì)成員去做，我們的團(tuán)隊(duì)成員大多數(shù)是三年經(jīng)驗(yàn)以下的，1個(gè)畢業(yè)兩年，2個(gè)今年畢業(yè)，1個(gè)去年畢業(yè)，這樣的團(tuán)隊(duì)搭配不是很合理，我們的解決方案是，一要給設(shè)計(jì)預(yù)留時(shí)間，二是對(duì)于初級(jí)工程師來說，實(shí)行結(jié)對(duì)的方式來進(jìn)行，讓高級(jí)的和初級(jí)的結(jié)對(duì)，三是對(duì)于復(fù)雜一點(diǎn)的設(shè)計(jì)要進(jìn)行review。

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

這個(gè)問題其實(shí)不可以簡(jiǎn)單的回答可以還是不可以，要看具體情況，我覺得對(duì)于這樣的情況，我們應(yīng)該可視化出來，有一個(gè)報(bào)表可以體現(xiàn)團(tuán)隊(duì)完成的story point,否則PO或者PM只會(huì)一味的埋怨。

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

?

好吧，就寫到這里吧，下周要實(shí)行結(jié)對(duì)了，看看我們的情況吧。

?

轉(zhuǎn)載于:https://www.cnblogs.com/even-ctit/p/5794148.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。