專案組一直在推敏捷開發，但發現乙個關於每日例會的問題。
場景：有時大家比較忙時，主持人會乙個個去詢問團隊成員工作狀況。
問題：不應該有個主持人，這會導致主持人過於繁忙，而其他人投入度降低（只關注自己的問題），建議每人個人主動去講解自己的工作和計畫，主動，自發和自組織，這才是關鍵；
最糟糕的是，主持人挨個詢問，這壓根就不能叫站立會議（只有主持人站著），只能叫任務跟蹤。
總結：站立會議 沒有 故事牆，是沒辦法把站立會議的成果 貢獻出來，這樣會導致反饋不足。
解決辦法：
建立故事牆，把故事分解成乙個個小任務，並按優先順序從上到下排列。標明未處理， 正在處理，已完成的任務。
團隊成員必須都到故事牆前，輪流講解。 自己昨天做了哪些任務；完成了那些；未完成的任務（為什麼沒完成？，需要什麼幫助？，或換人認領？），今天打算幹什麼（把一些未處理的任務移到正處理欄），最後如果有什麼心得可以分享給大家，如果有苦難也要及時求助。（任務標籤也可以寫上checkout 的名字，不是為了跟蹤，而是為實時知道誰在做哪個任務好及時溝通）。
故事牆更進一步的思考：
故事牆過高：
有些專案把故事牆放到很高，為什麼要放這麼高？我總結為：這個跟他們的位置有關係，因為他們是做成一條線的， 為了讓遠處的成員也能看到，就把故事牆放高了。
這裡有個問題是：他們的座位不合理，坐成一條直線，不利於最好的溝通 ；
故事牆放過高也不好，看不清楚，修正故事 也不方便。
可公升降故事牆：
使用可公升降的故事牆；如果高優先順序的故事完成了，可以上公升故事牆；人們就可以關注到現在要關注的故事，而不是已完成的。
想想這也有問題，為什麼要公升降，是不是說明當前sprint中的故事太多了呢？ 這應該是提示.
如果sprint 可以完成，說明sprint 週期太長了，可以縮的更短些（縮短反饋週期);
如果sprint 不能完成，說明sprint 承諾的太多了。
sprint 能不能完成可以從 burndown 燃盡圖看出來，如果曲線在 計畫斜線的上方，說明是承諾太多了，要減少故事。
軟體開發中，站立會議的必要性
筆者經歷過大到600人 小到20人的專案團隊，很多團隊中會引入敏捷尤其是scrum實踐，其中乙個重要的實踐是站立會議，遇到過團隊成員抱怨站立會議浪費時間，甚至在有些團隊中leader也持這種觀點，最後堅持不了幾次就不了了之了。那麼，站立會議 甚至說敏捷 是否有必要呢？我很能理解團隊成員抱怨站立會議浪...
團隊專案 站立會議DAY14
第十四次站立會議記錄 參會人員 張靖顏，鍾靈毓秀，何玥，趙瑩，王梓萱 專案進展 1 張靖顏 修改頁面，查漏補缺。進行需求分析，監督每個組員，把大家的問題都一一梳理。2 鍾靈毓秀 繼續修改模組 查詢其中的錯誤，利用已有的手邊資料結合所學的知識進行修改。3 趙瑩 把錯誤集中整理，乙個個查詢它的解決辦法以...
團隊專案 站立會議DAY12
第十二次站立會議記錄 參會人員 張靖顏，鍾靈毓秀，何玥，趙瑩，王梓萱 專案進展 1 張靖顏 已經將部分 完成，對一些模組化的功能進行擴充套件，對已具備的功能進行完善。2 鍾靈毓秀 對 進行了修改，將各個功能的 劃分成模組，繼續檢查每乙個模組的 並進行完善。3 趙瑩 將報錯 審查及修改，通過模組化進行...