Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Rétrospective d’une décennie en affaires

Publié par Vincent Crépin le jeudi 6 mars 2014 à 21:03

Le mois de mars 2014 représente un moment tout spécial pour l’équipe d’Elapse Technologies. Et oui, ça fait 10 ans ce mois-ci que mon partenaire Pascal Roy et moi-même avons fondé l’entreprise. Je trouvais intéressant de partager avec les lecteurs de notre blogue une rétrospective de nos dix premières années à travailler à l'amélioration de la profession du développement logiciel.

Si on revient au tout début, en janvier 2004, l’entreprise qui nous employait alors venait d’être achetée par un gros joueur dans l’unique but de faire monter la valeur de sa propre action à la bourse. À partir de cet instant, il n’y avait plus de vision, plus d’avenir, et ce, malgré tous les efforts que nous avions investis au cours des années précédentes. Les aspects financiers étaient devenus tout ce qui comptait dans cette organisation et nous avions l’impression de n’avoir plus aucun contrôle sur la situation.

Pascal et moi avons alors discuté et convenu que nos objectifs de carrière étaient différents de ce que nous offrait cette organisation. Nous pensions sincèrement être en mesure de faire une différence dans l’industrie, si petite soit-elle. Nous avons donc établi les principales valeurs auxquelles nous croyions : indépendance par rapport aux banques et investisseurs, respect total des personnes avec qui nous travaillons quotidiennement, prudence et réflexion dans nos actions ainsi qu’excellence dans nos interventions. À partir de cette idée, nous avons recruté 5 autres personnes qui travaillaient pour la même entreprise que nous et voilà, Elapse venait de naître!

Les débuts nous prouvèrent rapidement que nos valeurs étaient bonnes. Malgré les enjeux associés au démarrage d’une entreprise, nous sommes passés au travers des premières années grâce à l’appui de fidèles clients et de partenaires d’affaires. J’en profite pour souligner au passage le soutien de mon bon ami Yves Bilodeau durant cette période.

Si Elapse est devenue ce qu’elle est aujourd’hui, une entreprise qui peut faire une différence pour ses clients par la qualité de ses interventions, c’est grâce à son équipe.  Bien sûr, certaines personnes nous ont quitté en cours de route, ça fait partie de la vie d’une entreprise. Cependant, nous avons toujours misé sur la rétention de nos gens. Pour une firme qui recrute des individus d’exception, je dois vous dire qu’il est essentiel d’être capable de bâtir une relation de confiance durable. Probablement que notre modèle de transparence à livre ouvert y est aussi pour quelque chose. En tout cas, je suis fier de pouvoir vous dire que les résultats démontrent que nous avons fait de bons choix.

Au cours de cette première décennie l’offre de services d’Elapse a beaucoup évolué. L’accompagnement et la formation sont venus s’ajouter au service-conseil. Nous avons développé  des spécialités très en demande comme l’agilité, l’architecture de solutions et la conception logicielle, pour ne nommer que celles-là. En fait, l’agilité s’est imposée d’elle-même au fil du temps. Lorsqu'on prend un peu de recul, on peut remarquer que les valeurs de respect, de collaboration et de transparence que l'on associe avec le développement Agile sont aussi fortement alignées avec les valeurs fondamentales de notre organisation. L'agilité est devenue notre approche de choix pour amener les équipes avec qui nous travaillons à réfléchir sur leurs façons de faire et leur permettre d’envisager de nouvelles pratiques pour mieux atteindre leurs objectifs.

Je me dois évidemment de souligner la confiance que nous a accordée notre clientèle au fil des ans. Nous sommes conscients des opportunités fantastiques  qui se sont présentées à nous et nous sommes immensément fiers d’avoir pu relever ces défis en collaboration avec nos clients.

En rétrospective, je suis très fier d’être associé à une équipe passionnée et motivée à rendre la profession du développement logiciel meilleure. Des gens qui croient qu’on peut faire mieux chaque jour pour faire progresser les règles de l’art et qui n’hésitent pas à sortir de leur zone de confort et proposer des solutions novatrices et originales.  D’ailleurs, nous sommes toujours à l’affut de personnes exceptionnelles qui partagent nos valeurs et qui souhaiteraient faire partie de l’aventure pour la seconde décennie.

