Release judgment mechanism・Release judgment is also possible two-department meeting or individual judgment

10/12/202020/10/2021Release Judgment

If it is not the first edition, there is also a release judgment by a two-department meeting or individual judgment

In the previous article, I introduced the official review of the release judgment methods . For the release of less important software such as minor feature improvements and bug fixes, Gutara has also used a simpler two-department meeting and individual judgment method than the official review , so in this article these two I will introduce about.

The two-department meeting is a review conducted by the quality assurance department and the development department.

Release judgment by the public review method where related departments gather is a good method with high reliability, but it takes a lot of man-hours because it is a meeting body where many people gather . If 6 people hold a 2-hour meeting, that alone is 6 people x 2 hours = 12 man-hours. In addition, if each participant spends two hours preparing materials for the meeting, a total of 24 man-hours will be required, which is costly .

In the case of the release judgment of the first edition of software that has been developed on a large scale, it is often difficult to judge whether or not it can be released due to high quality risk, so it is better to carry out by the public review method even if it costs a little labor cost. ..

On the other hand, it is a little too expensive to judge the release of the public review method every time, so in the case of small development scale or additional function development, it is the responsibility of two departments , the quality assurance department and the development department. The release judgment was carried out in a meeting-style review in which only the persons in charge related to the person gathered, and this was called the two-department meeting method. Actually, there are quite a lot of release judgments with this pattern.

Information held by other departments should be interviewed and collected before the meeting.

For information such as the market situation of the sales department, future release plans of the planning department, test results of the test department, etc., we will grasp the information in advance by hearing etc. and make a release judgment based on that information.　

Regarding residual bugs , in order to confirm that they do not affect the service provision in the market, what kind of defects will occur in the market as defects caused by residual bugs, and what are the conditions under which the defects will occur ? Ask the development department to explain a little more detailed information such as what kind of recovery method is available when a bug occurs and how often the bug occurs .

Based on that information, we will judge whether or not there is a substantial impact on the service provision in the market even if there are residual bugs, and we will judge whether or not it can be released. For the development department, it is sufficient to grasp the outline of development by looking at materials such as business plans, but in order to efficiently collect information on residual bugs, the person in charge of development is in charge of development as necessary. You may be asked to attend a meeting.

The meeting between the development department and the quality department will end in about 1 to 2 hours if the information on the remaining bugs is organized in advance, although it depends on the number of remaining bugs . For other items, the quality assurance department reads various materials, so depending on the quality of the materials, it can be completed in a few hours to a long time, about a day.

Individual judgment is confirmed by the person in charge of the quality assurance department alone

As the release judgment method, the review method carried out by the development department and the quality department explained earlier was the most common, but the release of the complete bug FIX version software such as only two bug fixes In some cases, you may not even need a review meeting with the development department.　

If the only change from the previous version is two bug fixes, the other bugs still remain. Since the degree of influence of those remaining bugs on the production service was confirmed at the time of release judgment of the previous version, there is not much need to reexamine the influence of the remaining bugs on the service provision in this release, and the development department I don’t often hear about it.

In such cases, the person in charge of the quality department often checks the quality status of the software based on the materials submitted by each department and decides whether or not to release it. Of course, the person in charge of the release judgment is the product insurance department manager, so the procedure for approval of the quality assurance department manager is entered after the person in charge confirms, but the specific release judgment is done by the person in charge alone.

How should I use the release judgment method properly?

We have introduced three types of release judgment methods , but how should we use them properly ? There is no right answer, but as long as time and money allow, the public review method, which is carried out by the relevant departments, is the best.

But, the world is always normal or can work with say if such a thing in the rarely in ,,, always small of the best work being evicted to no cost and short delivery time progresses that is the sad sex of the software industry.　

In my experience, if I leave it to the reality, the result will not be very good, so I decided some conditions to adopt the public review method that the related departments gather and implement , and that condition is satisfied. When you do, it’s a good idea to make a rule that no matter how busy you are or when the delivery date is approaching, you should make a firm public review-type release decision.

Father Gutara had a rule to carry out a public review method release judgment when any of the following rules was established.

1.  When the first edition software is released (when Ver1.0 is released)
2.  At the time of release when additional development of functions with large development scale was performed (at the time of major VerUp)
3.  The software itself is existing, but when it is first released to a new market

In short, when there is a big quality risk in releasing, it is better to collect enough information and check from various viewpoints before deciding whether or not to release, so I feel that I adopted the public review method. is.

I want a tool for release judgment

Now that the person in charge of release judgment has been organized, what kind of tool should be used for release judgment at the end? I will introduce the point.