samedi 22 août 2009

Agile : spécialistes ou généralistes ?

Dans la littérature des méthodes agiles, on y lit souvent qu'une équipe devrait être plutôt composée de membres généralistes plutôt que spécialistes. Pour quelle raison ? Essentiellement, parce qu'on dit d'un spécialiste qu'il est souvent focusé sur une seule solution à un problème, qu'il peut parfois manquer de modestie et d'introspection et qu'il est difficile de travailler avec lui en équipe, car il ne comprends pas bien les autres membres de l'équipe. À l'inverse, on prête aux généralistes, une plus grande facilité à travailler ensemble, ils connaissent mieux ce que les autres font et n'ayant pas de spécialisation précise dans un domaine donné, ils sont plus ouverts à regarder plusieurs alternatives pour étayer leur solution.

Qu'en est-il dans la réalité ? Pour ma part, je trouve cela un peu paradoxal, car en TI, le domaine est tellement vaste et les possibilités infinies, que chaque individu en vient à se faire une niche, une spécialisation dans un domaine plus ou moins précis. Je crois que c'est inévitable si on veut survivre dans le domaine des TI.

À mon avis, dans une équipe agile, on doit avoir toute sortes d'individus, généralistes, spécialistes, plus ou moins généralistes, plus ou moins spécialistes, peu importe ... Cependant, ils doivent partager certaines qualités communes : l'ouverture d'esprit, la capacité à travailler en équipe et à collaborer et le désir d'apprendre et de se dépasser. Il n'y a pas de mal à avoir un expert (spécialiste) d'une technologie dans une équipe pour autant qu'il est en mesure de partager sa connaissance et d'accepter qu'il a peut-être tord et qu'il existe une solution mieux adaptée au problème à résoudre. Il doit être ouvert à faire des compromis ou même à changer son fusil d'épaule. Au même titre que, le généraliste doit être en mesure de profiter de la connaissance de son collègue pour ajouter une corde à son arc et reconnaître qu'il est plus expérimenté dans un domaine donné.

Ce qui tue une équipe, c'est la hiérarchie et l'individualisme. En TI, nous avons la fâcheuse tendance à vouloir hiérarchiser les rôles dans une équipe en leur accordant plus ou moins d'importance : programmeur, analyste, architecte, gestionnaire de projet, directeur, etc. Chaque joueur d'une équipe a un rôle important. Enlever vos programmeurs, pensez-vous réaliser une solution complète ? De plus, qu'est-ce qui empêche un programmeur de participer à l'architecture du système ? Ou vice-versa, à l'architecte de participer à la programmation ? Chacun a ses forces et faiblesses et chacun a à tirer profit de l'expérience et la connaissance de l'autre.


La force d'une équipe est donc d'exploiter les forces de chacun, de les mettre à profit pour acquérir une plus grande maturité collective. Pour ma part, le débat n'est pas de savoir si mes membres qui composent mon équipe sont des généralistes ou des spécialistes ou les deux. Ma préoccupation et plutôt de mettre en place une équipe en mesure d'affronter n'importe quel défi en équipe tout en étant flexible. Au final, ce qui compte, ce que mon équipe soit AGILE !

dimanche 2 août 2009

Solutions libres ou propriétaires : une bataille à finir ...

Un sujet qui soulève bien des passions, même dans mon quotidien ! D'entrée de jeu, je tiens à dire que je suis pas un expert du domaine ni un partisan de l'un ou l'autre des côtés. Je remarque que dans ce domaine, on en voit de toute sorte ! D'un côté, les solutions propriétaires incarnant le diable en personne et de l'autre, les solutions libres incarnant la voie de rédemption.

Pardonnez-moi cette image un peu forte et caricaturale, toutefois, force est d'admettre que nous en sommes pas si loin à entendre certaines personnes débattre sur le sujet. Il est évident que lorsqu'on s'attaque à un plus fort, c'est plus facile de passer pour le "gentil" de l'histoire.

