當你的所有團隊都使用敏捷、忙於實施本地改進之時，在過去被稱作「it」或者「系統開發」的更大範圍的組織中，會發生什麼？一位大型敏捷專案組的教練分享了乙個策略，他們打算讓更大範圍的團隊社群發現趨勢並從所有這些知識中獲益。thoughtworks公司的paulo carol將其稱作「回顧之回顧」（retrospective of retrospectives）。其中有些取捨需要權衡，大型專案向來如此。
\u0026#xd;\n
反饋是敏捷軟體開發方法的乙個基石。它是團隊定期採取的重要間歇，用以進行「檢查和調整」，留意他們的流程和產品中的警示並做出反應，發現那些在急促的交付過程中可能被疏忽的機會。thoughtworks公司的paulo carol的專案有著十幾個15人的團隊，他在其中注意到，團隊層面上發生改善的同時，整個專案組卻逐漸喪失了對持續改善的關注。
\u0026#xd;\n
有些時候，乙個團隊的回顧產生的行動計畫依賴於其他團隊；還有些時候，兩個團隊回顧產生的行動計畫互相矛盾。\u0026#xd;\n
專案組面對的另乙個挑戰是，專案組層面的管理層沒有渠道去了解問題和改善。「專案組經理（和其他人）想要參加每個團隊的回顧會議，可同時參加多個會議根本就是不可能的。」
\u0026#xd;\n
caroli的解決方法借用了scrum of scrums的智慧型：回顧之回顧，簡稱ror。
\u0026#xd;\n
就像每日scrum被擴充套件成了scrum of scrums……我提出了大型敏捷團隊開展回顧之回顧的想法。...ror的語境是：「我們作為乙個團隊（整個專案組團隊），需要做什麼去改善專案整體產出呢？」\u0026#xd;\n
ror的參加者包括所有團隊和專案組的代表，包含了每個團隊的經理，和該團隊的另乙個成員（此人不是必須的，可以輪流擔任）。他的起步指南沒有指出產品管理部門的參與，但這可能是被所使用的角色名稱掩蓋了。該會議從每個團隊回顧中的最高5個要點開始，對去除重複項之後的結果進行投票表決（想必是為了決定討論的先後次序）。
\u0026#xd;\n
這裡我們撞上了大型專案中進退維谷的局面：是的，讓經理們親自走訪所有團隊十分困難，所以，由團隊來見經理。這樣的多對多會議很可能變得大大超過敏捷所推薦的小組人員規模，而與通常的回顧會議相比，需要更多促進措施來彌補會議中親密感的缺失。
\u0026#xd;\n
caroli記錄的關鍵效益包括：
\u0026#xd;\n
這一清單產生了個問題：在這裡，回顧會議的保密性又如何確保呢？採用這一體制，在團隊層面上必須設定期望值，讓大家了解它可能影響到未來團隊回顧會議上的互動。知道非團隊成員（不在團隊語境中）會得知討論結果，團隊成員是否還願意**敏感課題呢？可能在乙個高度互信、高度誠實的組織中，這一體制的效益大過其風險。
\u0026#xd;\n
檢視英文原文：retrospective of retrospectives
趣味回顧會 回顧
快樂與收益活動是乙個非常棒的活動，用來談論所有工作相關的事情，工作如何影響每個參與者 有關快樂與否 以及工作給團隊帶來多少收益。開展活動 1.畫出快樂與收益圖 2.請參與者向圖中新增便簽 基於工作中做過的事情，請參與者回答如下兩個問題 在做這件事的時候，你感到快樂或者痛苦嗎？做這件事的過程中，收穫或...
敏捷之回顧會議
每個迭代週期結束的回顧會議剛開始對我而言是例行公事，我一直在思考我到底從回顧會議裡得到了什麼？整個團隊得到了什麼？首先，回顧會議的在於回顧，之後總結。在公司裡我們總結的議題包括 好的點top3 壞的點top3 經驗教訓 可以改進的點和措施 與會之前所有兄弟反饋意見，會上每個人都在會上進行回顧，發表的...
Android回顧之布局
前面回顧了四大元件，今天我們來回顧一下android的布局方式 linearlayout可以說是最常用到的布局方式了。linearlayout是按照水平或是垂直的方式排列元素，垂直布局 android orientation vertical 和水平布局 android orientation ho...