Agile Requirements Collaboration (1)
Beyond Story Cards: Agile Requirements Collaboration
http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html
James Shore是"The Art of Agile Development"一書的作者, 在agile是赫赫有名的作者. 他在2005年受邀到Software Process Improvement Network (SPIN)演講. 主題是Agile Requirements Collaboration.
在這演講中, James主要討論的是以下的主題
- what happens before you create the story cards and
- what happens after you create them
但是他並不提story本身的細節
1. 為什麼要 Collaborate?
(1) 這裡他引用"Project Management: The Criteria for Success"的內容, 讓我們知道正確需求的重要性:
Lack of user involvement traditionally has been the No. 1 reason for project failure.
Conversely, it has been the leading contributor to project success.
Even when delivered on time and on budget, a project can fail it it doesn't meet user needs or expectations.
(2) 所以他認為:
user involvement is a key success factor in software projects... in all software projects, agile or not.
(3) Agile development values collaboration because it increases your chance of success.
- 所以作者要調強的是要如何ehance collaboration,來進一步釐清需求. 而不是只有把它寫出來, 貼在牆壁上而已
2. 那stories從哪裡來呢?
(1) On an XP project, that person is usually called the "on-site customer."
- You'll also hear terms like "lead customer" and "product manager."
- I'm going to call him (or her) a "product manager" in this presentation, because it's more in line with common industry terms.
(2) The product manager needs to have a strong, clear vision of the product
- but that doesn't mean he or she is solely responsible for it.
- work with interaction designers, business analysts, real customers, marketers, users...
- has to have a strong sense of vision, to tie all the diverse threads together into a strong, usable product.
- has to know the market well and understand what it needs.
- has to have the political savvy to juggle all of the project stakeholders' demands, and he has to have the authority to make his decisions about priorities stick.
(3) 所以作者覺得XP其中一個最難的地方, 是找到好的product manager
=========================================================
觀眾所提的問題
1. Audience question: What if you don't have anyone with a vision of the product?
Ans:
(1) I haven't encountered that. What I have seen is that people sometimes aren't sure what they want.
(2) They think they know, but when they actually see it running, they realize that they wanted something else.
(3) I think the frequent iteration-by-iteration deployment of agile methods are an important way to help people understand on what they really want, because they get to see the software actually running.
(4) 這裡有作者以前的工作經驗:
- I was on a team where we were working with a customer and we were showing him the product every two weeks.
- We weren't sure that we were really delivering what he wanted.
- Every time we said, "this is really what we're going to deploy!" And he said, "sure, sure."
- And then, about four weeks from release, we said that again and he said, "wait! That's what we're going to deliver? No, no, it's all wrong."
- But it only took us one two-week iteration to change the software to what he wanted. Most of the changes were just user interface changes.
2. Audience question: I think something that's more common is to have too many people with product vision. How do you balance this?
Ans:
(1) That's the product manager's role, to balance the competing visions of all the different stakeholders. You need someone with political savvy to do that.
(2) I've tried a number of different options, such as allocating each group a portion of the iteration budget, having people justify the value of their stories, and they didn't work well.
(3) We spent too much time doing bits and pieces of too many things and never got anything completely done. Ultimately what worked best was just having a product manager make the call.
=========================================================
The "latest responsible moment"
(1) Story card hell
- Story card hell is when you have 300 story cards and you have to keep track of them all. This doesn't work.
- Story cards aren't meant to capture all of the details of your product requirements. They're only supposed to be a sentence or two. At most, a paragraph.
- 作者舉了一個例子
* You have one story card that says "make toast" and another that says "cook bread."
* Is that the same story? Or are they different requirements for completely different parts of the system?
* You can't tell, and you lose track of the overall vision because you're surrounded by trees.
(2) 發生"Story card hell"的徵兆
- A good sign that you're in story card hell is when you start hearing the question, "can we put these in a database?"
- Every customer I've ever worked with wanted to put story cards in a database. That misses the point of story cards.
- If you're worried about losing story cards, you're doing too much with them.
(3) Latest Responsible Moment
- "Latest responsible moment" is a core agile idea.
- The term comes from Lean Software Development.
- The idea is that you want to put off decisions as long as you can: to the latest responsible moment.
- But it's the latest responsible moment, not the "last possible" moment. That wouldn't be responsible.
(4) 為何要用"Latest Responsible Moment"
- The reason we do this is because putting off decisions is cheaper and results in better decisions.
- Money we spend tomorrow is cheaper than money we spend today, and between now and tomorrow, we'll learn more things about our environment and the decisions we need to make.
- Plus, things could change so much that the decision isn't relevant any more.
- If we've spent the time and effort to make the decision, that money is wasted.
- So we wait as long as we responsibly can.
Beyond Story Cards: Agile Requirements Collaboration
http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html
James Shore是"The Art of Agile Development"一書的作者, 在agile是赫赫有名的作者. 他在2005年受邀到Software Process Improvement Network (SPIN)演講. 主題是Agile Requirements Collaboration.
在這演講中, James主要討論的是以下的主題
- what happens before you create the story cards and
- what happens after you create them
但是他並不提story本身的細節
1. 為什麼要 Collaborate?
(1) 這裡他引用"Project Management: The Criteria for Success"的內容, 讓我們知道正確需求的重要性:
Lack of user involvement traditionally has been the No. 1 reason for project failure.
Conversely, it has been the leading contributor to project success.
Even when delivered on time and on budget, a project can fail it it doesn't meet user needs or expectations.
(2) 所以他認為:
user involvement is a key success factor in software projects... in all software projects, agile or not.
(3) Agile development values collaboration because it increases your chance of success.
- 所以作者要調強的是要如何ehance collaboration,來進一步釐清需求. 而不是只有把它寫出來, 貼在牆壁上而已
2. 那stories從哪裡來呢?
(1) On an XP project, that person is usually called the "on-site customer."
- You'll also hear terms like "lead customer" and "product manager."
- I'm going to call him (or her) a "product manager" in this presentation, because it's more in line with common industry terms.
(2) The product manager needs to have a strong, clear vision of the product
- but that doesn't mean he or she is solely responsible for it.
- work with interaction designers, business analysts, real customers, marketers, users...
- has to have a strong sense of vision, to tie all the diverse threads together into a strong, usable product.
- has to know the market well and understand what it needs.
- has to have the political savvy to juggle all of the project stakeholders' demands, and he has to have the authority to make his decisions about priorities stick.
(3) 所以作者覺得XP其中一個最難的地方, 是找到好的product manager
=========================================================
觀眾所提的問題
1. Audience question: What if you don't have anyone with a vision of the product?
Ans:
(1) I haven't encountered that. What I have seen is that people sometimes aren't sure what they want.
(2) They think they know, but when they actually see it running, they realize that they wanted something else.
(3) I think the frequent iteration-by-iteration deployment of agile methods are an important way to help people understand on what they really want, because they get to see the software actually running.
(4) 這裡有作者以前的工作經驗:
- I was on a team where we were working with a customer and we were showing him the product every two weeks.
- We weren't sure that we were really delivering what he wanted.
- Every time we said, "this is really what we're going to deploy!" And he said, "sure, sure."
- And then, about four weeks from release, we said that again and he said, "wait! That's what we're going to deliver? No, no, it's all wrong."
- But it only took us one two-week iteration to change the software to what he wanted. Most of the changes were just user interface changes.
2. Audience question: I think something that's more common is to have too many people with product vision. How do you balance this?
Ans:
(1) That's the product manager's role, to balance the competing visions of all the different stakeholders. You need someone with political savvy to do that.
(2) I've tried a number of different options, such as allocating each group a portion of the iteration budget, having people justify the value of their stories, and they didn't work well.
(3) We spent too much time doing bits and pieces of too many things and never got anything completely done. Ultimately what worked best was just having a product manager make the call.
=========================================================
The "latest responsible moment"
(1) Story card hell
- Story card hell is when you have 300 story cards and you have to keep track of them all. This doesn't work.
- Story cards aren't meant to capture all of the details of your product requirements. They're only supposed to be a sentence or two. At most, a paragraph.
- 作者舉了一個例子
* You have one story card that says "make toast" and another that says "cook bread."
* Is that the same story? Or are they different requirements for completely different parts of the system?
* You can't tell, and you lose track of the overall vision because you're surrounded by trees.
(2) 發生"Story card hell"的徵兆
- A good sign that you're in story card hell is when you start hearing the question, "can we put these in a database?"
- Every customer I've ever worked with wanted to put story cards in a database. That misses the point of story cards.
- If you're worried about losing story cards, you're doing too much with them.
(3) Latest Responsible Moment
- "Latest responsible moment" is a core agile idea.
- The term comes from Lean Software Development.
- The idea is that you want to put off decisions as long as you can: to the latest responsible moment.
- But it's the latest responsible moment, not the "last possible" moment. That wouldn't be responsible.
(4) 為何要用"Latest Responsible Moment"
- The reason we do this is because putting off decisions is cheaper and results in better decisions.
- Money we spend tomorrow is cheaper than money we spend today, and between now and tomorrow, we'll learn more things about our environment and the decisions we need to make.
- Plus, things could change so much that the decision isn't relevant any more.
- If we've spent the time and effort to make the decision, that money is wasted.
- So we wait as long as we responsibly can.
全站熱搜
留言列表
