When a developer receives a new task
1. Trace upward (align vertically)
1.1 First question
- What is the demand point targeted by this task?
- Who are the users/customers? What are their characteristics?
- What value does this requirement provide to the user/customer?
- What are the conditions for satisfying this requirement?
1.2 The next thing that comes to mind is
- Which release version does this requirement belong to?
- Why does this version need to develop this requirement?
- What are the conditions of satisfaction for this version?
1.3 thought of it three times
- Which characteristic does this requirement belong to?
- What other requirements are there for this feature? What is the relationship to current needs?
- Why is the current requirement necessary to develop this feature in the current version? What will be the impact if it is not developed?
1.3.1 characteristic
Features come from the Feature Tree in "Software Requirements, Third Edition". A feature consists of one or more logically related system functions that provide value to users. The feature tree shows how features are decomposed into smaller feature groups, which are ultimately related to specific user needs and lead to functional requirements.
The feature tree provides a concise perspective on the project and helps managers quickly understand the project scope. It is usually divided into three levels: first-level (L1), second-level (L2) and third-level (L3) characteristics.
Notice: Feature is a non-agile development concept and has certain conflicts with agile development. Personally, I think feature trees are more suitable for product development. If the user stories do not form a feature tree, it may be that the user stories are too scattered.
1.4 thought of four times
- What is the overall goal of the current development business?
- How is the version planned?
- How many features does the current goal consist of? In particular, what features are associated with the current feature?
- What are the satisfaction conditions for the goal?
1.5 thought of five times
- If you continue to think deeply, you can trace it back to product vision, strategy and corporate vision. Since these contents are relatively broad, they will not be expanded upon here.
1.6 think
- If the goal is wrong, the more you do, the more mistakes you make. Developers need to have a deep understanding of the goals, otherwise it is easy to achieve half the result with twice the effort.
- If the value of the task is not high, no matter how well it is completed, it will be difficult to gain recognition from users/customers.
- By the time the task is in the hands of developers, goals and values are often blurred. A common problem with PRDs (Product Requirements Documents) is failure to clearly communicate goals and values.
- To do a good job, you need to be aligned vertically and horizontally. Vertical alignment is the pursuit of goals, and horizontal alignment is the pursuit of related needs. If goals and associated requirements require deliberate pursuit, there is a problem with the process.
2. Task traceability
2.1 For current tasks
- What are the dependencies, assumptions, and limitations of the current task?
- What are the satisfaction conditions for the current task?
- What open questions need clarification?
2.2 user stories
2.2.1 user stories
Once I get the task, I try to understand it through user stories. User stories typically include:
- Users and features: As a *** user,
- Recommended solution: I hope ***,
- Value: For ease of use.
Sometimes one user story does not meet the needs and multiple user stories may be needed. For example, a feature may have users and maintainers, which need to be described separately.
2.2.2 Application scenarios
User stories are more abstract. I will try to write one to three application scenarios to describe the specific usage scenarios of the function. Application scenarios are more vivid, helping to reach consensus among different people and providing a basis for problem solving.
2.2.3 Satisfactory conditions
After the user stories and application scenarios, I will list the conditions of satisfaction (acceptance conditions). Satisfactory conditions need to be communicated and agreed with the business personnel, and the number of suggestions should not exceed 7.
2.3 develop
2.3.1 Estimating and Planning
In agile development, Fibonacci numbers are often used for estimation. I would start by developing a simple plan as a basis for subsequent adjustments.
2.3.2 Association diagram
Before development, I will draw a correlation diagram to clarify the relationships and dependencies between tasks.