La technique avant le fonctionnel

La division du travail en informatique en 2 parties distinctes qui séparent la technique du fonctionnel semble relever d’une approche simpliste. En effet l’organisation des projets informatiques fait apparaitre 2 forces aussi légitimes l’une que l’autre qui sont : les besoins fonctionnelles et les moyens techniques pour y parvenir. Ainsi on entend parler d’une part de Matrise de d’ouvrage (MOA) qui détient le savoir du quoi et d’autre part de Maitrise d’oeuvre (MOE) qui détient le savoir du comment. Cette conception tirée du domaine des projets du bâtiments propose ainsi de façon implicite une hiérarchisation des rôles. La MOA est ainsi le donneur d’ordre et la MOE l’executant. D’ailleurs on voit bien que les métiers de la MOA sont plus valorisés que ceux de la MOE.

Cette vision est hélas typiquement française. Chez nous de nombreux informaticiens en quête de reconnaissances (pécuniaires) se tournent vers la MOA et finissent par oublier les fondement de leur métier: la technique. La technique n’est pas péjorative sauf en France. La technique informatique met en Å“uvre des idées et de concepts très abstraits. Bien sûr je veux parler de l’informatique d’un niveau assez élevé, que ceux qui considère la technique comme un passe-temps d’ados bouteunneux ne connaissent pas. L’informatique sont en vérité des mathématique avec une application pratique. Redonnons ses lettres de noblesse à cette sciences !

Cependant les applications pratiques de l’informatique sont souvent d’un niveau scientifique assez faible voir inexistant notamment en informatique de gestion. Néanmoins les techniques récentes de génie logicielles offrent des champs d’investigation qui peuvent abreuver la soif de technicité de l’informaticien. Mais la encore la vision française de l’informatique mettra l’informaticien encore dans une position inférieure à celle du fonctionnel si bien que les prérogatives de la MOE ‘effaceront devant celles de la MOA. Par exemple si un programme fait ce qu’on attend de lui c’est-à-dire qu’il satisfait les utilisateurs, on ne se souciera pas de comment il est fait. N’est-ce pas ? C’est normal somme toute. Mais est-ce toujours le cas ?

Dans certains projets au forfait, la répartition des rôles jouent clairement en défaveur de la MOE. Le donneur d’ordre ayant acheté un logiciel final, le comment n’a que peu d’importance devant le quoi. Cependant des raisons de maintenance peuvent tempérer ce raisonnement.Ou bien des question de sécurité. Ainsi le but d’une compagnie aérienne est de transporter des personnes et la sécurité et la maintenance des appareils sont des postes budgétaires qui ne sont pas directement lié au métier qui sont pourtant placées comme priorité “numéro un” avant tout exercice réel. Il y a donc bien des cas où la technique passe avant le fonctionnel. Est-ce que les domaines sensibles comme le militaire ou la sécurité des personnes ou la santé sont les seuls où les techniciens (au sens noble) ne sont pas soumis au dictat du fonctionnel ?

Avant toute chose essayons de comprendre pourquoi il y a cette opposition entre technique et fonctionnel. Est-elle justifiée ? A mon sens cette opposition viens d’une incompréhension historique qui nous a fait passé de l’ère de l’informaticien dans sa tour d’ivoire à l’informaticien-technicien sans pouvoir. Dans les 2 cas nous avons une organisation inefficaces puisque dans le premier cas, le logiciel ne correspond pas au besoin et dans le second le logiciel ne sort pas en temps en heure avec des coûts de maintenances accrus puisque pauvre techniquement. Un analogie avec la compagnie aérienne illustre mon discours. La technique seule ne transporte personne et sans la technique les avions s’écrasent. Je prône donc une juste répartition des rôles sans hiérarchisation des pouvoirs. Le fonctionnel et tout aussi important que la technique et vice-versa.

Alors pourquoi le titre de ce billet met-il la technique avant le fonctionnel ? Il s’agit simplement résultat d’un constat empirique. Lorsque que vous devez faire 2 tâches, vous avez intéret à commencer par celle qui est ou parait la moins importante in-finé parce si vous commencez par celle qui constituent le but final vous ne reviendrez jamais sur l’autre. Les développeurs vous diront tous: les rustines que l’on met dans le code pour contourner un problème ne sont jamais enlevées du code final. Aussi je prône de toujours commencer par la moins prioritaire du point de vue fonctionnel mais qui est la plus prioritaire d’un point de vue technique. Rentrent dans cette catégorie toutes les tâches liés à l’infrastructure constituant l’échafaudage par lequel le logiciel va pouvoir être construit. Ainsi il faut toujours commencer par mettre en place les outils de builds, définir les processus de livraisons… Cela veut dire aussi avoir le courage de repousser les livraisons fonctionnelles quand la qualité technique n’est pas au rendez-vous dès le début.

