Using Agile Programming Techniques for the Enterprise

Short Description
Information management has a cyclical history that resembles the fashion cycle of men’s ties; hold on to a tie long enough and it comes back in style. In the 1960s mainframe era, centralized processing ruled. Controlling access to resources and code efficiency were key IS goals. The introduction of the personal computer ushered in the distributed processing age. Users customized the environment and hardware became relatively cheap. Now that server based peer networks dominate the firm, centralized principles are being revisited as data integrity and controlling access are once again a priority.

Website: www.clarionmag.com | Filesize: 95kb
No of Page(s): 17

Content
…
Extreme Programming
The most widespread form of agile concept is Extreme Programming (XP) was first proposed by Beck (2). The formalizing of XP principles arose from the development of the Chrysler Comprehensive Compensation system headed by Beck in 1997. Paulk (6) best summarizes the principles of XP:
1. Planning the game — quickly determine the scope of the next release, combining business priorities and technical estimates.
2. Small releases — put a simple system into production quickly. Release new versions on a very short cycle.
3. Metaphor — guides all development with a simple, shared story of how the whole system works.
4. Simple design — designed as simply as possible at any given moment.
5. Testing — continually write unit tests that must run flawlessly; customers write tests to demonstrate functions are finished. “Test then code” means a failed test case is an entry criterion for writing code.
6. Refactoring — restructure the system without changing behavior to remove duplication, improve communication, simplify, or add flexibility.
7. Pair programming — all production code written by two programmers at one machine.
8. Collective ownership — anyone can improve any code anywhere in the system at any time.
9. Continuous integration — integrate and build the system frequently, every time a task is finished. Continual regression testing means no regressions in functionality as a result of changed requirements.
10. 40-hour week — work no more than 40 hours per week as a rule; never work overtime two weeks in a row.
11. On-site customer — real, live user on the team full-time to answer questions.
12. Coding standards — rules emphasizing communication throughout the code.
…