Ah oui, il faut que je vous dise en terminant qu’au cours de l’année qui vient nous comptons célébrer cet anniversaire en grand et partager avec vous encore plus de contenu relié au développement logiciel. Nous vous invitons à continuer à nous suivre sur notre blogue et sur les médias sociaux pour ne rien manquer de tout ça.

Mots-Clés :

Souligner les succès…

Publié par Vincent Crépin le lundi 3 février 2014 à 20:11

J’ai récemment été appelé à effectuer une intervention à La Capitale et c’était la première fois que l’occasion se présentait à moi. J’avais eu de bons mots de plusieurs personnes ayant effectué des interventions auparavant mais rien de précis. Bien évidemment j’ai été impressionné par leur nouvel édifice vert qui vaut le détour à lui seul. Mais ce n’est pas le sujet de mon article…

Lors de rencontres avec les architectes d’affaires et organiques, j’ai pu prendre connaissance du niveau d’implantation des techniques agiles dans le département du développement et je dois dire que j’ai été impressionné. Je n’avais jamais vraiment entendu parler de cet aspect de La Capitale mais parmi les endroits que j’ai visités, ils sont au sommet de la liste selon ce que j’ai vu.

Salle de développement à La CapitaleJe parle surtout ici des pratiques de développement (TDD, refactoring, intégration continue). Ils utilisent TDD pour tous leurs développement qui utilisent la plateforme Ruby on Rails. Ils possèdent actuellement une base de tests qui se comptent en plusieurs milliers et dont la couverture frôle le 100%. Ils ont une salle de développement dans laquelle la première chose que l’on remarque, c’est la présence intimidante d’un écran géant qui donne en temps réel l’état des builds (il y avait une tuile rouge quand je suis passé ;-)). Voici d’ailleurs une photo de cela.

On sent dans cette salle la très grande complicité entre les développeurs et tous ces facteurs se matérialisent par des mises en production exemptes de défauts.

Il va sans dire que cet accomplissement est un travail acharné d’équipe, comme on le devine tous. Je félicite ces personnes qui se sont battues pour leurs idées et qui ont accompli quelque chose de bien et qui peut servir de modèle pour notre communauté.

Pourquoi HTML5 a supplanté Flex

Publié par Vincent Crépin le mercredi 12 juin 2013 à 22:04

Dans ma carrière de développeur passionné désirant toujours demeurer au niveau technique du développement logiciel, j'ai touché à une multitude de technologies de présentation. En évitant de remonter trop loin dans le passé, je peux dire que j'ai été tour à tour très à l'aise avec les technologies de présentation Web suivantes :

  • Applets Java
  • ASP.NET
  • HTML-Javascript
  • JSF-Facelets
  • GWT (Google Web Toolkit)
  • Adobe Flex (Flash)
  • HTML5

On peut regrouper toutes ces technologies selon deux modèles principaux : celles qui s'exécutent directement dans le navigateur et celles qui utilisent un moteur pour abstraire la technologie sous-jacente. Dans la dernière catégorie, on retrouve les technologies Applets Java, Flash et Microsoft Silverlight avec laquelle je n'ai pas travaillé. L'inconvénient de cette approche est la nécessité d'installer le moteur (le Flash Player dans le cas de Flash et la JRE dans le cas des Applets). L'installation du Flash Player est extrêmement simple et peu coûteuse en espace. D'ailleurs, le moteur Flash était présent sur près de 99% des navigateurs il y a à peine 3 ans, ce qui était plus élevé que le nombre d'usagers qui permettaient l'exécution de Javascript!

Je dois dire que je suis un peu surpris de constater la tendance du marché. Celle-ci s'oriente vers une technologie qui s'exécute directement dans le navigateur. On parle évidemment ici de HTML5. Je suis surpris parce que de très loin, la technologie la plus puissante et efficace avec laquelle j'ai travaillé est Flex. Il n'y a pratiquement pas de limites à ce que l'on peut faire dans un navigateur avec Flex. Et ça fonctionne. Tout le temps. Peu importe le navigateur utilisé. Évidemment il y a de petits accrocs occasionnels mais ce n'est nullement comparable au cauchemar de portabilité rencontré avec toutes les autres technologies. Et de plus, la productivité atteinte avec cette technologie est largement supérieure aux autres.   

