在執行Scrum中我覺得最重要的是團隊合作的氣氛提升, 這是我覺得收穫最多.
在以往因為角色的關係, 大家著重於把自己角色的利益發揮到最大, 可是忘記了區域最佳化, 是不會帶來整體最佳化的. Scrum正是要打破這樣的藩籬.
在執行Scrum一開始時, 我便要求要記錄工作時間的分布. 初期我發現到RD和QA溝通時間的比例很低, 這不是件好現象. 因為一開始是屬於釐清需求的階段, 再加上我們的iteration只有兩周長度, 若是彼此之間無法緊密合作, 勢必無法在期限內完成工作.
因此我在 Daily stand up meeting, 和 retrospective meeting 都大聲疾呼, RD 和 QA 必須要再緊密合作. 但是就像一般管理上會遇的問題一樣, 若是只是管理階層知道要做, 底下的人沒有相同的想法, 這樣事情是無法推動.
可是這時候Scrum的好處就來了, 因為我們的 iteration 是兩週, 所以也就是每兩週我們有一個 retrospective meeting, 大家便有機會來討論, 我們哪些地方做的不好, 為什麼無法 meet 這次 iteration 的目標, 以及要如何改善等等.
團隊在這時候便開始省思, 是否有些地方是可以在做的更有效率. 要知道改善是無法一蹴可及, trust也不是馬上就會發生. 所以當然我們也是漸漸才體認到彼此間是需要更合作無間, 並且也不是一開始就是全面性的, 而是從單一事件開始, 進而達到全面融合.
一開始時, RD 覺得若是不花時間和 QA 討論或是講解如何設計, 自己可能還要花大量時間撰寫文件來說明. 並且即使花時間寫了文件, 也無法確保 QA 能夠了解. 同時等到文件交付時, QA 已經沒有多少時間處理個案開立和執行的工作.
接著, QA 這邊也發現到, 若是受測程式無法通過測試個案, RD 需要花額外的時間去 fix, 甚至需要修改架構, 自己也需要額外再進行測試. 因此會盡可能的在 RD 開發時期, 要請 RD 一起 review 測試個案, 以確保這些狀況或流程, RD 已經思考在他的程式裡面, 因此便可以一次就到位.
當 QA 在做測試自動化時, 若是切入的點不對, RD 需要花很多時間處理, 因此 RD 便建議什麼方法是比較理想, 並且會額外開發一些小工具, 幫助 QA 測試時會進行的比較順利. 因為 RD 會發現雖然他們花了一些時間開發額外的工作, 但是在之後處理 bug 時, QA 便可以利用哪些工具來幫助他 reproduce, 或是更深入找出可能的原因, 或是幫忙找出一些不容易發現的 bug.
這些事情都不是同時發生的, 是隨著Scrum的進行, 發現工作效率不佳, 因此成員自行體會需要有所改變, 才能突破目前的困境.
此外, 在空間的安排上, 因為大量提供可以討論的白板, 因此當有討論的需求發生時, 願意討論的動機也比較大. 不會因為找不到會議室, 或是找不到白板,而感到十分挫折.
在座位的安排上, 我們前中期都是 RD, QA 各自做在一起, 但是 RD 和 QA只有一個走道之隔, 所以討論起來還是很方便. 不過, 我們也去會議室拿了額外的椅子來, 所以若是要一起討論解決問題時, 便可以都有位子坐. 後來因為公司組織重整, 我們換到不同樓層, 藉此我們趁機讓 RD 和 QA 交錯坐在一起, 目前感覺起來效果融洽, 因為就在隔壁, 隨時喊一聲就能開始討論.
最後, 令人激賞的是讀書會, 一開始我不沒有對它抱太大的期望, 因為大家都有做這件事, 可以效果很有限, 因為只是流於形式, 大家動力不大. 可是我們是 RD 和 QA 一起參加, 並且輪流報告, 不但 RD 可以教導 QA 在一些事情上要如何coding, QA 也可以share在某些系統上的操作, 所以雙方可以sync對一些技術的認知, 並且藉由這樣的交流增長雙方技術的成長.
留言列表
