David Ko的學習之旅

有人常問說, 如何檢查到底 scrum 到底有多深入, 這裡有份簡單的檢查清單

1. 我們有產品負責人,scrummaster和開發團隊嗎？
2. 我們有排好順序的產品需求清單嗎?

在進行 scrum 時, 有一個常見困擾大家的問題, 就是什麼叫做一個功能已經完成. 如果不是真的做完, 或者做完的結果並不是讓人滿意, 我們需要早點知道, 以做出因應的事情.

那我們會怎麼處理呢? 常見的做法如下:

在 Scrum 中有個 review meeting, 是在 sprint 最後時舉行, 在這個會議中通常要進行 demo, 來展示所完成的功能. 可是有些人發現即使 demo 完後, 產品還是無法 release, 這是怎麼回事?

個人覺得 review meeting 的作用應該是以下事情
1. 檢視功能是否客戶要的

昨天在 Lean Coffee 聚會時, 有人問到當 sprint 時間要到, 可是 story 還沒做完, 是否要結束. 這是一個很好的問題, 因為這是一開始執行 scrum 的團隊, 必定會遭遇的問題, 即使是很有經驗的團隊也會碰到.

首先, 我們先來看如果延長會有什麼問題:
1. 有可能不知道什麼時候會結束

scrum 最大的問題，是無法在iteration 內徹底完成預計完成的功能。

大多以為程式寫完就好，可是往往無法通過測試，需要花大量時間在修復bug,或是重工來處理誤解或遺漏的功能。無法儘可能的一次到位。

因此如何讓在開發時, 就能寫出正確的程式碼，和符合客戶需求的功能，是團隊改進的主要方向。

站立會議的時間?

在 SCRUM 中站立會議是, 每天同步資訊和及時解決問題不可或缺的元素. 因此你需要固定好開會時間, 開會的地點, 以方便會議的進行, 和讓大家養成習慣.

通常書上或是blog上, 會說這會議的時間最後在早上, 也就是一天開始的時候. 這時候大家來談昨天做了甚麼, 今天要做甚麼, 以及遭遇了什麼問題, 會是有意義的, 因為時機點和這三個問題是相配合的. 因此我也對此不成文的規定, 堅定不移.

可是隨著所帶領的專案越多, 或者說遭遇更多不同的團隊後, 覺得一早開站立會議似乎不見得都適用.

在台灣很多高科技公司是責任制, 也就是可能上班不用打卡, 可是可能要做到半夜. 對於這樣的團隊, 若是你還規定 9 點或是 9 點半開站立會議, 似乎對於團隊士氣是種打擊. 也許站在專案經理的角度, 你想要求團隊成員有較長的工作時間, 並且加上Scrum 站立會議問題和時間的搭配性, 因此你可能會堅持在這個時候開會.

隨著時間的轉移, 越來越體會到士氣高昂的團隊, 和有品質的工作時間, 是遠遠比一早開會還重要.

回顧會議的重要性 (The importance of retrospectve meeting)

上週五, 我們團隊招開了第一次回顧會議, 個人覺得效果很好, 把平時沒說的話都說了出來, 或許不見得沒有保留, 但至少跨出了第一步.

你可能會很驚訝, 為何會是第一次? Scrum不是每次sprint完後都要舉行一次回顧會議?

是的. 這是目前我們的困境. 我們專案是由兩個小組所組成, 平時溝通並不是很密切, 兩個小組在不同樓層, 不同的軟體開發流程(一個waterfall like, 一個scrum like), 不完全相同的老闆, 因此彼此累積了不少問題.

很多時候我們都急著想要去交付東西, 急著趕上進度, 可是卻沒有時間思考. 沒時間問問自己, 做這些事情有幫助我們的產品大賣嗎? 那些是顧客要的嗎? 或者如何驗證那些是客戶要的?

甚麼時候不適合使用scrum

When Not to Use Scrum
http://www.scrumcrazy.com/When+Not+to+Use+Scrum
author: Charles Bradley

很多人常常問我, 甚麼狀況下不適合使用scrum. 因為很多人認為他們的project, 適不適合使用scrum的.

組織影響學習結果

最近在看蕭老師所寫的"讓脈絡思考創新"一書, 其中有一段話讓我感觸深刻.

他提到在分析脈絡時, 要考量組織的作為. 因為組織的所發展出來的運行原則, 會影響創新運行的有效性.

就像武俠小說中的屠龍刀, 一般人拿到只能耍耍花槍, 只是一把鈍兵器. 當武林高手拿到後, 應用他原先的內功或招式, 才能變成一把真正的寶刀.

拿到推行 scrum 這件事情上面, 也有同樣的結果.

目前台灣有那些Scrum的教育訓練課程

小弟特地上網查了一下, 發現目前在台灣, 對於Scrum or Agile的相關訓練, 還真是少的可憐.

1.XP/Agile敏捷式開發實作班
小弟開的課程.
http://www.iiiedu.org.tw/ites/AgileXP.htm

Ken Schwaber 和 Jeff Sutherland對Scrum Guide的修正

Ken Schwaber and Jeff Sutherland Release Updated Scrum Guide
http://www.infoq.com/news/2011/07/UpdatedScrumGuide

Ken Schwaber 和 Jeff Sutherland 在2010二月時, 對Scrum Guide 做了一些更新, 它是一份獨立的檔案, 並沒有整合到原先的 Scrum Guide.

在這分文件中, 提到有些改變很有趣:

常見Agile不容易實施的緣因

1. 用waterfall的方式來run sprint
雖然名稱叫agile,但是所有工作都是循序進行，要等前一項做完，下一項才能接著做. 需求分析完,才能架構設計。架構設計完才能寫程式，程式寫完才能做測試。自然永遠都無法如期完成,  測試永遠被壓縮或是放在下一個sprint.

2. 不知道如何拆解user story
每次都是一個很大的功能,要放進兩週的iteration. 不知道可以拆解成小的user story.或者拆解完後不知道架構設計要怎麼做。因此往往一個sprint要一個月或一個半月，才能完全開發完畢，但是測試還是要下個iteration才能做完，並且也沒有時間修改上個iteration的bug.

Succeeding With Agile讀書會

目前在Facebook的Scrum in Taiwan的community, 發起一個讀書會.

是針對Succeeding with Agile" Software Development using Scrum這本書. Schedule規劃如下:
7/9 Ch14(David),
7/16 Ch15 (David),
7/23 Ch11 (Sam Ku)

產品擁有人的十個主要工作

Top 10 Activities of the Product Owner
http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner

1. 建立和維護產品的 backlog

2. 根據商業價值和投資報酬率, 排定 backlog 的優先順序

3. 持續把 epic, theme, 和 feature 展開成使用者故事, 好讓其詳細程度可以足夠在一個 sprint 內完成.

之前和朋友討論, 發現在實施 Scrum 時, 一旦執行不順的時候, 團隊成員或是經理們, 常常認為是 Scrum 的問題, 以下是早期常見的現象: 

1. 想把 Scrum 用在所有的地方