Ces principes sont bien connus des tenants de méthodes telles que le développement guidé par les tests gagnent à être connus et pratiqués réellement.

Un environnement de developpement Java

J’ai eu envie de faire un petit développement personnel en Java et comme j’avais réinstallé mon ordinateur, je devais refaire mon environnement depuis le début. Ce n’est d’ailleurs pas un si grand mal et l’exercice serait même intéressant car il arrive que nous devions le faire quand par exemple une défaillance de notre IDE survient comme un crash d’Eclipse réduisant à néant la configuration du workspace.

En partant d’une distribution classique Ubuntu 64 bit avec les dépôts officiels, peut-on monter un environnement de développement Java ? Est-il nécessaire d’installer des logiciels manuellement et donc maintenir par soi-même les mise-à-jour ? Est-ce que l’installation est accessible ou nécessite-t-elle une équipe système ? Pour réponde à ces questions il faut commencer par définir ce dont nous avons besoin.

Le système d’exploitation est un Linux abordable: Ubuntu. Nous supposons qu’il est déjà installé et fonctionnel. C’est une supposition très raisonnable. A partir de là il nous faut obtenir un environnement de développement Java complet comprenant :

  • un outils de modélisation
  • un éditeur de source
  • un compilateur
  • un outils de versionnage
  • un outils d’intégration continue

L’outil de modélisation sera bien pratique pour les phases préliminaires avant tout codage et devra permettre au moins la génération de code. L’opération inverse sera aussi utile car une fois emporté dans le code on risque bien d’oublier l’architecture générale et voire même la galvauder dans notre élan. Nous pouvons soit opter pour outils dédié  comme BOUML ou bien se contenter des fonctions UML de l’IDE. LEs 2 IDE open-source majeurs propose de l’UML.

L’IDE doit permettre d’écrire du code, d’apporter la coloration syntaxique, l’assistance à la frappe, le debogguage et le support de plusieurs JVM. L’IDE ne doit pas nous enfermé dans un système propriétaire de build et devra donc s’interfacer simplement avec notre outil de build préféré : Maven. Nous porterons notre choix sur Netbeans dont l’offre “packagée” estplus complète que Eclipse et mieux adapté que ce dernier pour une utilisation avec Maven.  La version 6.0 est installable directement depuis Ubuntu en utilisant Synaptic. Il faudra ajouter les plugins Subversion, Maven et UML pour completer l’installation de base. Cela ce fait directement depuis l’ID.

La partie compilateur dans le cas de java se compose du JDK  qui est l’ensemble des outils pour compiler et debugger des programmes écrit en Java. Le JDK contient aussi un JRE qui permet d’éxécuter les programmes Java. C’est le point de départ de notre environnement. Les dépots officiels d’Ubuntu propose OpenJDK 1.6 donc son installation se fera le plus simplement du monde via le gestionnaire de paquet Synaptic.

L’outils de versionnage devra permettre un refactoring constant du code et devra gérer le renommage les déplacements de fichiers sans perte d’historique sans avoir recours à l’administration du serveur. On choisira naturellement subversion dont l’installation est possible depuis les dépôt Ubuntu.

L’intégration continue est une pratique obligatoire dans les projets nécessitant plusieurs développeurs ou plusieurs module devant être assemblés. Cependant même dans le cas d’un seul développeur il aura besoin de découper le projet en modules qui devront être assemblés. Un outils permettant d’assurer le que l’ensemble “fonctionnent” correctement est nécessaire. Afin de simplifier l’intégration nous allons choisir Continuum qui se marie à merveille avec Maven. Son installation se fera manuellement en décompressant l’archive trouvé sur le site officiel de continuum

Enfin pour terminer la liste des outils nous mentionnerons l’outils de build maven qui est avec l’intégration continue les éléments le splus importants de l’environnement de developpement d’un point de vue structurel. Nous allons installer maven par le biais de Synaptic. Pour simplifier et offrir une évolutivité maximal dans l’utilisation de maven nous allons utiliser le gestionnaire de repository Apache Archiva

Maintenant que tout est installé, il faut s’assurer que tout fonctionne bien ensemble. Pour cela l’article suivant traitera de la création initiale du projet.

Etes-vous agile ?

