Agile development has now become the preferred solution for Internet companies. In order to cope with the rapid changes in the market, our company is also vigorously promoting agile. Recently, I am reading the book "User Stories and Agile Methods". I want to share and spread knowledge while reading. Also strengthen memory.
1. User-based modeling is a good starting point.
The product team can use brainstorming and other forms to dig out the actual or potential users or customers of the product and give them some roles.
When multiple roles overlap, an independent role is formed from the overlapping part.
For example, "operation and maintenance role" and "deployment role" both need to do one thing: to modify data, then we consider a "data modification role" to do this thing, and then "operation and maintenance role" and "deployment role" are both This function is not included.
Then, find a vivid virtual character to replace each character, and let the team know this person as well as a friend around you.
Example: "Borrower role", the representative is "Zhang Qiong", 30 years old, a small restaurant operator. The business has been doing well in the past two years.
When modeling users, you can consider some special groups of people, who can help to find some detailed needs. For example, the old lady needs the screen font to be large enough.
2. Find users.
The ideal way is to be able to find real users of the software and understand their needs.
If the conditions are not mature, you can only find user agents. Different groups of people can act as user agents. However, it should be noted that different user agents view problems mostly from personal needs, and you need to find out some of their temperaments.
Managers of actual users: They may not pay much attention to the details of the product, because they probably don’t do practical operations and don’t know enough about the suffering of the masses; they may pay too much attention to some management functions, such as task scheduling, checking each subordinate The current task completion status, etc., and these functions are probably not the core of the product.
Development managers: They usually lack the actual experience of the software, and their inner driving factor is likely to be business pressure or a sense of achievement, which can easily deviate from the core business value of the product.
Sales staff: Their core value is usually to get as many orders as possible. In order not to lose orders, they always promise "no problem". All kinds of strange things want to be thrown into the product, so that the product has no plan and is easy to meet.
Domain experts: They can usually provide great help in product design, but be careful that they come up with something that is too "tall", ungrounded, and makes the software extremely difficult for Xiaobai users to use.
System analyst: They are creative young people with great ideas. They understand both technology and business, and they are very good user agents. But beware of their paranoia, they may spend two days carefully designing a business process without doing any research at all. The worst result is that in the end, a well-crafted pavilion has to be overthrown, wasteful and painful. .
3. Cut the story.
Most of the traditional cutting methods are divided according to the implementation level or technology stack. For example, a function should be divided into front-end, back-end, and database tasks, or according to the technology stack, it can be divided into java -related, C# -related, and mobile-end tasks.
The biggest problem with this way of cutting is: a single task cannot generate business value, and interdependence makes it impossible to quickly deliver and get feedback.
It is recommended to do vertical cutting. Each story should be a functional closure as much as possible. The completion of a story means that a function can be delivered.
Taking the order submission function of JD.com as an example, its business process is: based on the pre-selected product information, first select the payment method, then select the delivery method, and then submit and save.
Traditional cutting methods may be:
T1: Front-end interaction implementation (choose payment method, delivery method), form submittable order data and submit it to servlet
T2: The background receives the order data, saves it to the database, and gives a success prompt.
Consider a different cut:
S1 : Based on the pre-selected product information, using the default payment method and shipping method, submit the order and save it.
S2：支持用户选择支付方式并保存订单。
S3：支持用户选择配送方式并保存订单。
我们不要写哪种大而全的故事，一个故事只为一种客户编写，只满足其一个小小的业务价值。
编写故事时尽量避免涉及界面的描述，这会诱导开发人员按照某人脑海中印象来实现功能，这实际是把设计意图强加到故事之中，更致命的是会隐含的扩大故事范围。
比如这样一个故事：
在首页的右上方，用户可以看到“注册”按钮并点击它，之后弹出一个对话框，用户录入注册信息后，点击提交按钮，若注册成功就回到首页，并发送激活邮件。
它的问题：
涉及太多的界面信息，它阻止了开发人员或者分析师跟客户做进一步沟通的欲望，也许这样的交互设计是蹩脚的呢？
考虑写成这样也许更好：
在首页醒目位置可以进行用户注册，注册成功需要发送激活邮件，注册失败需要失败提醒。
下期分享：故事估算和制定计划，谢谢围观~~