引言：
我會以系列文章的形式跟蹤記錄我現在正在做的一個完整運用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了。謝謝收看。馬上三八婦女節了，提前預祝天下辛勞的婦女們節日快樂。
注：如有轉載還望標明出處，謝謝。