Skip to Content

Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 20.1
edited by Erik Bakker
on 2022/08/30 08:28
Change comment: There is no comment for this version
To version 21.1
edited by Erik Bakker
on 2022/08/30 08:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -9,7 +9,7 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -Peer reviews are defined as follows: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. Its a well known and working concept with IT organization, and it can definetely applied in DevOps teams that have eMagiz as one of the technology pillars. In the context of eMagiz, peer reviews are done usually after the Create phase.
12 +Peer reviews are defined as follows: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. Its a well known and working concept with IT organization, and it can definetely applied in DevOps teams that have eMagiz as one of the technology pillars.
13 13  
14 14  [[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
15 15  
... ... @@ -24,8 +24,14 @@
24 24  
25 25  == 3. Running peer reviews in eMagiz ==
26 26  
27 -=== 3.1 Considerations for reviewee ===
27 +=== 3.1 Who and when ===
28 28  
29 +Doing peer reviews increases the quality of the delivered work by the team. This means it is the whole team's responsibility to ensure peer reviews are performed. Following that logic, asking different individuals within your team for other peer reviews makes sense.
30 +
31 +As described below, peer reviews should be conducted for every critical decision when building an integration solution via the eMagiz platform. See section 3.3 for a detailed list.
32 +
33 +=== 3.2 Considerations for reviewee ===
34 +
29 29  Here are some things to keep in mind when presenting the work to peer review.
30 30  
31 31  * Quickly explain the story / task / background
... ... @@ -35,7 +35,7 @@
35 35   ** Don’t show every single detail but try to highlight the important parts and/or details you’re less sure about. This takes time and experience to get “right” and is different depending on the story, the reviewee, the reviewer, the project, etc.
36 36  * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
37 37  
38 -=== 3.2 Considerations for reviewer ===
44 +=== 3.3 Considerations for reviewer ===
39 39  
40 40  Here are some things to keep in mind when peer reviewing the work .
41 41