Tips for Software Developers
Agile encourages building software with the end user in mind. It will then help to have a clear and common understanding of this end user within the team. Therefore you can use a so-called persona. Personas represent fictitious people, based on the teams knowledge of the end user. Within this persona you will together write all the details that are of interesting when defining the user stories within your project.
Read More…It is up to the Product Owner (PO) to exactly define what he or she expects from a user story within the Definition of Done.
It is up to the team to challenge the PO to have a proper defined user story.
If in the sprint review the PO isn’t satisfied with the end result, saying he or she expected more, the PO is accountable for the result.
On the other hand the team had also to challenge the PO to ask for what he exactly expected from the story.
Both PO and Team are involved, so both are responsible. If the first one doesn’t take the right action, the end destination of the team is very unsure, so changes are big the result doesn’t fit. A PO who has never got time to answer the questions of the team, isn’t a good fit.
If the team fails, they can be blamed asking the wrong or lack asking of questions. Both faults will come at a cost. But be sure you minimize the costs.
Code reviews are most of the time introduced within a team to have an additional pair of eyes. Developing is a human practice, hence can lead to mistakes. When you’re developing a piece of code, you can miss things like wrong assumptions regarding your design or code that might cause issues. Things that your peer might address.
If you as a developer put your work to review, it feels like that you have to go to a jury and people will judge your work. Although this could feel like this, it is also an opportunity for you to grow as a developer. Other people might have different insights and give you hints and tips to different solutions. It will also catch up issues and typo’s in upfront before delivering.
What does it take to have a productive and good code review? It first starts with good preparation; knowing what the code does and behave before actually starting to review it. Then we can wrap it up and give the reviewer some suggestions that he can look at, without being aggressive.
Let’s go through these steps and look them into detail with some suggestions how to tackle them.
Read More…One of the tasks when writing software, give an estimation of how much a certain feature is going to take to implement. For the Product Owner or project leader or some other internal customer, it will define which features he or she will get within an amount of time. So it will help the product owner with his or her decision-making, whether the feature must be in the upcoming sprint or not.
We can also determine the velocity with a software estimation, creating a commitment for the team to meet the sprint goals. By knowing how much a task is gonna take to implement, we can put that number of tasks within a sprint which can be handled by the team. Not meeting sprint goals will bring the team into a negative emotional state: “whatever we do, we don’t make it this sprint”. So, people won’t even try their best to meet the sprint goals.
Task estimation seems to be a difficult part of our job as software engineers. Most of the times, it takes more time to deliver features than initially estimated. Why is this and what can we do about it?
Show my LinkedIn-profile