English | EN 
Based on my work on Beautiful Delivery with autonomous cross-functional teams (for more details, see Use Beautiful Delivery to Speed Up Your Digital Transformation), I have set out to define the different roles in a bit more detail. This time I will focus on what I call the DevOper.
The main responsibility of the DevOper is to create a solid implementation of the end result and make sure that it runs smooth in operation. The role name comes form the term DevOps, and indicates that this is a developer that make the implementation, but also takes care of the operations of what he implements. This used to be two separate roles with very drastic differences in approach. The developer usually wants to push for change and implement new and cool features, while the operator works agains change to keep things as stable as possible. Both are right, of course, and I thing the best compromise is usually achieved when both roles are combined into one person – a DevOper. It’s amazing seeing this in action, when the developer part of this person gets a great idea of some new implementation and says “let’s do this now”, and then the operator part of the same person realizes the consequences of the new implementation running in production and says “well, let’s make sure this is stable, so let’s wait a bit”.
So the main task for the DevOper is to create the actual implementation, which means to create code that correspond to both the functional (user stories) and non-functional (availability, response time, security, etc) requirements. Besides coding the user interface and logic, it most often also includes the data management of SQL or NoSQL databases. Common tools are integrated development environments (IDEs) like Visual Studio and IntelliJ, as well as tools for database management.
Another important task for the DevOper is to create and manage the continuous delivery pipeline, and the ultimate goal is to automate everything. I like to set a goal of one single click to set up the development environment, and then everything should be automated from there. When the DevOper commit code to the source code repository, it triggers an automatic build (compile), which in turn trigger the run of automated (regression) tests, and if those are successful, an automatic deployment (if it’s server components) or an automated distribution (if it’s a client component, like a mobile app or firmware in a connected thing) is made. Common tools are Visual Studio Team Services (VSTS), Jenkins, and HockeyApp.
As the DevOper is also responsible for the run in all environments, including production, it’s important to be familiar with cloud computing. Most organizations are moving to a multi-cloud approach, and therefore it’s vital with knowledge about clouds like Microsoft Azure, IBM Cloud, Amazon Web Services, and the Google Cloud Platform.
It’s a common prejudice that programming can easily be automated, but coding is creative work, and I consider it fine art, just like composing music, painting, and sculpture. Even if computers already try to simulate such work, it will take ages before they will surpass humans.
