mardi 31 août 2010

De l’artisanat en informatique

Tout au long de ma carrière et en particulier pendant les entretiens d’embauche, j’ai rencontré des personnes qui considéraient l’informatique comme une activité artisanale. La différence entre l’artisanat et l’industrie tient moins dans les volumes traités que dans la manière de faire.

Un artisan réalise des chefs d’œuvre pour chacun de ses clients et l’industriel des biens de consommation. Cette différence ne concerne pas tous ceux que se prétendent artisan. Mais elle offre une perspective importante sur la manière de travailler. Un industriel réalise des objets qui doivent plaire aux plus grand nombre. L’artisan lui réalise un objet pour une personne particulière.

En informatique, une idée fausse est de penser que le programme est un chef d’œuvre est une illusion habituelle. Et cela pour plusieurs raisons, la première est de croire d’être le premier à résoudre ce problème. Même, si la situation est nouvelle, les éléments qui vont permettre de le résoudre existent déjà. Il suffit d’analyser et de décomposer le problème pour savoir ce qu’il faut chercher comme solutions validées. Le travail de programmeur consiste plus à assembler des solutions pérennes pour créer un programme de qualité, qu’à réécrire des algorithmes que d’autres ont validé depuis longtemps. La seconde est que le programme n’est pas destiné à un usage exceptionnel mais c’est un outil du quotidien. Une autre illusion est celle du client. Il s’imagine très souvent que son problème est particulier. Alors que son problème est la plupart du temps le même que ses concurrents au moins. Enfin, l’informatique est un travail d’ingénierie où la vraie difficulté est dans la compréhension des problèmes du client.

L’autre différence est sur les aspects économiques. Une entreprise informatique doit respecter deux contraintes majeures : les coûts et les délais. Contrairement à un artisan qui réalise un chef d’œuvre, les moyens sont limités.

La qualité a aussi une signification différente. Pour un artisan, c’est une notion intrinsèque car il travaille pour un seul client. Pour un industrielle, c’est une notion plus complexe car il y a des clients et des utilisateurs dont les besoins et les objectifs ne sont pas identiques. Ils concourent tous à la réussite de l’entreprise mais les contraintes de leurs travail ne sont pas les mêmes.

L’informatique en tant qu’industrie doit satisfaire des clients et des utilisateurs. Un problème supplémentaire se pose, c’est que les utilisateurs n’ont pas les mêmes besoins. Lors de la phase d’analyse des besoins clients, il est très important de définir correctement les rôles de chaque utilisateur, et de comprendre les besoins de chacun de ces rôles. En effet, même dans une petite entreprise il faut faire abstraction des individus car ils changeront au cours du temps alors que les rôles évolueront peu. Chaque rôle correspond à des fonctions précises. Certaines personnes pourront être associées à plusieurs rôles. Un avantage est que ces rôles sont en réalité une expression du métier de l’utilisateur et est partagé par des sociétés différentes. Ils existent même des rôles qui existent dans toutes les sociétés.

Un problème courant dans les sociétés informatiques (SSII, intégrateur, ou éditeur) est la polarisation sur la technologie. Il est certain que le suivi des évolutions technologiques est un problème en informatique car il est rapide. Mais c’est une illusion car c’est souvent la remise au goût du jour de technologie qui existe déjà. Il existe trois véritables révolutions : la programmation orientée objet, les méthodes agiles, et le cloud computing car elle change le niveau d’abstraction du métier qu’elle concerne : la programmation, l’organisation du travail, et l’infrastructure qui sont les trois bases de l’informatique.

L’informatique est une industrie dans son immense majorité. Il existe quelque cas particulier qui concerne peu d’informaticiens qui sont souvent les meilleurs. Un programmeur assemble le plus souvent des composants validés. L’analyste a la lourde tache de comprendre les besoins des clients et des utilisateurs. Le scrum product owner doit lui faire réaliser des fonctions standards tout en gérant la croyance de l’utilisateur dans la particularité de sa société.

lundi 23 août 2010

Fundamentals of agility: Time boxing

The time boxing is a main part of agility. But, it’s a difficult idea to explain precisely and to implement. The basic idea is to control and encapsulate the time of the action.

The time boxing allow to an agile team and its members to control the working time and the time limit for the realization by cutting in tasks. Each task is so small it’s possible to define exactly the working time and respect this time. This way of working is applied on all the activities from the realization to the meeting and the personal projects. In fact, it’s a way of thinking, each time I’m going to do something; I begin with the valuation of the work. If the time is too big, which mean that the valuation is imprecise, I break up it to valuate each part as well as the integration.

The simplest sample is the management of meetings. For the industrial quality a meeting is defined in order of priority by the agenda, the length, the participants with a role, a day and a time, and a place. A meeting doesn’t respect the agenda or the length failed. When you prepare a meeting, you start by define a target. This target gives the points to tackle. Each point is evaluated. If a point is difficult to define or estimate, it will be split. When all the points are completely define and valuate, the agenda is done. Careful, a meeting can’t take more than 2 hours. Otherwise the points discussed after will be skimmed over or settled. In this case, you must organise some meetings with smaller targets perfectly defined and a synthesis meeting. Sometime, you can organize a meeting with some targets; you should separate them with ns introductions and conclusions to allow to the members to know the target of the meeting at a time.

Define a time for a task and do it in the time expected show the control on the achievement.