Alors pourquoi HTML5 plutôt qu'une ou deux technologies présentant une couche d'abstraction avec le navigateur (comme Flex et Silverlight par exemple) ? Parce que dans notre industrie comme partout ailleurs, tout est une question de lobby. Et de désir des principaux joueurs de ne pas dépendre d'un autre joueur. Meilleur exemple : le refus d'Apple de supporter Flash sur ses tablettes IPad même si à ce moment, Flash était un incontournable. Dans ce cas-ci, Apple a été plus forte que le marché, ce qui constituait un pari risqué mais qui en bout de ligne semble avoir fonctionné. Les chiffres montrent un recul très important des développements faits en utilisant Flex et un avancement de ceux faits avec Objective-C (le langage utilisé nativement sur les plateformes Apple).

Pour ma part, avec HTML5, je considère qu'on retourne en arrière avec un modèle qui n'a jamais vraiment fonctionné très bien (à moins d'efforts considérables que peu d'entreprises peuvent se permettre). Je pense tout-de-même que c'est la seule option sur laquelle les principaux joueurs peuvent arriver à s'entendre puisque c'est un standard indépendant qui n'est pas contrôlé par une entreprise en particulier.  Et cette dernière phrase est critique dans mon analyse. S'ils réussissent à s'entendre et que tous les navigateurs supportent le standard de façon adéquate, nous arriverons possiblement à un état qui est comparable à ce que l'on a aujourd'hui (et que nous avons depuis des années) avec Flex. Cependant, il faudrait des outils pour augmenter la productivité lors de l'utilisation des technologies HTML-Javascript-CSS. Malheureusement, je remarque une forte carence à ce niveau sur le marché. Mais par contre, si certains joueurs récalcitrants décident, comme ils l'ont déjà fait dans le passé, de boycotter la démarche ou de prendre des chemins légèrement divergents, je pense que je vais décider alors de me recycler dans un autre domaine. :)

Plus sérieusement, je pense que cette initiative, qui n'est pourtant pas la première de ce type, pourrait être la bonne. J'ai le sentiment que les entreprises qui ne se conformeront pas à ce nouveau standard seront laissées de côté par une industrie qui demande de plus en plus des technologies standards et moins de dépendance par rapport à un fournisseur. Et je pense que nous arriverons à cet état d'ici 2 ans. Je ne serais pas encore totalement à l'aise actuellement de recommander à un client d'investir à fond dans HTML5 mais mon niveau de confort augmente progressivement depuis un an.

Agilité et SOA : pommes et oranges ?

Publié par Vincent Crépin le jeudi 23 mai 2013 à 07:28

D’abord, il me semble utile de mentionner que dans ses fondements, le développement Agile a pour but de rendre une organisation plus…agile. Donc, en deux mots, plus apte à s’adapter facilement aux changements qu’elle rencontre. Ce principe est d’ailleurs l’un des piliers du Manifeste Agile.

Une démarche agile peut donc prendre des chemins très variés pour autant que la destination nous permette d’en arriver à une plus grande facilité de réaction de l’entreprise. Le paradigme SOA (qui est essentiellement un style architectural), par définition, permet justement de rendre une organisation mieux équipée face au changement. Avec une approche SOA on y arrive en facilitant l’intégration entre les systèmes et, surtout, en fournissant une base grandissante de fonctionnalités logicielles réutilisables et composables afin de répondre à de nouveaux besoins plus rapidement et plus uniformément. Donc, on peut dire, sans risque d’offenser quiconque, que SOA peut représenter un élément important dans une démarche Agile, et vice-versa.

Voici quand même les arguments que l’on entend le plus souvent à l’encontre de l’application de l’agilité dans une initiative SOA :

  1. SOA encourage un exercice d’architecture élaboré dès le départ (parfois appelée Big Design Up Front) tandis que l’agilité le décourage, favorisant plutôt les approches de conception émergeantes et incrémentales;
  2. SOA encourage la division des équipes selon des lignes fonctionnelles tandis que l’agilité encourage des équipes multifonctionnelles;
  3. SOA ne propose pas nécessairement une approche prescriptive pour gérer un cycle de rétroaction (feedback) et faciliter le changement des services une fois qu’ils sont construits alors que l’agilité encourage les rétroactions et les changements fréquents et ce, autant au niveau technique que fonctionnel.

