In 1st Part of Basics of DevOps, we discussed the basics including definition and origin of the terminology. In 2nd Part of Basics of DevOps; misconceptions, principles, requirements, benefits were discussed. In 3rd Part of Basics of DevOps, We Will Discuss About DevOps Team Covering Team Structure, Project Management, Design and Quality Management. The size of a DevOps team can be differentiated individually from project to project by the company. It depends on the company itself, which variant is preferred. Usually, teams are tried to keep smaller in size. It should be a good mix of operations, testing, and development.
3rd Part of Basics of DevOps : DevOps Team
Colleagues should have sufficient professional competence and communication skills, but on the other hand, they should understand the big picture or business value and be able to communicate put the focus.
Advantages of small team :
- The appointments take less time in general because it does not take so long for each team member to voice their opinion on a topic
- Many peoples find it easier to express their opinion to a small group than to a larger crowd
Advantages of big team :
- Several perspectives of the project are considered, as there are several opinions
- The test phases are being tested more thoroughly and in several different ways
Both variants offer advantages and disadvantages. The type of team a company chooses depends on the company’s philosophy.
A general advantage of a DevOps team is that the conflicts can now be resolved and resolved within a team. So there is no blame because the team as a whole has to stand straight for this conflict. So there is also potential for savings in terms of time and trouble. By tackling the problem together in the team, a solution to the problem is found much faster. The matter between Dev and Ops also takes into account non-functional properties of the systems, i.e. issues of security, stability, maintenance and scalability – properties that make a product sustainable and robust. External partners can also be responsible for the successful operation of the application and the new features, not just for providing new features. External partners are often only in contact with the project manager.
The project manager is the one who has a grip on a project within the company, the interface where all strands come together, he has to be able to lead, organize, budget, and withstand a lot of pressure do not lose the big picture.
For the customer, the project manager serves as contact person and advisory body for the technical feasibility. He is in close contact with the entire team. Organizes the various meetings and ensures a regulated communication between the team members. The project manager is always under great pressure, as he is the supervisor or manager of the project. The project manager is responsible for the planning, implementation, acceptance and follow-up of projects.
The communication capability of the project manager is the most important prerequisite for ensuring a good project flow. The project manager must always be transparent and open to the suggestions of the team members.
The design of a software is significantly tied to success. A user-friendly and simple design is one of the main reasons for the success of a software. There are different approaches to how a DevOps team can work on design. In the following, the “Design Thinking” approach is briefly explained: The “Design Thinking” approach is based on the needs of the customer, and if it is to be convinced of the new product, then much should be discussed with the customer about their ideas and wishes divide the procedure into six steps :
Understanding: The DevOps team needs to understand what the customer is having a problem with and which solution he would like. Here the project manager stands by word and deed in consultation with the rest of the team.
Observe: Once the problem is identified, the customer process that needs to be optimized must be thoroughly observed. For this, the customer’s daily business needs to be thoroughly analyzed. The observation is the basis for the successful implementation of a project.
Defining perspective: Now the collected observations have to be analyzed and defined in different perspectives. One can clarify this with a simple example: Although beer is consumed all year round, people do not go to drink beer in the rain and snow The insight: It is not just because of the beer, but because of the beautiful atmosphere favorable having a good time with friends.
Finding Ideas: Ideas are then collected in the DevOps team. This is done by brainstorming or similar. Methods. Outside people are helpful in brainstorming because they often bring in new ideas.
Prototyping: Prototyping is not about testing the alpha version, it helps illustrate the ideas and test them within the audience. The user should get a sense of how the idea or product might work and look later.
Testing: So many prototypes are tested until the customer says it should become one. It is important that the customer is satisfied with the prototypes they have seen and understands the idea behind them.
As a short summary of “Design Thinking” it can be said that it is not necessarily a guarantee for success. But by involving the customer, the chance of being satisfied with the product at the end of the project is increased.
Developers in a DevOps team work much more directly with contacts than “normal” developers. The developers are involved in each meeting and work closely with the project managers and designers.
The keyword for development in the DevOps team is agile development. It’s not just about helpful tools, it’s also about soft skills of the employees. The focus here is on communication and transparency. There are important aspects of agile work organization. A task board and a daily meeting not only ensure that the team makes its work processes transparent, but also fosters understanding for the work of others and ensure that the team solves problems. Furthermore, much emphasis is placed on making the software usable and maintainable. In agile development there should be a work instruction and of course to be so working.
The frequency of releases in the year makes a big difference for developers. In agile development, DevOps pursues the approach of publishing several smaller releases a year. DevOps takes a contrasting approach to the classic big bang with one or two major releases a year. DevOps prioritizes more frequent and smaller releases that can directly and immediately improve the customer experience. This is also called “continuous delivery”.
Also in terms of application type or developer language DevOps is neutral. There are of course preferred languages, but in principle it is possible with any developer language.
Thanks to the close cooperation between these teams in the eternal dispute in IT departments is who is to blame and who is not resolved, as the team is always responsible as a whole for a project.
Quality assurance, like development, has to be more and more agile in its work and in its methods by DevOps. The tests are performed during “the software development lifecycle” and not at a specific time of the project. An important DevOps approach to quality assurance is “Continuous Integration”. This approach allows to run the tests in an isolated environment and instantly communicate the results to the developers. Here is the opportunity to immediately respond to errors and correct them. This method of early error detection and correction is both useful and inexpensive.
For quality managers, there are two levels at which they move. The strategic and operational levels, where the strategic is the classical level. According to DIN ISO 8402, quality management (QM) covers all activities of the overall management task which define the quality policy, goals and responsibilities and realize them through means such as quality planning, quality control, quality assurance and quality improvement in the context of quality management. The operative level deals with the planning and conception of the test cases and tests, the control of the test execution as well as the communication within the project.
If the customer encounters an error during the operation of the software, he will never have to wait long for support and can therefore work reliably with the software. For example, embedded tests usually take place late in the day. As part of this, there is a fundamental choice to postpone the mission due to detected errors or to perform limited tests that risk the defects that occur during production. In a DevOps method, integrated testing would already take place several stages before. Quality assurance is in constant communication with the developers. The project manager must ensure a good working atmosphere within the DevOps team so that communication and transparency are maintained.
Conclusion of 3rd Part of Basics of DevOps
In this part we learned quite important aspects of “inner working” of DevOps like Quality Assurance, Design Thinking, Project Management which is sufficient amount for revise purpose or knowing but not sufficient for a manager or software engineer. It is recommended to go through textbooks on those topics on need. In the next part, we discussed about DevOps processes.