持續改進 12月團隊溝通

看到很多的敏捷指導、都是每個人會和組員進行單獨溝通、聊下組員的一些想法、也能及時察覺團隊的問題、幫助團隊做持續改進。

12月份和組員溝通了下、提出了以下問題

前後端的溝通不夠、很多東西互相了解過少、導致某些需求在做的時候、前後端互相影響、這個平時還看不出來、但是當業務需求非常複雜、且需要前後端共同做業務、比如多步驟的下單的時候、就會出現意想不到的問題。

需求的質量太差、很多需求拿出來、經不起推敲、而且需求也沒有經過深思熟慮的思考、導致後面會出現頻繁的需求變動。

出於程式設計師的持續改進的風格、他們願意在迭代之外的事件抽出事件來進行**的優化、但是擔心**的優化導致bug的出現，結果好心變壞事。

產品經理覺得能實現的都盡量實現、哪怕技術難度大或者需要花費較多的時間、現狀是很多東西、為了追趕進度、都做了簡化處理。

打算從下個迭代開始、採取以下措施來改進：

需求會的重視程度提公升、目標是將所有的風險都在這個會議上面發現出來、不至於在迭代過程中出現大的風險、以後周五我們會過所有的需求、包括高保真和一些互動、都會仔細地過。然後大家一起討論每個需求的風險、評估時間等。

我會在迭代開始之前、提前過需求、過濾一些不存在實施可能的需求、這樣也對產品經理提高了要求、所以盡量下個迭代開始之前、能確定的需求都確定，能定稿的ui盡量定稿、這個實際是要求、給到開發的需求都是經過深思熟慮的、確定的、也可以減少需求的變動。