Maintenant que la table est mise, qu'est-ce que le logiciel libre ? Cela se définit par un logiciel dont la licence donne à chacun le droit de l'utiliser, de le modifier et de le diffuser librement. Par ailleurs, un logiciel libre est souvent à code ouvert (open source). La promesse du logiciel libre est d'offrir souvent plus de fonctionnalités et des solutions fiables et sécuritaires, car ils sont développés par une communauté qui peut rassembler des centaines, voire des milliers de personnes. Ce sont aussi des solutions qui affirment être respectueuses des standards et indépendantes. De plus, plusieurs affirment que ce sont des solutions économiques grâce à la liberté et la flexibilité de la license qui les accompagnent.

Passons maintenant au logiciel propriétaire. Le logiciel propriétaire a une license qui relève du droit d'auteur et est accompagné de certaines conditions d'utilisations (contrat). Comme son nom l'indique, le logiciel demeure l'entière propriété de son éditeur. Habituellement, un logiciel propriétaire ne permet pas les droits d'une solution libre. Les solutions propriétaires, à leur défense, promettent une intégration étroite et une homogénéité de leurs produits. Ils garantissent avoir une plus grande maturité et expertise du champs d'application et assure un support de leur gamme de produits.

Bon j'entends déjà les partisans des deux camps me crier des bêtises défendant allèguant que je confère des caractéristiques ou des avantages à l'une ou l'autre des alternatives et que ce n'est pas vrai ! Je vous l'accorde, rien n'est tout noir ou tout blanc. En effet, il y a beaucoup de zones grises dans ce domaine. Je répondrais simplement qu'il y a de mauvais logiciels libres et de mauvais logiciels propriétaires.

Avoir une solution libre ou propriétaire ne garantit souvent en rien sa qualité. Quand je parle de qualité, je parle de qualité globale. Le choix de l'une ou l'autre de ces solutions ne se limitent pas à un seul critère.

On ne choisit pas une solution parce que son coût de licences est moins élevé ou nul. Par exemple, pour une automobile, on s'attend que tout véhicule aille quatre roues et permet de se rendre du point A au point B. Il y a des véhicules à partir de 10 000 $, pourquoi chaque individu n'achète pas le véhicule le moins cher ? Sans doute, parce que nous avons des exigences et/ou des besoins et/ou des attentes différent(e)s.

On ne choisit pas uniquement une solution parce qu'il y a des meilleures possibilités de maintenance ou d'extensibilité. Encore une fois par analogie, on peut choisir son automobile pour sa renommée en terme de fiabilité et son faible coût d'entretien, car on espère la conserver longtemps. On peut aussi opter la louer à court terme et ne vouloir aucun tracas sachant qu'on la changera rapidement. On peut aussi être en mesure de faire sa mécanique chez soi ou opter pour un contrat d'entretien prolongé, car on a pas les connaissances techniques pour faire son propre entretien de véhicule.

En fait, unitairement, on peut descendre chacun des avantages/désavantages de l'une ou l'autre des solutions et trouver un contre-exemple dans le monde du logiciel. Un choix technologique ne passe pas par une idéologie dite libre ou propriétaire. Tout passe par une bonne analyse de besoins (exigences) et ensuite, on peut et plutôt, on DOIT regarder également toutes les alternatives qui peuvent répondre en partie ou totalement à notre besoin. Combien de fois j'ai vu un projet dans lequel, on sait déjà avec quelle technologie il sera réaliser, mais on a même pas fait une analyse préliminaire du projet.

