那該怎麼做sprint回顧呢？
第一點是找出在上乙個sprint中做得好的地方，並繼續保持。分析那些導致成功的流程是非常重要 的，這樣我們才能有意識地保持下去。只有團隊中的每乙個 成員都清楚什麼才是最佳實踐，才能有效地鼓勵和保持這些實踐。除了可以鼓舞士氣外，還可以避免把回顧會議變成消極的抱怨會議。
第二點是找出 上乙個 sprint中需要改進的地方，以及對應的改進措施。回顧的目標就是持續不斷地改進，這也是敏捷開發的主要理念之一。讓我們想一想如何才能在下乙個 sprint中更加有效率，想一想在哪些方面如何做才能跟上乙個sprint不同。可以收集任何可以量化的資料，以便於做定量分析，推動改善。
其 他一些什麼事情是要特別注意?
首先，一定要明確這樣乙個最高指導原則。即「無論我們發現了什麼，考慮到當時的已知情況、個人的技術水平和能 力、可用的資源，以及手上的狀況，我們理解並 堅信：每個人對自己的工作都已全力以赴」。
對團隊成員的績效評估，當然不能採用這樣的指導原則。我們現在談論的是 sprint回顧，回顧的最終目的是學習，而不是審判。如果敏捷回顧沒有確定這樣的 「指導原則」，倡議團隊成員信任自己的夥伴，就會讓回顧會議成為互相攻訐、互相推諉的批鬥大會，脫離了我們召開回顧會議的初衷。
「指 導原則」就是為回顧會議豎立乙個標桿，那就是在專案開發中沒有破壞者，沒有替罪羊，沒有關鍵人物，只有整個團隊的利益。雖然某個人或許在上一次迭代中 出現了錯誤，但我們會善意地相信此人之所以犯下錯誤，並非有意為之或者消極怠工，而是囿於當時之識見、經驗、技能。我們的回顧會議必須指明這些錯誤，並試 圖總結出最佳實踐以避免在下一次迭代中犯下同樣的錯誤，而「指導原則」則能夠消除因為錯誤的指出而給成員帶來的負疚感，消除同事之間可能因此出現的隔閡與 誤解。換句話說，回顧會議提出的所有批評都應該「對事不對人」。
組織sprint 回顧的最簡單方法是找個白板紙，在上面註明「哪些項工作順利」，「哪些項不成功」或者「哪些項可以做得更好」，然後讓與會者在每一類別下增加一些條目。當 條目重複時，可以在該項旁邊計正字累計，這樣普遍出現的專案就一目了然了。最後團隊成員共同討論，找尋這些條目出現的根本原因，就如何在下乙個 sprint 中改進達成一致意見。
敏捷回顧的主要工作就是明確目標、持續改進、處理問題。 敏捷開發之所以採用迭代的方式，實際上是利用蠶食方式逐步完成開發任務。將乙個巨集偉的目標切割為一 個個小目標，會給予團隊成員更大的信心，並且能夠更加清晰地明確目標。而每次迭代後的回顧，則使得團隊成員可以更加清晰地明確我們在這個征途中，已經走到 了**，未來還有多遠的路程，就像印第安人那樣，等待自己的靈魂，否則就會不知身在何處了。
poi 開發回顧 模板讀取
最近參加了乙個日本保險公司的內部專案管理的專案，我擔當的是文件出力處理這個模組，開發過程中遇到幾個問題，解決方法同大家分享下。處理文件的單元格樣式是從模板檔案裡邊讀取出來的。第乙個問題是單元格的顏色問題，出力的檔案單元格顏色和模板上的顏色不一致，經查api，發現每乙個workbook物件都有乙個專屬...
Hybrid混合式開發 回顧
一 前言 1 新鮮的玩法，短期可以吸引大量使用者 2 讓使用者足不出戶就可以抓娃娃，滿足一些喜歡抓娃娃人群的訴求 3 使用者留存率低，一般使用者就是在獲取免費金幣進來玩一把，然後就不會再來了，所以還得通過各種手段吸引使用者來，提高付費率 4 需軟硬體結合，打通之後還需專門人員維護機器 5 需要倉儲 ...
敏捷開發歷程回顧
學習並嘗試敏捷以來，目前是第三個團隊。第乙個團隊，在乙個小公司，我負責公司兩個開發團隊之一。那是第一次帶隊開發，沒有什麼專案管理經驗，在強大的開發壓力下，有一段時間把自己搞的焦頭爛額 團隊成員比較清閒，因為他們沒能力解決複雜的問題，我自己天天忙死累活。痛定思痛的開始研究專案管理，嘗試了一些傳統的管理...