Skip to main content

We have the following proces: The work for our development team is defined in user stories, for each user story we create a feature branch. Once the development for the user story is done, the user story will be set to ‘ready for review’ and a different developer will review the code changes in the feature branch. This works fine for code, but in most user stories the model is also modified and we want to include that in our review.

The challenge is that it is not always clear what exactly in the model is changed. I know there are different ways to get all modified objects of a branch (Model rights - new objects, Difference analysis, Prepare merge and look at impact), but none seems targeted on the review proces.

So I am wondering, how does your development team review model changes? 
 

Is there a Thinkwise best practise?

Hi ​@PeterKeeris,

I usually choose one of the options you mentioned—starting a merge session to assess the impact. Can't say for sure if this is “the Thinkwise best practice”, but at least is does include all the changes and seems the most suitable to me for now.

I agree that this approach isn't currently focused on the review process. There's already an idea in place to change this:

 

Hi ​@PeterKeeris,

I don’t think there is an optimal solution at the moment. What I usually ask for is a comment related to the user story that includes any changes regarding the model. It is far from perfect and not a catch-all solution but it helps. 

But I agree, when reviewing you don’t want to look at code in isolation but rather at everything that has been changed regarding a specific user story. 
 

I’m not sure if there are any ideas in the community section regarding “branch-review”. But that is what I think we need. A place that lists all changes, code and model that you can review/approve before executing the merge. 

Will you post the idea? I’ll happily advocate for this as well. 

I was posting at the same moment as Jeroen. There is a topic already. 

In addition to the code reviews we require our devs to perform a “technical review” for each user story. During this technical review a developer shows all changes made in the software factory to another developer and explains why certain choices were made.

This definitely isn’t a perfect solution, because it’s easy to miss some important changes and it requires quite a bit of discipline to make it work well. It does result in a nice dialogue about the solutions and it increases the shared team knowledge.

In addition to the code reviews we require our devs to perform a “technical review” for each user story. During this technical review a developer shows all changes made in the software factory to another developer and explains why certain choices were made.

This definitely isn’t a perfect solution, because it’s easy to miss some important changes and it requires quite a bit of discipline to make it work well. It does result in a nice dialogue about the solutions and it increases the shared team knowledge.

I like that a lot, you create good learning opportunities as well. But this does not negate the fact that it would be good to have a formalised way of collecting ALL changes regarding a branch (user story) and be able to put comments against them / have a way of approving them.

Hi ​@PeterKeeris,

I don’t think there is an optimal solution at the moment. What I usually ask for is a comment related to the user story that includes any changes regarding the model. It is far from perfect and not a catch-all solution but it helps. 

But I agree, when reviewing you don’t want to look at code in isolation but rather at everything that has been changed regarding a specific user story. 
 

I’m not sure if there are any ideas in the community section regarding “branch-review”. But that is what I think we need. A place that lists all changes, code and model that you can review/approve before executing the merge. 

Will you post the idea? I’ll happily advocate for this as well. 

This is also how we have implemented it. As part of the development we require devs to write technical release notes that contain all changes made.

This serves 2 goals: peer review and being able to easily find what has been changed for a PBI if we have bugs/problems.

Reply


Terms & ConditionsCookie settings