Difference between revisions of "Review Techniques"
(→How in detail) |
(→How in detail) |
||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
Review documentation. | Review documentation. | ||
| − | [[Image: | + | [[Image:Review.png]] |
== How == | == How == | ||
| Line 9: | Line 9: | ||
'''The dish''' | '''The dish''' | ||
| − | Review of documentation | + | Review of documentation |
'''Ingredients''' | '''Ingredients''' | ||
| − | * | + | * All produced documents |
'''Process''' | '''Process''' | ||
| − | The EUDP | + | The EUDP review is a method that distinguishes itself by transferring other people's knowledge and experience to the construction/product which is to be developed. Be it software, hardware or mechanics. The purpose of a review meeting is to consider and discuss the methods used by the developer to solve a specific task. At the meeting, you will discuss e.g. defects, weaknesses, or give some good advice as to the further development, etc. |
| − | The review procedure should be applied as early in the project phase as possible. Additionally, you should review on a continuous basis throughout the entire project period. In other words you should hold a review meeting whenever you need to verify your construction/product. | + | The review procedure should be applied as early in the project phase as possible. Additionally, you should review on a continuous basis throughout the entire project period. In other words, you should hold a review meeting whenever you need to verify your construction/product. |
== How in detail == | == How in detail == | ||
| Line 25: | Line 25: | ||
The procedure of a review should be as follows: | The procedure of a review should be as follows: | ||
| − | The developer invites | + | The developer invites relevant colleagues to a review meeting. First, appoint a chairman; it is important that the person is qualified to manage conflicts in a constructive way, i.e. the person must be able to deal with issues professionally with emphasis on the further development of the construction or product in question. Besides the chairman, it can be a great advantage to appoint a note-taker so that the developer can concentrate on the meeting without being disturbed in his thoughts and ideas. Alternatively, it could be a good idea to bring along a dictaphone. |
| − | Remember to provide the | + | Remember to provide the attendees with documentation, diagrams, listed programs and the like before the actual meeting. Thereby, the attendees have the opportunity to make preparations for the upcoming meeting. |
| − | At the meeting the developer explains how the construction/product he has developed works. The colleagues ask questions and try to find defects or weaknesses in the construction/product. | + | At the meeting, the developer explains how the construction/product s/he has developed works. The colleagues ask questions and try to find defects or weaknesses in the construction/product. |
| − | Do not be afraid to review! It is better to discover defects in the construction before it leaves for | + | Do not be afraid to review! It is better to discover defects in the construction before it leaves for production. It is both cheaper and easier to deal with these issues in the construction phase. The earlier the better. |
| − | The | + | The attendees have different tasks at the meeting. In the following, you will find a list of the various tasks depending on your role at the review meeting: |
| − | + | If you are the '''chairman''', you have the following tasks: | |
| + | |||
| + | '''1.''' Make sure that one person finishes speaking before you allow the 'next in line' to talk. | ||
| + | |||
| + | '''2.''' Make sure that the meeting is held in a proper and constructive tone. | ||
| + | |||
| + | '''3.''' If conflicts arise, make sure that an action plan is carried out. | ||
| + | |||
| + | '''4.''' If there is no note-taker, write down notes to give to the developer after the meeting. | ||
| + | |||
| + | |||
| + | If you are the '''reviewer''', you have the following tasks: | ||
| + | |||
| + | '''1.''' Provide a clear picture of the construction/product that has been developed. | ||
| + | |||
| + | '''2.''' Ask the developer how the construction/product has been developed. | ||
| + | |||
| + | '''3.''' Ask elaborating questions which are related to items no. 1 and 2. | ||
| + | |||
| + | '''4.''' Ask why the developer has made certain choices during the process. | ||
| + | |||
| + | '''5.''' Ask questions beginning with: "Why didn't you do...?" | ||
| + | |||
| + | '''6.''' Or ask: "Did you consider ...?" | ||
| + | |||
| + | '''7.''' Look for defects and weaknesses in the construction/product. | ||
| + | |||
| + | '''8.''' Give constructive criticism. | ||
| + | |||
| + | '''9.''' Give positive feedback to the developer, if s/he has developed good solutions. | ||
| + | |||
| + | '''10.''' REMEMBER THAT YOU ARE AT THE MEETING TO HELP! | ||
| + | |||
| + | '''11.''' REMEMBER THAT IT IS NOT YOUR CONSTRUCTION/PRODUCT! | ||
| − | |||
| − | + | If you are the '''developer''', you have the following tasks: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''1.''' Explain the functions of the construction/product in question: Divide the construction/product into smaller parts to give your audience a better overview. Any construction/product can be divided into mechanics, electronics and software. Electronics can be divided into printed circuit boards, which again can be divided into different parts of a diagram. Use the path of the signal, power supply or the like. Software can also be divided into parts such as different classes which are used in the same component, i.e. user interface, etc. | |
| − | + | '''2.''' Do not keep anything secret. | |
| − | + | '''3.''' Inform about the choices you have made. Emphasise the difficult ones. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''4.''' Be open-minded towards criticism. Remember that the participants are present to help. | |
| − | + | '''5.''' Be open-minded towards corrections. Think about your product and its quality. Do not get offended. Appreciate feedback. | |
| − | + | '''6.''' Remember to schedule a new review meeting. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | All of the above are suggestions for the different roles of the attendees at review meetings. At the EUDP project, we believe that reviewing is an essential aspect. Therefore, the EUDP method highly recommends review meetings on a continuous basis throughout the entire project. Many companies have developed their own methods; some follow the international standard 'IEC 1160' and amendment 1 'IEC 61160'. | |
Latest revision as of 10:00, 8 July 2015
What
Review documentation.
How
The dish
Review of documentation
Ingredients
- All produced documents
Process
The EUDP review is a method that distinguishes itself by transferring other people's knowledge and experience to the construction/product which is to be developed. Be it software, hardware or mechanics. The purpose of a review meeting is to consider and discuss the methods used by the developer to solve a specific task. At the meeting, you will discuss e.g. defects, weaknesses, or give some good advice as to the further development, etc.
The review procedure should be applied as early in the project phase as possible. Additionally, you should review on a continuous basis throughout the entire project period. In other words, you should hold a review meeting whenever you need to verify your construction/product.
How in detail
The procedure of a review should be as follows:
The developer invites relevant colleagues to a review meeting. First, appoint a chairman; it is important that the person is qualified to manage conflicts in a constructive way, i.e. the person must be able to deal with issues professionally with emphasis on the further development of the construction or product in question. Besides the chairman, it can be a great advantage to appoint a note-taker so that the developer can concentrate on the meeting without being disturbed in his thoughts and ideas. Alternatively, it could be a good idea to bring along a dictaphone.
Remember to provide the attendees with documentation, diagrams, listed programs and the like before the actual meeting. Thereby, the attendees have the opportunity to make preparations for the upcoming meeting.
At the meeting, the developer explains how the construction/product s/he has developed works. The colleagues ask questions and try to find defects or weaknesses in the construction/product.
Do not be afraid to review! It is better to discover defects in the construction before it leaves for production. It is both cheaper and easier to deal with these issues in the construction phase. The earlier the better.
The attendees have different tasks at the meeting. In the following, you will find a list of the various tasks depending on your role at the review meeting:
If you are the chairman, you have the following tasks:
1. Make sure that one person finishes speaking before you allow the 'next in line' to talk.
2. Make sure that the meeting is held in a proper and constructive tone.
3. If conflicts arise, make sure that an action plan is carried out.
4. If there is no note-taker, write down notes to give to the developer after the meeting.
If you are the reviewer, you have the following tasks:
1. Provide a clear picture of the construction/product that has been developed.
2. Ask the developer how the construction/product has been developed.
3. Ask elaborating questions which are related to items no. 1 and 2.
4. Ask why the developer has made certain choices during the process.
5. Ask questions beginning with: "Why didn't you do...?"
6. Or ask: "Did you consider ...?"
7. Look for defects and weaknesses in the construction/product.
8. Give constructive criticism.
9. Give positive feedback to the developer, if s/he has developed good solutions.
10. REMEMBER THAT YOU ARE AT THE MEETING TO HELP!
11. REMEMBER THAT IT IS NOT YOUR CONSTRUCTION/PRODUCT!
If you are the developer, you have the following tasks:
1. Explain the functions of the construction/product in question: Divide the construction/product into smaller parts to give your audience a better overview. Any construction/product can be divided into mechanics, electronics and software. Electronics can be divided into printed circuit boards, which again can be divided into different parts of a diagram. Use the path of the signal, power supply or the like. Software can also be divided into parts such as different classes which are used in the same component, i.e. user interface, etc.
2. Do not keep anything secret.
3. Inform about the choices you have made. Emphasise the difficult ones.
4. Be open-minded towards criticism. Remember that the participants are present to help.
5. Be open-minded towards corrections. Think about your product and its quality. Do not get offended. Appreciate feedback.
6. Remember to schedule a new review meeting.
All of the above are suggestions for the different roles of the attendees at review meetings. At the EUDP project, we believe that reviewing is an essential aspect. Therefore, the EUDP method highly recommends review meetings on a continuous basis throughout the entire project. Many companies have developed their own methods; some follow the international standard 'IEC 1160' and amendment 1 'IEC 61160'.
