Wednesday, 27 December 2017

The key to the success of large-scale transformation of the technical organization of the software engineering

Deming's red beads experiments show that in the upstream part of the delivery of unqualified quality circumstances, downstream no matter what approach can not enhance the final output of material quality. Therefore, the implementation of automated testing in this area is a false starting point for change. What become? The second layer of resistance: lack of consensus on the feasibility of the program The  third layer of resistance: lack of confidence in the program to resolve the consensus  of the problem The fourth layer of resistance: fear of new solutions in turn will have new problems The goal of how an organization can achieve change is its transformation program through decision-making. It should be a combination of a series of strategies based on the organization's current situation and underlying causes. For each organization, it should be customized and targeted. Make change happen! Level 5 Resistance: Lack of a clear path to the blockade implementation This is the most common and the most difficult resistance: finally reached a consensus in the upper, passed the program, go to the team to see the delivery of tasks are piled up, how to learn new tools and new ways to learn new tools? Catch up immediately. Often at this time, a well-seasoned master is needed to quickly resolve the team's current problems and "loosen" them so that confidence and prestige can be quickly established and the team can move to a new trajectory. The sixth floor resistance: lack of follow-up This is also the most common ultimate resistance and the reason customers often complain about "coaching" advisors: We want you to bring in the capabilities of a project manager, and do not let us do anything! Large-scale transformation After the success of the startup and the initial success, the next step is to consider the scale of the organization. There are usually two directions:  Vertical Depth: Copy to a team of the same or similar size, business, or characteristics as the pilot team.  Horizontal promotion: For a method, practice or experience, to promote the entire organization. Because it involves a large number of personnel and capital investment, but also involves the adjustment of organizational structure and role, scale has so far been a restructuring of the industry problems. Experience summary:  practice on the ground floor is to have platform-level tools as a support for technical practices to reduce the complexity of organizational input. For the DevOps transformation, there is a need to come down with a set of DevOps tools platforms and standards. DevOps tools platform implementation key First, the foundations of the foundation: version management. As a source of code, it supports the entire build, deploy, test, and release process. Version of the baseline management is already a very backward approach, compared to git-flow, I am more respected Netflix test release product three constant branch respectively support development, release, trunk. hotfix as a temporary branch of online repair.  Developers usually work on the Test branch, its submission can trigger the automatic deployment of the test environment.
 The Release branch is intended for weekly automated deployments by submitting the code to the Release branch, which triggers automated tests and integration tests, which are initiated by a specific member or deployment team and all are automated. After the deployment is complete, the code is automatically pushed to the Prod branch.  If a feature needs to be released immediately rather than through a weekly fixed release process, developers can submit it to the Prod branch, which automatically triggers a merge of Release branches and triggers an automated deployment process that will be immediately deployed if the auditor passes it   Second, the system architecture governance, and even high-level architecture governance, including the language, the framework of the choice of norms, modular refactoring, and so on. To fully assess the debt and benefits of each system, whether the decision is worth sustained maintenance.  The lack of governance and norms of technical organizations, it is difficult to support all systems in a platform, and with a variety of different technologies, systems may become another huge complex project, which in itself runs counter to the DevOps can give organizations The original intention was to deliver the ability to consistently deliver reliable business versions at low cost and short cycles.  Last advice  I worked as a Product Manager + Architect for Continuous Integration Cloud in over 6,000 IT organizations, split and rewritten Jenkins' most critical task scheduling, and log storage expanded horizontally to build performance.  Six months to deliver the beta version of the development support 800 people, one year released to a stable version, supporting more than 4,000 people tens of thousands of daily build release.  Subsequently, as a consulting project leader, a 2,000-person organization was set up to open source DevOps platform and team within two months to support the development and operation of the pilot team.  DevOps implementation of the difficulty lies not in technology, the biggest obstacle comes from the organization is too large, the management of various tools, the implementation is fragmented in various departments, if the organizational level is not consensus and adjust the centralized decision-making, even if the market behind mature DevOps commercial Products, it is difficult to effectively landing within the organization.

0 comments:

Post a Comment