If you wonder how to make Agile become real. Here is a list of some practices that help us turn Agile into more practical ways. I write them in an alphabetical order. Let’s start ^_____^
- Acceptance Testing
The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day. - Coding Standards
The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style. - Collective Ownership
The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes. - Continuous Integration
Programmers integrate and test the software many times a day. Big code branches and merges are avoided. - Customer Team Member
Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product. - Metaphor or Vision
The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers. - Open Workspace
To facilitate communications the team works in an open workspace with all the people and equipment easily accessible. - Pair Programming
Two programmers collaborate to solve one problem. Programming is not a spectator sport. - Planning Game
XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases. - Refactoring
As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally. - Simple Design
The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming. - Small Releases
Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system. - Sustainable Pace
The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime. - Test Driven Design
Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on. - User Story
A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.
I recommend you all to try this Agile’s practices by gradually changing your company process. Then I’m sure you will love this light-weight methodology.
