很多人對於不明確的需求, 或者需求變動, 感到十分痛苦. 在 waterfall 中這件事並沒有說明要如何處理, 因為他一旦需求文件 sign 之後, 便鎖定範圍, 之後便不允許再改了. 接下來便是靠各位經理的功力, 自己找尋方法去處理.
因此, 當 agile 出現時, 大家便很期待, 是否這就是銀製子彈, 只要一扣板機 ... 不不, 只要一旦實行 agile, 這個問題就瞬間被消滅, 是這樣嗎? 在回答 agile 如何處理之前, 必須要先各位聊聊他的原理, 要觀念正確, 才不會有錯誤期待.
敏捷並不是要做得比較快, 他是在強調有能力因應改變. 藉由頻繁回饋和改進, 及早讓不確定的部分變成確定.
很多人以為用了 Scrum, 然後不做任何事情, 需求就不會變, 或者事情就變清楚了. 須知道所謂的頻繁回饋和改進, 就是你要經常地做出一些東西, 跟用戶和主管確認, 才能讓不確定變成確定. 因此, 要做到確定性是要付出代價的.
另外, 也不是頻繁回饋和改進後, 需求就能都了解, 或者是是完整無缺, 只能說降低不明確的風險.
在沒有敏捷之前, 有經驗的管理者所做的事情, 也是頻繁地和用戶確認, 以提高成功的機會. 以前 waterfall 並沒有講這塊, 靠的是各個管理者的經驗. 而現在 Scrum 只是將這個過程, 明文加到開發流程, 變成是 process 的一部分.
需知 Scrum 不是憑空產生, 他也是採用了某些公司或團隊好的做法, 所以以前 waterfall 時代用來解決需求的方法: 頻繁地和用戶確認. 很自然就會把它考量到流程中.
那 agile 團隊中如何把 "頻繁地和用戶確認” 給落實呢? 我們來看看這些常見的手法:
(1) 縮短回饋的週期
很多人一開始實施 Scrum 時, 會挑選 4 週的 sprint, 因為他怕時間太短, 會做不完開發和測試. 他的角度是從開發團隊來思考. 但是在做的東西不知道對不對時, 你把它做的很有品質, 對用戶來說也是無用. 因此你需要較短的 sprint, 做出一點東西, 就讓用戶給你回饋, 或者讓他思考他到底想要什麼.
你會說, 那這樣開發團隊不就有很多溝通代價, 是啊. 不可能你不做任何事, 需求就能清楚.
想想 waterfall 時代, 如果你不能鎖住需求不變, 或者無法確認需求是什麼, 你做得也不是一直找客戶聊聊嗎?
(2) 逐漸展開需求
很多時候一個人的能力是有限的, PO 或者 用戶 不可能憑自己就可以把事情想得周全. 因此可以利用多次且不同人的檢視需求, 讓需求可以漸漸明確和完整.
例如對於每個功能, 可以要求要進行這些事情:
PO 對需求的說明
檢視 UX designer 的 UI mockup,
討論 RD 的架構設計,
review QA 的測試個案
雖然看起來後面三件事是在做 review, 在檢查他們的部分是否有做好, 但是很多時候都是在討論大家對於需求是否有共識. 像 UI 的 flow 是否要這樣走, 是否要呈現什麼, 這是需求. 某些資料進來或是某些操作做發生時, 系統要如何反應, 這是需求. 某些案例通不通過, 還是這是設計, 這也是需求.
這時候不會只靠 PO or SA, 每個人都會幫忙確認需求, 持續越挖越深.
(3) 探索階段和交付階段交叉前進
產品開發通常分成兩個階段: product discovery 和 product delivery. 在探索階段是在確認要做什麼, 而交付階段則是如何有效力把它完成.
傳統 waterfall 流程, 會花一段時間寫出詳盡的流程. 然後就鎖著不動來開工. 如果要等全部寫完, 可能要耗時很久, 並且內容不見得正確.
因此有個折衷的方式, 先給 PO 一個 timebox 的時間去釐清需求, 要釐清的範圍是前 2-3 個 sprint 的內容, 時間一到然後團隊就開始作已經寫好的需求. PO 繼續寫下幾個 sprint 的處理的需求. 也就是利用 spint 0 的概念, 讓 需求早開發一個或數個 sprint.
這樣 PO 不會一次做太多, Team 每次拿到的東西還算具體, 如果不對在 sprint 結束後就可以馬上確認. 算是在進度, 不確定, 和浪費 中取得點平衡.
(4) 利用 agile release planning 去收集問題
有時候老闆或是用戶真的不知道細節, 然後 PO 也覺得需求沒問題. 這時候可以用 agile release planning 的方式(參見 Mike Cohn 的 Agile Estimating and Planning), 找團隊去討論這個 release planning.
此時, 真的要開發的人就會問很多問題, 提出很多考量, 或者是某些假設, 畢盡是他們要做出來的, 他們正常來說會叫很大聲的. 這時候把這些疑問收集起來, 拿回去和客戶和老闆確認, 也是有助於更暸解需求到底要做什麼.
(5) 利用案例說明需求
以前需求規格是利用文字說明系統要做什麼事情. 但可能寫的人文筆不好, 別人會看不懂. 或是讀的人背景知識不夠, 讀不懂寫的人要什麼. 因此, Spec by example 是試圖利用一些範例, 來說明這個需求想要什麼, 會確認一些條件下系統會怎麼運作.
例如 web application 的登入功能.
a. 老闆可能說: 當使用者登入系統時, 需要有認證的功能, 確保是合法的使用者
b. 你可以進一步用幾個案例來確認需求
使用者輸入 “XXXX” (不正確密碼), 系統則顯示”密碼輸入錯誤, 請再次數入. 若是輸入錯誤 3 次以上, 系統將會鎖住 30 分鐘”
使用者輸入 “12@小心” (正確密碼) ,系統則顯示 homepage
c. 然後你就可以根據這些來撰寫自動化
如果當方向還很模糊時, 個人覺得進行 spec by example 代價太大. 因為還不清楚要什麼, 準備自動化是沒必要的. 但是做到步驟 b. 是有機會的.
另外, 也不需要每個功能都做, 對於比較複雜, 或者真的很不清楚的才做步驟 b., 這樣會讓 usr, PO, dev team 三方了解更有共識.
(6) 每次都非用盡全力
如果用戶常常都會亂, 然後你也擋不下他. 這時候有一種作法, 就是保留時間來處理插件.
首先先統計一段時間, 了解用戶多久會要求插件, 每次插件要處理多久. 例如可能大約要 10% 資源處理. 你可以
a. 每次只用 90% 的能量做事. 保留 10% 處理插件.
b. 每次都放掉最後 10% 的事情.
(7) 在範圍不變中處理插件
敏捷雖然強調要面對改變, 但是也不是隨時說變就變.
以前 waterfall 一開始會先確認需求範圍, 一但確認之後, 便鎖定這個範圍, 以此為基礎開始進行後續活動. 所以彈性有限.
Scrum 在這件事情上, 他是從最高優先順序的需求開始做, 每次(sprint)先做一些需求, 得到反應再看看下次要做什麼. 但是在這個 sprint 的時間內, 你是不能在改變 sprint 的範圍. 若是這段時間內一直變動, 對團隊來說, 不但無所適從, 士氣變差, 也會讓要做的飯為品質不穩. 所以他只是在 waterfall 鎖定後不能變, 以及一直都在變 之間, 取得一個平衡. 也就是在 sprint 時間內不變, 但是之後會再重新考量.
但是凡事都有例外, 如果真的被逼急了, 有些
a. sprint 早期
可以利用以物易物方式, 將插件跟等價的功能交換. 這樣還是維持 sprint 範圍差不多.
b. sprint 後期
犧牲 PO 和客戶聊天, 等到釐清需求後, 差不多也是下個 sprint 開始, 也並沒有延遲太多
不過我也聽過一個故事: 有人說 sprint 固定範圍這件事, 正是 scrum 不如以前做法的地方. 以前沒有 scrum 時我說改就改, 但是現在不能馬上改, 這真的很不方便, 很糟糕耶.....
好啦, 今天教聊到這邊. 如果你有更好的招, 歡迎來分享
全站熱搜
留言列表
