iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 7
0
自我挑戰組

再戰軟體工程系列 第 6

『為了估算而估算』 -- 談Negotiable的重要意義

打開Scrum教科書,翻到Planning Meeting,然後我們開始照本宣科的開了Planning Meeting,並且很乖的估算了故事點與工時。

然後呢?

對啊,然後呢?估算本身到底代表什麼意思?估算完的故事與數字可以拿來做什麼?如果他不能改變目前工作的困難,那又為什麼我們必須非估算不可呢?

Essential Scrum一書中,作者指出,『估算本身並沒有價值,估算本身引發的密集討論才有。』是的,我們要的就是那個密集討論。就算PO把story都寫得很清楚很完整,也不能保證大家對需求的理解都是一樣的。甚至,就算大家的理解都一樣,也不能保證大家想出來的solution都一樣,對吧?

所以我們想透過估算,引發討論,讓團隊取得共識,同時趁機決定為了滿足這個需求,我們必須要做什麼『工作』才可以達成目的。簡單來說,我們要的會議產出不是『故事點』,而是『工作』與『共識』。當然,故事點是有他的參考價值的,它可以幫助團隊評估這個story的工作量,看看是不是太大,或是一看就知道根本塞不進這個sprint。

工時也是一樣,估算出工時,然後呢?在健康的scrum運作過程,團隊是自組織並且自管理的。一個sprint能做多少事,不是PO決定,而是團隊取得共識後自行決定的,而這個工時就是決定的依據之一。『親愛的PO,這個Sprint我們只能做這些這些story,因為我們估出來的工時是這樣這樣。』這樣的對話在scrum裡面是正面且健康的。他讓團隊與PO同時知道這個sprint結束後,產品會變成什麼樣子。

反過來說,如果PO單方面決定了這個sprint要做的工作,那麼大家在這邊估算工時和故事點有什麼意義呢?萬一估出來也不能調整story數,那我們要估什麼呢?很無趣吧?

所以,圍繞著『自主管理團隊』而設計出來的Planning Meeting估算活動,如果不能讓團隊自己決定sprint內容與工作數,那就只是『為了估算而估算』,而失去意義了。

不要為了估算而估算,就像不要為了scrum而scrum一樣。了解背後的含義,善用其產出的價值,才能讓這個流程發揮他的力量。


上一篇
『為了做事而做事』 -- 談價值的重要性
下一篇
『根本就沒有QA』 -- 淺談測試與品保
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言