Juggernaut Liu

最近好像有流行起 Jeff 當時討論的 Nokia Test Questions

大家都想知道 Scrum Team 怎麼做得更好,我們試著問問自己以下問題吧:

Q1: Iterations

Sprint長度是否小於一個月?

Jugg: 長度太長的迭代失去了應變的靈活性

Q2: Testing

每個 Feature 在 Sprint 結束之前都有測試嗎?

影片中有提到,開發結束之後就有馬上測試嗎?如果有,測試可以 1 小時內測完 ; 如果 2~3 週後才測試,測試需要 1 天。

Jugg: 有些團隊為了個體最佳化,不想讓個體停下來等待,所以都超前部署偷跑新的開發,殊不知這影響了整體最佳化。整體一起完成項目才是最有效率的。

Q3: Specifications

每個 Sprint 的需求是夠小到能讓團隊容易吸收的嗎?能讓團隊方便評估實作與測試嗎?

Jugg: 這其實也有個奧妙的地方,儘管我們都理解把需求切小,然後盡快上線是合理的,但是需求夠小到讓團隊能夠在短週期 Sprint 內開發完並測完,這真的對客戶會造成足夠的影響嗎?還是上了一個不完整的功能反而徒增困擾呢? Feature Toggle 是不是一個可行的方式呢?

Q4: Product Owner

是否有 PO 專門負責管理一個 Product Backlog 嗎?

Jugg: 總是要有個人不斷地整理優先順序,才能夠領導團隊往正確的方向邁進。

Q5: Product Backlog

在 Sprint Planning 開始之前,Product Backlog Item 是否已經是 Ready 的狀態?

Jugg: 沒有 Ready 的項目變數還很大。團隊也不容易估算。

Q6: Estimates

團隊使用相對估算嗎? e,g, Planning Poker。如果使用相對估算可以減少很多時間

Jugg: 對我而言,估算只是初步猜測我能做多少事,估算花的時間越快越好。相對比絕對好。

Q7: Burndown

團隊有沒有透過 Burndown Chart 檢視目前進度?

Jugg: 就算不用 Burndown Chart,團隊也要有辦法知道目前進度。

Q8: Disruption

Sprint 中有沒有碰到插單?

Jugg: 插單在所難免,但真的是必要該插的嗎?

Q9: Team

團隊是不是自組織團隊?沒有人指揮也能自行運作?

Jugg: 大家都是自走砲這再好不過了,只要大家是關心這個團隊,這個產品,團隊間也有凝聚力,向心力,可能就成生出自組織團隊,但要注意的是,自走砲遍地開花有沒有因此讓團隊沒有方向?

根據 Jeff 的看法,大部分的團隊大概達成 40%,如果進步到 60%,將能夠有兩倍的產出,如果進步到 80%,將會有三倍的產出。

我看看我們團隊目前的表現,嗯…. 大概是 25 % 😭 😭 😭 還有很多進步的空間

你們的團隊呢?

如果你喜歡我的文章,歡迎幫我按下拍手,給我一些正向的力量,也歡迎你們分享或轉發給你們的朋友,教學相長,大家一起討論,一起變強 👊👊👊

--

--

當我們在談敏捷的時候,有些人會反映這我們公司不適合啦…

當我們在談敏捷的時候,有些人會反映這太理想化啦…

當我們在談敏捷的時候,有些人會反映這要自組織的團隊才玩得起來啦…

我們或許等不到這樣的環境,那如果從自己開始呢?

今天跟大家聊聊 Manifesto for Agile Software Development

但是今天我們不聊 Agile,今天我們不聊軟體開發。

我們來聊聊怎樣從自己開始,怎樣是正確的做事態度。

投影片

工商服務

每年年底的敏捷盛事 Agile Tour 需要敏捷夥伴們一起來參加,今年很特別的是我們結合了線上與線下。也因為是線上演講的關係,我們這次有 6 位海外的講者跟我們一起共襄盛舉。歡迎敏捷夥伴們一起來學習。

--

--

Juggernaut Liu

Juggernaut Liu

敏捷鬥士,實踐家,追求正確的軟體開發之道。