10 Iteration 0_ What should you prepare before starting development? #
Hello, I am Zheng Ye.
Regarding “starting with the end in mind,” we have talked about it from various aspects. You may wonder, if we should have the mindset of “starting with the end in mind,” would the project progress a little smoother if we prepare everything that needs to be prepared at the beginning of the project?
Indeed, this is already a common practice. Today, let’s talk about the practice of preparing the project at the very beginning: Iteration 0.
Why is it called Iteration 0? In today’s age where “agile” is no longer a new term, software teams are already familiar with the concept of iterations. An iteration is a complete development cycle, and the main difference in iterations among different teams is the length of time.
Generally speaking, the first iteration cycle is called Iteration 1, followed by Iteration 2, Iteration 3, and so on. From the name, you can easily understand that Iteration 0 is an iteration before Iteration 1, so we can understand it as the preparation phase of development.
Since Iteration 0 is the preparation phase of the project, we can prepare the various items that need to be prepared in this phase. I would like to declare in advance that the specific content provided here for Iteration 0 is just a basic checklist. After understanding these contents, you can completely expand or adjust this checklist according to the actual situation of your project.
Alright, let’s take a look at what the Iteration 0 checklist I’ve prepared for you includes.
Requirements #
1. Refined Iteration 1 Requirements #
The most important aspect of a project is its requirements, and in Iteration 0, the most important task is to figure out the first step. When we decide to start a project, we usually have no shortage of requirements. It is necessary for us to make decisions about which requirements to implement first and which ones to implement later. The goal of Iteration 0 is to bring these floating ideas down to earth.
After decomposing the requirements, we will have a long list of requirements to be developed. However, at this stage, the requirements are only a list and have not been refined. It is unlikely that all the details can be refined at this stage. If you have experience with the Scrum process, you’ll know that these things go into your backlog.
Next, we need to select the requirements for Iteration 1 based on their priority. The priority is determined based on the Minimum Viable Product (MVP) that we want to deliver, which is determined by the content we want to validate in this iteration. This is a step-by-step process that leads us to the requirements for Iteration 1.
Once the requirements for Iteration 1 are determined, the next step is to refine them to a level where they can be executed. As we discussed in the previous section on user stories, we should have a clear definition of the acceptance criteria when refining requirements.
Therefore, in Iteration 0, we need to determine the requirements for Iteration 1 based on their priority and then refine them.
2. User Interface and User Interaction #
If your project involves a user interface, it is natural to define the user interface in Iteration 0. In addition, another important aspect that should be defined in Iteration 0 is user interaction.
I have seen many teams that only provide the user interface and expect the frontend developers or app developers to implement the user interaction based on the interface. While programmers can implement the functionality, defining the interaction is not necessarily their strong suit. It should be part of the requirements.
Designing a user-friendly experience is an art. We often come across websites or apps that are difficult to use, and they are usually designed based on the programmers’ own preferences.
Nowadays, we can easily find tools for prototyping on the market. With some of these tools, if used properly, we can even achieve a high level of fidelity. If we go a step further, we can even use tools that simulate a server to create the entire interactive interface. As the developer of Moco, a mock server, I am well aware of what a prototype can achieve.
Therefore, for a project with a user interface, the user interface and user interaction should be defined in Iteration 0.
Technical Aspects #
1. Basic Technical Preparation #
When it comes to technical aspects, there are many things that need to be prepared right from the beginning of a project. Some of these are things that you can easily think of, such as selecting the appropriate technologies and determining the basic technical architecture before starting to write code in iteration 1. The database schema should also be prepared at this stage, as you probably already considered.
Indeed, these are all things that should be prepared early on in a project, and they are things that most people think of. Now, let me add some things that you might overlook.
- Continuous Integration
When we talk about continuous integration, the first thing that usually comes to mind is setting up a continuous integration server. That’s correct, but it’s not enough. The key here is actually the build script, because the continuous integration server runs the build script.
So what should be included in the build script? The most obvious thing is the compilation and packaging process. Thanks to modern build tools, they typically include testing as a part of the basic build process.
However, that’s not the only thing that should be included. We should also consider adding more content to the build script, such as building IDE projects, code style checking, common bug pattern checks, and test coverage.
There is also an important aspect of continuous integration, which is the display of the continuous integration status. Why is the display important? How would you know when your continuous integration fails?
A simple solution is to set up a large display monitor and use a CI monitoring software to display the continuous integration status on it. Some teams even use a physical lamp, which provides a stronger sensory stimulus.
In the “Start with the End” module, when we mentioned integration, we only talked about the need for continuous integration. Later on, we will talk about what a good continuous integration should look like.
- Testing
Testing is an interesting thing that programmers both love and hate. Generally, running tests has become a default option in many modern build tools. If the tool you are using doesn’t have this capability, I suggest you add it to your build script.
Adding tests to a project later on can be a painful process. If you include testing as a specification from the beginning, it becomes less painful to write tests while developing, and team members are more likely to follow this development practice.
One way to enforce making testing a specification is to include test coverage in the build script.
When most teams talk about testing, especially among developers, they usually think of unit testing and integration testing. However, “end-to-end testing” that covers the entire system is typically handed over to others or developed by a dedicated testing team.
In today’s software development, there are some other methods that are more suitable for describing these types of tests, such as Behavior-Driven Development (BDD) and Specification by Example. You can think of them as different ways to describe the behavior of a system. Another good practice is that some software frameworks provide excellent support for this type of development method, such as Cucumber. If you have this kind of test, consider adding it to your build script as well.
2. Release Preparation #
- Database Migration
If you are doing server-side development, dealing with databases is inevitable. Whenever you interact with databases, it is strongly recommended to manage database changes.
Managing database changes used to be a challenge for many teams. Fortunately, there are now many tools available to support this, such as Flyway, which allows you to treat each database change as a file. This way, you can put the database changes into version control and easily manage them.
There are several different ways to manage changes. One approach is to have each change as a separate file, while another approach is to have each release as a single file. Each approach has its own advantages, so you can choose the one that suits your needs.
- Release
Technical teams are good at developing features, but often overlook deployment and packaging as part of the early considerations. This also leads to teams becoming flustered and chaotic.
If you automate the deployment and release process from the beginning, your future life will be much easier. If you are using Docker, prepare the first deployable Dockerfile; if you are self-deploying, write a good shell script.
In fact, you will find that all the things mentioned above, even if not done in iteration 0, will still be encountered at various stages of the project. And in most cases, even if you do a good job of these tasks in iteration 0, you will still need to make adjustments later on. However, I still recommend that you do these things well in iteration 0 because it will set the tone for your project, an automated one.
Daily Work #
Finally, let’s take a look at what your daily work should look like in Iteration 1, assuming everything is ready during Iteration 0.
You have selected a task card from the prepared tasks and confirmed a few details with the product manager that you were unsure about. Now you are ready to implement it. You update the latest code from the code repository and start writing code.
This task involves adding a field in the database. You open the development tool, add a database migration file, and run the database migration tool. Everything goes well, and the new field appears in the database.
This is a simple task, and you quickly finish writing the code. You run the build script, but there is an error in the code style check. You fix it easily. Then you run the tests, and they pass, but the test coverage is not high enough. You think to yourself, “I’ve been slacking off and it got noticed.” However, it’s a minor issue, and adding a few more tests will solve it. Everything is going smoothly!
You update the code again and encounter a few merge conflicts. After resolving them, you run the build script, and everything passes. You commit the code.
You stretch and yawn after completing the task and decide to take a short break. Suddenly, you notice that the big screen for continuous integration turns red. You quickly check the code and realize that you forgot to commit a new file. You smack your forehead and promptly add the missing file. After a while, the big screen for continuous integration turns green again, indicating vitality has been restored.
After a good rest, you are ready to tackle the next task.
This is what a typical development process looks like. When you have prepared well in Iteration 0, your subsequent work will be well-organized. Any simple issues that arise will be quickly identified, and everyone will be working in a systematic work rhythm.
Summary #
In this lecture, I introduced the concept of Iteration 0, which is a practice of doing some foundational preparation before the formal development iteration begins. I provided a checklist of my own Iteration 0 preparation, which includes both requirements and technical aspects. You can refer to it to design your own Iteration 0 checklist.
Based on my experience, most new projects are not well-prepared in one or several aspects compared to this checklist. Even if you are not working on a project starting from scratch, by comparing this checklist, you will find areas where the project is lacking and can make targeted supplements.
If you only remember one thing from today’s content, please remember: design your Iteration 0 checklist and give your project a check-up.
Finally, I would like you to consider what content would be included in your Iteration 0 checklist if you were to design one. Feel free to write down your thoughts in the comments.
Thank you for reading. If you found this article helpful, please feel free to share it with your friends.