需求會一直改變, 是再正常不過的事情, 因此如何在需求變動中求生存, 是軟體開發中最重要的事情之一.
waterfall 的作法天生不太適合這個狀況, 因為它一開始需求確認後, 就不太會變. 或者要變動時, 澳召開需求變更會議, 然後再走一次分析, 設計, 開發, 測試的流程. 不但不切實際, 並且反應也太慢.
目前分類：敏捷需求探索 (22)
- May 09 Tue 2023 08:51
對於不斷改變的需求敏捷可以幫上什麼？
- Dec 18 Wed 2019 14:32
[Testing Business Ideas] 假設的說明
做沒人要的功能, 是件很浪費的事情, 因此 hypothesis driven development 是個很重要的概念. 可是大家知道什麼是 hypothesis 呢? 今天就讓我們來聊一聊.
在古代來說, hypothesis (假設) 來自於希臘字 “suppose”, 也就是 ”以為”, “應該是”, 是一種根據知識或經驗的猜想, 可以被用來證明或是反駁某件事情.
何謂好的假設
- Dec 02 Mon 2019 21:51
[The Right It] 如何評估實驗結果 (1)
我們知道要去驗證假設, 避免我們浪費資源去做客戶不要的. 可是這時候可能會遇到一個陷阱: Skin-in-the-game, 也就是受訪者可能沒有切敷之痛, 因此隨意地回答, 導致你拿到沒有用的結果.
那你要如何避免這樣的現象呢?
- Dec 01 Sun 2019 17:46
[The Right It] 驗證假設的工具 - Pretotypes
Pretotype 這個字要怎麼解釋呢? Pre- 通常是指某件事情 A 現在事情 B 之前發生. 所以 Pretotype 就是要發生在 Prototpye 之前的事情. 他就是原型(Prototype)之前的傆型(Pretotype)
Protoype 的目的是要回答我們是否正確地打造這個開發產品, 想要確認一些細節, 一些具體. 比如說:
- Nov 28 Thu 2019 08:14
[The Right It] 如何撰寫你的假設
點子能不能大賣, 在開始實踐之前要先確認, 否則等到做下去後才發現不對, 這樣就會很浪費資源. 為了要能確認點子是否正確, 第一步便是描述清楚你的想法, 唯有清楚描述, 才能被檢視以及進行近一步的測試.
Market Engagement Hypothesis
這裡我們介紹一個作法, 叫做 Market Engagement Hypothesis (MEH), 用來描述市場如何和你的想法或假設互動. 也就是市場、會如何回應或是使用你的點子.
- Nov 28 Thu 2019 08:09
[The Right It] 數據說話? 什麼才是好的數據
- Oct 11 Fri 2019 12:35
SBE 可以彌補 傳統需求文件 的不足
一般需求文件, 開發人員都會覺得寫得不是很清楚, 讓他們誤解客戶或是 PM 的意思, 導致開發過程來來回回, 時間和成本都浪費了.
這時候 PM 可能會跳出來說, 我已經寫得很詳細了, 否則你出來寫寫看, 看看在相同時間和壓力下, 你是否能寫得更好.
沒錯有些 PM 是非常努力, 盡可能把他知道或者所有狀況寫出來, 他們已經做出最好表現了. 但是, 文字描述天生上就容易讓人誤解, 並且有很多漏洞, 所以需要有別的方法來幫忙.
- Feb 14 Wed 2018 08:37
Agile, Lean 和 Design Sprint 的比較
在網路上看到一篇文章(見參考資料), 比較了 Agile, Lean 和 Design sprint, 感覺他的想法很不錯, 因此整理了重點出來.
Agile
(1) 資源: 開發團隊
(2) 著重於: 做出一些東西來驗證想法
(3) 週期: 通常迭代是 1-4 週, 最常見是 2 週
- Oct 10 Tue 2017 11:15
用戶故事真的無法用在傳統合約型的專案嗎?
這個月在新竹敏捷聚會時, 我們舉行了一個有關於用戶故事的撰寫工作坊, 介紹了什麼是用戶故事, 讓大家動手撰寫了一些用戶故事和驗收條件. 希望能讓參與的人, 對用戶故事有基本的認識.
在這次的聚會中, 有人提到在合約型的專案是否可以使用 user story, 那天因為時間不多, 我沒有解釋得很清楚, 所以我特地撰文整理了一下我的想法, 大家可以一起來討論討論.
- Aug 10 Thu 2017 11:25
敏捷需求探索 課後意外篇
星期日我開了一們課程: 敏捷需求探索入門工作坊. 那時候我們實作的題目是關於旅遊的系統. 其中有一組做出的成果, 事後發現居然和目前市面上的產品很相似, 學員感到非常驚訝, 也對於他們自己感到驕傲, 他們的想法真的是可以商品化的.
撞衫的產品: 旅型 (https://travostyle.com/)
下面是學員的成果
- Jul 11 Tue 2017 21:43
故事地圖如何銜接影響地圖
在探索需求時, 其中有一種做法, 就是會用故事地圖(user story mapping)如何銜接影響地圖(impact mapping). 先利用影響地圖制定產品策略, 然後再利用故事地圖列出要做的故事, 並且排出優先順序. 正如下圖所示:
可是真的能接得那麼順暢麼? 在我看來缺少了一些東西:
- Jul 09 Sun 2017 22:53
故事卡片地獄
在敏捷社群中, 我們常常會使用 user story 來描述要做的事情, 並且用它來啟動跟用戶的對話. 唯有深入瞭解客戶要什麼, 你才能做出接近正確的產品.
可是問題來了, 如果你有 200-300 張 user story 呢? 我想對於一個正式的產品, 不是練習的作業, 這樣的數量似乎很正常, 這時候你就會遇到 James Shore 所說的 Story Card Hell 問題.
- Jul 04 Tue 2017 20:52
雙軌政策(Dual Track)的產品開發方式
對於想要結合 Scrum 和用戶體驗, 這篇文章是必看的參考資料. 這是由 User Story Mapping 的作者 (Jeff patton) 所撰寫, 相信有不錯的參考程度. 以下是我整理的一些重點
Dual Track Development is not Duel Track
- Jul 02 Sun 2017 22:31
需求文件不對是正常的狀況
最近在翻閱 Exploring Requirements 一書, 他說到需求難搞是正常的事, 以下是我整理出來他的觀點:
產品開發的工作, 就是將某人的想要 (desire), 轉化爲能夠滿足這個”想要"的產品的過程.
- May 30 Tue 2017 11:32
敏捷需求探索 (8): 在新創事業中如何進行需求探索
有人問到新創事業需要進行需求探索嗎? 因為新創事業都是很未知的, 真的有方法可以探索啊?
老實說, 沒有任何方法論可以明確知道客戶要什麼. 但是, 如果有方法能讓你保持持續改善, 並且提供良好的回饋機制, 這樣的方法就是好的做法.
在 Running Lean 一書中提到, 初創事業可分成以下的三個階段
(1) 問題/解決方案適配 (Problem/Solution Fit):
- May 04 Thu 2017 09:05
敏捷需求探索 (7): 用戶訪談時第一個重點
在繪製完影響地圖後, 因為地圖中有的 who, 很多人接下來便會想要了解這些 who, 也就是我們的用戶. 因此, 用戶訪談往往是第一個活動, 希望透過這樣的過程, 能更清楚知道用戶想要的是什麼.
- Apr 05 Wed 2017 20:06
敏捷需求探索 (6) : 以分鏡圖說故事的方式驗證解法
很多人在用了 story mapping, 列出了產品要提供的功能後, 接下來很多人就會想開工去寫程式了. 這樣做的話, 還是太快了些, 如果在此之前先做的驗證, 可以讓你少走些冤枉路.
有的人會說, 那我們來選出 MVP, 找出最有價值的部分, 先來驗證看看. 這是一個很好的開始. 但是, MVP 要做出來也是要花時間的, 因此我們還需要更簡單, 更省錢的方法, 再做出 MVP 之前再確認一下.
那天在上用戶訪談那門課時, 老師提到一個分鏡圖的方法, 覺得還不錯, 整理下來給大家聽聽.
- Mar 25 Sat 2017 11:16
敏捷需求探索 (5) : 沒有流程的故事要怎麼辦
在敏捷需求探索時, 一開始會用 impact mapping, 描述要產生什麼影響, 以及會什麼要做這功能. 然後使用 story mapping, 依著時間順序, 來述說產品的功能.
這一切看起來都很完美, 不是嗎? 可惜, 天下的事情太複雜, 不太可能用一招, 就可以解決所有問題. 例如: 防毒軟體. 使用者根本不知何時有毒要進來, 不知道他什麼時候已經中了毒, 也不知道中了以後要怎麼辦. 因此, 以時間軸為主的 story mapping 完全無用武之地.
那怎麼辦? 沒有時間順序觀念的產品, 還能使用 story mapping 來進行嗎? 相信有不少人會有這類的問題.
- Mar 18 Sat 2017 09:40
敏捷需求探索 (4) : 招與意之間
在上次敏捷需求探索工作坊中, 還被問到一個問題, 有人提到是否可以單獨來教 user story mapping, impact mapping 和 客戶訪談. 也有人提到 persona, storyboard 這些, 每個都是一門學問, 每個都需要花好多時間學習.
是的, 這些東西拆開來看, 都是很複雜, 都是一門不得了的學問. 需要花時間學習, 才能夠精通.
但是, 我並沒有想分開討論他們, 或者花時間討論每個 practice. 我想要做的, 不是要告訴你, 每個劍招要使到哪個位置. 而是要讓你清楚, 這整個獨孤九劍的劍意為何.
- Mar 05 Sun 2017 17:10
敏捷需求探索 (3) : 如何尋找目標客戶
在敏捷需求探索工作坊中, 另一個困擾大家的問題, 就是要如何挑選客戶. 一開始時, 大家野心很大, 認為自己的產品應該可以賣遍天下, 但真的是是這樣嗎? 讓我們看下去吧.
之前曾經寫過一篇文章: 由技術採納週期來看敏捷推廣.(http://kojenchieh.pixnet.net/blog/post/400902718 ). 那時候提到使用者採用新技術的週期分成五個階段.
