Use Cases 和 User Story 不同之處

Use cases - User Stories: so precious but not the same !
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/


以前在做object oriented/UML 時, 談的都是user cases, 現在在做agile時, 開始改談user story.

可是一開始覺得user story的描述和user case很像, 只是user story長了一點. 然後user story也不會像user case一樣要寫, scenario, pre-condition, post-condition...等等.

總覺得兩者, 說像不像, 總是同中有異.

在網路上找到有人比較兩者之間的差異, 讓我們一起來看看有什麼不同:

1. A user story is a brief description of functionality as viewed by the user (Role → Goal).
- It doesn’t model the interaction between the actor and the system, what the use case does.
- A user story is not a sequence of actions.

2. A user story is short and consist in one or two sentences written in the language of the user
- Example: As a recruiter, I can submit job vacancies. A role and a goal, then it is discussed.
- A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.

3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension

4. User stories are used for planning.
- They play a major role in project estimation and planning (via story points and velocity).
- Use cases are not used for planning, even if you can use “use cases points” technique to estimate project size.

5. User stories emerge faster than use cases; use cases require more time for analysis and writing

6. User stories are more readable than use cases
- Use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template

7. User stories are easier to maintain than a 150 pages Use cases Document

8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details
- Use case is a textual model (associated with diagrams): every thing is written !

9. User stories are in theory written on cards
- Remember the 3 C rule: Card, Conversation, Confirmation
- They’re not intended to be archived unlike use cases.

10. A user story must be implemented and tested in one iteration
- A specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …

11. User stories can be more easily written by a user or customer
- Most of the time use cases are written by user proxies (BA, Consultants …)

12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation

13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !

14. Finally, Use cases and user stories are usually associated with two different methodologies (Unified Process vs eXtreme Programming).
- But you can do user stories in a Unified Process environment !

作者雖然已經有十年使用use case經驗, 但是現在他覺得user story是他的最愛, 原因呢?
* User stories focus on what is really important
* User stories are more appropriate for collaboration
* User stories can perfectly be combined with UX(User eXperience) activities (Personas, Storyboard, Wireframes):
  User stories + UX artifacts = Just enough

看起來user story是比use case, 更有效率想要找出user真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?

kojenchieh 發表在 痞客邦 留言(8) 人氣()

如何進行Sprint 的Demo

How we do sprint demos
from "Scrum and XP from the Trenches - how we do Scrum"

最近要作sprint的demo, 這可是大姑娘上花轎, 頭一遭. 還不知道要怎樣做會比較好. 因此survey了一下, 看看是否有人提說哪些東西要注意的.

在"Scrum and XP from the Trenches - how we do Scrum"一書中, 有提到相關要注意的事情.

首先他談到為什麼要做sprint 的demo,會帶來怎樣的好處:
1. The team gets credit for their accomplishment. They feel good.

2. Other people learn what your team is doing.


3. The demo attracts vital feedback from stakeholders.


4. Demos are (or should be) a social event where different teams can interact with each
other and discuss their work. This is valuable.

5. Doing a demo forces the team to actually finish stuff and release it (even if it is only to
a test environment).
- Without demos, we kept getting huge piles of 99% finished stuff.

- With demos we may get fewer items done, but those items are really done, which is
(in our case) a lot better than having a whole pile of stuff that is just sort of done and
will pollute the next sprint.

接著他列出了在demo時要注意的檢查項目:
1. Make sure you clearly present the sprint goal.
- If there are people at the demo who don’t know anything about your product, take a few minutes to describe the product.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

一個立見分曉的測驗來檢驗Agile化的程度

Quick Poll: A Litmus Test for Agile Development
http://www.scrum-breakfast.com/2008/10/quick-poll-litmus-test-for-agile.html

