The Practices of Extreme Programming

• Whole Team. We want customers, managers, and developers to work closely with one another so that they are all aware of one another's problems and are collaborating to solve those problems. Who is the customer? The customer of an XP team is the person or group that defines and prioritizes features. They can be working in the same company as the developers or a user representative commissioned by the body of users.
• User Stories. A user story is mnemonic token of ongoing conversation about a requirement. A user story is planning tool that the customer uses to schedule the implementation of a requirement, based on its priority and estimated cost.
• Short Cycles. An XP project delivers working software every two weeks. Each of these two-week iterations produces working software that addresses some of needs of the stakeholders. At the end of each iteration, the system is demonstrated to the stakeholders in order to get their feedback.
• Acceptance Test. Acceptance test are written by business analysts, quality assurance specialists, and testers during the iteration. It is from these tests that the programmers learn the true detailed operation of the stories they are implementing. These tests become the true requirements document of the project. Every detail about every feature is described in the acceptance tests, and those tests are the final authority as to whether those feature are done and correct.
• Pair Programming. Code is written by pairs of programmers working together at the same workstation. Pair programming dramatically increases the spread of knowledge throughout the team. Although specialities remain, and tasks that require certain specialties will usually belong to  the appropriate specialists, those specialists will pair with nearly everyone else on the team. Pairing does not reduce the efficiency of the programming staff but does significantly reduce the defect rate.
• Test-Driven Development(TDD). When you write code in order to make test cases pass, that code is by definition testable. What's more, there is a string motivation to decouple modules so that they can be tested independently. Thus, the design of code that is written in this fashion tends to be much less coupled.
• Collective Ownership. A pair has the right to check any module and improve it. No programmers are individually responsible for any one particular module or technology.
• Continuous Integration. The programmers check their code in and integrate several times per day. The rule is simple. The first one to check in wins; everybody else merges.
• Sustainable Pace. A software project is not a sprint; it is a marathon. It must intentionally run at steady, moderate pace. The XP rule is that a team is not allowed to work overtime. The only exception to that rule is that in the last week in a release, a team that is within striking distance of its release goal can sprint to the finish and work overtime.
• Open Workspace. The team works together in an open room. Tables are set up with workstations on them. Each table has two or three such workstations. Two chairs are in front of each workstation. The walls are covered with status charts, task breakdowns, Unified Modeling Language (UML) diagrams, and so on.
• The Planning Game. The essence of the planning game is the division of responsibility between business and development. The business people(customers) decide how important a feature is, and the developers decide how much that feature will cost to implement.
• Simple Design. An XP team makes its designs as simple and expressive as they can be. 3 XP mantras guide the developer: Consider the simplest thing that could possibly work, You aren't going to need it, Once and only once. XPers don't tolerate duplication of code. Wherever they find it, the eliminate it.
• Refactoring. Refactoring is the practice of making a series of tiny transformation that improve the structure of the system without affecting its behavior. Each transformation is trivial, hardly worth doing. But together, they combine into significant transformation of the design and architecture of the system.
• Metaphor. Metaphor is the only XP practice that is not concrete and direct. It's the big picture that ties the whole system together. It's the vision of the system that makes the location and shape of all the individual modules obvious. If a module's shape inconsistent with the metaphor, you know that is the module that is wrong.

Extreme Programming is a set of simple and concrete practices that combine into an agile development process. XP is a good general-purpose method for developing software. Many project teams will be able to adopt it as is. Many others will be able to adapt it by adding or modifying practices.

Agile processes

• SCRUM. www.controlchaos.com
• Crystal. www.crystalmethodologies.org
• feature-driven development. Peter Coad, Eric Lefebvre, and Jeff De Luca, Java Modelling in Color with UML: Enterprise Components and Process, Prentice Hall, 1999.
• Adaptive Software Development. James A. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House, 2000.
• Extreme Programming.
  • Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.
  • James Newkirk and Robert C. Martin, Extreme Programming in Practice, Addison-Wesley, 2001.

Manifesto for Agile Software Development

 

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work  we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following the plan

That is, while there is value in the items on

the right, we value the items on the left more.

 

Above manifesto made by Agile Alliance in early 2001, and I found it only now. But that's the fact I've found in my projects, slipping schedules, growing budgets, and poor quality. The lack of effective practices leads to unpredictability, repeated error, and wasted effort.

Agile Principles

 

1. Our highest priority is to satisfy the customer through early and continuous delivery of valueable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4. Businesspeople and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity the art of maximizing the amount of work not done is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

OO in Python (1)

We will discuss, about 3 concept in OO :

• Encapsulation
• Inheritence
• Polymorphism

Encapsulation in short term information hiding. Python 2.1 hide attribute begin with '__', but it is not true information hiding, you can still get the attribute with following way, if we set attribute '__AttributeName', we can get the attribute by get '_ClassName__AttributeName', eg:

class ClassA:

  def __init__(self):

    self.__Name = 'ClassA class'

iTest = ClassA()

print iTest.__Name // raise exception, attribute not found

print iTest._ClassA__Name  // OK

Python 2.1 does not support property, so you must define a function to Get and Set the attribute.

All attribute in class-instance (object) stored in dictionary : __dict__

If we want to have attributes that only can set inside class, but accessible outside class, you can use this trick.

 

class ClassA:
    __vdict = None
    __vdict_name = locals().keys()[0]
    def __init__(self):
        self.__dict__[self.__vdict_name] = {}
        self.__Name = 'Class A'
    def __getattr__ (self, name):
        propHandled = 1
        attrName = '_ClassA__' + name
        if self.__vdict.has_key(attrName):
                return self.__vdict[attrName]
        else:
                propHandled = 0

        if not propHandled:
                return self.__dict__[name]

def __setattr__(self, name, value):
        headLength = len('_ClassA__')
        headName = name[:headLength]
        if headName == '_ClassA__':
                self.__vdict[name] = value
        else:
                self.__dict__[name] = value

iTest = ClassA()

print iTest.__Name // raise error, attribute not found

print iTest.Name // OK

As you can see, you define attribute Name in __init__ with '__Name', and information store in collection named '__vdict' (actually '_ClassA__vdict' in __dict__), and then you can access it by only call 'Name'.

Creating business component logic in easyDAF with Python

We usually creating business component logic (formerly kernel) in delphi.
Delphi is strong-type language that has a lot of ability, but also has weakness.
I don't say that delphi is bad, but if we have better way, why not?

What's the better way? Python
Yeah.. using python will increase our development productivity (IMO), especially
for end-user programmer, but not for creating foundation of framework. Actually
Microsoft still use C++ for develop their kernel OS.

Although, python is dynamic language, but it implement OO concept, so we can still
use OO paradigm in our program. Some people say OO language must implement
Class, but some not (for some people javascript is OO language with its prototype-based).
But at least, there are 3 concept, must accept by OO language:
- Encapsulation
- Inheritance
- Polymorphism

I will explain that 3 concept in python in another blog, and design pattern in creating
business logic in easyDAF MVC framework.