Please login or join to subscribe to this thread
While DevOps may be a new term, I don't see that this is too much different from what we should have been doing in the past (and perhaps some have been doing in the past)...i.e. building the product of the project taking into account future operational considerations as well... (doesn't mean that the operation itself is part of the project)
If you agree with this thinking, then there is no dramatic additional responsibility for the PM... simply aligning with the new formalized approach called DevOps and doing the old things under a new name and formalized methodology.
Perhaps I don't comprehend the depth of DevOps... so please correct me as needed
While DevOps is not a methodology, it is more than that, I guess the project should end once the requirements as stated in scope document are delivered.
Glad you brought up this discussion! This kind of spins to the popular discussion of Technology-savvy project managers. DevOps changes the way we manage the projects or we manage the delivery of DevOps projects as per our style and standards! What do you have to say?
Thank you. Agree. We should manage the delivery of DevOps projects as per our style and standards!
Infact adoption of DevOps for an organization can also be a project.
I just found a detailed article here. http://www.projectmanagement.com/articles/...DevOps-Projects
DevOps streamlines the software development pipeline. A very basic description is operations support for the development team within the context of the project. It isn't operations as we think of when we end a project and turn it over to an operations group.
In an agile project, code and configuration merges are being submitted frequently (in a well run project, it happens at least once a day) with frequent builds of the entire software package.
In order to keep the development flow moving and consistent this requires a solid framework and automated processes. Usually there is at least a single DevOps engineer dedicated to this. Consider this sample flow for a new feature to see opportunities for automation and linking all the tools together:
1. Developer pulls the latest master code onto their local machine (requires automated virtual machine)
2. Developer alters the code in their local environment, unit tests their work and checks in the code for peer review
3. Peer review is accepted and code is merged into the Integration environment which triggers an automatic build of the software (using a tool like Jenkins)
4. QA engineer pulls down the build from the Integration environment into the QA environment and performs QA
5. Once QA is passed, the test is automated and the script is checked in. Full automated regression is performed on the entire build.
6. UAT engineer pulls the latest QA build into the UAT environment and performs final UAT. Full automated regression is performed on the entire build.
7. Once UAT is passed, the build candidate is deployed into the Production environment where it is set live.
DevOps would be responsible for the setup, configuration, and automation of processes between things like code repositories, virtual machines, environments, build software tools, test coverage tools, monitoring tools, servers, content delivery networks, IP's, and so on. The technology stack alone can be quite large and requires the appropriate tools for the job as well as expertise in the automation suite to ensure the process moves smoothly between tools and environments.
In an Agile context, this is part of the work the development team is responsible for. As a project manager, you'd add stories and technical tasks to support the development process just like you would any feature (I usually keep an Infrastructure and a Continuous Integration epic for tracking these types of tickets). As a PM it's good to be familiar with the infrastructure and the tools because it's part of ensuring project quality. I rely on engineer expertise, so it's good to have an experienced lead architect paired with a stellar DevOps engineer to ensure the rest of the development team can perform their functions seamlessly.
Devops dosent change the way management skills are applied. Its just extension of what was already there, albeit with new name now, DevOps. But this doesnt mean managers will only have to do activities they were doing. With DevOps i think knowledge of ITIL is also becoming important for managers along with PMP.
There is nothign new about DevOps, just another acronym in the industry. It what we been calling for decades, Release Management, or Technical Engineering Management depending on the organization. Any engineered product development lifecycle has to have a technical governance aspect during delivery. As far as impact on a PM, in some environments the PM would be technical enough to give the approval to move from one stage to another, and would facilitate the operational needs of the designers, developers and testers with possibly oversight of these teams. I dont see that changing much. If the PM is not charged with these resposibilities but rather a Release Manager, that role becomes part of the "DevOps" context
I don't agree with you there, Ayman, this is actually quit trendy and important, too, just like Surendar us indicating, it actually redefines the term project. The discussion on devops is a good one, because it may help us in making better products that eventually are a better fit for purpose
I fully agree with Ayman. Old people like me see that nothing new below the sun. The key here is to understand the roles, that´s all. Project management is up to DevOps. DevOps is using as the life cycle model/life cycle process/method to perform the project.
Please login or join to reply