距離寫完還有兩章左右。最近突然對生活有了新的感受，按照我以往的性格，對身邊的事情都非常在意，在意人的感受、在意彼此的關係、在意別人的看法。但突然之間，很多事情、很多人，似乎都沒有那麼重要。人與人再緊密，彼此之間依然會活成一座座孤島。在這其中，最重要的是要懂得珍惜自己，珍惜生活，珍惜當下。也許就是在這個時候，突然感受到了一直在追求的時間管理的下一個階段，對當下的珍視和關注——不思量過去，不焦慮未來，投入最大的心力和注意，就在當下。
從項目開始到結束，一個需求從頭腦中的想法轉變成“機會”，經過“探索”找到更多細節，由設計師進行模型設計，然後進入“故事工作坊”進行週期評估，最後研發、測試、上線。開發也許到此已告一段落，然後對於團隊而言，它還有一個重要環節需要進行，那就是“回顧”（或稱爲總結、覆盤）。
我們常常會經歷過這樣的回顧：
- 對回顧不重視，時有時無；
- 回顧總結形式化；
- 其樂融融或者爭吵不休。
大部分回顧會議似乎都很少能持續推進具體執行力、對團隊有易的結論和措施。回顧之所以被忽略，想來原因很大可能是因爲回顧不是“特效藥”，即不可能當下就對項目、對產品產生可見的幫助，而錯誤的回顧方式和會議技巧，無疑加重了對這一認知的偏見。在《用戶故事地圖》中，回顧的作用被說明爲“沉澱優化產品和開流程”，它向我們提供了兩種不同目的回顧會議：
- 與項目外的角色一起回顧
- 與項目內的角色一起回顧（項目反思與回顧會議）
與項目外的角色一起回顧
此類回顧需要邀請的“項目外角色”是指團隊外的重要干係人。回顧會議能幫助他們理解剛剛完成的內容和整體規劃的關係，在團隊討論中對產品的一些洞察和利弊分析。團隊開發需要全員參與，因爲它是非常不錯的、讓團隊成員看到他人對產品真實反應的機會，有助於提醒他們自己在做的事情有多重要。
回顧會議不需要很正式，最好帶一些吃的（這是這本書中反覆強調的，也許吃的東西能讓人們放鬆一些）。在這場回顧會議中，要評估兩個內容：
1. 可交付的故事
內容包括方案的目標用戶和預期結果、當前方案的發佈進度、每個方案構建成果。
2. 後續探索性的故事
包括當前已在處理的機會、爲理解問題和解決方案做的所有工作、當前所做的原型，並討論用戶對解決方案的看法。
與項目成員一起回顧
當然，與項目成員在一起回顧的氛圍可以更輕鬆，找一個安全的地方，帶上一些吃的。這種回顧會議有三方面內容：
1. 針對產品，需要成員對產品質量進行評估
這是指項目所有成員對產品質量的一次主觀評級，質量共分爲1〜5級，最是最好的。我們會通過問自己一些問題，來從三個方面進行評級。具體如下：
- 用戶體驗質量：
- 它有預期的那麼好嗎？
- UI和具體使用體驗是怎樣的？
- 功能質量：
- 測試過程是否流暢？
- 測試人員認爲測試更多內容或時間可以發現更多BUG嗎？
- 是否還有許多BUG未解決？
- 代碼質量：
- 維護的容易度和擴展度？
- （應該是隻有開發人員纔有資格對代碼質量進行評級）
2. 針對過程，成員們討論最近一次開發週期中的工作方式
它主要包括兩方面的內容：
- 下一次開發週期要做哪些改變？
- 最近一次開發週期中做的改變有效嗎？這些策略是繼續保持還是放棄？
以上部分常常是最容易被忽略的，因爲它們並不與KPI直接相關，也無法對產品有快速見效的改變。也許這就是短視之處，人們常常需要“特效藥”，但我相信團隊協作和效率問題，並不是一兩項舉措就可以有所改變而受用終生。團隊，畢竟是一羣人的協作，只有慢慢協調和調整，引導羣體逐漸適應，才能源源不斷的爲團隊提供向前衝的動力。
3. 針對計劃
瞭解scrum的朋友相對更容易理解大迭代和衝刺的關係。無數個衝刺組成一個迭代，每個衝刺相當於小的開發週期。而在每個衝刺結束時，都需要進行回顧，團隊成員一起目前項目的進展，已完成和未完成的故事和數量。以決策是否需要對開發內容和進度有所調整。
——end——
所有內容（持續更新中）