An agile engineering practice

Practical technology

• 用户故事
• 结对编程
• TDD（测试驱动开发）
• 持续集成
• CodeReview
• 发布规则

User story

User story is aA short description used to identify users and user needs。
The typical descriptive sentence is: As a XXX customer, I need XXX function, which can bring XXX benefits.
The user story isDescribe requirements from the perspective of usersA way
Each user story must have a corresponding acceptance test case;
User stories are hierarchical and hierarchical, gradually decomposed and refined during use;

key point

I – Independent，可独立交付给客户
N – Negotiable，便于与客户交流
V - Valuable ，对客户有价值
E - Estimable ，能估计出工作量
S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
T - Testable，可测试

benefit

From the user's perspective, it is convenient to communicate with customers and accurately describe customer needs;
User stories can be delivered independently in units and small in scale, suitable for iterative development to obtain quick feedback from users;
User stories emphasize the preparation of acceptance test cases as acceptance criteria, which can prompt requirements analysts to accurately grasp requirements and lead developers to avoid over-design.

User stories make it easy for the team to decompose and refine requirements from the perspective of users and formulate acceptance criteria

Sample story

Insert picture description here

Story characteristics

Reflect the value of customers (users), a lightweight point symbol
Follow the 3C principle

 卡片（Card）：作为XX，我希望XXX，这样可以XXX
 对话（Conversation）：不描述到细节，由团队通过持续对话细化，激发大家的深度理解
 确认（Confirmation）：有明确的验收标准

card

The traditional form of user story description is a hand-written user story card. There should be only a few sentences on the card to capture the essence or purpose of the requirement.

The usual format: as a <role>, I want <function> to facilitate <commercial value>
Insert picture description here

Conversation

Conversation refers to that the user story recorded on the card can be discussed and refined. It includes stakeholders (customers/users), product owners and development teams to discuss the feasibility of user stories in more detail . After the user story is confirmed by the session, it can enter the development stage (user story realization).

The process of agile development fully reflects the flow of user stories (requirements)

The circulation process of user stories (take Scrum as an example)

1. The person in charge of the product is responsible for organizing the user story and forming the product backlog.
—— User story finishing
2. Release planning meeting: The product owner is responsible for explaining user stories, estimating and sorting them. The output of the meeting is to work out a list of stories to be completed in this iteration, the sprint backlog.
—— User story confirmation
3. Iteration planning meeting: The project team decomposes the tasks of each story. The decomposition standard is to complete all tasks of the story. In the end, each task has a clear person in charge and completes the initial estimate of working hours.
—— User story breakdown
4. Daily stand-up meeting: Every day the scrum master convenes a stand-up meeting, and the team members answer what they did yesterday and what they plan to do today, and what are the questions.
—— User story realization
5. Demonstration meeting: After the iteration, a demonstration meeting is held, and relevant personnel are invited to participate. The team is responsible for showing everyone the results of this iteration. During the period, everyone’s feedback was recorded and sorted by po to form a new story.
——Reorganization of user stories

confirm

User story confirmation can be understood as a test of whether the user story meets the acceptance criteria. User stories require a series of acceptance tests to ensure the completion of the story function and the software running as expected. At the same time, it is necessary to ensure that the final realization of this user story can bring commercial value.
The confirmation of the user story is done by the tester. The tester executes the use cases in the use case list associated with the test version, completes the test, and then generates a test report.
The test report is the most direct manifestation of the degree of realization of the user story. If a use case fails to execute, a bug can be created directly from the test case, and the developer will perform secondary development and repair until the test passes.

User story size level

• Epic story (1-2 months)
• Characteristic story (1-2 weeks)
• Sprint story (1-2 days)
• Task (a few hours): Can be divided into tasks

User Story INVEST Standard

Independent: The stories are loosely coupled, independent, and should not be dependent on other user stories.
Negotiable: It is only used as a placeholder at the beginning, and gradually refined.
Valuable: User stories are valuable to the end user, so they should be written from the user's perspective.
Estimable: The design, development, and test teams can estimate the workload and cost. (Unestimable reasons: too big to be broken down, or incomplete information needs to be further explored)
Small: The story should be as short as possible (such as a two-week sprint, the story is generally within 2 days)
Testable (Test): There are corresponding test acceptance standards.