This is a basic aspect of the agility. In fact, when the set up Agile Methods is to delivery in a defined time some functions divided in tasks. These functions are done which means that they can be tested and tested, with no bugs. The only remarks must be improvements to obtain a perfect adequacy with the needs of customers and users. The definition of the done is an essential part of the agility.

Now, we can master the working time because if the breaking up of the tasks is enough short. The tasks are already known and their valuation known. A known task was not necessarily done before but a similar task was done in which you can valuate the new easily.

In another part, this mastering of the working time allows a realistic undertaking toward customers. They can see unlike previous experiences, the deliveries are done in the time with a good quality. They use less time to test the delivery and these tests are about the functional part and the imprecision on the product that is generally associated to communication troubles between the customer and the product owner. Some points often minor are difficult to explain precisely.

This way also avoids starting an unrealistic project. Often for a customer or a user, a function is simple in his opinion but lead to difficult troubles for the programmer. If the customer participates to the planning meeting, he can understand the difficulties to realize these functions. The explanation shows to a customer that the evaluation is realistic and is the sum of the tasks from which he isn’t used to thinking.

This communication way is another basic part of agility. It leans to the transparency and the honesty. It is naturally going to a trust relation where the parts communicate more information to each other what avoid mistakes and allow finishing more quickly a good and efficient solution.

mardi 10 août 2010

Des bases de l’agilité : le time boxing

Le time boxing est une notion difficile à traduire en français. La traduction la plus fidèle est la gestion du temps par encapsulation. Cette idée parait simple en anglais et compliqué en français. En fait, elle est simple à expliquer mais difficile à réaliser.

Le time boxing doit permettre à une équipe agile et à ses membres de contrôler le temps de travail et les délais de réalisation en découpant les taches pour travailler uniquement sur des taches avec un temps de réalisation maitrisable et définissable. Cette manière de travailler concerne toutes les activités de la réalisation aux réunions et les projets personnels.

En fait, c’est plutôt une attitude mentale, chaque fois que je me prépare à faire une action, je commence par estimer le temps dont j’ai besoin. Si ce temps est trop important. C’est à dire que son estimation est floue, je la décompose pour pouvoir estimer précisément chaque partie y compris l’intégration.

L’application la plus simple est la gestion des réunions. Pour la qualité industrielle, une réunion est définie par ordre d’importance par un ordre du jour, une durée, des participants avec un rôle, une date et une heure et un lieu. Une réunion qui ne respecte pas l’ordre du jour et sa durée est une réunion ratée. La préparation de la réunion commence par se définir un objectif. Cet objectif fournit des points à aborder. Chaque point est estimé. Si un point pose des problèmes (définition, estimation), il doit être décomposé. Lorsque les différents points sont complètement définis et chiffrés, l’ordre du jour est réalisé. Attention, une réunion ne doit pas durer plus de 2 heures, sinon les points traités après seront survolés ou liquidés. Dans ce cas, il faut organiser plusieurs réunions avec des sous-objectifs parfaitement clairs et une réunion de synthèse. Parfois il est possible d’organiser une réunion avec plusieurs objectifs, il faudra prévoir de la séparer avec des conclusions et des introductions pour permettre aux participants de savoir l’objectif de la réunion traité à un moment donné.

Définir un temps pour une tache et réaliser celle-ci dans le temps prévu montre la maitrise de la réalisation. C’est le premier pas dans le contrôle de son travail et vers le travail de qualité.

C’est un aspect fondamental de l’agilité. En effet, la mise en place des méthodes agiles a pour objectif de livrer dans un temps défini des fonctions réparties en taches. Ces fonctions sont finies, c'est-à-dire qu’elles sont testables et testés et ne contiennent pas de bug. Les seuls remarques doivent être des évolutions pour obtenir une parfaite adéquation avec les besoins des clients et des utilisateurs. La définition du fini est un élément essentiel de l’agilité dont je parlerais dans un prochain article.

Il est aujourd’hui possible de maitriser le temps de travail car si la décomposition des taches est suffisamment fines, les taches sont déjà connues et leurs chiffrages possibles. Une tache connue n’a pas forcément été déjà réalisé avant mais une tache similaire a été réalisé ce qui permet de chiffrer l’actuelle facilement.

D’autre part, cette maitrise des temps de travail permet un engagement réaliste vis-à-vis du client. Il peut voir que contrairement aux expériences précédentes, les livraisons sont réalisées dans les délais et que le produit est de bonne qualité. Il consacre moins de temps à tester le livrable et ses tests concerne les aspects fonctionnels et les imprécisions sur le produits qui sont généralement liées à des problèmes de communications entre le client et le product owner. Il existe toujours des points souvent de détail qu’il est difficile d’expliquer.

Cette approche évite aussi de s’engager sur des projets irréalistes. Souvent pour un client ou un utilisateur, une fonctionnalité est simple de son point de vue mais pose des problèmes complexes à la réalisation. Sa participation à la décomposition de la fonction permet de lui faire comprendre les difficultés qui seront rencontrées lors de la réalisation. Cette explication montre à un client que le chiffrage ne sort pas d’un chapeau mais est la somme de taches auxquelles il n’est pas formé à penser.

Cette forme de communication est une autre base de l’agilité. Elle s’appuie sur la transparence et l’honnêteté. Elle amène naturellement à une relation de confiance où les deux parties se transmettent plus d’informations ce qui évite les malentendus et permet d’aboutir plus rapidement à une solution satisfaisante.