什麼是需求呢? 根據維基的定義, 需求是軟體開發時應滿足的功能與非功能要求.
在傳統瀑布式的開發中, 我們是靠著產品經理, 或者是系統分析師, 撰寫詳細的需求文件, 然後交給開發人員進一步去做設計.
在這過程中, 我想大家一定遇到這些問題:
目前分類：Scrum (126)
- Mar 24 Tue 2015 20:56
對談可以幫助繳出更好的需求
- Mar 22 Sun 2015 19:52
Scrum 對於需求的想法
- Mar 01 Sun 2015 11:06
Scrum 團隊是開發團隊嗎?
Scrum 開發方法中, 包含三個角色: Scrum Master, 產品負責人(Product Owner), 和團隊. 很多人對於團隊要包含誰, 常常有不同的見解. 那到底正解是什麼呢?
從 Ken Schwaber 和 Jeff Sutherland 所撰寫的 Scrum Guide 中, 便對這件事情做了說明. 他們把團隊分成了兩類:
- Feb 24 Tue 2015 22:05
只有 Scrum 流程還不夠
很多團隊或公司實施 Scrum 並不順利, 明明就是很簡單的 framework, 道理也很清楚, 可是卻做不到 Scrum 所說的境界, 為什麼呢?
我想這是因為大家認為 Scrum 就是一種軟體開發流程, 認為只要照著步驟做就好了. 事實上, 這是不對的. 要做好 Scrum, 你必須考慮到組織模式, 以及實施的人們. 缺乏這兩個, 是無法成事的.
- Sep 21 Sun 2014 21:47
Scrum Master 和 Product Owner 到底在幹嘛?
在剛學習 Scrum 時, 很多人對於 Scrum 的角色, 要做哪些事情感到非常困惑, 今天就讓我們來聊聊到底他們要做什麼.
Product Owner
很多人看到有 product 這個字, 就覺得他就是要做專案管理, 因此就認為他負責管時程, 要求大家做事情. 並不是這樣的, 他最主要的工作如下:
- Sep 17 Wed 2014 23:33
驗收標準和做完的定義的比較
很多人對於驗收標準 (Acceptance criteria) 和做完的定義(Definition of Done) 搞不太清楚, 覺得他們似乎很相像. 但是事實上這其實是兩回事. 讓我們一一道來
驗收標準 (Acceptance criteria)
- Sep 15 Mon 2014 22:58
小柯講古 - Scrum 打從哪裡來
雖然很多人在學習 Scrum, 但是可能不知道是怎麼來的. 那就讓小柯今天來講講古吧.
很多人小時候應該做過實驗吧, 課本上一定會叫你要控制變因, 一次只有一個假設, 然後進行實驗, 分析當初的變因帶來什麼影響, 是否和原先假設相同.
- Sep 12 Fri 2014 06:42
Scrum Master 的工具箱
最近又重新溫習的 CSPO (Certified Scrum Product Owner), 這一次聽到了 Scrum Master 經常使用了哪些工具
1. 給範例
在很多狀況下, 團隊都不知道要怎麼進行 scrum, scrum master 需要利用身教, 來展示 scrum 要怎麼做. 像是 Daily Scrum 時, 要如何跟大家同步訊息, 如何主持這樣的會議等等. 讓大家可以學習和模仿.
- Jun 23 Mon 2014 08:01
retro 事件簿 - agile 是否有比較快的疑問
謝謝你在會議中提出問題, retro 的目的就是要講真話, 要讓有問題的事情早點講出來, 早點處理. 需要的是團隊成員對專案的向心力, 願意把事情做好的思維. 這些你都表現得很好.
你對於 scrum 做法是否能幫助團隊加速有疑慮, 我想這是正常的, 因為我們並沒有加速, 而且問題很多.....
- Apr 07 Mon 2014 07:01
Scrum 的困境
之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:
1. 基本消費額太高
在每個 sprint 中, Scrum 要進行 planning meeting, daily standup meeting, review meeting 和 retrospective, 很多人在抱怨都一直在開會, 2 周的 iteration 其實不是兩周, 可能只剩下 7-8 天而已. 如果再加上要參加別人的 review, 或是公司的會議, 那其實沒有多少時間在工作上面.
- Mar 10 Mon 2014 06:44
如何在 scrum 中處理緊急的插單
在實施 Scrum 時, 最常遇到的一個狀況, 就是忽然說有急件, 希望團隊可以趕快處理.
根據 Scrum 的定義, 在 iteration 中途, 是不能再加功能, 也不能變更iteration 的長短.
- Mar 06 Thu 2014 06:37
推廣敏捷也是要考慮使用者經驗
最近選舉到了, 都是一堆候選人的新聞. 其中看到有人在 FB 上 po 某個候選人所的話, 他提到了, 施政必須重視使用者經驗. 也就是任何政策的制定, 應以方便民眾使用或方便民間部門做事為出發點, 而非方便政府管理或方便公務員好做事
先不管這個候選人怎樣, 但是我想到的是, 這個情況不只在公家單位有這樣的思維, 我們自己開發產品, 或是在推廣敏捷時, 是不是也犯了同樣的問題.
- Feb 20 Thu 2014 06:56
Scrum 只是個 framework ...
有些人提到, 為什麼大家執行 Scrum 感覺起來差這麼多? 這是一個很有趣的問題.
首先, 先跟大家澄清, Scrum 只是個 framework, 因為在這個 framework 下你可以選擇自己的實施方式.
例如: Scrum 要求要有 product backlog, 並且裡面的需求要照優先順序排好. 這些是 Scrum 要求的. 但是他並沒有說 product backlog 要怎麼寫, 你可以用 SRS, use case 或者 user story, 只要你排好優先順序, 並且可以在一個 iteration 內完成. 我想就可以了.
- Feb 10 Mon 2014 06:42
你執行 Scrum 有多深入?
有人常問說, 如何檢查到底 scrum 到底有多深入, 這裡有份簡單的檢查清單
1. 我們有產品負責人,scrummaster和開發團隊嗎？
2. 我們有排好順序的產品需求清單嗎?
- Jan 20 Mon 2014 06:38
如何檢查做完
在進行 scrum 時, 有一個常見困擾大家的問題, 就是什麼叫做一個功能已經完成. 如果不是真的做完, 或者做完的結果並不是讓人滿意, 我們需要早點知道, 以做出因應的事情.
那我們會怎麼處理呢? 常見的做法如下:
- Jan 13 Mon 2014 06:00
Scrum of Scrums 的缺點
通常我們在大規模使用 scrum 時, 會利用 scrum of scrums 來處理多個團隊之間同步資訊的問題.
什麼是 scrum of scrums 呢? 當你有很多人時, 根據 scrum 的經驗, 大約每個團隊的人數是 7 +/- 2 人, 因此會把一個很大的團隊, 拆解成多個小小的團隊 (或者是 feature team).
- Dec 25 Wed 2013 06:58
Review meeting 的目的是什麼
在 Scrum 中有個 review meeting, 是在 sprint 最後時舉行, 在這個會議中通常要進行 demo, 來展示所完成的功能. 可是有些人發現即使 demo 完後, 產品還是無法 release, 這是怎麼回事?
個人覺得 review meeting 的作用應該是以下事情
1. 檢視功能是否客戶要的
- Dec 20 Fri 2013 09:55
sprint 做不完時是否要延長
昨天在 Lean Coffee 聚會時, 有人問到當 sprint 時間要到, 可是 story 還沒做完, 是否要結束. 這是一個很好的問題, 因為這是一開始執行 scrum 的團隊, 必定會遭遇的問題, 即使是很有經驗的團隊也會碰到.
首先, 我們先來看如果延長會有什麼問題:
1. 有可能不知道什麼時候會結束
- Nov 22 Fri 2013 15:20
Unit testing + ATDD 是 Scrum 成功的要素
scrum 最大的問題，是無法在iteration 內徹底完成預計完成的功能。
大多以為程式寫完就好，可是往往無法通過測試，需要花大量時間在修復bug,或是重工來處理誤解或遺漏的功能。無法儘可能的一次到位。
因此如何讓在開發時, 就能寫出正確的程式碼，和符合客戶需求的功能，是團隊改進的主要方向。
- Oct 16 Tue 2012 06:57
QA 團隊單獨執行 Scrum 的困難