Libre ou propriétaire, les deux voies sont des options viables pour autant qu'on accepte les avantages/désavantages que chacune nous offre. De plus, il faut faire preuve de plus d'objectivité que ce soit dans un cas ou l'autre, malgré que la subjectivité et les passions soient plus souvent tentantes. Dans notre domaine, libre VS propriétaire, c'est un faux débat. Le vrai débat est de déterminer comment les firmes en TI peuvent mieux réaliser les mandats qui leur sont confiés et de livrer des solutions de qualité répondant parfaitement aux attentes et besoins du client. Pour cela, il faut être en mesure d'avoir une offre variée et ne pas se buter à ce genre d'idéologie réductrice à mon avis.

Et pour terminer, vous avez beau avoir les meilleurs arguments de vente, si un client veut une voiture sport dont il rêve depuis longtemps coûtant plusieurs milliers de dollars et que vous lui proposez un choix plus rationnel telle une compacte fiable et économique. Vous passez à côté de son besoin (plutôt discutable vous me direz), mais dans toute chose, il y a la perception et une bonne dose de subjectivité. Il faut donc travailler fort pour changer les perceptions et convaincre, mais ce n'est pas en dénigrant l'une ou l'autre des solutions qu'on y parvient. Par conséquent, partisan de l'un ou l'autre des camps, au lieu de vous taper dessus, travaillez fort et concentrez-vous plutôt à répondre aux besoins de vos clients en lui offrant LA meilleure solution. C'est beaucoup plus constructif de prouver la qualité de sa solution que de défendre la légitimité de sa solution en s'attaquant aux faiblesses de son compétiteur ...

samedi 20 juin 2009

Agile pure et dure ou un pas vers l'agilité ? ...

Je vous entends me dire : "Il va encore nous parler encore d'une autre tendance à la mode, la saveur du moment, un buzzword, ...". Peut-être ... Toutefois, essayons de comprendre ce qui se cache sous cette méthode Agile (ou technique pour les puristes de méthodologie) qui dérange dans le monde des TI.

L'encyclopédie Wikipédia définit les méthodes Agiles comme étant des procédures de conception logicielle qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. Comme dans toute chose, il n'y a pas une seule vision de ce qu'est la méthode Agile puisque qu'ils existent plusieurs implémentations : Rapid Application Development (RAD), Extreme Programming (XP), Scrum, etc. Mon intention n'est pas de vous vendre l'une ou l'autre de ces méthodes, ni de vous entretenir sur ce qu'elles sont. Mon intention est plutôt de vous exposer qu'est-ce qui fait défaut dans la réalisation des projets actuels en TI et l'urgence de modifier nos manières de faire.

Je n'invente rien, les échecs dans les projets en TI sont monnaie courante. L'échec prend différentes formes : insatisfaction du client et des utilisateurs parce ses besoins ne sont pas bien couverts, dépassement des coûts et retard dans la livraison, frustration de l'équipe de développement face à des spécifications incomplètes et un échéancier trop serré et nommez-les ! J'ai l'impression que dans mon domaine, un projet qui réussit est uniquement un projet livré dans les temps avec des profits avantageux pour une organisation. Le reste est accessoire. Cette approche nombriliste de certains chargés de projet me laisse perplexe et me fait douter de la capacité des méthodes de gestion de projet dites traditionnelles à mener à bien un projet informatique. Pourquoi ?

Un projet informatique, ce n'est pas :
  • un processus linéaire;
  • composé d'un groupe de ressources (terme largement utilisé et très péjoratif à mon avis) triées sur le volet que vous pouvez interchanger ou en ajouter à tout moment pour pallier à toute urgence;
  • une livraison d'une solution qui ne convient pas, mais livrée dans les délais en respectant les coûts;
  • une chose qui se fait toujours de la même manière et qu'on pourra toujours réaliser en utilisant les mêmes principes peu importe ce qu'il arrive.

Un projet informatique, c'est plutôt :

  • une suite d'impondérables;
  • composé d'une équipe de collaborateurs humains possèdant certaines qualités et défauts;
  • une livraison d'une solution qui s'ajuste à l'évolution des besoins du client et qui lui donne entière satisfaction;
  • une chose qui se déroule jamais de la même manière et qui demande d'être flexible.

