當我們說到Scrum的時候，首先想到的可能是每日站會，ScrumMaster。其實Scrum包含的角色和實踐活動還有很多，為了便于記憶，我們一般將它們總結為“3355”，即：

3個角色（產品負責人Product Owner 簡稱PO；ScrumMaster 簡稱SM；Scrum團隊）

3個工件 （產品列表 Product Backlog；迭代列表 Sprint Backlog；潛在可交付產品增量 Product Increment）

5個活動（迭代規劃 Planning Meeting；站會 Standup Meeting；迭代評審 Sprint Review；迭代回顧 Sprint Retro； 迭代執行 Sprint）

5個價值觀（專注 Focus；勇氣 Courage；透明 Openness；承諾 Commitment；尊重 Respect ）

我們是一個組建了一年多的敏捷團隊，期間項目目標幾經修改，團隊成員也幾經更迭，最近才剛剛走入平穩期。參照團隊狀態變化的5個階段，現在的團隊應該處于從Norming向Performing轉變的過程中。

加入團隊之后，我發現團隊中的敏捷實踐跟我之前經歷的敏捷團隊不太一樣，在漸漸熟悉這些敏捷實踐，并慢慢的習以為常。但是在讀過《Scrum精髓》之后，這才慕然發現其實我們的敏捷實踐并不是完全照搬Scrum的方式，接下來詳細對比一下與《Scrum精髓》相比，我們的中華田園式敏捷到底有哪些“發明創造”。

角色

PO：我們的產品負責人（PO）是一個剛剛承擔這個角色不久的新人PO，老本行是一個專業的UX（用戶體驗設計師）。在項目組中先后擔任過UX，BA，PM和PO的角色。擁有深厚的客戶項目經驗和產品意識。

ScrumMaster：我們團隊其實并沒有一個專職的ScrumMaster，每日站會等敏捷活動大多是團隊成員輪流組織。

敏捷團隊： 一個PM，一個QA，一個Dev轉的Tech BA（因為我們做的平臺產品技術要求比較高），五個開發（Dev）。

問題：前文提到過我們的產品比較偏技術，所以UX出身的PO在面對業務干系人提出的一些比較技術化的用戶需求時，會顯得比較乏力。因此產品列表的工作其實是我們的Tech BA在做。因為團隊沒有一個ScrumMaster，很多敏捷實踐的裁剪和修改都是團隊成員在一次次的迭代回顧中總結和歸納出來的，一股濃郁的中華田園風。

工件

產品列表（Product Backlog）：產品列表之前大部分的內容是Tech BA擬定的，并與PO最終確認。

迭代列表（Sprint Backlog）：迭代列表是由Tech BA初步擬定，并在一個稱為Pre-IPM的會議中，由PO，PM，BA，QA和TechLead（TL，senior Dev）來審定通過的。

潛在可交付產品增量（Product Increment）：根據迭代列表的范圍完成的產品特性。

問題：由上面三個工件的描述可見，在最前面的兩個工件中，Tech BA都起著決定性的作用。目前可以看到的情況是因為涉及到跨時區跨語言的業務干系人溝通，剛剛切換角色不久的Tech BA沒能很好的代替PO完成業務干系人需求收集和優先級排序的工作，導致產品的交付無法讓業務干系人完全滿意，由此產生的拉扯給團隊和業務干系人都帶了非常糟糕的體驗。

活動

迭代規劃（Sprint Planning Meeting）：在我們的項目敏捷實踐中，對應迭代規劃，我們有三個會議與之對應，分別是Pre-IPM，Technical Discussion 和 IPM（Iteration Planning Meeting）。三個會議的參與者和主要目標如下：

Pre-IPM（PO+PM+BA+QA+TL），目的是為了劃定下個迭代的范圍，排定迭代內部優先級。

Technical Discussion（TL+Dev+BA+QA），目的是為了澄清下個迭代每張卡的范圍，Dev溝通每張卡可能的技術解決方案。這個會議里是開發人員第一次接觸到下個迭代的故事卡。

