迭代會議問題總結

問題2：會議時間無法控制。

分析：其實這個問題是由問題1引起的，因為討論過多的技術問題，和細節的小bug，導致會議程序的緩慢。

2、回顧/反思會

問題1：經過多次會議之後，我發現，有些人還是能發現我們iteration中存在的問題，但是提出問題後，他們不會主動去想解決方案，或者想了也想不出來。最糟糕的是，他們視乎很依賴於我，認為我最後一定會給出解決方案或者參考意見，都等著我來總結。

當我問大家：「大家認為這個問題還有更好的解決方案嗎？」他們會說：

「那你覺得是什麼？我們按你說的做不就行了？」

分析：大家的主動性還不夠。平時工作當中大家及時發現了問題也不善於總結。

所以在會議上，要麼就是沒問題可說，要麼就是說了也不能找到解決方案。以前我會讓他們提出問題，然後我就乙個問題誘導他們找出最佳解決方案，發現到最後都成了我強迫他們認為我的方案是最佳的，導致執行效果不佳。但是這個問題確實我還沒找到更好的方法。

問題2：會議時間不可控，要麼大家沒話說，很快就結束，要麼大家很多問題卻無法收斂，拿不出解決方案而延遲會議時間。

分析：1、沒話說，這個問題倒好解決，我會引導大家，或者乾脆自己丟擲問題來，讓大家討論。2、無法收斂找不到解決方案，這個問題同上問題1。

問題3：提出了問題，也有了解決方案，但是有的問題還是無法落實。

分析：大部分情況還是好的，比如，我們提出問題「要提高測試環境更新頻率提高」結果下個iteration我們更新為每天一次。但是有的問題就，比如「超過2小時無法解決的問題，我們要提block」。

這個問題就不能很好的落實。我的想法是，像這類問題，多次提出都無法很好解決的問題，我們應該在每次反思會的時候都要拿出來說一下，並且每次都把字型加大一號，然後每次拿出方案，分析方案為什麼沒有做好，分析可行性與執行力。

第二部分：iteration planning meeting

問題1：會議時間長。最近幾次會議時間特別長，原因有兩個。

一、需求澄清時間長。

二、計畫時間長。

分析：一、需求澄清的時間長，主要責任是我，主要原因有：1、開發沒有及時知道我們下個iteration要開發的內容。

都是在會議上才知曉。改進方法：在iteration planning會議之前，最少1-2天，羅列好下個iteration可能將要開發的條目即sprint backlog。

2、需求分析做的還不夠深入，以至於很多需求問題是在會議上討論得出。改進方法：在iteration之前，需要對下乙個iteration將要開發的內容做深入的分析，並挖掘客戶的業務價值。

我可以把這個階段的工作叫做pre-iteration。如下圖：

二、計畫時間過長，主要責任也是我。主要原因是：我過於要求細緻，對每乙個story我甚至要求他們分解到設計層面。

（也表現了我對團隊的不信任，這非常的不好）。目前已改正，現在的方法是，對於story由個人來認領，或者大的story由兩個或多個人來認領，認領後，由認領人或團體自行分解task並估算時間。而不做task的全體估算。