The Develop phase focuses on:
The goal: to build upon small, client-approved parts as the project progresses (vs. delivering one large application at the end of the project).
This objective is accomplished by keeping the build up-to-date. To do this, you must consistently demonstrate progress to customers, with their feedback being continuously incorporated into the build.
Doing things the quick and dirty way creates a "technical debt" (code that works but is hard to alter and maintain). In general, it is better to refactor the quick and dirty into a better design now rather than pay the burdensome interest on this debt later.
Technical debt is code that works but is hard to change, expand, and maintain.Doing things the quick and dirty way creates a technical debt, which is similar to financial debt. Like financial debt, technical debt incurs interest. Technical debt interest payments are the extra effort required on future development because of the earlier quick and dirty design choice. You can either continue paying interest or choose to pay down principal by refactoring the quick and dirty design into a better design. Although it costs to pay down the principal, you make long-terms gain by reducing your future interest payments.
Conversely, this metaphor also explains why it may sometimes be sensible to take the quick and dirty approach. Just as a business may incur debt to take advantage of a market opportunity, developers may incur technical debt to meet an important deadline. Effective managing of technical debt allows project teams to keep costs under control and avoid spending most of their future development effort paying crippling interest payments.
A story is "done done" when the stakeholders can use it as they intended. The work is finished, tested, and production ready. Done done includes but is not limited to the following:
Source code management lets team members manage changes to parts of the code or documentation. Scripted builds reduce time devoted to builds.
Source code management allows team members to collaborate by managing changes to different parts of the code or documentation. Scripted builds reduce time devoted to builds. This encourages building often. Teams will decide the frequency and approach to builds:
First, get a story functioning, then refactor to clean up code, and finally focus on performance tweaking.
When working on a story, consider the following ordered steps in this principle.
Make It Work
Program with your mind focused on the story's basic behavior. Just make the feature work. Ensure that all tests pass for that story.
Make It Right
Now that your feature is working (all tests passing), focus on refactoring the code. Tests will provide the necessary feedback. Clear up structural and aesthetic issues, remove duplication, rename variables, and so on.
Make It Fast
Once tests are passing and code is clean, focus on performance tweaking. Use a profiler if possible. Once again, you can feel confident in your changes because the tests will ensure that functionality is not broken.
These steps can be executed one after another or spread over time (across iterations and depending on the story) as the project progresses.
Less code means coding only what is necessary. Avoid over-architecting.
Develop code just for story cards that really add business value, writing only what is needed for a given story. Code the bare minimum to express the prioritized stories without guessing ahead and building reusable code that may not be a priority.
A spike story is a tye of story card used when situations make a normal story card difficult to estimate. It allows the team to try a quick experiment in order to learn and better estimate.
A spike story is a specific type of story card. Use it when the team is presented with an unknown solutions, technology exploration, or high-risk requirement that makes an original story difficult to estimate. The development team runs an investigation, which should be time boxed. The output of a spike story is knowledge.
Spike stories help mitigate architectural risk by giving team members an opportunity to try an unfamiliar solution. They are generally used for learning and estimating purposes and are not typically released to users.
Test-driven development (TDD) requires developers to create automated unit tests before they write the code. Behavior-driven development (BDD) specifies that the unit tests be written in a way understandable by both developers and the business.
Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle. The developer:
TDD requires developers to create automated unit tests that define code requirements before they write the code. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers can use testing frameworks, such as xUnit, to create and automatically run sets of test cases.
Behavior-driven development (BDD) is an evolution of TDD (beyond using story cards to confirm understanding) that seeks to write tests that can be understood by both the development team and the business. BDD relies on the use of a very specific, small vocabulary to minimize miscommunication and to ensure that all participants—the business, developers, testers, analysts, and managers—are of the same understanding and are using a common language.
Refactoring involves restructuring code to make it more maintainable. Refactoring is done to small bits of code at a time and is ideally documented so to minimize problems.
Refactoring is a disciplined technique for restructuring an existing body of code to make it more maintainable and for improving its design. When you refactor you alter the internal code structure without changing its external behavior in order to make it right. Its heart is a series of small behaviors preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it is less likely to go wrong.
The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.
When you identify an opportunity for refactoring, it is ideal to document it. Create a new story card, and so on.
A story card walkthrough is a meeting between developers and the stakeholder most representative of the story. It is the job of the stakeholder here to explain the story card's requirements and the job of the developer to learn the expectations.
The story card walkthrough (also referred to as “domain walkthrough”) is a meeting between the developers and the stakeholder who best represents the story. The stakeholder provides an overview of what is to be designed/developed and explains the requirements. This should also include information that is related to the story but not necessarily part of its implementation. The developer(s) should review all pertinent documentation associated with the story before the meeting. At the end of the meeting the developer(s) should have a complete understanding of exactly what is desired functionality for the story, and what are the expected results.
The time frame and existing understanding of the story card area determine the format of the story card walkthrough. If the task is set for four hours to edit an existing story, a single phone call might be all that is needed. A two-week task about a new story would call for a more extensive, face-to-face meeting that would include the customer experts.
Continuous integration (CI) is the practice of periodically executing automated build scripts (ABS). When integrated with unit tests, CI prevents integration problems by encouraging frequent check ins by developers.
Continuous integration (CI) is the practice of periodically executing automated build scripts (ABS), preferably in short intervals. There are two flavors of CI.
The first flavor states that the system is built by one developer at any given time. Teams adopt various physical tokens signifying the builders’ "right of build.” ABS are still required, although kicking off a build happens manually. Since this version relies heavily on the entire team being collocated, it does not scale well in distributed ITS Iterative projects.
The second flavor of CI relies on a computer background process to poll the code repository in short intervals. The build process is automatically triggered if changes since the last build are detected. In this version of CI, the developer is only responsible to build locally and check in the code. This model is better suited to highly scalable Agile teams since it relies on automated, asynchronous processes to trigger the build. This gives distributed teams early feedback on the status of the system. Non-collocated team members and managers quickly receive the same feedback as the team.
When combined with a comprehensive suite of unit tests, CI helps prevent integration problems by encouraging developers (and testers) to make frequent check ins. Since the build executes all unit tests, it identifies integration problems early for immediate fix.
Scripted Builds/Source Code Management