敏捷開發過程中，有效開展站立會議，能夠提公升開發效率、促進團隊建設和資訊溝通，現將我作為企業過程改進負責人旁聽某專案組「站立會議」的經驗體會與大家分享。
主持人：***
參加人員：專案組成員、qa、cm、過程改進專家（旁聽）
序號
成功要素
實際執**況
符合度1
限時15分鐘
少於15分鐘，時間控制很好 符合
2固定的時間、固定的地點、固定的人員
固定在早晨上班5分鐘後開始，地點固定，專案組在公司全體人員都能參加。
計畫到系統測試前，每天都進行。 符合
3站立會議 站立
符合 4
成員必須準時，否則懲罰 準時
符合 5
時刻圍繞實際專案工作主題
大多數成員能圍繞主題，能突出工作重點符合
6 每個人給全體成員說明工作進展，而不是給專案經理匯報
能夠進行團隊成員間的資訊和工作經驗交流符合
7 每個人都必須回答且僅回答三個問題 (昨天你完成了什麼？今天要做什麼？有什麼需要別人幫忙的？)
每個成員都能就三個問題簡要進行說明，由於第一次開，個別存在跑題需要主持人引導
基本符合 8
圍繞三個問題討論
沒有跑題 符合
9同步進展而不是解決問題
能夠簡要的討論問題、交流解決思路，且沒花費太多時間
比敏捷有創新 10
只有乙個聲音
，不能乙個人在發言，其他人在開小會
沒有人開小會 符合
11一般要有白板，在白板上貼上或畫出本專案組的任務狀態：未開始的，進行中的，中斷的，完成的。
沒有使用白板，團隊間每個人熟悉相關任務分配，但進度不清晰
不符合 12
不需要整理會議紀要
未整理 符合
13 主持會議要確保每位組員發言時不能跑題；可以點評、提醒每個人的工作，但是一定要簡短點評；如果對總體情況進行總結，一定要簡短；
主持人能夠進行切合團隊成員工作的交流和簡短總結，有簡短工作安排，有工作提醒。 符合
14非本小組的成員，可以旁觀，不需要發言
，不能下指令，只能旁聽
在團隊開會過程中，旁聽者未發言 符合
15不能中途有人退席，或接聽**
無人退席，但有人接打**，主持人已經確定在會後同此成員溝通
不符合
主要優點：
1 達到了團隊及時溝通進展的效果。
2 會議主題清晰，進展控制很好。
3 參會人員沒有發散議題，均圍繞工作主題陳述或說明。
建議改進點：
1、建議在每週一的站立會議上，可以回顧上週工作的總體完成情況，在周二以後的每天站立會議上，再嚴格按三個問題 (昨天你完成了什麼？今天要做什麼？有什麼需要別人幫忙的？)進行，這樣會使每週、每天的個人工作計畫與進度，無形中進行相互監督，消除個人惰性，不至於發生太大的偏差。 2、
主持人可以在每天或每週末的站立會議的結尾，進行簡短點評，1）工作總體進展回顧，哪些做得好，哪些需要努力加強；2）需注意的關鍵事項或風險，3）到週末的階段點，工作總體進展分析，以及要求（此項如能借助漫索或白板，形成進展圖最好）。 3、
建議在必要時使用白板，在上面快速的繪出工作任務、進展情況，或者記錄關鍵點。可以把白板上的記錄內容，拍下**，會後發給每個成員；主持人可以在下次站立會議前列印出來，開會時進行對照。
建議在下次召開站立會議開始時，主持人強調一下會議規則：開站立會議期間，不可接打**，一是避免干擾，二是本來站立會議時間就短，可以不帶**，三是以示對團隊成員講話人的尊重，要認真聽別人的交流，不應開小差。這此注意事項，主持人可以合適方式在會上說明，或者找對應的人談話說明。
每日站立會議
每日站立會議是 scrum 方法中的一條關鍵實踐，看似很簡單的乙個活動，其實內涵豐富，如果能夠成為一種習慣，還是不容易的。其成功的要點為 1 站立會議通過每天面對面的溝通，可以 1 快速同步進展，讓專案組內部的員工互相了解彼此的進展，從而了解本專案的整體進展。2 給每個人一種精神壓力，信守承諾。這是...
站立會議4
昨天遇到的問題 設計出想要的ui並不難，但是之前沒有接觸過這方面的程式設計，和昨天一樣要呼叫並複寫類庫中好多繪製函式。這就要求不僅對如何實現想要的效果十分了解，還要對windows中原本的基類中的相關函式更加熟悉。於是我在各種論壇蒐集了相關資料，並且在微軟的官網中找到了vs2010中幫助的函式詳細資...
站立會議01
1 昨天幹了什麼 昨天開展了第一次站立會議，初步分析了作業派系統內部測試板的基本框架，大致概括了作業派系統的基本選項功能，分為作業輸入 作業提醒 校園訊息提醒，作業資源上傳和查詢功能等。2 今天準備幹什麼 準備開始第二次站立會議，將系統的功能更加詳細的解析出來，同時各個小組的成員領取組長所分配的任務...