## 4.11 Development The core of PM2-Agile lies on the development of information systems that are part of the project’s solution. In this context, development activities such as designing, developing, building, testing, turn the specifications turn into something tangible and allow the system to take shape. The main goal of the development activities is to ensure that the requirements are properly designed, implemented and made available through an iterative and incremental approach. The requirements should also comply with architectural, infrastructural and governance constraints and deliver the value expected by the business stakeholders. To help providing the necessary ‘agility’ to the development aspect, PM2-Agile recommends three different but complementary practices: Continuous Integration, Evolutionary Design and Test-Driven Development (TDD). With **Continuous Integration**, team members integrate their work frequently (at least daily). The effort required to integrate a system increases exponentially with time. Therefore, by integrating the system frequently, the overall integration effort is reduced because integration issues are identified and resolved earlier. This results in a higher-quality product and more predictable delivery schedules and activities. The essence of Continuous Integration can be described by the following activities. - After making changes in their validated workspaces, developers will perform unit-tests before making them available to the team. - Change from all developers are merged in an integration workspace and tested frequently (at least daily but ideally, any time a new change set is available). The first activity ensures that changes are made in a configuration that is known to be good and tested before making them available. The second activity identifies integration issues early so that they can be corrected while the change is still fresh in the developer’s mind. The **Evolutionary Design** practice is based on the assumption that design evolves over time. It minimises the need for documentation while still providing guidance for making design decisions and communicating them. During each round of design, developers add, refine, and refactor the solution. This can be summarised by the following. - Understand new requirement details - Identify design elements - Determine how elements collaborate to realise the scenario - Refine design decisions - Design internal elements - Communicate the design - Understand the architecture - Evaluate the design Test-Driven Development (TDD) describes an approach to development in which test cases are created before the actual code. These tests work as guardrails since the code being developed must pass these tests in order to be considered acceptable. Test-Driven Development reduces delivery time by decreasing the time required to integrate and stabilise builds. It improves productivity by finding and fixing errors close to the point when they are introduced. TDD also increases the overall quality of the software by guaranteeing that new developed code has been tested and existing code has been regression tested, prior to check-in. The practice of Test-Driven Development12 changes the way developers think. Developer tests are not written as an afterthought but instead, as part of the everyday way of building software.