Look*Gade

  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.

Today, we will focus on process of agile.  I didn’t write this article myself but I find that it’s a very good one. If you would like to know more at the original site. please visit  http://www.objectmentor.com/omSolutions/agile_what.html

Agile/XP teams use an iterative design process. The process is described briefly below:

• Envisioning
  The process begins with envisioning where the team gathers information about the market and the product. They assess the risks associated with building the product from a market and development perspective. Product requirements are entered into a requirements backlog and risks are entered into a risk backlog.
• Definition
  The team proceeds to definition where product requirements are converted into product features containing concrete use cases and acceptance criteria. These features are sorted into product releases and initial development estimates are created. In addition, a product architecture is also created. In large-scale development environments, teams are organized around the architecture (e.g. application teams, component teams, platform teams) and given ownership for specific parts of the architecture.
• Development
  From there, the team proceeds into the development. The teams divided the features they need to develop into stories. These stories are small units of functionality taking about a week or two to code and test. Developers now prepare estimates for the stories and compare their estimates to the original estimates created during the definition phase. Discrepancies or anomalies between the estimates are resolved through negotiation. This process ensures the integrity of the estimates. It allows the customer to prioritize development based on the value and time cost of the stories. It allows developers to “own” and “commit” to their deliverables. And it allows “stakeholders” to set release dates that can be used by the rest of the company. Development is done iteratively and incrementally using Test Driven Development Model and a Continuous Build and Integration Environment. Test are written for each unit of code and only code that passes its test is committed to the build. Every two weeks, the development team delivers working stories that pass their tests.
• Release Engineering
  End-to-end release engineering is performed on an ongoing basis as the development proceeds and the product evolves. Like unit tests, end-to-end acceptance tests are run from day one to ensure the overall continuity and integrity of the system as a whole. As a result, a robust and reliable system grows in functionality, piece by piece, from the very first day. This means that, at any point in time, a “potentially shippable product” is available for release. Practically speaking, it is highly unlikely that the initial builds would actually be “shipped” but the theory behind the Agile/XP methodology is that any software developed should be reliable and robust at any point in time.

Throughout this iterative process, progress is measured and tracked by automatically querying the code library and generating daily and weekly reports. Everyone from developers to stakeholders can see how many stories have been built, how many stories have passed their tests, how many stories have failed and how many stories still need to be built. So rather than relying on “hand-crafted” GANT charts, Excel spreadsheets or PowerPoint slides, Agile/XP measures progress by interrogating the system itself. In essence, the system becomes the measure of its own success.