L’architecture

Le point 1 réfère à une caractéristique importante de SOA. En effet, la création des services nécessite une réflexion importante dès le départ parce que ceux-ci doivent être pensés de façon à accommoder des besoins futurs qui ne sont pas nécessairement définis encore. On parle particulièrement ici du modèle canonique de l’entreprise (par exemple la notion de client). Par contre, je considère que ce n’est pas parce qu’on adhère à SOA qu’on devient subitement des devins. Pas plus qu’avec n’importe quelle autre technique en tout cas… Je pense donc que trop investir dans une réflexion en amont est une erreur.

De mon expérience avec SOA, je conclus que la création de services trop « futuristes » n’apporte pas toujours les résultats escomptés. Si elle ne fait pas attention, l’équipe risque d’entreprendre  une démarche de conception conjuguée au conditionnel et jalonnée de « si » et de « lorsque ».  Il faut plutôt, à mon avis, prendre le temps de créer un service qui soit bien découpé en sous-services ayant des responsabilités plus spécifiques. Ce sont en général ces sous-services qui possèdent le plus grand potentiel de réutilisation. En effet, plus un service possède une valeur d’affaires élevée, moins son potentiel de réutilisation est grand. Par contre, des services de moindre valeur d’affaires (comme des services d’accès aux données simples) possèdent un plus grand potentiel de réutilisation.

L’organisation des équipes

Le second point découle du fait que la création de services peut facilement se faire en groupes séparés et de façon parallèle puisque les services sont destinés à faciliter l’intégration (entre autres) et la définition et le respect du contrat assure que les cauchemars d’intégration sont minimisés. À cela je réponds qu’il n’est pas obligatoire de séparer les équipes selon des lignes fonctionnelles, même si c’est facile de le faire! Dans les projets SOA auxquels j’ai participé, nous n’avons jamais effectué cette ségrégation et je ne crois pas que notre productivité s’en est ressentie. En fait, en impliquant des gens de différents secteurs de l’organisation on bénéficie de plusieurs points de vue différents. Cela permet de s’assurer un peu plus que les services développés soient conçus de façon à répondre réellement aux besoins de toute l’organisation.

L’évolution des services

Le dernier point est un peu plus complexe à défendre…les notions de feedback et d’accueil aux changements étant centrales à l’agilité. Il est indéniablement plus difficile d’appliquer cela à SOA puisque les services peuvent être utilisés par plusieurs applications de nature fort différentes (applications web, applications mobiles, intranet, extranet, internet, etc.). Il peut effectivement paraître plus laborieux de modifier le comportement d’un service existant lorsqu’on prend en considération les impacts potentiels d’un tel changement.

Un des avantages d’une démarche itérative est de nous permettre de nous rendre compte très tôt dans le cycle de développement de la nécessité de supporter plusieurs versions d’un service et d’identifier les meilleurs façons de le faire dans le contexte de l’organisation. Il est tout aussi facile d’y arriver dans une démarche SOA qu’avec n’importe quel autre style architectural. C’est exactement ce que nous préconisons dans nos projets SOA. Une fois les services construits, déployés et utilisés, nous nous en remettons à des stratégies de gestion des versions pour faciliter l’évolution sans impacter les consommateurs de ces services.

En conclusion, je pense que l’application des principes du développement Agile à des projets SOA est une approche très sensée. Il ne faut surtout pas hésiter à créer un service rapidement pour répondre à un besoin actuel en autant qu’on prenne bien le temps de découper celui-ci en sous-services réutilisables.

La géolocalisation sur mobile avec HTML 5

Publié par Vincent Crépin le mercredi 8 mai 2013 à 20:43

Une des nouvelles fonctionnalités intéressantes que HTML 5 fournit  est la capacité de géo-localiser l’utilisateur peu importe la plateforme sur laquelle l’application s’exécute. Par exemple, dans un navigateur standard, l’adresse IP sera utilisée (ce qui est souvent très imprécis) mais sur un téléphone intelligent, le GPS sera utilisé s’il est disponible et activé. Cela se fait de façon transparente. Dans cet article, je m’attarderai à la géo-localisation sur les plateformes mobiles qui utilisent le GPS.

