Back

Picscout ‘s development process at a glimpse

July 15, 2014

Home » Picscout ‘s development process at a glimpse

The role of software engineers

At Picscout, each SE takes full responsibility on a task. This is achieved by using the following guidelines:

User stories (can also be refer to as tasks) are written and described in advanced, either by product owner or R&D team, and inserted into a queue.
When a Software Engineer (SE) is available, they pull a US from the queue and start to work on it.
The SE should read the US and verify they understand it completely. For that they may turn to the person who wrote the US, other group members, group leader, operation team or anyone who can help them understand the US.
If the US is not well defined in such way the SE can’t start working on it, they should raise a flag and talk to the person who wrote it. In this case, the US may return to the queue and it will be reviewed again.
US should not take more than 5 days. If there’s a US which we think will take longer, it should be divided into smaller User Stories. It is up to the SE to decide and divide the US.
Once they started to work on a US, they should set a due date for it (no longer than 5 days as discussed previously). This due date helps planning the team schedule and set milestones.
A SE should handle each US end to end. Understanding, designing, implementing, testing and deploying are part of the task.
When a US is finished, it should be flagged as delivered or done. If the US involved code changes, it should be flagged as ready for ‘Code Review’

Code quality

Maintaining our code in high quality is one of our main goals. In order to achieve this goal we use a variety of processes and tools:

Coding skills and analysis

We use code analysis tools such as FxCop and Sonar to give better insight into the code quality at both the developer’s and the project’s levels. At the same time, we put a big emphasis on the human factor:

Code reviews are done on a daily basis
Code reads are done once a week- A team member will show code that he/she has written to a group from R&D and the group will discuss the code (design, architecture, implementation considerations etc…)
Clean code lessons and educational meetings are done every 2-3 weeks
Special events such as hackatons and code retreats are done every 6 weeks

Tetsing

We do not have a QA team. We don’t believe we need one. Why?

Because we believe our software engineers should write code that works – that’s as simple as that.

hat seems like a very naïve idea of how software development can work in the real world. So how can we achieve this goal in practice?

When we develop new code we also develop some layers of testing for it:

Unit tests (Using NUnit)
Integration tests (Using NUnit)
Acceptance tests (using Selenium, Specflow and NUnit )

we do have a small team of automation verification engineers that help us manage and thicken the Acceptance testing layer Some manual testing are sometimes needed of course, and our software engineers do manual testing whenever required.

To support the development of maintenance of our products we also require a very efficient process of CI – this was discussed in our previous post.