通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的
工作事項。
敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。
團隊的每個成員都應該描述自上次會議以來所做的工作。
他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任何問題或礙。
為了確保會議準時開始並在
15
分鐘或更短時間內結束。
在此會議中，每個團隊成員都需要回答以下三個問題：
昨天我完成了哪些工作？
今天我將完成哪些工作？
哪些阻礙性問題或障礙可能影響我的工作？
但是，在每日例會實行的過程中也遇到了各種各樣的問題，所以現在總結一下。
1. 會議無法按時召開
問題：以前是在早上開，但是老有人遲到，也無法硬性規定不能遲到。即使是大家都按時上班了，也會由於各種拖拉，導致例會不能按時召開。
解決：後來我們就放到了下午，下班前20
分鐘，提前
10分鐘提醒。這麼調整之後，效果確實不錯。所以確定乙個大家都合適的時間，形成習慣和規律，堅持執行。可以有獎勵和懲罰的措施。
2. 互不關心
問題：剛開始大家都在各自說著各自的事情，做的多少，準備做哪些。乙個人講話的時候，其他人都在想著自己的那點事情。各自講完一遍之後，大家對其他人要做的東西和問題還是搞不清楚。
解決：為了解決這個問題，後來每日立會就採用了抽查提問的方式進行改善立會的問題，基本的形式就是，在每日立會上，當乙個人講完了之後，隨機抽取乙個人進行提問，問剛才講了什麼，有**不明白的。這個人要明明白白說出剛才那個人說了什麼，如果說不出來，就讓這個人去向剛才講的人進行詢問和了解。別人都在一旁看著這兩個人進行對話，直到不明白的人能夠清清楚楚的說出來為止，如果說不明白，就繼續問。一段時間之後，發現效果不錯，大家的情緒一下子提公升起來了，氣氛也熱鬧起來了。
3. 描述含糊
問題：立會上大家所說的話中如果存在含糊的詞彙，就需要引起注意，含糊的地方，其實有可能就是需要注意的地方。比如「已經差不多完成了」、「這個任務有些複雜」、「遇到了點小麻煩」、「昨天弄點別的耽誤了」，「有個地方有問題，需要重寫」等等。咋一聽，感覺上合理的，因為一些原因，導致今天的任務有所延誤，也是合情合理的，但是仔細一想，導致這些問題沒有被及時發現。這些地方其實就是問題的地方。
4. 任務過大
問題：任務挪動不了，因為沒有做完。連續兩天可能都挪動不了。
解決：拆分任務，如果每天都挪動不了，會增加心理壓力，產生沮喪感。拆分任務可以解決這部分問題。
5. 返工太多
問題：由於沒有明確完成的定義，所以剛開發完，沒有經過測試的任務，就直接說完成了。導致後期返工，又重新花時間去改之前的bug。
解決：明確完成的定義，團隊所有人達成共識。我們對於人物的定義是：經過了開發人員自己的測試和另一位開發的交叉測試（具體在前面一片文章有講）。這個任務才算完成，才可以挪到完成裡面去。這樣就促使開發人員，必須自己的測試全面，沒有問題。也能夠解決開發人員不願測試的毛病。
循序漸進的敏捷 每日例會
通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的 工作事項。敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。團隊的每個成員都應該描述自上次會議以來所做的工作。他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任...
循序漸進的敏捷 每日例會
通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的 工作事項。敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。團隊的每個成員都應該描述自上次會議以來所做的工作。他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任...
循序漸進的敏捷 交叉測試
由於各種原因，團隊人員換了一些人，新到的團隊成員，由於對業務不夠了解，對系統的 和架構，也不是很清楚，很多時候測試也不到位，導致了一系列問題和bug。很多問題在我們看來都是不應該發生，或是當時如果仔細測試，是完全可以避免的問題。針對於這樣的情況。我們進行了總結和反思，決定嘗試加入交叉測試，來提高系統...