聊聊程式

scrum是經驗主義 所以被驗證過的成功 才是成功 不猜測 不空想
怎樣驗證呢 就是把產品釋出到市場上 看看使用者說好不好
好的 如何維持 或是 更好
不好的 如何改進 或是 方向是否正確
怎樣的開發 才能這樣 不停地釋出新版本到市場上呢
迭代跟小增量的觀念出現了
以前的開發軟體 像是 Firefox  (參考資料 Firefox版本歷史)
Firefox 2.0發表於2006年10月24日
Firefox 3.0發表於2008年6月17日
Firefox 4.0發表於2011年3月22日
基本上就是 一年以上才更新一個版本 而這一個版本會改變很多東西
Firefox 2011年4月開始改變
Firefox 5.0正式版發布於2011年6月21日
Firefox 6.0正式版發布於2011年8月16日
直到最近
Firefox 63.0正式版發布於2018年10月23日
Firefox 64.0正式版發布於2018年12月11日
改變成大約1個月 釋出一個新版本 每個新版都加入一些功能
這樣的改變就是 迭代跟小增量 最好的說明
不停地釋出 也就可以不停地去取得回饋
scrum 適合用來開發 複雜的產品 或是說 需求變化快速的產品
scrum 就是 一個開發框架 來去達到 迭代 , 小增量 , 回饋
scrum有三個支柱 透明 , 檢核 , 調適
團隊都清楚為何而做 ,  工作內容進度 都是 公開透明
每次產出的小增量 都需要 檢核
檢核內容 會需要不停的 調適
不只是產品 團隊本身也需要 檢核 當然也需要 調適
具體如何做到呢
人員上會有
產品負責人 他負責這產品的成敗
大到產品的方向 小到哪個功能最有價值要先做 
都會產品負責人的工作
scrum master 他負責讓 團隊能夠理解 小增量 , 回饋 , 透明 等等的重要性 
服務 組織 開發團隊 跟 產品負責人 解決 scrum 的問題 
開發團隊  這團隊是能夠把產品負責人的對於產品的價值想法
變成一個一個小增量 釋出到市場上去驗證

因為釋出產品不再是長久計畫的時候 就需要新的時間週期 
讓開發團隊知道 我有多久的時間 可以 產生出小增量
所以有了 Sprint 的概念
Sprint 就是 多久可以產生出小增量的時間
有些人用1周 或2周 這就看 組織 跟 團隊 討論選擇一個適合的時間週期 
( 這裡挖個坑 有緣再說 我覺得新手上路 理想的情況下 1周是比較合適 )

要能夠知道這次的Sprint要交付那些對產品有用的價值
所以需要 Sprint planning 來計畫這次Sprint要把哪些價值實現
Sprint planning 有一個重點就是確立這次Sprint的Sprint Goal
這需要整個團隊一起討論出來的Sprint Goal
也會產生出 Sprint backlog , Sprint backlog並不是強制要全部做完的
一個Sprint是否成功 應該是取決於Sprint Goal是否有達到
而不是Sprint backlog有沒有做完
不過Sprint 的時間是固定的 所以能夠實現多少價值 是要 團隊一起討論
產品負責人 負責把 價值高的需求 排在最前面
開發團隊需要猜測是否在這次Sprint是否可以實現
應該有人對於猜測這用詞 有問號
( 這裡挖個坑 之後 有緣再說 點數 時數 精煉product backlog 老闆要知道多久才能做到 老闆覺得很酷的需求 這坑有點大 )
總之 Sprint 的實現多少價值 是在 Sprint planning 團隊一起討論出來的
並不是 產品負責人說的算數

接下來的每天都會有 Daily scrum 這是一個15分鐘的討論 
這名子非常有意思 每天的scrum 是怎樣的意思呢
scrum 是經驗主義 , 開發需求變化快速的產品
所以加上每天之後的意思會是
這24小時 我們做得如何 這樣有幫助到達成Sprint Goal 嗎
讓已經發生的24小時 ( 經驗 ) 看看我們的計畫 猜測 是否在通往實現Sprint Goal的路上
哪邊不如我們預期的 ( 變化快速 ) 馬上反應出來 
這給了團隊每天一個 檢核 的機會 , 跟 遇到問題解決問題的時刻 也就是 調適
我覺得Sprint planning 是計畫 這次的 Sprint 
那 Daily scrum 就是 檢查過去24小時的成果 計畫下個24小時 ,如何 達成Sprint Goal
是依照計畫呢 還是情況有變 
當然三個問題 是一個讓開發團隊很好上手的方式 只是要知道為何要問那三個問題

這樣的Sprint 到尾聲 會有兩個檢核的機會
一個是檢核 產品 的 Sprint review 也就是把這次Sprint我們想要交付的價值
給相關人士了解這次Sprint 實現怎樣的價值  並且得到回饋 
看是要操作一次給大家看 還是 讓大家自己實際用看看 這就看個組織了 
相關人士 最重要的是 能夠代表使用者的人 或是 最理解使用者的人 如果這些人都沒有的話
這 Sprint review 就會沒有辦法 發會出它的價值 沒辦法提早得到 最接近使用者 回饋
最好可以請到使用者代表 但我知道 這是非常困難的
團隊需要好好收集這回饋 product backlog 是否要調整 優先順序
開發團隊哪裡不夠細心 沒有注意到這是 使用者在意的點

另一個檢核 團隊 的  Sprint retrospective
開發團隊 這次Sprint Goal有達到嗎
產品負責人 相關人士都很喜歡這次的小增量嗎
哪邊的流程很奇怪 或是 很不順 拿出來討論
小增量的品質好嗎 發現的Bug多嗎 如何能夠改進呢
上次說卡住一小時就馬上求救 這樣的方式 成效如何
產品負責人 說會提供更多資訊 讓開發團隊 能理解為何要做這樣的東西 有做到嗎 效果好嗎
有很多可以 檢核 團隊的 跟提出改進項方法 也就是 調適

這樣一個Sprint結束後 團隊會交付一個 可以釋出的小增量
至於要不要釋出 就看產品負責人或組織的決定 
然後馬上就是下一個Sprint 的開始

打太多了 這大概就是我兩年多理解的 scrum 的 理論篇

哪天心血來潮 再來打個 實踐篇  或是 補一下上面挖的坑

推薦好文
團隊導入Scrum會遇到的30個問題  ( 問題都非常真實 但解法 請不要照抄 每個團隊都有不同的處理方式 )

Scrum Master使用Coaching的這回事

為自己學習成為 Scrum Master 的經驗分享