l

2013年10月9日 星期三

DoD與成熟度

Sept. 29 20:26~21:16

螢幕快照 2013-09-29 下午9.14.31

 

導入Scrum的團隊經常會遇到一個問題:沒時間做測試。一個sprint兩個禮拜,怎麼有辦法在sprint結束之前把每個story都測過?尤其是有些story可能在sprint結束的前一天才開發完成,根本沒有留下任何測試的時間,那麼這個story還可以算是做完了嗎?

這個問題,可以從兩個方面來思考。

強化DoD

強化DoD的意思是說,如果團隊認為「所有story必須要被測試過才可以算是做完」,則請把這條規則寫入DoD,讓團隊成員一體遵守。如此做之後可能會造成兩個現象:

  1. 有些story總是無法在sprint結束前被測試,所以團隊成員被迫將這些來不及測試的story移到下個sprint中,造成團隊的velocity(團隊產能)降低。Velocity降低並不見得是一件壞事,因為這只是反映出團隊目前真正的產能,而不是虛假彭風的產能。因為嚴格來講,未被測試的story也只能算是半成品,如果假裝這些半成品已經完成並且算入團隊的產能之中,只會造成進度正常甚至是超前的假象。等真正產品發佈之前,還是要花一些時間來做所謂的「測試」或是「優化」工作。
  2. 有些團隊也可能因此改變工作模式,採用BDD/ATDD與TDD開發模式,確保測試案例先於story的開發,如此一來每個story「做完」的時候,驗收測試與單元測試也保證同時完成。

***

區分不同等級的DoD

Teddy在《Slow-start:導入Scrum首部曲》提過,剛開始導入Scrum的時候,先不要加入太多敏捷實務做法(例如寫自動化測試、導入持續整合、實施Pair Programming等),要求團隊改變太多原有的開發習慣,把主要的目標先放在讓團隊熟悉Scrum框架以及培養團隊合作的習慣。從這個角度來看,雖然理想上每個story做完的時候應該伴隨著也完成了自動化單元和驗收測試案例,但實務上如果團隊的能力如過還沒養成到那樣的程度,光是把這個要求加入DoD裡面只會造成團隊因為無法達到DoD的要求而一再的失敗,打擊成員自己以及採用Scrum的信心。

所以,從整個產品生命週期的角度來看,可以把DoD區分為:

  • Story DoD:Story完成前必須做到的事情。
  • Sprint DoD:Sprint結束前必須做到的事情。
  • Release DoD:產品發佈前必須做到的事情。

以剛剛所談論的測試為例子,假設一個剛剛推行Scrum的團隊,團隊成員完全沒有撰寫單元測試的經驗,更不用提要他們撰寫自動化驗收測試。此時團隊可以把「測試所有的Story」放在Release DoD,也就是說在產品發佈之前所有的Story一定要被測試過,但是在Sprint結束前,如果團隊還沒辦法做到測試每個Story,這種狀態是可以暫時被接受的。等待專案時間許可,或是團隊成員對於Scrum與敏捷開發的熟悉度提高,此時便可採用「強化DoD」策略,把原本放在Release DoD裡面對於測試的要求,提升到Sprint DoD,甚至是Story DoD層級。

***

友藏內心獨白:DoD也可以升級、降級喔。

2 則留言:

  1. 泰迪老師,文章要用單書名號唷:〈Slow-start:導入Scrum首部曲〉

    回覆刪除