Agile 🏈 聊聊增量,PM:需求要擠牙膏地說還是一次全講完?

筆者曾任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌》

前幾天到高雄參加 MOPCON 主講敏捷開發的主題《PM 說我全都要!工程師自救的 7 種拆分需求技巧》,在會後和社群的朋友有很多有趣的討論。當時和我聊天的是一位 PM ,她提到的情境是這樣的:

『 敏捷開發講求增量 (Increment)和迭代,所以開需求的時候我會先規劃一部分,但工程師卻希望我一次把所有需求講完。 』

在向她確認所開的需求都是 End to End 的形式之後,她又提到:

『 可是,當我把全部需求跟工程師講完,對方又說要做好幾個月。』

『 工程師要全部一次做?』

『 對,工程師說全部都要做,沒辦法拆。』

這情況讓她有些苦惱。聽完她的描述,我覺得有兩個地方可以討論,也因為這個題目實在很有趣,因此決定將當時我與她交流的內容一併記錄下來。

▍工程師的不安全感?談談增量是什麼?

At regular intervals, preferably every week or two, the developers provide an integrated, running, tested version of the software, the “Increment”, containing all the features and capabilities which have been completed so far in the project.

— Ron Jeffries

上述是敏捷開發大師 Ron Jeffries 對增量的定義,他談到「增量」是工程師在某時間區間後 (regular intervals) 所產生的軟體,並且是已整合的 (integrated)、可運行的 (running) 、已測試的 (tested) 軟體,以專有名詞來說:

增量就是一個「可用的軟體」 (Working Software)

上圖是敏捷開發中常用的 Scrum 的開發流程,增量它不是微觀上在產品清單 (Product Backlog) 裡的一個條目,而是應該宏觀地看,增量是在一次迭代後,可以釋出的軟體 (見右上角紫色的區塊表示)。又因為增量是在整個迭代過程後大家的最終產物,因此:

增量所涉及的範圍,必須要是團隊的共識。

了解增量的定義後,回到最開始的問題:PM 想要增量地規劃,但工程師希望把所有需求全講完。以過往的經驗來說,工程師會希望把需求講完整,通常是因為不安全感,擔心架構規劃沒有考慮周全。

因為增量必須是團隊的共識,工程師身為團隊的一員,他們的不安全感是需要被解決的。

那麼需求要全部一次講完嗎?

在敏捷開發中,有很多方法論可以協助我們釐清需求,例如:使用者故事對照 (User Story Mapping) 或是事件風暴 (Evenet Storming) 等等。這些方法在概念上來說,都是先把大流程或要完成的里程碑拉出來,細節「有必要時」再陸續補充進去。

舉例,下圖是使用者故事對照的模板,上方的使用者活動 (User Activity) 是粗略的大流程和里程碑,下方的使用者故事 (User Story) 是內容細節。在實作時先完成上半部在補充下半部。

事件風暴也是類似的概念 (如下圖),先把要發生的「事件」定位出來,再根據需要補上細節。

(圖片來源:https://www.lucidchart.com/blog/ddd-event-storming)

特別要注意的是,以上兩個方法在使用的時候:

PM 對細節不用一次全部補完,只要針對團隊 (工程師等等) 有疑慮的地方補上細節即可。

這樣做就可以消弭工程師的不安全感,也能讓工程師做出更好的設計。

其實我們生活中做很多事情也是這樣的。舉個生活化的例子,假設我們規劃要去高雄玩,一開始只會把大流程或要完成的里程碑拉出來,例如要去駁二、逛瑞豐夜市、吃丹丹漢堡等等里程碑。如果對怎麼到達駁二或是怎麼逛駁二才有效率,有很多「不安全感」,可以針對這部分補上細節即可。

在解決增量的問題之後,我們來看看工程師提到需要「全部做」的問題。

▍工程師:我要打全部!但要花三個月

其實敏捷開發很常被人忽略的地方是:

要實現增量 Increment,需要紮實的技術實踐。

前面有提到,增量是一次軟體釋出,並且要做到已整合的 (integrated)、可運行的 (running) 、已測試的 (tested) 。這容易嗎?

因此我跟那位 PM 聊到:

除了糾結自己需求怎麼開之外,更應該去檢視工程師目前的工程實踐。

有以下幾點可以做:

❶ 開發環境 & 程式碼品質

  • 目前可供測試部署的機器足夠嗎?工程師從「開發」到「驗證」的週期是不是太久?導致需求要做很久?如果是,PM 可以幫忙爭取資源。
  • 要做的功能有現有的函式庫或元件可以套用嗎?如果沒有,需要建立共用函式庫等機制,才能讓下次開發更快速。
  • 程式碼的品質怎麼樣?是不是有很老舊的系統,每次改每次痛?如果有,PM 需要安排時間讓工程師做封裝。

❷ 測試

  • 目前工程師團隊有沒有寫自動化測試?
  • 能不能寫出有效的、可維護的測試?如果不能,在無效的測試下,你也不敢釋出,另外,難維護的測試只會把程式碼搞得更複雜,增加維護成本。靠人工測,速度又快不起來了。

❸ 工作切換 Task Switching & 緩衝時間

  • 盤點工程師目前手上的任務,是不是資源分配出了問題,同時兼很多案子? 導致工作切換的開銷過大,因此開發時間較久?
  • 業務端時常有臨時插件嗎?是不是因為常有插件,所以工程師想要預留緩衝時間?

這些議題都是 PM 可以建議或幫忙釐清的,這些問題都一一解決後,才能讓開發時間從一次迭代三個月降到一個月,最後做到兩週一次釋出,達到真正的敏捷。

▍後記

在技術社群裡,面對面的交流往往是最有趣的部分,如果你也對敏捷開發有興趣,可以閱讀我先前寫的其他文章或是訂閱我,在軟體開發的路上,一起交流,一起成長。

若是喜歡我分享的內容,可以訂閱我的粉絲團《程式猿吃香蕉🍌》,在軟體開發的路上,一起分享交流,一起成長。

--

--

我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jayden Lin

Jayden Lin

1.7K Followers

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