[Agile] 快速交付價值才是王道

今天讓整個軟硬團隊練習需求切割的過程中,感受到一些有趣的現象,記錄下來與各位分享。這是一個真實存在的需求,但不是實際的時程,藉由這個需求讓團隊練習,也或者說趁此機會同步一下大家的想法。

 

完整需求大概是這樣的操作情境:

  1. 使用者可以在軟體上選擇該系列所有產品。
  2. 選定某個產品後,點擊按鈕可以叫出該產品的所有參數列表,提供使用者選擇。參數約莫數百個,有分群。
  3. 選擇後進行下載作業,完成產品設定。

而上述幾點實際對應到個工程技術大概是:

  1. 透過編輯 XML 描述文件即可達成,一台設備需要一份XML,約莫幾個小時就可以全搞定。
  2. a. 需要設計一個 UI 供顯示參數讓使用者選擇。
    b. UI 顯示的參數必須從 SQL 資料庫取得,團隊內無人熟稔此技術。
  3. 此技術已經完全打通,不需要額外的工程。

我請大家設想的情境為兩週(一個 Sprint)後,可以給使用者什麼產出?大略得到以下幾種答案:

  • 一份合約書,讓使用者明白我們已經排入時程,會在期限內交付成品。
  • 一份投影片,向使用者描述、介紹我們的設計細節。
  • 做一份簡單的 XML,接著先刻 UI,可以讓使用者看到大略的參數選擇介面操作方式。
  • 做一份簡單的 XML,接著先做比較難的技術核心 SQL,這之後換機種也都很有用處,不會做白工。

其中也包含與我想法相同的答案:

  • 詢問使用者,現在最急、最迫切的需求是哪一台產品、哪幾個參數。就只做該產品的 XML,並且有一個很簡單的 UI 能夠裝載迫切的幾個參數。不串 SQL、不設計複雜的 UI,以能夠快速交付最高的商業價值為優先考量。

在這個 practice 中,發現大家的思考方式不盡相同,但卻往往忽略能夠最快交付最高價值才是首要任務。工程師習慣將工作以技術層面切割,一個技術沒有告個段落,對於下一步感覺不太踏實,然而這個習慣往往成為需求切割的盲點。一個可用的軟體,對使用者才具有真正的價值,這是我在 CSM 課程中紮紮實實感受到的。而可用的軟體,重於詳盡的文件,使用者透過實際的操作才能給予真正的反饋,紙上談兵看起來一切都將很美好。

之前瀑布式的開發模式中,已經逐漸形成一種與 PM 對於時程討價還價的模式。PM 要求時程評估,總得先加個一些 buffer 再來討價還價,把所有心力都放在「估計」時程上。然而在敏捷思維中,我們換個方式與 PM (PO) 溝通,我們拆解需求,知道哪一種情境才是使用者現在最急迫與最在意的,擅長縱向的打通功能、盡速交付才是我們的核心競爭力。這已是一個快的打敗慢的世代。

然而,在這個 practice 中我也發現自己對於需求蒐集、訪談技巧不足,談了兩三個小時候,才發現使用者多數的應用情境根本沒有如此發散,好歹後來有想到趕緊收斂回來。期待接下來 David 老師的課程