關於引入每日站會的思考
距離上次寫部落格已經一月有餘，實質是在上完《每日站會》的線上課後一直想寫下當時的思考，總因為自己思考不清晰乾脆不做，因為自己都想不清楚如何去實踐呢？
同時作為團隊的管理者在思考這個動作不是是否有效的問題，為了避免「每日站會」若是掌握不好就會進入流於形式以至於到最後整個團隊的夥伴失去信心，畢竟這個團隊的共同語言沒有完全建立起來，難！難不是問題，有問題的是如何找到恰當的方法來實踐。所以不是從上至下的要求，而是由夥伴們從下至上的發起，這個不容易做到。因此等了乙個多月才從昨天開始出現由下面的夥伴發起這個問題，引出怎麼做每日站會的討論和交流，能夠走到這步已經是很不容易的了。
以下為自己一步一步的引導夥伴們走到這步的乙個過程的小結：
1.自身先學習《每日站會》的模型（需要注意的要點），成功的秘訣；
2.為了更深入了解scrum 的前世今生 閱讀《敏捷革命》，同時分享給團隊的夥伴，但不做要求，只做自己的感悟和分享，以及部分的實踐案例；
3.通過內部夥伴的迴圈溝通：能夠了解到夥伴們還是願意加強內部作業的快速溝通的願望的，期待本人能夠引領大家一起做每日站會。（同時在這個時候也能夠聽到團隊中不同的聲音，真的很好，其實大家並不反對，因為每個人的知識理解的不一致，所以認為以專案的方式作業的工作比較適合採用每日站會。雖然這個小小的進步不能說明什麼太大的問題，但是團隊中的夥伴們講出了心聲）
更重要的是：咱們現在的團隊不是乙個純粹軟體開發團隊，雖然咱們的團隊中開始有了少量的軟體開發，但是從心開始的路是要一步一步走的。
4.在以上的過程中，咱們的團隊一直在堅持著每週的周例會，對工作進行回顧，夥伴們自主的領任務，自主的發現問題解決問題的狀態好棒。同時我們也引入了自願做會議主持人的活動，讓大家有用心來溝通這個團隊的工作，氛圍很好。這部分其實真的很重要，沒有這樣的鋪墊，大家無法拿出真心來講，讓大家覺得這個團隊是大傢伙的，不是某個領導的，這樣更能接近敏捷所倡導的：「咱們這個故事完成了麼？」 ；而不再是：「你的工作完成了麼？」。
小小的心裡路程，但是卻改變了自己和團隊的變化，感謝《scrum 實戰》線上課程的各位老師的引領。
關於敏捷開發當中的每日站會
在敏捷開發當中有乙個每日站會，開會的時間不是很長。基本是總會昨天做了什麼時事，遇到了什麼問題，然後今天準備做什麼事情。由於是第一次使用這種模式開發，剛開始很不習慣，感覺這些事情好像用一封郵件就可以解決了，沒必要開什麼每日站會，甚至有點浪費時間，而且我們在前面開會的時間都不好把握，有時開得很長，然後一...
糟糕的每日站會
每日站會，作為scrum裡面重要活動之一，非常容易理解和實施，同時也是公司引入敏捷最容易和最應該開展的活動之一。然而卻因為執行不易歷來飽受爭議。很多有心嘗試scrum的專案試行一段時間後，往往是在站會上最先打了退堂鼓，繼而產生質疑。總覺得站會就是例行匯報，聽不到什麼實際內容的討論，枯燥無味 在有些團...
敏捷中的每日站會
每日站會，日常敏捷中的最重要的團隊活動。必須團隊全員參與，鼓舞團隊每日同步更新 1 昨天我做了什麼 2 今天我要做什麼 3 遇到了什麼障礙 團隊板是資訊雷達，同一時候也是團隊鼓舞的看板！當每日站會習以為常時，可以考慮使用的所謂 契訶夫站立 a 我們做了什麼？b 有無新增卡片 c 銷售會議 d 今天 ...