Les méthodes Agiles visent justement à améliorer ces points et offre des techniques pour l'atteindre. Alors faut-il jeter nos bonnes vieilles méthodes ? Non !

En fait, c'est impossible pour une organisation de se convertir du jour au lendemain et de jeter tout ce qu'elle a utilisé pendant des années. Il faut faire un pas vers l'agilité, s'inspirer des techniques utilisées pour améliorer le déroulement interne d'un projet, mais aussi pour améliorer sa relation avec son client et lui livrer une solution satisfaisante.

Il faut minimalement :

  • repenser le rôle du chargé de projet;
  • restructurer nos équipes de développement;
  • donner plus de latitude à votre équipe et leur faire confiance (auto-gestion);
  • faire preuve de flexibilité et savoir s'adapter rapidement;
  • accorder une place importante aux clients et aux utilisateurs.

Je vous invite à lire et prendre connaissance de chacune des méthodes dites Agile, d'aller chercher les meilleurs éléments et de les expérimenter. Arrêtons cette guerre de tranchées entre puristes. L'important n'est pas de se définir comme une organisation agile pure et dure, mais de bien réaliser notre travail. Être agile, c'est d'abord reconnaître qu'il faut être agile dans l'application de la méthode elle-même. Faisons preuve de gros bon sens !

dimanche 14 juin 2009

Pourquoi la génération "Y" est déconcertante ?

Pour faire suite à mon précédent message, voici quelques raisons qui font que la génération Y est déconcertante pour les précédentes générations et nos organisations :

1) Ils manquent souvent de respect et de politesse envers les seniors. En effet, pour cette génération, la loyauté et le respect ça se mérite et ce n'est pas une question d'âge ou d'expérience. Ne pensez pas que seul vos années d'expérience vous permettront d'établir votre autorité et le respect que vous espérez. Vous risquez plutôt d'obtenir l'effet inverse.

2) Ils sont constamment connectés et prêts à communiquer sur tout. Par exemple, ils échangent ouvertement avec leurs connaissances des informations sur leur rénumération, ce qui rend la tâche difficile pour les employeurs qui veulent conserver cette information confidentielle. Par conséquent, les employeurs doivent être de plus en plus concurrentiels et faire preuve d'originalité pour les attirer.

3) Ils n'accordent pas vraiment une grande importance à la structure hiérarchique de l'entreprise. Ils sont plutôt tournés vers une structure horizontale : le travail d'équipe et la collaboration. Par ailleurs, il faut les intégrer au processus décisionnel de l'entreprise et les prendre au sérieux. Les jeunes "Y" veulent être inspirés par leur supérieur, il cherche le respect mutuel.

4) Ils recherchent des défis et du succès et de la gratification à court terme. Conséquemment, l'entreprise qui ne réussit pas à les motiver rapidement et entretenir cette motivation sera confrontée à des employés, qui dès leur mission accomplie, voudront quitter l'organisation pour d'autres défis. Il faut donc constamment leur offrir des défis, reconnaître le travail accompli et leurs efforts (rétroaction constante). Il faut d'ailleurs leur offrir rapidement des possibilités de progression. En fait, les "Y" sont ambitieux et veulent avancer rapidement.

5) Ils ont souvent des projets personnels en dehors de leur travail. Pourquoi ? En fait, ils recherchent ce que leur travail ne leur offre pas : ils sont en effet créatifs et veulent être à la fine pointe de la technologie. Pour eux, c'est un moyen de s'accomplir. C'est aux organisations d'exploiter cette caractéristique, certaines l'ont compris.

Enfin, les problèmes générationnels sont vieux comme le monde et sachez une chose, vous n'êtes pas éternels et la génération Y fait son entrée sur le marché du travail. Il y a donc réactions possibles : soit vous profitez de cette nouvelle génération, vous acceptez ses qualités et ses défauts, soit vous pensez être immortels et vous faites fi de ce changement. Si vous optez pour cette dernière option, vos jours sont comptés à la tête de votre organisation ... :)

