首先簡單澄清一下，我們小組的iteration會議召開方式和方法。我們組每週是乙個iteration時間比較短，所以每週我們僅固定召開一次大會。這次大會有兩大部分：1、上乙個iteration的review meeting。2、下乙個iteration的planning meeting。時間是每週五下午13:30~17:30，4個小時。第一部分2小時，第二部分2小時。第二部分視情況可延長半小時。
下面我們逐一分析：
第一部分：iteration review meeting
這一部分又可分為三個議程：1、case演示。2、回顧此次iteration。3、技術討論。我的理解，如果用敏捷scrum的觀點來看，1,2 兩個會議可以理解為是：sprint reviewmeeting（評審會）和sprintretrospective meeting（反思會）。
1、case演示
問題1：此部分沒有客戶參加，也沒有相關利益者參加，只有我們團隊本身的人員參加。流程是每個開發會上台講他自己在本次iteration中開發的內容。但是在講的過程當中比較凌亂，而且都是以技術角度在講述此次iteration開發的內容。恰恰坐在下面聽的也都是技術人員，所以經常開著開著就成了技術討論會，而不像是演示會或者評審會了。
分析：這個會議的目的是什麼？如果會議的目的真的像scrum的評審會，那麼我可以負責的說，我們目前還做不到，至少我這個專案中客戶無法能在iterationreview會議上評審產品成果。所以我認為沒有價值的會議可以取消，此部分可以由pm在會下做產品驗證即可。
但是如果會議的目的是想讓開發也了解我們整個產品到目前為止是個什麼狀況了，到什麼地步了。那麼我建議把演示流程嚴格定義下來。有兩種方式，1、可以有tm一人負責講述我們這個iteration主要開發的功能。先做簡單業務背景/場景描述，再做簡單的設計說明，再演示功能。只要保障我們團隊都了解產品開發的功能進度即可。有技術問題可以記下，但不要再這個會議上討論。2、還是由每個開發自己描述自己開發的部分，但是也要如同1方式一樣來講。
問題2：會議時間無法控制。
分析：其實這個問題是由問題1引起的，因為討論過多的技術問題，和細節的小bug，導致會議程序的緩慢。
2、回顧/反思會
問題1：經過多次會議之後，我發現，有些人還是能發現我們iteration中存在的問題，但是提出問題後，他們不會主動去想解決方案，或者想了也想不出來。最糟糕的是，他們視乎很依賴於我，認為我最後一定會給出解決方案或者參考意見，都等著我來總結。當我問大家：「大家認為這個問題還有更好的解決方案嗎？」他們會說：「那你覺得是什麼？我們按你說的做不就行了？」
分析：大家的主動性還不夠。平時工作當中大家及時發現了問題也不善於總結。所以在會議上，要麼就是沒問題可說，要麼就是說了也不能找到解決方案。以前我會讓他們提出問題，然後我就乙個問題誘導他們找出最佳解決方案，發現到最後都成了我強迫他們認為我的方案是最佳的，導致執行效果不佳。但是這個問題確實我還沒找到更好的方法。
問題2：會議時間不可控，要麼大家沒話說，很快就結束，要麼大家很多問題卻無法收斂，拿不出解決方案而延遲會議時間。
分析：1、沒話說，這個問題倒好解決，我會引導大家，或者乾脆自己丟擲問題來，讓大家討論。2、無法收斂找不到解決方案，這個問題同上問題1。
問題3：提出了問題，也有了解決方案，但是有的問題還是無法落實。
分析：大部分情況還是好的，比如，我們提出問題「要提高測試環境更新頻率提高」結果下個iteration我們更新為每天一次。但是有的問題就，比如「超過2小時無法解決的問題，我們要提block」。這個問題就不能很好的落實。我的想法是，像這類問題，多次提出都無法很好解決的問題，我們應該在每次反思會的時候都要拿出來說一下，並且每次都把字型加大一號，然後每次拿出方案，分析方案為什麼沒有做好，分析可行性與執行力。
第二部分：iteration planning meeting
問題1：會議時間長。最近幾次會議時間特別長，原因有兩個。一、需求澄清時間長。二、計畫時間長。
分析：一、需求澄清的時間長，主要責任是我，主要原因有：1、開發沒有及時知道我們下個iteration要開發的內容。都是在會議上才知曉。改進方法：在iterationplanning會議之前，最少1-2天，羅列好下個iteration可能將要開發的條目即sprint backlog。2、需求分析做的還不夠深入，以至於很多需求問題是在會議上討論得出。改進方法：在iteration之前，需要對下乙個iteration將要開發的內容做深入的分析，並挖掘客戶的業務價值。我可以把這個階段的工作叫做pre-iteration。如下圖：
二、計畫時間過長，主要責任也是我。主要原因是：我過於要求細緻，對每乙個story我甚至要求他們分解到設計層面。（也表現了我對團隊的不信任，這非常的不好）。目前已改正，現在的方法是，對於story由個人來認領，或者大的story由兩個或多個人來認領，認領後，由認領人或團體自行分解task並估算時間。而不做task的全體估算。
歡迎兄弟姐妹們，大哥大姐大牛們拍磚！！！
迭代回顧會議諮詢記錄
每次敏捷迭代都是一次pdca迴圈，迭代的回顧會議則是其中的a adjust 不斷的覆盤總結可以幫助專案一次比一次做的更好，使團隊形成乙個自學習的組織。近日我旁觀了乙個敏捷專案組的迭代回顧會議，專案組成員對本次迭代的經驗教訓進行了總結，我作為外部顧問旁觀了整個過程，並對專案組中存在的問題，本次回歸會議...
Restful會議總結
api 設計風格 restful只是一種風格，http只是一種協議，二者不應有交集。專案可以採用多種api設計風格，restful也不一定依賴http協議。restful representational state transfer 表示層狀態轉移，細糾的話和 表示層 狀態 轉移 有關。restf...
2011 12 22 會議總結 12 209
軟體架構其實很簡單，就是將要解決的問題劃分為模組，同時設計好模組之間的介面 做某個領域先把這個領域的書讀完 模型可以是圖形，甚至是某種特殊的描述性的語言 任何領域都沒有銀彈，都沒有一成不變，一勞永逸，完美無缺的解決方案 分層管理 對於乙個架構是否良好，從software product line e...