jeudi 29 avril 2010

Agility and quality

What’s Quality? This word has many meaning. For my purpose, quality is the industrial quality. In this way, the definition is “A quality product is delivery like is design by us selves or with the customer”. A producer who satisfies quality requirements doesn’t produce the best product.

When I work on a project with the Methods Agile, I realize a quality project. When I explain this idea in an interview in a company specialize in Agility, the director answer me that agility can’t offer quality.

If you consider the agile project as a whole, the project isn’t a quality project. Because you can modify the list of functionality when the customer needs to exchange a functionality less important by another more important at this time.

But if you watch the project with all this functionality, each functionality is realize with quality. And when you deliver all the functionality, you deliver the software. And the quality of the software depends only on the quality of each functionality.

Each sprint contains full functionalities and can be delivered. For quality, a sprint is an industrial batch which verifies the constraints of quality.

The quality is more important than in the Predictive Methods because the customer receives exactly what he needs. If he needs some functionality less important which the customer decides to abandon, the supplier can realize them in a second time.

For a customer, the most important thing is that the end user has the best productivity. The end user needs simple, complete and useful functionality. The view of the user is different of the view of programmer or analyst. He can’t see the complexity or simplicity of a function like the programmer and he see the software like a list of functionality not like a system.

lundi 12 avril 2010

The Agiles Metthods and the Uncertainly Principle

I discovered Agile Methods while working for Docubase which put them in place at the end of 2007. I found them to be a realistic approach to IT project

I didn’t take formal computer training but learned to program through maintaining an application in C that I didn’t ever understand completely. I also used the “Kernigan and Ritchie” book.

Later I took training about Object Programming. During this course, I understood why Procedural Programming hasn’t been a solution for the long-term software creation and how but it is preferable to use Procedural Programming for smallest disposable programs.

After this course, I realized software which was conceived by project managers. I progressed to conceiving some programs by following the managers’ examples and studying from books.

Then, I took a traditional course about computer analysis. In 2004, the course only proposed the Predictive Methods Which leave an unsolved problem: how to manage the fluctuating needs of customers.

The discovery of Agile Methods allowed me to understand that this problem is inherent not to the customers themselves but to the Predictive Methods.

The Predictive Methods assert that all computer projects can be analyzed globally. A project comes to fruition in five steps.

· The needs analysis

· The writing of specifications

· The realization of project

· The tests

· The delivery

It’s called Predictive because it states that we may predict the entire usage situation for a computer project.

The agile methods suggest a totally different approach. They offer to construct a project in short steps which, apart from the last step, are finished by partial delivery.

The strength of these methods is to involve the customer and the user from the beginning of the project. They quickly have a usable partial product. Special users can quickly test the software and inform the team about any changes in order to obtain the project approval.

Since I known the Agile Methods, I have found them to be natural as much as pragmatic.

Later, while I read the magazine “La recherche”, an article about quantum physics allowed me to understand why Agile Methods is preferable. It spoke in particularly about the Uncertainty Principle.

One the expressions of this principle is:

The state of a system depends on the observer. The main representation of this is the Schrödinger’s Cat experiment. See this article in Wikipédia

The Uncertainty Principle is certainly far from computer science. Yet it has an expression in computer science.

The customer needs constantly change as the customer develops what they want to achieve.

If this idea is true, the Predictive Methods can not be applied because the studied need is always different to the real need of the customer.

In fact in each step, it studies a need that the customer doesn’t have anymore. This is the most simple explanation as to why computer projects realized with this method need to change as soon as they deliver.

The Agile Methods give a solution to this idea. Indeed, they consider the change as part of the project and offer an organisation and tools to accept and manage it.

My experience and that of the project manager who I work with, shows me that this idea is true. This idea doesn’t contest the computer ability to solve complex problem. It simply works with the adaptability of humans.

This process is based on the idea that a person or a group of people adapt themselves systematically to the world around them. It simply uses the adaptability of humans.

When a customer decides to computerize a function in his company, he starts to study this function. From this moment, this function is going to change. First, some small bad functioning always exists. Next, the computer as a tool imposes some constraints which are going to change the way of working. These elements can be managed with predictive methods. But the changes in the mentality of customers and the users aren’t seen during the study. They come up when the software is delivered.

To be able to deliver a high-performance and a well accepted tool, it needs to know these changes as soon as possible and the only possibilities is to deliver as fastest as possible an operational software even partially.