印第安人在趕了3天路後，會停下來小憩一天，因為他要等著自己的靈魂跟上來。敏捷開發在經歷了一次迭代或者衝刺（sprint）後，也需要休整，以等待團隊的靈魂跟上來，這一過程被稱之為「敏捷回顧（agile retrospectives）」。敏捷回顧與專案總結會議不同，它並非專案結束之後的蓋棺論定，而是在專案過程中，通過回顧會議及時總結上一次迭代中的得與失，以期達到改進專案開發、團隊合作等敏捷活動的目的。
如果將專案開發比作是一次征途，那麼在專案中期的短期休整是很有必要的。然而這種休整並非是將團隊成員集體拉出去＊＊一次，或者到k廳去鬼哭狼嚎一番，以洩心中的鬱悶，如此種種只能說是身體心靈的休息與放鬆。就像是運動員在比賽期間，隊醫的按摩、擦汗的毛巾、解渴的飲料。這些重要嗎？當然重要，放鬆疲憊的身體與心靈，方能更好地走向更遠的目標。但更重要的是靈魂的「反芻」，就像教練員針對運動員在上一局比賽的盤點與指導，指出選手以及對手的優與劣，從而制定出後面比賽的對策，方能把握取勝之鑰。
敏捷回顧不是一場沒有主題的討論會，大家坐下來，七嘴八舌漫無目的的一陣「亂彈」，這樣的形式對於專案進展沒有任何幫助。scrum對於回顧有乙個主要指導原則，這也是敏捷回顧的「最高指導原則」：
無論我們發現了什麼，考慮到當時的已知情況、個人的技術水平和能力、可用的資源，以及手上的狀況，我們理解並堅信：每個人對自己的工作都已全力以赴。
——敏捷回顧之「最高指導原則」
聽起來，有些像一團和氣的「和稀泥」做法，這樣的原則會否讓回顧會議的參與者乙個個都變成好好先生呢？難道我們一定要善意地評價團隊中的害群之馬，對他們的過錯視而不見，使其「逍遙法外」，並天真地以為我們的好心能夠感化他們？難道我們要在專案開發中建立乙個烏托邦式的大同世界，同薪同酬，為了團隊利益而抹煞團隊成員之間的個體差異。
坦白說，我反對在進行團隊成員評價時，採用這麼一條「最高指導原則」，但這樣的看法已經偏離了***的靶子了。需要知道，「最高指導原則」是應用在敏捷回顧中，而敏捷回顧的最終目的是學習，而不是績效評審活動[1]。
如果敏捷回顧沒有確定這條「最高指導原則」，用來倡議團隊成員信任自己的夥伴，就會讓回顧會議成為互相攻訐、互相推諉的批鬥大會，忘記了我們召開回顧會議的初衷。「最高指導原則」就是為回顧會議豎立乙個標桿，那就是在專案開發中沒有破壞者，沒有替罪羊，沒有關鍵人物，只有整個團隊的利益。雖然某個人或許在上一次迭代中出現了錯誤，但我們會善意地相信此人之所以犯下錯誤，並非有意為之，或者消極怠工，而是囿於當時之識見、經驗、技能。我們的回顧會議必須指明這些錯誤，並試圖總結出最佳實踐以避免在下一次迭代中犯下同樣的錯誤，而「最高指導原則」則能夠消除因為錯誤的指出而給成員帶來的負疚感，消除同事之間可能因此出現的隔閡與誤解。換句話說，回顧會議提出的所有批評都應該是「對事不對人」。
我曾經在乙個專案的回顧會議上，聽到了測試經理對於某開發小組產品質量的評價，認為該小組開發的模組出現了太多的bug。經過回顧會議的認真分析，最後得出的結論是該小組leader迫於進度壓力，因而盲目地追求開發進度，卻忽略了保障**質量的單元測試覆蓋率。於是，我們仔細討論了下一次sprint的 sprint backlog，根據團隊成員的能力進行了合理的分配。果然，在下一次sprint中，該小組開發的模組出現的bug率降低了差不多50%，即使bug總量並不大，這樣的比例仍然是非常可觀的。而且，由於專案組成員都明白回顧會議的原則，因此並沒有產生團隊成員之間的不快，開發人員和測試人員仍然能夠合作得非常愉快。
在《scrum checklists》中，指明了scrum回顧會議的議程：
1、在白板上寫上主要指導原則；
2、在白板上畫上乙個至少三頁紙連在一起長的時間軸；
3、在白板上寫上「我們的成功經驗是什麼」；
4、在白板上寫上「有什麼能夠改進」；
5、在白板上寫上「誰負責」，然後分成兩個區域——「團隊」和「公司」。
從以上的步驟可以看出，敏捷回顧的主要工作就是明確目標、持續改進、處理問題。敏捷開發之所以採用迭代的方式，實際上是利用蠶食方式逐步完成開發任務。將乙個巨集偉的目標切割為乙個個小目標，會給與團隊成員更大的信心，並能夠更加清晰地明確目標。而每次迭代後的回顧，則使得團隊成員可以更加清晰地明確我們在這個征途中，已經走到了**，未來還有多遠的路程，就像印第安人那樣，等待自己的靈魂，否則就會不知身在何處了。
在專案中持續改進至關重要。所謂「取其精華，去其糟粕」，唯有如此方能夠去蕪存菁，提高敏捷團隊的戰鬥力。每乙個敏捷團隊都不可能是十全十美的，要麼是在技術上存在個體差異，要麼就是缺乏足夠的領域知識，或者，還未曾找到符合團隊現狀的開發方法（即使採用敏捷方法，也需要因地制宜，切忌生搬硬套。即使現在符合，也不等於永遠符合，即使符合這個專案，卻未必符合下乙個專案。敏捷方法不可能放之四海而皆準）。即使這些均已具備，那麼團隊成員之間的磨合也並非一朝一夕之功。若沒有持續改進，團隊就會像生鏽的刀刃，不僅會褪去攝人的光芒，還會逐漸鈍化腐朽。
在專案過程中，有乙個原則是處理問題越早，那麼付出的代價與成本就越小。問題是，當我們在緊張的開發任務中，有時候很難發現這些錯誤，更加意識不到這些錯誤會帶來嚴重的影響。通過回顧會議，利用團隊成員互相善意地「敲擊」對方，或者反覆「鍛鍊」開發過程與方法，就能夠讓每一位成員都煉就「火眼金睛」。在會議中，我們經常會發現，一旦某個成員發現了乙個問題，接踵而來的就是每個成員都會發現一大堆問題。
發現問題僅僅是第一步，我們還要在回顧會議中合理分析這些問題出現的原因、所屬類別，並因此劃定問題的「責任田」。我們要明確這些問題是團隊內部的，還是由於外在因素導致的，也就是說要明確「責任田」的歸屬，指定處理人和處理時間。
此外，《敏捷回顧——讓團隊從優秀到卓越》一書的作者esther derby在接受infoq的採訪時，還提到：「使用回顧來解決衝突問題。他們在每個迭代中都進行檢視、實驗，並構建解決衝突的技能和信心。隨著時間推移，他們學會了如何處理每個團隊都會發生的「平常的」衝突。當大家意見出現嚴重分歧時，他們有能力、也有信心在團隊內部解決問題。而且更有利的是，由於他們可以在團隊內部解決全部問題，他們的經理就可以花費更多的時間來消除組織中對團隊造成的障礙。當然，這使得團隊能夠輕裝上陣，以更加輕鬆的心態來開發軟體。」[2]
現在，在你的專案團隊經歷了一次艱難的迭代之後，你需要休息一下以等待靈魂的到來麼？那麼，就請嘗試一下敏捷回顧會議吧，或許你會從中得到意想不到的收穫。
參考文獻：
[1] linda rising，敏捷回顧活動「最高指導原則」答疑解惑
[2] deborah hartmann，圖書節選：敏捷回顧——讓團隊從優秀到卓越
印第安人的靈魂 敏捷回顧
如果將專案開發比作是一次征途，那麼在專案中期的短期休整是很有必要的。然而這種休整並非是將團隊成員集體拉出去腐敗一次，或者到k廳去鬼哭狼嚎一番，以 洩心中的鬱悶，如此種種只能說是身體心靈的休息與放鬆。就像是運動員在比賽期間，隊醫的按摩 擦汗的毛巾 解渴的飲料。這些重要嗎？當然重要，放鬆疲憊的 身體與心...
印第安人的靈魂 敏捷回顧
印第安人在趕了3天路後，會停下來小憩一天，因為他要等著自己的靈魂跟上來。敏捷開發在經歷了一次迭代或者衝刺 sprint 後，也需要休整，以等待團 隊的靈魂跟上來，這一過程被稱之為 敏捷回顧 agile retrospectives 敏捷回顧與專案總結會議不同，它並非專案結束之後的蓋棺論定，而是在專案...
第乙個多層感知器例項 印第安人糖尿病診斷
多層感知器是最簡單的神經網路模型，用於處理機器學習中的分類與回歸問題。第乙個案例 印第安人糖尿病診斷 匯入必需的包 import tensorflow import keras from keras.models import sequential from keras.layers import ...