前陣子和朋友聊到敏捷開發與轉型的話題，聊到手邊有經歷過幾個帶全新專案團隊的經驗。
包含團隊一開始沒有跑scrum，到後來團隊很習慣scrum 步調。
這整個過程，回想起來很不容易又很容易。
不容易的是，在緊湊的開發時程中，極度仰賴整個團隊的緊密合作和共識。
容易的是，團隊很open mind，多數成員都願意直接提出問題和進行討論 （雙手合十）。
這段旅程中，也經歷了開發節奏的轉換和sprint 長度的調整，從沒有特意run scrum(POC / idea validation期)-> 5 Weeks --> 3 weeks -> 2 weeks。
趁著還記憶猶新，整理一下當初的背景和當時改變sprint 長度的主要思考決策點，提供給有需要的朋友參考，也歡迎交流討論。
/
以下是幾個sprint 節奏。
題外話，Peggy所使用配合run scrum 的tool 是 JIRA.
Phase 1 : 5 weeks, 其中一週W0 是Plan & Design week
一開始的sprint 長度怎麼決定的？
在對整個團隊介紹Scrum 概念後，前幾件要決定的事情包含了第一個sprint 的長度。
當時有不少討論，最後關鍵決定點是想和主要合作團隊有一致的步調。
因為雙方有不少dependency，在POC 階段其實時有卡卡的感覺。
透過和對方一致的開發步調，比較好抓到何時和對方談需求，大概何時對方可以delivery 給我們。
ex. 大概抓最遲對方Week 0 前，把feature request 和對方提清楚，除非urgent request，一般的需求大概抓五週後on production。
如果對方因為滿載需要晚一些才能給，大概抓十週。大概是這樣的感覺。
在這個階段，我們也定了版號：<Project Name>-<Major Version>-<Minor Version>
在期間每個sprint 結束，團隊都會進行retrospective ，以幫助改善。
以下是其中一次的整理。
很有意思的是，可以看到不同成員間有不同看法。
例如sync up meeting ，當初我們是先訂每週一、三、五。
有成員覺得這個很不錯，同時間也有同事覺得想少一點。
Phase 2 : 3 weeks, 其中前三天是Plan & Design days
在一兩個sprint 後的某次retrospective meeting中，團隊成員提到，五週一個sprint 的步調似乎不符所需。
五週太長了，無法應對中間的需求變動，release 要等五週也太久了。
Week 0 的Plan和設計可能很快就要調整，那預留這設計週就沒有那麼有意義了。
（此時專案尚未建置完整CI/CD flow, 原本是先訂 release 統一在sprint end 上，上之前要經過足夠的測試以確保上線品質）
這時候的討論以及mindset change
- 討論: Change handling / change management
- 做法一：sprint 變短 ( 見 action item)
- 做法二：某些job點數被替換掉
- Mindset change
- More aggressive
- Sync "Dev-Ops" understanding definition
- "Service" mindset, not "Product" mindset
- Drive solution by our own! convince yourself firstly
另外，也把sprint name調整成 <Project Name>-<Sprint No>-<Sprint Start Date> ，以表達更明確的起始日
Phase 3 : 2 weeks, 預留一個下午給 plan & design.
在Phase 2 原本三週的長度，相較原本的五週，團隊已經較能反應變動的需求。
此時，調整成兩週的主要考量是—協作團隊的步調一致性。
在此時，此專案除了原先合作密切的團隊A外，同時間也融入一個由更多不同的小團隊所組成的公司年度策略大專案之中。
由於在其中的組成團隊數已達兩位數，原本溝通複雜維度暴增，而溝通時程沒有接近的步調和語言又更增加困難度。
經由一陣子的磨合與討論，這達兩位數的團隊的leaders 一起決議，如果沒有特殊考量的話，可以的話，一起盡可能調整成兩週一個sprint ，且共用sprint 的format包含sprint no, sprint start date但還保留前面自己的專案名字。
<Project Name> - <Sprint No> - <Sprint Start Date>
其實一開始對於sprint 長度改成兩週，有點擔心太短，可能會花太多不必要的時間在頻繁的sprint plan/design/review/retrospective等meeting中。
把這個議題帶回團隊中和leaders 一起討論，也決議做一些微調整，迎接兩週的sprint步調。 共識是，先改成兩週讓大團隊間步調一致，成員們在過程中若覺得有不順的、有問題的部分，盡快提出來討論。
中間陸陸續續經歷一些微調整，維持兩週的sprint 步調維持至今。
/
最後聊聊幾個常見討論題⋯
FAQ 1: Software delivery 的步調和 sprint 長度有相關嗎？
Ans: Yes! 正相關！
FAQ 2 : 一般幾週好？
Ans: 都好！ 適合專案屬性和團隊即可，個人建議五週內。
想要快速一點的交付節奏，或應對快速的變動，可以從嘗試讓它短一點開始。
另外，您的專案和哪些團隊合作？合作團隊的步調為何，也是很重要的考量點。
FAQ 3: 為什麼會導入 scrum？開始的契機點？
為什麼Peggy會把scrum 導入團隊 daily work 中？
主要考量點是「團隊開發節奏」與「品質」。
之前在POC/validation 期，考量到團隊還在成型與磨合中，保持開放和彈性。很多時候，有idea就可以先 POC 一下。
到一段時間後，確認是對客戶有價值的，將會是公司正式的Service，Peggy就開始思考以下這些議題。
怎麼讓整個開發更有節奏？
如何Ｒ＆Ｒ可以更清楚？
如何Delivery 更有品質？
...
這時候，導入scrum 就是一個好的時機點啦！
以上為Peggy 的專案經驗和觀點，歡迎交流討論。
歡迎轉貼，禁止商業使用，請註明原文標題、連結以及作者。
沒有留言:
張貼留言