學習敏捷系列 - Daily Scrum

我參與過很多次的傳統瀑布流專案進度匯報會議,不帶杯咖啡進去真的很容易睡著,還好現在有了智慧型手機可以刷FB…(大誤)。

以我的理解,專案進度匯報會議是比較偏單向的,資訊從一方流向另一方:讓團隊或PM(或PM的老闆)得到最新訊息,接下來PM(或PM的老闆…XD)可能會依專案的狀態進行一些工作項目跟資源上的調度,目的是控制好專案進度,以免造成延遲。

但Daily Scrum的本質不太一樣,我傾向這樣描述它: 類似系統開機時的自檢,緊接著載入要執行的工作項目,並檢視周邊支援設備是否有異常,如有則必須優先排除以讓工作順利進行。

  1. 從上一次Daily Scrum到現在我做了什麼?
  2. 接下來我要做什麼?
  3. 我遇到了什麼障礙無法前進?

這3個問題形成了一個大致上以天為單位的Feedback loop。藉由頻繁的系統自檢,如果整個開發工作出了問題,比較容易地在問題發生初期就解決它。

舉例來說:負責需求分析的同事認為他前一天承諾的工作已經結束可以進行下一個需求分析,但另一個準備接手開發的同事並不是這樣想的,他還需要釐清一些細節,而這些細節必須有另一位同事協助。在Daily Scrum短短的15分鐘裡充分揭露這些資訊,就能在結束後進行有效的後續討論。

call for help + I can help + I’m interested + something is different from our expected -Joey 91 replied in FB

2018.1.20 以上是我原本發在FB的一篇感想文,之後在準備內訓教材時,覺得有些值得補充的地方,所以整理成這篇文章發在部落格。(話說好久沒發文了…XD)

  • 以積極的個人來建構專案,給予他們所需的環境與支援,並信任他們可以完成工作。
  • 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
  • 團隊定期自省如何更有效率,並據之適當地調整與修正自己的行為。

這是12條敏捷宣言中的其中3條,Daily Scrum不就正好對應到這3條原則嗎? 對管理層來說,專案的Transparency很重要,故專案管理的手段常見定期的團隊專案進度匯報會議,但以敏捷的精神來說,Daily Scrum無疑是更靈活的方式,而且不僅僅如此,如同91在FB的回應,團隊成員會逐漸學習到承諾、責任與互相信任,從Working Group昇華成為真正意義上的Team。

學習敏捷只看具體實踐常會讓人感到困惑,唯有深入原則與價值觀才能真正理解與認同敏捷。

上篇Upgrade GitLab from 10.3.3 to 10.7.1