HTML 5 fournit deux fonctionnalités de géo-localisation : soit obtenir la position actuelle ou effectuer un suivi de la position dans le cas où la personne se déplace (watch). Dans les 2 cas, les données retournées sont sous la forme d’une position qui comprend les coordonnées géo-spatiales (longitude et latitude), la vitesse de déplacement, l’altitude et une précision de la position obtenue en mètres. Les exemples de code suivants illustrent la simplicité de cet API :

function getLocation() {
    if (navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(showPosition);
    } 
    else {
        x.innerHTML="Geolocation is not supported by this browser.";
    }
}

function showPosition(position) {
    x.innerHTML="Latitude: " + position.coords.latitude + "<br />Longitude: " + position.coords.longitude;
}

function getWatchLocation() {
    if (navigator.geolocation) {
        navigator.geolocation.watchPosition(showWatchPosition);
    } else {
        x.innerHTML="Geolocation is not supported by this browser.";
    }
}
function showWatchPosition(position) {
    x.innerHTML="Latitude: " + position.coords.latitude + "<br />Longitude: " + position.coords.longitude;  
}

La première function (getLocation) invoque l’API asynchrone de géolocalisation (tout est asynchrone ou presque en Javascript…) et appelle notre function callback (showPosition) lorsqu’un résultat est disponible. Dans celle-ci, on affiche simplement les coordonnées obtenues (longitude et latitude dans un DIV. La deuxième fonction (watchLocation) se comporte de la même façon mais cela déclenche un traitement qui retourne une nouvelle position à environ toutes les secondes.  Le callback (showWatchPosition) est donc appelé à chaque fois.

Il est donc très facile avec ces données de tracer un parcours sur une carte en utilisant l’API de Google Maps qui ne nécessite aucune installation, seulement l’ajout d’une référence javascript:

<script 
    type="text/javascript" 
    src="https://maps.googleapis.com/maps/api/js?v=3&&libraries=geometry&sensor=true">
</script>

Une des applications que j’ai développées comportait justement ce besoin de suivre la route de l’utilisateur en temps réel et de la représenter sur une carte. Une première implémentation simple plaçait les points sur la carte et les reliait à l’aide d’une polyline (ligne droite entre deux points) ce qui est facilement supporté par Google Maps.

L’exemple de code suivant tiré de la documentation de Google démontre comment tracer une ligne sur la carte. Dans cet exemple, on construit un plan de vol fictif que l’on affiche sur une carte.

function initialize() {
  var myLatLng = new google.maps.LatLng(0, -180);
  var mapOptions = {
    zoom: 3,
    center: myLatLng,
    mapTypeId: google.maps.MapTypeId.TERRAIN
  };
  var map = new google.maps.Map(document.getElementById("map-canvas"), mapOptions);
  var flightPlanCoordinates = [
    new google.maps.LatLng(37.772323, -122.214897),
    new google.maps.LatLng(21.291982, -157.821856),
    new google.maps.LatLng(-18.142599, 178.431),
    new google.maps.LatLng(-27.46758, 153.027892)
  ];
  var flightPath = new google.maps.Polyline({
    path: flightPlanCoordinates,
    strokeColor: "#FF0000",
    strokeOpacity: 1.0,
    strokeWeight: 2
  });
  flightPath.setMap(map);
}

On voit que pour tracer le parcours, il faut fournir une série de coordonnées géospatiales et construire une polyline avec ces coordonnées. On indique ensuite sur quelle carte (map) la ligne doit être tracée et cela se fait automatiquement comme la figure ci-dessous le démontre.

Cette implémentation de base comporte plusieurs problèmes. Ils concernent tous la précision de la route obtenue. Un des buts importants de cette fonctionnalité dans mon application est de calculer la distance parcourue. En utilisant des lignes droites entre les points, le nombre de points requis est très grand pour tenir compte des changements de direction. De plus, la précision des points obtenus par le GPS est très variable ce qui donne parfois des distances complètement erronées. J’ai donc dû utiliser des stratégies de filtration des points pour obtenir des données plus précises.

La première modification que j’ai apportée est de rejeter les points GPS qui comportent une précision trop faible (exemple : plus de 30 mètres). Cela a aidé un peu mais une bonne précision ne garantit pas la précision réelle du point parce que la précision obtenue du GPS peut être imprécise elle aussi!!!

La deuxième modification que j’ai apportée est d’utiliser le service de directions de Google (Direction Service). Celui-ci permet de tracer une route entre deux points en utilisant une carte routière et aussi d’obtenir la distance entre ces points. C’est déjà une amélioration considérable puisque les points utilisés par l’API se trouvent nécessairement sur une route. Donc en fournissant mes points GPS, le service de directions essaiera de trouver une route entre ces deux points même si les points ne sont pas exactement sur la route en question. Mon application en étant une de suivi routier, cela convient parfaitement. L’exemple de code suivant tiré de la documentation de Google illustre l’utilisation de cet API :

var directionsDisplay;
var directionsService = new google.maps.DirectionsService();
var map;

function initialize() {
  directionsDisplay = new google.maps.DirectionsRenderer();
  var chicago = new google.maps.LatLng(41.850033, -87.6500523);
  var mapOptions = {
    zoom:7,
    mapTypeId: google.maps.MapTypeId.ROADMAP,
    center: chicago
  }
  map = new google.maps.Map(document.getElementById("map-canvas"), mapOptions);
  directionsDisplay.setMap(map);
}

function calcRoute() {
  var start = document.getElementById("start").value;
  var end = document.getElementById("end").value;
  var request = {
    origin:start,
    destination:end,
    travelMode: google.maps.TravelMode.DRIVING
  };
  directionsService.route(request, function(result, status) {
    if (status == google.maps.DirectionsStatus.OK) {
      directionsDisplay.setDirections(result);
    }
  });
}

En gros, on invoque cet API en lui spécifiant 2 points et il nous retourne une route qui tient compte des routes terrestres véritables pour aller du départ à la fin. L’objet directionsDisplay permet de tracer automatiquement cette route sur une carte sans avoir à traiter les points intermédiaires. Mais il est aussi possible de tracer nous même les points si on veut appliquer des traitements particuliers.

Mais cela ne s’est pas avéré suffisant pour répondre à mes besoins. Il peut en effet arriver que des points erronés se trouvent sur une route secondaire et le service de directions essaiera de trouver une route qui tient compte de cette route secondaire même si on ne l’a pas visitée réellement. Cela se produit surtout dans les quartiers résidentiels où les routes sont très rapprochées. J’ai donc dû ajouter un troisième correctif important. J’ai créé un algorithme de filtration assez simple : pour chaque point qui est fourni par le GPS, je calcule la distance linéaire et la distance obtenue du service de direction de Google et j’utilise la vitesse moyenne des 2 derniers points ainsi que le temps écoulé entre les deux. Je compare ces valeurs et si la valeur linéaire calculée est beaucoup plus grande que la valeur obtenue en tenant compte de la vitesse moyenne, je rejette simplement ce point. Cette stratégie a complètement éliminé les points qui se situent sur les routes secondaires puisque le temps requis pour parcourir cette distance serait beaucoup trop grand par rapport au temps réel.

Me restait un cas à régler. Si on fait du surplace pendant un certain temps (arrêt à une lumière par exemple), et que pendant ce temps on obtient un point sur une route secondaire, le temps écoulé pourrait permettre d’avoir parcouru cette fausse distance. J’ai donc finalement rejeté tous les points GPS pour lesquels la vitesse est très basse (ex : moins de 0,5 mètres par seconde).

En conservant tous les points retenus dans une base de données (voir le billet précédent sur ce sujet), il est possible de consulter les routes parcourues comme l’illustre la figure suivante :

 Geolocalisation-mobile-exemple

En conclusion, les outils de géo-localisation disponibles sur les plateformes mobiles avec HTML 5 sont très puissants mais il est nécessaire d’appliquer une certaine intelligence au traitement pour obtenir des données précises. Et cette expérimentation m’a amené à supposer que les compagnies telles que TomTom ou Garmin ont accès à des données satellites de grande qualité ou possèdent des algorithmes très élaborés.

Archive