Les méthodes de développements sont assez nombreuses et vont de la classique méthode du cycle en V aux méthodes dites agiles en passant par une étrange mais néanmoins utilisée méthode dite “pas de méthode”. Bien-sûr le dégrée de maturité de l’organisation conditionne la méthode utilisée. Il est courant donc de voir des organisations de très petites tailles, dont le cÅ“ur de métier n’est pas le développement de logiciel, opter pour l’étrange méthode avec un succès qui dépend uniquement de la capacité du responsable à gérer sans méthodes son activité. Il est étonnant de constater que cela marche… parfois. Il suffit simplement d’avoir confiance en l’extraordinaire faculté d’adaptation de celui qui dispose d’une bonne volonté à gérer le désordre. Au contraire une organisation plus mature dont le but est le développement de logiciel aura sans doute adopté une méthode : cycle en V pour certaines ou méthodes itératives pour d’autres mais avec toujours un penchant pour la mise en place de processus écrasant pour le développeur.

Qu’est-ce que l’agilité ? L’agilité est la faculté de pouvoir s’adapter en changeant rapidement d’orientation, de position afin de répondre plus rapidement au besoin du milieu. Les informaticiens de la nouvelle génération c’est-à-dire ceux qui sont arrivés sur le marché après 2000 sont assez au courant des méthodes agiles mais sont souvent contraints d’appliquer les méthodes que leur organisation aura mis du temps à éprouver.  Cela ne veut pas dire que le choix d’une méthode ou l’autre est le simple fait de la génération car si les méthodes agiles paraissent modernes, il ne s’agit rien d’autre que la formulation de principes issus  du bon sens et de l’expérience acquise par la pratique de développeurs chevronnés durant les années 90. L’agilité semble aujourd’hui être de plus en plus utilisée comme une évidences qui s’impose.

Quelles sont les raisons de cette adoptions ? La difficulté de prendre en compte les modifications de spécification en cours de projet quand sont utilisées des méthodes à effet tunnel. La difficulté de détecter les incompréhensions des développeurs à cause de l’effet tunnel. A ces raisons parmi d’autres visant directement la réussite du projet , s’ajoute de véritables raisons sociologiques. Ce qui est frappant des les méthodes agiles, notamment XP, c’est la mise au centre du développeur qui avait peu à peu pris une place d’éxécutant dans le processus de plus en plus complexe et encadré de la production de logiciel. C’est d’ailleur un des arguments des détracteurs des méthodes agiles qui disent que c’est la méthode des nostalgiques du temps de l’informaticien dans sa tour d’ivoir. C’est un argument simpliste car les méthodes agiles au contraires rapproche le développeur de l’utilisateur et visent améliorer l’adéquation entre le besoin et le logiciel, la perception de l’avancement et l’état réel de l’avancement. Les méthodes agiles sont des méthodes pragmatiques et efficaces car elles partent d’une approche “down-top” et non pas “top-down”.

Nous abordons alors un point très controversé dans notre culture française. En effet le système français globale est organisé autour de l’élite. Nous avons un système politique et éducatif qui prône l’élitisme c’est-à-dire la mise en avant des individus plus par l’origine corporatiste que par la démonstration de compétences dans un domaine donnée. Mais cette tendance est d’ailleur en train de changer comme le montre l’exemple de l’actuel président qui n’est pas sorti de l’ENA. Si dans la politique on assiste à une “américanisation”, il est intéressant de remarquer que ce n’est que la consécration d’un mouvement général qui touche aussi le monde de l’informatique dans sa dimension “sociologique”. Il est en effet remarquable de voir comment les méthodes agiles commencent à faire leur chemin en plaçant la compétence première de l’informaticien au centre du processus de production de logiciel. Il est en effet plus facile de contrôler une machine quand on est à l’intérieure de celle-ci.

L’agilité en informatique relève d’une culture particulière des individus, qui je pense, ne se décrète pas. Est-ce que cela s’apprend-t-il ? Peut-être. L’informaticien agile est réaliste, courageux, honnête et possède un certain sens de la qualité de travail. Ce sont là des qualificatifs que l’on attribuerait volontiers à un amoureux de son métier, à un simple travailleur de la base… Le concept de méthode agiles dans son côté très pratique serait-il à rapprocher de celui de la lutte syndicale… L’idée m’effleure souvent. Prenons l’exemple de la charge de travail. En méthodologie agile, on admet que le développeur doit conserver un rythme de travail régulier et ne jamais recourir aux heures supplémentaires pour satisfaire au délai. Si un dépassement survient, on enlève des fonctionnalité pour tenir le délai. C’est une gestion résolument tournée vers le bien être de l’individu.

Je pense que c’est la dimension sociologique des méthodes agiles qui freine leur adoption dans les organisations. L’évangéliste doit alors appliquer une conduite au changement à une population d’informaticien du “middle au top management”. Cette population est souvent culturellement non ouverte aux méthodes agiles. L’évangéliste doit alors user de tout son pouvoir de démonstration et de persuasion pour parvenir à ces fins. Et vous, êtes vous agiles ?