Note: This article is based on the author’s work experience in T and T (correct). Thank you very much
What is Agile development
Agility: The ability to benefit from and respond to change in a volatile business environment.
| Agile thought | The traditional method | |
|---|---|---|
| And the interaction | Is more important than | Processes and Tools |
| Software that works | Is more important than | A document that demands perfection |
| Customer collaboration | Is more important than | Contract negotiations |
| Be ready for change | Is more important than | conventional |
One of the assumptions of agile development is:
Users can not be in the beginning of the design before product development, complete and clear requirements. It is unrealistic to expect users not to change requirements during development. What users want before development may not be what they want in the end. (what? What is the first draft of the proposal? Go through the trash!)
| Waterfall flow development | Agile development | |
|---|---|---|
| Assuming, | Requirements are defined and rarely changed | Requirements are unclear and change frequently |
| Suitable projects | Building houses, Bridges, cars, rockets | Internet product development |
| advantages | 1. Clear progress feedback 2. The implementation process does not require a lot of communication 3. Each process has clear work, strong immersion and high efficiency |
1. Short feedback cycle and rapid response to demand changes 2. The initial requirements for product design are not high 3. It is conducive to members’ overall understanding of the product |
| disadvantages | 1. The cost of responding to change is high, the higher the later 2. The “design” stage is extremely demanding and needs to be comprehensive and professional 3. Long feedback cycle |
1. Need to communicate frequently 2. High requirements for needs assessment and pace control 3. Requirements change affects the development experience |
What is iteration
Run in small steps and deliver continuously
Eric Ries introduced the concept of a Minimum Viable Product (MVP) in Lean Startup Practice — a viable product — the fastest and most concise way to build a working prototype of what your product should look like in the end, then iterate to refine the details.
While the concept of MVP sounds simple, it’s not so easy to implement. Because that’s what a lot of designers do when they’re prototyping a product: they make a list of features that they think the product should have, and then they rule them out, prioritize them, and decide which features should be in the first release and which should be later. But designers often can’t really leave only the most essential features in the first version — there’s just too much temptation. Designers want to impress users with cool, surprising little details, but in the big picture, imposing certain features on a product can undermine the overall smoothness of the product. Mr Jamie, on his blog, once called this psychological manifestation “the artist’s knot”.
What needs to be done in the iteration
In time dimension
Before the iteration
1. Write requirements
Requirements template, for example: as “XXX”, I want “XXX” so that “XXX”
2. Maintain the Backlog
Evaluation priority
- Step1 – importance assessment
| experience | The efficiency of | The quality of | risk | |
|---|---|---|---|---|
| KP demand | 5 | 5 | 5 | 5 |
| High volume | 3 | 4 | 5 | 5 |
| In the business | 2 | 3 | 4 | 5 |
| Low volume | 1 | 2 | 3 | 5 |
- Step2 – emergency assessment
- Step3 – ROI assessment
3. IPM meeting
Iteration Planning Meeting
- Assess workload
- Determine the scope of this iteration
Note: You may try to use “scale” instead of “hours” to assess the workload. It is optional and has the following benefits
| The size of the | Working hours | |
|---|---|---|
| unit | 1(s), 2(m), 3(L), 5(XL), 8(XXL), Fibonacci number | Person/person day |
| assessment | Experience varies, so does assessment | The results vary greatly with different experiences |
| To measure the efficiency | You can see the change in team efficiency from the change in total size | The total amount of working hours is certain, it is difficult to reflect the change of team efficiency |
4. Create a Sprint split task
Each task should have: responsible person, priority, workload (or estimated time), schedule, status, progress, etc
iteration
1. Daily standing meeting
- What did you do yesterday?
- What are you doing today?
- What are the difficulties, obstacles, and risks? (important)
- Updating task Status
2. Iteration progress tracking
For example: Planning => developing => product experience => testing => achieved progress (burnout) chart, story wall, project report (email), etc
3. The test
Templates, workflows, associated requirements, reports
4. Release
- Demand for the check list
- Regression testing
- notice
After the iteration
1. Well & Less Well List
Anonymous feedback, pick the top five
2. Quality statistics
Report regularly
By role dimension
PM Project Manager (Scrum Master)
- Organize IPM iteration planning meetings
Create/plan iterations, requirements estimates, split tasks, assign responsibilities
- Follow up iteration progress
Iterative burn charts, Gantt charts, progress tracking, story walls
- Send the report
Inform iteration progress, transfer test, etc
- Project custom
Menu Settings, templates, workflows, and optional functions
PDM Product Manager
- Management requirements
Create requirements, prioritize, and maintain the Backlog
- Experience function
Follow up the progress, experience function, flow demand
- Handle user feedback
User feedback to demand, bug
DE developer
- Check out my work
My workbench, message notification
- Development needs
Modify requirement status and submit associated code
- To solve the bug
Modify the Bug status
TE tester
- The test execution
Test case writing, test plan planning and execution
- A bug to follow up
Create bugs, verify bugs, and flow bugs
- Analysis of the statistics
Bug statistics and statistics reports
Scrum Practice Reference
values
Some of the wrong practices are most likely due to a lack of understanding of Scrum values, highlighted here: Commitment, courage, focus, openness and respect
The core material
Product Backlog
Product Backlog A Backlog that is maintained by the Product Owner and consists of multiple stories. It maintains all the backlogs that are not included in the Sprint.
Story
- Priority: P0: this month must be completed. (This means that, at the turn of every two months, we need to change priority P1 to priority P0 as a whole.) P1: It means that we must finish it in the next two months. P2: will do it in the future, but not scheduled at the moment.
- Status: PRD ready: We generally assume that the requirements from the Product Backlog have been properly split, produced detailed documentation, and reviewed by (not all) members of the Scrum Team before being allowed to enter the Sprint Backlog, and this state is called requirement Ready.
Sprint Backlog
Sprint Backlog A Backlog that is maintained by the development team. During the Sprint Plan Meeting, the development team determines which requirements (typically Meeting requirements Ready) can be added from the Product Backlog to the Sprint Backlog. In theory, a Sprint Backlog is created for each Sprint; The current Sprint Backlog is updated daily to observe progress, and the exposure risk is assigned an owner (typically RD) for each story, which is then disaggregated by the owner into finer tasks
Task
- Priority is similar to story priority, a more fine-grained priority identifier. Only the relative priority of tasks in the current Sprint is reflected
- Estimation is used to assist scheduling. According to the effective working time of 6 hours per day, the estimated time of a task is generally not more than 12 hours, which means that it can be split again
- Due Date
The completion Date may change every day with respect to the progress, so it is suggested to add a Plan Date for comparison. Risk and progress are mainly reflected by this
- state
Generally divided into: Done, Doing, Todo, Pending, Closed. Depending on the project
- Progress (Optional)
Percentage, a more granular example of progress than Due Date (for Sprint management by Asana) :
The core processes
Grooming
A day “around the midpoint” of each Sprint. PM and RD need to sort out the Product Backlog in advance, Review the stories one by one according to the priority, and adjust the priority when necessary. The meeting usually lasts 1-2 hours. At the end of the meeting, you should generally identify the stories that need to be done for the next Sprint, relative priorities, and a rough estimate of time. The story is allowed to be in the PRD non-ready state.
Plan meeting
The first day of each Sprint. RD needs to be done in advance (also in the meeting) to break down the Grooming ready story into tasks, and to estimate, prioritize and schedule it. Make task adjustment in the meeting, such as front and back end joint adjustment, task dependence, scheduling risk, etc. Depending on the circumstances, an unready story should theoretically not enter the current Sprint. Meetings usually last 30-60 minutes. After the meeting, create a Sprint Backlog for daily site use. Note: Schedule reference
- 2 natural weeks, 10 working days
- 6 effective working hours per day
- A total of 60 hours per iteration
Daily Stand-up meeting
Stand up every morning. Itemize the Tasks from the Sprint Backlog and modify the status, exposing issues and risks. Usually 10-30 minutes.
reference
- From Waterfall to Agile — A Comic interpretation of the changing History of Software Development Models
- Traditional vs. Agile development: There is no going back to the waterfall, no escaping iteration