Au fil du temps tout ces morceaux de code qui populent votre application et que plus personne n’utilise finissent par vous ralentir de façon dramatique et vous causent souvent les pires mots de tête. C’est pourquoi il est essentiel, avant de développer de nouvelles fonctionnalités, de vous assurer que celles-ci sont réellement nécessaires et seront utilisées.

Oubliez la “sauce” et les besoins incertains, et mettez votre énergie sur ce qui compte vraiment! C’est une remise en question qui sera bénéfique aux développeurs autant qu’au clients dans le moyen terme.

Just as Taiichi Ohno called overproduction the worst waste in manufacturing, unused features are the worst kind of waste in software development. Every bit of code that is there and not needed creates complexity that will plague the code base for the rest of its life. Unused code still requires unnecessary testing, documentation, and support. It will do its share of making the code base brittle and difficult to understand and change as time goes on. The cost of complexity in code dominates all other costs and extra features that turn out to be unnecessary are one of the biggest killers of software productivity.

An important consideration to bear in mind when schedules become a commitment is that people must always have the time to do the job that they have committed to complete, and at the same time, the details of the job will always change. If you expect teams to meet aggressive deadlines, you must limit work to capacity. [...]

Limit Work to Capacity

Far too often we hear that the marketing department or the business unit, “Has to have it all by such and-such a date,” without regard for the development organization’s capacity to deliver. Not only does this show lack of respect for the people developing the product, it also slows down development considerably. We know what happens to computer systems when we exceed their capacity—it’s called thrashing. [...]

Time sometimes seems to be elastic in a development organization. People can and do work overtime, and when this happens in short bursts they can even accomplish more this way. However, sustained overtime is not sustainable. People get tired and careless at the end of a long day, and more often that not, working long hours will slow things down rather than speed things up. Sometimes an organization tries to work so far beyond its capacity that it begins to thrash. This can happen even if there appear to be enough people, if key roles are not filled and a critical area of development is stretched beyond its capacity to respond.

However you do it, remember that it is impossible to implement responsibility-based planning and control unless you understand the capacity of each team and limit the work expected of a team to its capacity. [...]

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. [...]

Because we assume that our predictions are facts, we tend to make early decisions that lock us into a course of actions that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. [...]

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. [...]

There are, however, well-proven ways to create reliable outcomes even if we canot start with accurate predictions. [...] Fundamentally, an organization that has a well-developed ability to wait for events to occur and then respond quickly and correctly will deliver far more predictable outcomes than an organization that attempts to predict the future.

Pour réellement arriver � corriger un problème, il est primordial de commencer par bien le comprendre. Il faut en trouver les racines. De plus, l’effort supplémentaire pour bien analyser le problème va se payer de lui même en nous permettant de découvrir une solution qui sera souvent plus simple que l’on envisageait au départ.

Dans le livre Toyota Production System, Taiichi Ohno explique qu’il utilise la technique suivante : Répétez « Pourquoi? » 5 fois

Repeating Why Five Times

When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. For example, suppose a machine stopped functionning :

1. Why did the machine stop? There was an overload and the fuse blew.
2. Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
5. Why was the shaft worn out? There was no strainer attached and metal scrap got in.

Repeating why five times, like this, can help uncover the root problem and correct it. [...] By asking why five times and answering it each time, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms.