引言：

我會以系列文章的形式跟蹤記錄我現在正在做的一個完整運用Scrum管理專案的筆記，裡面會有一些經驗教訓總結心得，以便讀者與我互相學習勉勵。有寫的不對的或者寫的不好的地方還請海涵，當然我更希望大家多多提寶貴意見，讀者的支持是我最大的動力。（之一，之二，之三，之四，之五，之六）

============================================================================================

正文：

我儘量保持每週都會跟大家分享一點我在上一個Iteration週期中碰到的問題以及收穫，所有不一定有很多東西可以寫，但是我儘量能把我認為有意義的東西留下來。

每次到了週五都會有一種罪惡感，到底我上一個Iteration完成了沒有，對於敏捷來說，我們每一個Iteration或者是Sprint也好，都應該是階段可交付。也就是說我們應該有一些對使用者有價值的Story完成了。Iteration的產物不在多，而在於是否有可交付的Story，而對於可交付這個詞我不知道大家的理解是不是一樣，至少我認為就是得到客戶的認可，對客戶是可以用的場景或功能。而到目前位置我們已經結束第三個Iteration了。應該來說應該有東西可交付了。但是作為PM或者PO的我來說，我覺得還沒有一個Story是可交付的。因為我認為可交付的意思是說，這個Story的價值都已完成，可以Demo演示給使用者看，並且達到驗收準則。那麼關鍵詞就是價值、Demo、驗收準則。什麼是價值？簡單來說就是對使用者來說是有意義的，最實惠的。比如說使用者要一個查詢系統特定使用者許可權的功能，那麼我們有兩種做法，一種是做一個許可權查詢的功能模組，可以查詢所有使用者的所有許可權的通用模組。還有一種做法是，在特定場景下，按照特定使用者查詢許可權。第一種很通用，滿足客戶要求了，甚至超出了，但是這樣就是好的嗎？第二種看起來很呆板，但是是不是使用者更想要的呢？而且開放花的功夫比第一種更小，帶來的價值更大。然後是Demo，為什麼要強調Demo呢，我看來有這麼幾個優點，1.不是開發環境，可以更接近正式環境。2.更直觀，不管是演示還是使用者體驗也好都很好。3.如果要做Demo開發人員會更用心，不會認為只是隨便跑跑看。最後是要收準則，我的驗收準則很簡單就是在我這裡0缺陷。有的人可能會說是不是太苛刻，我覺得並不苛刻，我是一個非專業測試人員，我更關注的是業務、價值，在我常規業務操作下還有缺陷的話，我相信真實使用者也是不能接受的。

最後我想給大家分享一下專案執行到目前為止碰到的溝通問題，我是如何應對的。

首先要費點口舌介紹一下我目前的團隊成員大致情況，PM專案經理1人，TM技術經理1人，開發6人，美工前端2人，測試2人，QA1人。 因為我們不是完全按照敏捷Scrum角色來定義，所以角色會比較多，公司規定嘛，沒有辦法。所以這麼看來溝通就非常的重要了。我畫了一個簡單示意圖，該圖以開發一個完整Story為前提，以開發這個角色為主線，在開發過程中我們的團隊協調溝通示意。自己理解，請高手們海涵，歡迎拍磚！呵呵

OK，今天的分享就到這吧，下次我想改講一講Iteration Planning Meeting了。謝謝收看。馬上三八婦女節了，提前預祝天下辛勞的婦女們節日快樂。

注：如有轉載還望標明出處，謝謝。