作者想要知道一個team, adopt agile的程度如何, 到底做的好不好. 因此他整理了一些簡單的Yes/No question, 希望能很快得知到底狀況如何. 他也希望大家能幫他看看是否有遺漏哪些部份. 現在就讓我們來看看

   1. Source Code: Do you use source control?
   2. Build: Can you build in a single step?
   3. Daily Build: Do you make daily builds?
   4. Bug DB: Do you have a bug database?
   5. Fixing: Do you fix bugs before writing new code?
   6. Sched: Do you have an up-to-date schedule?
   7. Spec: Do you have a spec?
   8. Quiet: Do programmers have quiet working conditions?
   9. Tools: Do you use the best tools money can buy?
  10. Testers: Do you have testers?
  11. Intervew: Do new candidates write code during their interview?
  12. Hallway: Do you do hallway usability testing?
  13. Wiki: Do you use a Wiki?
  14. Continuous: Do you do continuous build / test / deploy?
  15. TDDev: Do your tests drive your development?
  16. Pair: Do your developers pair and support each other?
  17. Talk: Does everyone talk to each other, constantly?
  18. Hiring: Does the team select its new members?
  19. Colocated: Is the team colocated?
  20. Testing: Can you test in a single step?
  21. Releases: Have you delivered running, tested, usable functionality to users at least twice in the last six months?
  22. Deploy: Can you deploy in a single step?
  23. Integration: Do you integrate the system at least twice per week`
  24. News: Can you give your boss bad news?
  25. Access: Does it take less than three days from when you have a question to when an expert answers it?
  26. Improvement: Did you get together within the last three months to discuss and improve your group’s working habits?
  27. Retrospective: Does you team conduct a retrospective after every iteration?
  28. User Stories: Do you define the product in terms of user stories?
  29. Acceptence: Do you define acceptence tests before you write code?

如果我有找到作者最後用這些問題的survey結果, 再和大家分享.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在Run Agile時, 如何知道我們一切都上軌道?

Agile development - is our iteration on track?
http://blog.huddle.net/agile-development-is-our-iteration-on-track


作者認為如果只由story point, 其實很難知道team是否一切事情都on track.

過去或許有人列出了一系列的建議的解決方案, 來讓我們知道是否進度是否上軌道, 但是作者一
解釋, 那些方法並不能完全解決我們的需求

方案 1: “使用 iteration / sprint burndown chart.”
- Our signature story point burndown chart tends to look a bit like this

- So we often don’t know if we are going to make it until the last couple of days of the iteration.

方案 2:  所以, 那你們為什麼不以小時(hour)的方式, 來記錄和追蹤task的進度; 以及用小時計的burndown chart來顯示進度?
- We did this for a while.
- It was moderately useful when the team was very new to the process and struggling to deliver.
- But as the team became more experienced and more efficient, the overhead seemed less and less worthwhile.
- As the value decreased, the team’s motivation to supply the data also decreased, so the quality of the data dropped. So, we stopped.


方案 3: “這是Agile的基本常識, 你的daily stand-up meeting會告訴你是否你的team是on track"
- In traditional format stand-ups will not necessarily tell you if you are on schedule to meet your iteration commitment.
- It’s perfectly possible to describe what you did yesterday, list your commitment for the day and report on any blocks, day after day, accurately and honestly, yet still not provide enough information to ascertain whether iteration delivery is on track.
- This is because, typically, developers work on one story at a time, whereas the overall iteration scope consists of a series of stories with resource dependencies, and occasionally, technical dependencies.
- For example, if Bob gets less done than he’d planned in the first couple of days of the iteration, Anto gets ahead and Jenna is bang on track, but Jenna and Bob have a joint story further down the priority list that is dependent on Anto’s story, are we on track to get it done? Who knows!

方案 4: 把你的iteration計畫的更好, 指出每個story何時開始, 何時結束, 誰負責, 有沒有對它建立mini 的project plan
- Please! Remind me, which do we value more – a) following a plan, or b) responding to change?

方案 5: “Well then, if you work on your stories in priority order, and if you work efficiently and sensibly removing blocks as they arise, what does it matter anyway? If unforeseen issues materialise, the lowest priority stories won’t be delivered, and so be it!”
(1) Working on stories in strict priority order is not always practical.
- We do have some skill specialisms within the teams.
- For example, if the top priority stories are all backend development heavy, our UI developers will pick up some lower priority items.
(2) This is a bit of a guilty confession, I just like to know what we are going to deliver before we get to the end of the iteration!


作者知道大家都很期待, 是否他會提出什麼解決方案. 他說很可惜地, 他自己只解決一小部份, 以下是他的作法:
1. We keep an eye on the points delivered day to day and try to spot trends that indicate the iteration is deviating from the normal pattern.

2. If an individual developer wants to log hours against his tasks to help determine if he is on track to meet his personal commitment, he can.

3. We’ve amended our stand-up format a little. As well as emphasising “tasks I committed to but did not deliver yesterday” we also quickly review the overall status of each story at the end, and review priorities as needed.

4. The developers themselves decided to log a simple “target end date” for each story within the iteration, to help retain focus.

5. We do try to work on stories in priority order as far as possible, and use the stand-ups to divert effort from lower to higher priority stories where possible.


kojenchieh 發表在 痞客邦 留言(0) 人氣()

一個sprint 或是iteration 應該要有多長?

How Long should be a Sprint or Iteration ?
http://shishirtech.wordpress.com/2009/01/15/how-long-should-be-a-sprint-or-iteration/

一個iteration要有多長了, 通常是一開始要run agile的人, 所要痛苦掙扎的問題之一. 太短怕做不完, 太長又覺得feedback太慢. 以下是作者認為要考慮的因素:

1. 管理上的overhead
- Each iteration needs a planning meeting/ game to kick start the iteration, closing/ review meeting, and a retrospective at the end of iteration.
- Although one can say that the size of these meetings would depend on the length of sprint, so as long as these meetings comprise say just 10% of overall time available for a sprint/ iteration, it should be fine.
- If meetings are taking longer, then there are generally Process Smells - Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.

2. 回饋和彈性
- Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction - more chances of canceling the sprint and more chances of things being obsolete.

3. 多好的銷售團隊  
- If the marketing team is good, then the product owner will break the stories or tasks small enough to keep sprint/ iteration length small.
- Product Owner would know the worth and priority for each story or task and help the team pick up most important stuff - minimizing stuff thats not needed - helping the team become Agile.

4.團隊能移動多快
- This is generally the most important factor in deciding a sprint length.
- Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves.


通常來說, agile都會要求較短的iteration. 那較短的iteration有什麼好處呢? 以下是作者認為的原因:
1. Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.

2. Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.

3. Shorter sprints or iterations force continuous evaluation regularly and quickly.

4. Shorter sprints or iterations also allows the team to establish an empirical velocity very quickly.

目前我們team是採用2 weeks當做一個iteration, 因為剛開始run, 現在還困難重重, 之後有結果再跟大家報告

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