The practices in this book are organized according to six fundamental principles observed by IBM to characterize the most successful projects in the software development industry.[17] Many of the following principles (see Figure 1.2) are found to some degree in most iterative and agile processes:
Each of these principles is described in a separate chapter giving an overview of the principle, outlining the patterns of behavior that best embody each principle, and listing the most recognizable anti-patterns that can harm software development projects. The primary focus of each chapter is a set of supporting practices that will help your team to adhere to the principle. To provide a more logical sequence for the book, we have chosen to present the chapters in a different order from the alphabetical order in which the principles are listed above. There is no particular significance to the ordering of practices within a chapter. The principles and their supporting best practices are listed below in the order in which they appear in the book.
Demonstrate value iteratively.
Each iteration should deliver incremental capabilities that are assessed by stakeholders. This enables you to get feedback from stakeholders as well as on progress made so that you can adapt your plans as required. Iterative development also allows you to focus each iteration on addressing the key risks that the project is currently facing, allowing you to increase predictability.
Practice 1 Manage risk.
Practice 2 Execute your project in iterations.
Practice 3 Embrace and manage change.
Practice 4 Measure progress objectively.
Focus continuously on quality.
Continuously improving quality requires more than just testing to validate fitness for use. Rather, it involves all team members throughout the lifecyclehaving them build quality into the process and the product. An iterative approach focuses on early testing and test-and-build automation throughout the lifecycle as a means to reduce the number of defects, provide fact-based quality metrics early on, and allow you to plan and adapt your product more effectively based on reality.
Practice 5 Test your own code.
Practice 6 Leverage test automation appropriately.
Practice 7 Everyone owns the product.
Balance stakeholder priorities.
There will always be many competing stakeholder priorities, such as producing a solution rapidly and inexpensively versus addressing all the business requirements. We need to work closely with the stakeholders to make sure that we understand their priorities and to prioritize the right projects and the project requirements. We also need to strike the right balance between leveraging existing assets and building custom software, acknowledging that in some cases the former may require compromising on what requirements to address.
Practice 8Understand the domain.
Practice 9Describe requirements from the user perspective.
Practice 10Prioritize requirements for implementation.
Practice 11Leverage legacy systems.
Collaborate across teams.
We need to enable people to work at their best. This means that we need to equip talented people with the right skills, break down walls that prevent a project team from collaborating effectively, and put in place the right environments to facilitate meaningful collaboration. As software becomes increasingly critical to how we run our business, we also need to make sure that we work well together across business, software, and operational teams.
Practice 12Build high-performance teams.
Practice 13Organize around the architecture.
Practice 14Manage versions.
Elevate the level of abstraction.
Complexity is a major enemy to project success, and minimizing the amount of code, data structures, components, model elements, or other constructs humans produce during a project is crucial to reducing complexity. You can achieve this goal by reusing existing assetssuch as business models, components, patterns, and servicesinstead of custom-building new ones. You can also leverage higher-level languages, frameworks, and tools that can generate code from higher-level models; automate unit testing; and manage the complexity of configuration management. Another approach to reducing complexity is to promote implicity. You can do this by refactoring, keeping code and models clean, and implementing key aspects of the architecture first in what we call architecture-driven development.
Practice 15Leverage patterns
Practice 16Architect with components and services
Practice 17Actively promote reuse
Practice 18Model key perspectives
Adapt the process.
More process is not necessarily better. Rather, you need to adapt the process to the specific needs of your project, based on size, complexity, needs for compliance, and so on. In addition, you need to adapt the process to different lifecycle phases, so you may, for example, use less ceremony at the start of a project and more ceremony toward the end. You must also continuously improve the process, for example by assessing how well it works at the end of each iteration.
Practice 19Rightsize your process
Practice 20Continuously reevaluate what you do