IPM（PO+開發團隊），目的是為了團隊和PO一起確認下個迭代的可用人天數，估算下個迭代所有卡的復雜度，根據復雜度和依賴關系檢查下個迭代的關鍵路徑是否會超過最大可用人天數。

之前團隊只有一個IPM會議，但是在實際執行的時候會發現每一次的IPM時間都會拖得特別的長，開發人員針對每一張卡的技術實現細節進行討論，此時PO的參與度會非常的低，當PO和BA一起討論排定業務優先級的時候，開發人員的參與感也會非常的差。因此后來根據會議的目的將IPM拆分成三個會議，一個用來排優先級（Pre-IPM），一個用來討論技術實現方案（TechnicalDiscussion），一個用來估算故事卡點數。到目前為止實行得還算比較有效。

站會（Daily Standup Meeting）：每天上午PO和開發團隊一起拉通上一個工作日的任務完成情況以及當天的工作計劃，以及完成當前工作的阻礙。在每日站會之后還會有一個代碼審查的環節，dev們會將前一天完成的代碼展示給其他的團隊成員，這個環節對于團隊成員之間了解彼此的任務進度和實現方式非常重要，而且對于統一團隊內部的編碼結構和編碼風格非常有幫助。

此前我們曾經嘗試在每天下班之前進行代碼審查，但是因為彈性工作制的原因，每個同事下班的時間不太一致，因此任務完成程度也不太一致，因此有些同事在代碼審查的時候還沉浸在自己寫到一半的中，代碼審查的參與度和效果也不是特別理想。因此我們將代碼審查的環節放到每日站會之后，一方面可以讓大家更加專注在代碼審查上，也能保證大家每天都能將可以執行的代碼提交到集成環境之中。

迭代評審 （Sprint Review）：迭代評審是我認為到目前為止開得最擰巴的一個會議，在這個會議中QA會總結呈現出過去一個迭代中團隊在開發和敏捷實踐上發生的各種問題。由于此前全體dev們參加的時候，認為自己受到了來自于團隊其他角色的challenge，會議開得一度非常的尷尬。之后就變成了只有PO，TL，BA和QA參加的一個小范圍會議，后面隨著團隊融合度的提升，又開始引入了所有團隊成員參加。但是因為主題關注在延期完成的故事卡，做的不太好的敏捷實踐等內容等，使得迭代評審會議變成了迭代回顧會議的熱身前奏。

根據《Scrum精髓》對于迭代評審的定義，迭代評審會議的目的在于使每個可以對產品開發工作提出建議的人有機會檢視和調整當前構建的產品。說到底是大家一起看看經過這個迭代之后我們的產品變成什么樣子了。通過這個會議使平時分散在各個產品特性上的團隊成員對于產品現狀都有一個清晰的認識。

很顯然我們的迭代評審偏離了這個會議的初衷。此外因為迭代評審發生在下一個迭代的第一天，這使得當前迭代的結束節點非常的不清晰，缺乏基本的儀式感。

迭代回顧（Sprint Retro）：我們的迭代回顧會議也往往發生在下一個迭代的第一天下午，緊跟迭代評審之后。全體團隊成員一起針對此前的一個迭代中團隊表現得好的地方鼓掌，從各自的角度提出團隊敏捷實踐中可以持續改進的地方，并一起給出解決方案。

但是目前迭代回顧過程中還是存在一些問題，例如回顧過程中產生的一些改進行動過于模糊，無法衡量完成程度，或是執行周期過長，無法在下次迭代回顧中取得明顯的改進。而且團隊成員回顧會議中領取的Action的完成情況也不太好，往往會出現到回顧會議的時候，上一次迭代回顧定義的Action還沒有完成的情況。

迭代執行（Sprint）：迭代執行過程中包含我們每天的工作：PO收集業務干系人的需求；BA寫故事卡細化需求；Dev們Kickoff卡、desk check卡、挪卡、寫代碼；QA寫test scenario、測卡、挪卡。隨著團隊協作日趨默契，日常工作的敏捷實踐問題不大，但是故事卡的質量還需進一步提高，Desk check的時候還是偶爾出現漏掉AC的情況。

敏捷之路，道阻且長。