samedi 6 juin 2009

TI : Le choc des générations !

Saviez-vous que pour l'une des premières fois au pays, quatre générations se retrouvent sur le marché du travail ? Vous le saviez sans doute ... Cette réalité cause bien des problèmes aux employeurs et les oblige à faire preuve d'originalité afin d'établir de nouvelles stratégies afin d'attirer la jeune génération tout en conservant l'expertise et l'intérêts des autres générations.

Pour ma part, je fais partie de la jeune génération (la fameuse "Y"). Force est d'admettre que cette génération est celle qui est née avec l'informatique et la plus à l'aise avec les nouvelles technologies. En effet, nous sommes plus habitués et à l'aise d'intégrer rapidement les nouvelles technologies dans notre quotidien que les générations précédentes. En fait, à l'heure actuelle, notre génération cause bien des maux de tête aux gestionnaires TI.

Pourquoi ? Surtout à cause d'une incompréhension mutuelle, du moins, je crois. Pour ma part, je ne peux que parler pour ma génération. Plusieurs croient que nous sommes trop exigeants au niveau de nos attentes salariales. En fait, nous cherchons la flexibilité, un environnement stimulant et moderne, une possibilité de progression au mérite et un plan solide de développement de carrière. Actuellement, nous avons la chance de magasiner nos emplois comme nous magasinons une automobile. Par conséquent, c'est aux employeurs de s'adapter, nous ne ferons pas des compromis parce qu'ils ne sont pas habitués à ce genre d'agissement des ressources qu'ils embauchent. En fait, c'est à eux à s'adapter à la loi du marché et d'offrir mieux qu'une rénumération et quelques avantages sociaux standards.

Quand je parle d'environnement stimulant et moderne, c'est à tous les plans. Il faut donner à un jeune employé, des outils de travail modernes. Il n'est pas rare de nous voir mieux équipés que nos employeurs TI. Il faut aussi moderniser nos manières de faire. Le développement de systèmes a été longtemps une affaire de gestion serrée des processus. Plusieurs méthodologies ont vu le jour surtout axées sur la gestion du temps, des coûts et de la qualité. Cependant, ces méthologies sont peu axées sur la satisfaction du client. Plusieurs échecs de grands chantiers informatiques peuvent témoigner de la faiblesse de ses méthodes.

Pour ma part, je ne crois pas que nous devrions tout jeter à terre et oublier les expériences du passé en pensant que nous ferons mieux. Néanmoins, il est grand temps pour les grandes firmes TI de s'intéresser et de s'investir dans les nouvelles tendances : agile, Web 2.0, logiciels libres, cloud computing, etc.

Nous sommes dans un domaine qui connaît une croissance et une évolution incroyable. Toute résistance au changement dans ce domaine de la part d'une organisation ne fait que la rendre de moins en moins compétitive.

Nos organisations n'ont pas à avoir peur de la nouvelle génération, nous avons des défauts comme les générations précédentes, mais nous avons plusieurs qualités qu'elles ne possèdent pas et c'est aux organisations de s'en servir comme effet de levier. Par ailleurs, l'une des plus grandes lacunes que je constate, c'est la non prise en compte de l'opinion des juniors. C'est malheureusement terminé les décisions unilatérales, il faut favoriser un dialogue bidirectionnel : les jeunes sont habitués à commenter, challenger et collaborer.

Enfin, comme j'ai mentionné, ma génération n'est pas parfaite, mais elle a quelque chose à apporter à nos organisations. Les employeurs qui ne feront pas l'effort de les intégrer vont sans doute le regretter et plus tôt qu'ils ne le croient ...

Qu'en pensez-vous ? Comment vous voyez cela dans votre quotidien ? Comment doit-on s'y prendre ?

Gens de toute génération, à vous la parole !