En quoi un API de persistence ou tout autre couche d'abstraction augmente-t-elle l'agilité d'une entreprise? La réponse à cette question est évidente si on doit construire une solution qui sera déployée dans différents environnements et donc, qui doit se connecter à différents SGBDs. Cela est typiquement le cas de logiciels comerciaux ou sous licence libre. Par contre, quand on développe une solution maison, le reflèxe est de se dire que la portabilité et la possibilité de changer de SGBD n'est pas aussi importante et que cela ne constitue donc pas une justification pour une couche d'abstraction.
Par contre, j'ai été confronté, dernièrement, à une situation qui illustre bien le type d'écueils que l'on rencontre lorsque une organisation (dans ce cas-ci, une grande organisation avec de multiples solutions informatiques) n'utilise pas de couche d'abstraction pour un service comme la persistence. Dans le cas qui nous occupe, il s'avert que l'entreprise doit mettre à niveau le principal engin de BD qu'elle utilise et veut profiter de l 'occasion pour uniformiser les pilotes JDBC utilisés avec les pools de connexions. Trois pilotes différents sont utilisés pour se connecter à un même SGBD et on veut réduire cela à un seul. Cela parait sensé. Or, au moins une application utilise un "feature" qui n'est supporté que par un seul des pilotes (évidemment, pas par celui que l'on désire normaliser!).
Si on avait utilisé une couche d'abstraction comme Hibernate ou JPA, le risque de se retrouver avec un tel problème serait très faible. À moins, évidemment, que dans certaines applications on ait décidé de contourner l'API de persistance mais cela devient un problème de gouvernance n'est-ce pas?
En d'autres mots, ce que j'essaie de montrer c'est que les bénéfices d'utiliser une couche d'abstraction sont parfois là où on ne les attendait pas.
lundi 23 février 2009
vendredi 20 février 2009
La philosophie Google
J'ai eu la chance, dernièrement, d'étudier et d'exploiter différentes technologies fournies par Google notamment le Google Web Toolkit (GWT) et le Android SDK pour Smartphones utlisant le OS Android. Je ne m'attarderai pas à décrire en détails ces deux solutions mais plutôt à essayer de mettre en lumière ce qui semble être l'approche Googléène (!) au niveau des outils et technologies de développement. Disons simplement que GWT est une plateforme pour le développement et la livraison d'applications Javascript et que Android est une plateforme pour le déevloppement, la livraison et l'exploitation d'applications pour les Smartphones (je cherche encore un néologisme en français qui pourrait être utilisé).
En premier lieu, les deux systèmes misent sur la technologie Java. Cela a plusieurs avantages, notamment au niveau de l'agilité, mais avant tout cela permet de tirer profit d'une technologie et d'une plateforme riche et mature. Les développeurs Java qui ont eu, comme moi, à faire du Javascript ont sans doute trouvé que cela revenait bien souvent à retourner à l'age de pierre informatique car les outils d'aide au développement étaient (et sont encore) très primitifs. GWT change la donne complètement. En effet, avec lui, on code, on test et on déboggue en Java avec notre IDE préféré (généralement Eclipse). Cela facilite et accélère les chose considérablement par rapport à écrire directement du JavaScript. Lorsque'on est prêt pour les tests de déploiement, on invoque simplement le compilateur GWT qui génère le code javascript pour les différents navigateurs. Il s'agit d'une techno sophitiquée qui simplifie grandement le travail des développeurs et assure une plus grande qualité des livrables. Le plus excitant, c'est que ça marche!
Du côté du Android toolkit, on a utilisé sensiblement la même philosophie car on développe en Java, on test sur un émulateur Java et on utilise le compilateur Android pour produire un exécutable compatible avec le runtime (VM) Android.
Autrement dit, la philosophie Google semble être de miser sur les compétences et les outils Java qui sont généralement disponibles et de masquer les particularités de la plateforme cible à travers un "toolkit" propre à cette platefrome (en l'occurrence, les Navigateurs+Javascript ou le Smartphone+Android.
L'idée est bonne et l'exécution l'est également.
Chapeau!
jeudi 18 décembre 2008
Plateformes technologiques et agilité
La question du jour est de savoir si devant le dieu de l'agilité, toutes les plateformes sont égales ou équivalentes. Autrement dit, est-ce que certaines plate-formes ou technologies sont plus agiles que d'autres?
Il m'apparait clair que la réponse est oui, certaines technologies sont plus agiles que d'autres. La sous-question est de savoir par rapport à quelle aspect? Une technologie qui permet la construction d'artéfacts (ex. de logiciels) pouvant être déployés sur différents environnements et systèmes d'exploitation peut prétendre avec raison d'être plus agile qu'une autre qui ne le permet pas. Est-ce que vous pensez au débat Java vs .NET? De même, une technologie qui est polyvalente en ce qu'elle permet de construire des applications web, des applications mobiles, des applications graphiques etc. peut être qualifiée de plus agile qu'une technologie qui est destinée à une plateforme ou un type d'application unique. De plus, si on considère qu'une ressource qui connait cette technologie polyvalente est par le fait même polyvalente on peut déduire que l'organisation qui utilise cette techno à plus de marge de manoeuvre quand vient le temps d'assigner des ressources à des projets et donc, est plus agile que l'organisation qui a des ressources possédant des compétences qui n'ont pas une grande portée horizontale. Considérez, par exemple, le problème des applications et des ressources Cobol dans les entreprises. De telles applications et ressources ne contribuent manifestement pas à l'agilité de l'entreprise.
On peut considérer les choses sous un autre angle et évaluer le degré d'agilité d'une technologie sous le prisme de la rapidité avec laquelle une solution peut être mise en oeuvre. Le délais de mise en oeuvre est un bon indice d'agilité quand vient le temps de comparer deux systèmes sauf qu'il est souvent difficile de comparer deux produits car la technologie n'est pas le seul déterminant de la vélocité avec laquelle on peut produire une solution. En fait, contrairement à ce que beaucoup de gestionnaires croient, ce n'est probablement pas le facteur le plus important à cet égard.
Il m'apparait clair que la réponse est oui, certaines technologies sont plus agiles que d'autres. La sous-question est de savoir par rapport à quelle aspect? Une technologie qui permet la construction d'artéfacts (ex. de logiciels) pouvant être déployés sur différents environnements et systèmes d'exploitation peut prétendre avec raison d'être plus agile qu'une autre qui ne le permet pas. Est-ce que vous pensez au débat Java vs .NET? De même, une technologie qui est polyvalente en ce qu'elle permet de construire des applications web, des applications mobiles, des applications graphiques etc. peut être qualifiée de plus agile qu'une technologie qui est destinée à une plateforme ou un type d'application unique. De plus, si on considère qu'une ressource qui connait cette technologie polyvalente est par le fait même polyvalente on peut déduire que l'organisation qui utilise cette techno à plus de marge de manoeuvre quand vient le temps d'assigner des ressources à des projets et donc, est plus agile que l'organisation qui a des ressources possédant des compétences qui n'ont pas une grande portée horizontale. Considérez, par exemple, le problème des applications et des ressources Cobol dans les entreprises. De telles applications et ressources ne contribuent manifestement pas à l'agilité de l'entreprise.
On peut considérer les choses sous un autre angle et évaluer le degré d'agilité d'une technologie sous le prisme de la rapidité avec laquelle une solution peut être mise en oeuvre. Le délais de mise en oeuvre est un bon indice d'agilité quand vient le temps de comparer deux systèmes sauf qu'il est souvent difficile de comparer deux produits car la technologie n'est pas le seul déterminant de la vélocité avec laquelle on peut produire une solution. En fait, contrairement à ce que beaucoup de gestionnaires croient, ce n'est probablement pas le facteur le plus important à cet égard.
lundi 8 décembre 2008
Le gestionnaire d'enjeux: Un outil essentiel
Je suis toujours étonné de constater combien d'équipes ou d'organisations qui font du développement ou plus généralement de la gestion de projets font l'économie de l'utilisation d'un gestionnaire d'enjeux ("issue tracker"). Même si on n'utilise pas vraiment une approche agile, un tel outil est, à mon sens, essentiel à la progression harmonieuse d'un projet. Cette fausse économie est d'autant plus difficile à justifier qu'il existe une panoplie d'excellents outils disponibles gratuitement.
Plus le nombre d'intervenants est élevé, plus il y a de projets et plus les membres de l'équipe travaillent en des lieux et heures différentes, plus un tel outil est nécessaire.
Au délà des anomalies
Les développeurs logiciels sont généralement familiers avec les "bugs trackers" ou gestionnaires d'anomalies et la plupart des outils ont commencé leurs vie sous cette personnalité. On s'est rapidement rendu compte qu'une anomalie est essentiellement un enjeu qui doit être documenté, analysé, discuté, priorisé, assigné, solutionné et vérifié. Outre les anomalies, qui arrivent, par définition, après la première livraison, les projets sont invariablement affligés d'une pléthore d'enjeux et cela, dès les premiers jours de leur vie. En effet, comme chacun sait, dans la grande majorité des projets, on rencontre des enjeux techniques, logistiques, organisationnels, budgétaires, business, conceptuels etc. Dans ma pratique, j'ai tendance à traiter presque tout comme un enjeu: les exigences fonctionnelles et non-fontionnelles, les demandes de changements, les risques, les anomalies. En ligne avec l'approche agile, c'est à chaque équipe et projet de décider comment utiliser le système mais chose certaine, il est difficile pour moi d'envisager un projet sans gestionnaire d'enjeux.
Un outil universel?
Les systèmes de suivi sont populaires en génie logiciel mais qu'en est-il pour les projets de construction d'une infrastructure matérielle (route, pont, édifice) ou pour l'organisation d'un événement (spectacle, fête, expédition, élection), pour la production d'un film ou d'une pièce de théatre? De mon point de vue, la gestion de projet est essentiellement une suite d'enjeux à identifier et à solutionner. Qui plus est, une infrastructure (logicielle ou matérielle) étant généralement quelque chose d'évolutif soumis à de la maintenance et à des transformations, la gestion d'enjeux est une constante pour toute la durée de vie de cette infrastructure. Je serais curieux de recevoir des témoignages concernant l'utilisation de tels outils dans des contextes autres que des projets informatiques. En fait, je serais curieux de savoir si on préconise l'utilisation de systèmes de gestion des enjeux dans les programmes de formation de gestionnaires de projets (n'hésitez pas à partager votre expérience sur ce blog).
Principal avantage: La communication
Les avantages liés à un système de gestion des enjeux sont nombreux mais essentiellement, cela tourne autour de deux besoins: la communication et la mémoire. Le courriel est un outil formidable mais comme moyen principal pour gérer les enjeux, c'est infernal. Quand à Excel comme outil de gestion des enjeux, n'en parlons même pas. Il faut un espace web pour consigner les enjeux et en faire le suivi. Tous les membres de l'équipe doivent se discipliner et consigner les enjeux qui ont besoin d'être suivis. Ma propre règle est la suivante: si quelqu'un identifie un enjeu qui ne peut être réglé sur le champ, il faut le consigner dans le journal des enjeux pour qu'il ne soit pas oublié. La plupart des enjeux non triviaux font souvent l'objet d'un va et vient entre différentes personnes. Avec un système de suivi, cet "échange" est consigné et peut être consulté par l'ensemble des parties prenantes (d'où l'aspect "mémoire" du système).
Plus utile que Project!
Pour en revenir au génie logiciel, j'ai eu recours à des systèmes de gestion d'enjeux dans presque tous les projets que j'ai eu à gérer ou réaliser récemment et, de mon point de vue, on ne peut fonctionner efficacement (de façon agile ou autrement) sans ce type d'outil. À mon humble avis, l'utilisation d'un système de gestion des enjeux est plus utile et contribue beaucoup plus au succès d'un projet que MS Project mais il faut adhérer à une vision et à une organisation "agile" du travail pour avoir une telle opinion.
Épilogue
Nous aurons probablement l'occasion de revenir sur les outils et je serais particulièrement intéressé à échanger sur ce thème. Notamment, je crois qu'il faudrait proposer un néologisme (en français) pour cette catégorie de logiciel car cela aurait plus d'impact auprès des technocrates. En attendant voici quelque liens pertinents:
Plus le nombre d'intervenants est élevé, plus il y a de projets et plus les membres de l'équipe travaillent en des lieux et heures différentes, plus un tel outil est nécessaire.
Au délà des anomalies
Les développeurs logiciels sont généralement familiers avec les "bugs trackers" ou gestionnaires d'anomalies et la plupart des outils ont commencé leurs vie sous cette personnalité. On s'est rapidement rendu compte qu'une anomalie est essentiellement un enjeu qui doit être documenté, analysé, discuté, priorisé, assigné, solutionné et vérifié. Outre les anomalies, qui arrivent, par définition, après la première livraison, les projets sont invariablement affligés d'une pléthore d'enjeux et cela, dès les premiers jours de leur vie. En effet, comme chacun sait, dans la grande majorité des projets, on rencontre des enjeux techniques, logistiques, organisationnels, budgétaires, business, conceptuels etc. Dans ma pratique, j'ai tendance à traiter presque tout comme un enjeu: les exigences fonctionnelles et non-fontionnelles, les demandes de changements, les risques, les anomalies. En ligne avec l'approche agile, c'est à chaque équipe et projet de décider comment utiliser le système mais chose certaine, il est difficile pour moi d'envisager un projet sans gestionnaire d'enjeux.
Un outil universel?
Les systèmes de suivi sont populaires en génie logiciel mais qu'en est-il pour les projets de construction d'une infrastructure matérielle (route, pont, édifice) ou pour l'organisation d'un événement (spectacle, fête, expédition, élection), pour la production d'un film ou d'une pièce de théatre? De mon point de vue, la gestion de projet est essentiellement une suite d'enjeux à identifier et à solutionner. Qui plus est, une infrastructure (logicielle ou matérielle) étant généralement quelque chose d'évolutif soumis à de la maintenance et à des transformations, la gestion d'enjeux est une constante pour toute la durée de vie de cette infrastructure. Je serais curieux de recevoir des témoignages concernant l'utilisation de tels outils dans des contextes autres que des projets informatiques. En fait, je serais curieux de savoir si on préconise l'utilisation de systèmes de gestion des enjeux dans les programmes de formation de gestionnaires de projets (n'hésitez pas à partager votre expérience sur ce blog).
Principal avantage: La communication
Les avantages liés à un système de gestion des enjeux sont nombreux mais essentiellement, cela tourne autour de deux besoins: la communication et la mémoire. Le courriel est un outil formidable mais comme moyen principal pour gérer les enjeux, c'est infernal. Quand à Excel comme outil de gestion des enjeux, n'en parlons même pas. Il faut un espace web pour consigner les enjeux et en faire le suivi. Tous les membres de l'équipe doivent se discipliner et consigner les enjeux qui ont besoin d'être suivis. Ma propre règle est la suivante: si quelqu'un identifie un enjeu qui ne peut être réglé sur le champ, il faut le consigner dans le journal des enjeux pour qu'il ne soit pas oublié. La plupart des enjeux non triviaux font souvent l'objet d'un va et vient entre différentes personnes. Avec un système de suivi, cet "échange" est consigné et peut être consulté par l'ensemble des parties prenantes (d'où l'aspect "mémoire" du système).
Plus utile que Project!
Pour en revenir au génie logiciel, j'ai eu recours à des systèmes de gestion d'enjeux dans presque tous les projets que j'ai eu à gérer ou réaliser récemment et, de mon point de vue, on ne peut fonctionner efficacement (de façon agile ou autrement) sans ce type d'outil. À mon humble avis, l'utilisation d'un système de gestion des enjeux est plus utile et contribue beaucoup plus au succès d'un projet que MS Project mais il faut adhérer à une vision et à une organisation "agile" du travail pour avoir une telle opinion.
Épilogue
Nous aurons probablement l'occasion de revenir sur les outils et je serais particulièrement intéressé à échanger sur ce thème. Notamment, je crois qu'il faudrait proposer un néologisme (en français) pour cette catégorie de logiciel car cela aurait plus d'impact auprès des technocrates. En attendant voici quelque liens pertinents:
vendredi 5 décembre 2008
L'agilité comme principe d'organisation sociale
Le monde du développement informatique est de plus en plus familier avec le concept d'agilité comme méthodologie et comme concept directeur pour la construction de systèmes et la gestion de projets. Mais cette qualité d'agilité ne s'applique-t-elle pas à toute les formes d'organisations et d'initiatives? La plupart des gens sont prêts à se ranger derrière l'idée que l'agilité est préférable à la rigidité dans une organisation quelle quelle soit mais qu'est-ce que cela implique? Comment appliquer les principes agiles à une entreprise, à une gouvernement, à une société, à une économie?
Qu'est-ce qui caractérise une société agile et comment favorise-t-on cette agilité? Quels sont les avantages et quels sont les inconvénients ou compromis que l'on doit accepter si on veut être agile comme groupe ou société? A mon avis, l'agilité c'est un peu comme l'environnement, tout le monde est favorable et s'entend qu'il faut y travailler mais lorsque vient le temps d'appliquer des mesures qui vont avec le discours, on trouve généralement des bonnes raisons pour s'esquiver ou déléguer la responsabilité aux autres.
Pour qu'une organisation puisse être considérée agile, elle doit être capable de s'adapter rapidement et continuellement au changement. Si on accepte cela et qu'on l'applique à une société ou une économie, on doit également accepter certains principes comme la mobilité et la polyvalence de la main d'oeuvre.
Les emplois à vie et les travailleurs spécialisés qui ne savent faire qu'une chose sont des facteurs de rigidité et non d'agilité. Cela nous amène forcément à regarder les programmes de formation et les contrats de travail (par exemple entre syndicats et employeurs) de façon à favoriser cette mobilité et cette polyvalence. Malheureusement, c'est dans la nature même des regroupements de travailleurs et de professionnels (syndicats ou corporations) de s'opposer à la mobilité. En effet, ces groupes ont pour mission et comme réflexe de préserver l'intérêt de leurs membres. Ils ont, en pratique, généralement tendance à préserver l'intérêt de l'organisation elle-même (c-à-d. le regroupement) ce qui mène au cloisonnement des tâches (c-à-d : aux pratiques réservées) et à des luttes pour préserver le niveau du membership du regroupement. Autrement dit, les regroupements de travailleurs et de professionnels sont généralement des facteurs de rigidité dans une organisation ou une société. Cela ne veut pas dire qu'ils sont inutiles mais qu'il faut être conscient de cet aspect de leur nature et de leurs interventions et travailler à inclure des clauses qui préservent l'agilité dans les contrats et dans les chartes de ces organismes.
A suivre...
Qu'est-ce qui caractérise une société agile et comment favorise-t-on cette agilité? Quels sont les avantages et quels sont les inconvénients ou compromis que l'on doit accepter si on veut être agile comme groupe ou société? A mon avis, l'agilité c'est un peu comme l'environnement, tout le monde est favorable et s'entend qu'il faut y travailler mais lorsque vient le temps d'appliquer des mesures qui vont avec le discours, on trouve généralement des bonnes raisons pour s'esquiver ou déléguer la responsabilité aux autres.
Pour qu'une organisation puisse être considérée agile, elle doit être capable de s'adapter rapidement et continuellement au changement. Si on accepte cela et qu'on l'applique à une société ou une économie, on doit également accepter certains principes comme la mobilité et la polyvalence de la main d'oeuvre.
Les emplois à vie et les travailleurs spécialisés qui ne savent faire qu'une chose sont des facteurs de rigidité et non d'agilité. Cela nous amène forcément à regarder les programmes de formation et les contrats de travail (par exemple entre syndicats et employeurs) de façon à favoriser cette mobilité et cette polyvalence. Malheureusement, c'est dans la nature même des regroupements de travailleurs et de professionnels (syndicats ou corporations) de s'opposer à la mobilité. En effet, ces groupes ont pour mission et comme réflexe de préserver l'intérêt de leurs membres. Ils ont, en pratique, généralement tendance à préserver l'intérêt de l'organisation elle-même (c-à-d. le regroupement) ce qui mène au cloisonnement des tâches (c-à-d : aux pratiques réservées) et à des luttes pour préserver le niveau du membership du regroupement. Autrement dit, les regroupements de travailleurs et de professionnels sont généralement des facteurs de rigidité dans une organisation ou une société. Cela ne veut pas dire qu'ils sont inutiles mais qu'il faut être conscient de cet aspect de leur nature et de leurs interventions et travailler à inclure des clauses qui préservent l'agilité dans les contrats et dans les chartes de ces organismes.
A suivre...
Le code libre: un "agility enhancer"
Est-ce qu'il y a un rapport entre les logiciels libres (open source) et l'agilité?
Voilà une bonne question! A priori, on serait tenté de dire non. Le type de licence utilisé ne détermine pas le degré d'agilité d'une organisation. Par contre, pour tous ceux qui ont eu à composer avec cela , il est évident que le recours à des logiciels sous licences commerciales est un facteur qui augmente la rigidité et, comme tout le monde le sait, la rigidité est l'ennemie de l'agilité (!). J'ai essayé de dresser la liste des effets "rigidifiants" (sic) des licences commerciales:
Voilà une bonne question! A priori, on serait tenté de dire non. Le type de licence utilisé ne détermine pas le degré d'agilité d'une organisation. Par contre, pour tous ceux qui ont eu à composer avec cela , il est évident que le recours à des logiciels sous licences commerciales est un facteur qui augmente la rigidité et, comme tout le monde le sait, la rigidité est l'ennemie de l'agilité (!). J'ai essayé de dresser la liste des effets "rigidifiants" (sic) des licences commerciales:
- Le processus de décision menant à l'achat (ou non) d'une licence pour un logiciel est généralement lourd, long et ardu. En développement agile, les décisions doivent pouvoir se prendre rapidement et sans l'implication d'intervenants multiples comme c'est le cas généralement lorsque on doit faire émettre un bon de commande et pire, lorsque la révision et la négociation d'un contrat de licence est en cause.
- Les licences commerciales sont souvent contraignantes. Dépendament des termes de la licence, on est souvent soumis à un nombre maximum d'usagers, à une date d'expiration, à des coûts et processus de mise à niveau. Cela mène parfois à des situations absurdes où un logiciel acheté à gros prix n'est pas utilisé pour cause d'un manque d'un nombre suffisant de « sièges » ou pire, est utilisé par une partie des employés seulement ce qui dans le cas d'outils de collaboration notamment, est un non-sens (mais néanmoins une situation que j'ai rencontrée).
- Avec une licence commerciale, l'installation et la diffusion des copies du logiciel doit généralement se faire de manière contrôlée et supervisée. On a souvent besoin de clés (logicielles et/ou matérielles) et même d'une certaine expertise pour installer le produit. Bref, c'est généralement compliqué et fastidieux. Qualités qui sont difficiles à concilier avec l'agilité.
- Le fait qu'on débourse un montant (parfois élevé) pour un logiciel a un effet d'inertie à travers toute l'organisation et en particulier auprès des gestionnaires. Avez-vous déjà eu a expliquer à un gestionnaire que l'investissement qu'il a fait est inutile ou désuet? Qu'on ferait mieux de laisser tomber une solution qui a été payée très chère et même, qu'on aurait avantage à la remplacer par une solution qui elle, est gratuite? En général, on rencontre de la résistance lorsqu'on se présente avec une telle proposition ce qui est probablement normal mais pas nécessairement rationnel. On refuse d'abonner une solution logicielle au profit d'une autre qui est significativement meilleure, moins chère et plus efficace sous prétexte que l'on a déboursé un montant important pour la première. En fait, le prix payé pour une solution devrait être le dernier critère à considérer lorsque vient le temps d'évaluer sa pertinence. Il faut plutôt considérer les avantages liés au changement.
Inscription à :
Articles (Atom)