On May 15th, I participated in a lecture on continuous delivery, agile, and DevOps in practice, some of which were very inspiring. Several viewpoints (ideas, principles) have been sorted out for sharing.
- Continuity of development in agile iterations, should not be demarcated (begin or end) with a distinct iteration
- Automated testing strategy: http://lzhted.iteye.com/blog/2212646
- Deployment mode: http://lzhted.iteye.com/blog/2213844
This article introduces the first point (principle): The continuum of development in agile iterations should not be divided (beginning or ending) by a clear iteration.
Before introducing the new principles, we briefly describe our current situation and challenges.
Our current situation : We take each week as an iteration, and arrange development tasks (story) before the iteration, and developers complete development, testing, and release within a week.
Practical challenges : 1. Because the workload of the requirements and the scheme is not always ideal (there are many size gaps), it takes a lot of work to divide the scheme into suitable workload and verifiable stories. This can be considered a waste. 2. Each iteration only plans and implements the development tasks of this iteration. When a story exceeds the workload of the iteration or the dependencies are complex, it will be completely arranged in the next iteration, and the current iteration will be idle, the subsequent iterations will be busy, or even overdue. question. Refer to the example below: 6 stories with dependencies are scheduled to be completed in 3 iterations, and the first and third iterations are wasteful.
The following is the point of view of this article: If we make changes to ensure the continuity of development in agile iteration, and do not limit the development process of tasks by iteration, the entire iterative process will be shown in the following figure:
In the new iteration plan, the first iteration still only delivers A and 1 development tasks, but the second iteration can deliver all development tasks. It can be considered here that iteration is phased for external (delivery) and continuous for internal (development). Continuous development tasks make the developer's development rhythm more stable and efficient.
However, this also brings new challenges: 1. Does the unfinished work B need to be submitted at the end of iteration one? 2. How to post unfinished work. That is, at the end of the first iteration, how should task B be delivered, which is only half done?
The answer to the first question is yes, any development work must be submitted in a timely manner. So how do you commit and publish unfinished work? There are two things you can practice:
- Design common feature switches. Unfinished work will be filtered through the feature switch. Note: a. Use the feature switch only when there is no other way, otherwise it is preferred to filter by feature hiding. b. When the job is complete (feature activated), remove the switch.
- Programming based on abstractions (interfaces). Even if the dependent logic is not implemented, the system can compile and run normally.