Book contents
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
10 - Enabling DevOps
Published online by Cambridge University Press: 20 October 2018
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
Summary
DevOps is becoming an increasingly popular concept, trying to optimise the product lifecycle, rather than the product development lifecycle, where the development team and service management team are seamlessly integrated. This chapter tries to understand the details of DevOps, issues in the product lifecycle it is trying to solve and how KDD supports DevOps.
What Is DevOps
Before the advent of the personal computers, it was almost the same team that used to develop the software and maintain it, until its decommissioning. The advent of personal computers and other advancements in technology led to the specialisation of skills and the formation of development, quality assurance and service management teams. The IT organisation structure has been based on functional specialisations since then. This structure initiated the development of the popular handover-takeover mechanism to pass information from one team to the other. This mechanism has limited effectiveness, as during handover-takeover, it is practically impossible to pass on all the knowledge that is gathered by one team to the other. Often, the functional splitting of the project acts as a barrier to the work rather than being the enabler of project delivery as widely observed in Waterfall methodology.
The Agile methodology has brought significant improvement in the way software is developed. For example, Agile forms a joint project development team which is co-located and works together for the success of the project. Formal handover-takeover is no longer needed as the teams are physically or virtually co-located. This has made a working style possible that was difficult to imagine a couple of years ago. For example, testers in a Sprint team do not usually raise a defect. They come to developers, discuss and resolve the issue directly, saving a lot of effort in this way.
However, Agile, like Waterfall, focuses on project delivery. Agile hands over the project knowledge in the form of minimal documents and Waterfall hands over exhaustive documentation that may not be kept updated to service management team. Neither of these two scenarios are ideal from the service management team perspective. There is a need to look into optimising the entire lifecycle of the product and not only product development. In the product lifecycle, the three most important stakeholders are:
• Development team (includes business analysts), which develops the product.
• Quality Assurance team, which ensures the product is as per the specifications of the customer.
- Type
- Chapter
- Information
- Knowledge Driven DevelopmentBridging Waterfall and Agile Methodologies, pp. 198 - 202Publisher: Cambridge University PressPrint publication year: 2018