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.

Suggestion de lecture sur le Javascript

Publié par Jean-Francois Gilbert le mardi 9 juin 2015 à 00:00

S'il y a un langage qui est mal compris et parfois mal aimé, c'est bien le Javascript. Il est vrai que quelques particularités du langage peuvent être surprenantes ou même discutables. Lorsqu'on a travaillé un certain nombre d'années avec des langages tels que Java ou C#, certains concepts risquent de nous laisser perplexe. Plus souvent qu'autrement, les développeurs sont mis en contact graduellement avec ce langage. On commence d'abord par ajouter des validations ou de petites fonctionnalités à un formulaire web. Trop fréquemment, on va copier un exemple sur le web ou bien on utilisera une librairie telle que JQuery. On arrive à nos fins sans trop savoir comment ça fonctionne. Mais est-ce la bonne façon de faire ? Il y a tellement d'exemples (et de contre-exemples) sur le web qu'il est difficile de départager les bonnes pratiques des mauvaises. Puis, on utilise de plus en plus le Javascript dans nos pages (MVVM, MVC) et il arrive un moment où nos connaissances du langage montrent leurs limites. La fondation n'est pas assez solide.

Avec la multiplication des frameworks pour le web, l'ascension du Javascript côté serveur, le Javascript isomorphique et même le Javascript au niveau du hardware, on ne peut plus vraiment s'en tirer sans comprendre les principes et le fonctionnement du langage. 

Dans ma longue et difficile quête du savoir en développement, j'ai décidé d'approfondir mes connaissances en Javascript par l'achat d'un livre. L'ouvrage suivant m'a donné beaucoup de "ahhhhhh, c'est comme ça que ça fonctionne !". Il s'agit du livre Professional Javascript for web developpers . J'avoue que ça ne se lit pas comme un roman de gare (certains chapitres sont un peu arides) mais personnellement, ca m'a permis de comprendre des aspects du langage que je ne maîtrisais pas pleinement. Le chapitre sur la programmation orientée-objet m'a beaucoup éclairé sur les possibilités mais aussi les pièges du Javascript.

Bref, je vous le recommande si vous souhaitez maîtriser et exploiter ce surprenant langage dont la popularité ne se dément pas.

 

Lecture estivale pour Scrum Masters

Publié par Jean-Francois Gilbert le lundi 1 juin 2015 à 00:00

On dit souvent que les développeurs devraient s'évertuer à améliorer leurs techniques et approfondir leurs connaissances. C'est vrai, mais  ça l'est tout autant pour les Scrum Masters. Lire le guide Scrum ou recevoir une formation est un excellent point de départ, mais il faut comprendre que ce n'est qu'une base et qu'il reste beaucoup à apprendre. L'expérience sur le terrain comme Scrum Master vaut de l'or. Par contre, si elle n'est pas appuyée sur une solide fondation, le Scrum Master risque de ne pas exploiter au maximum les avantages que la méthode Scrum peut apporter à son équipe de développement.

Scrum, en tant que cadre de travail est relativement simple. L'agilité à l'origine de Scrum, mais qui également en découle, est un état d'esprit que les équipes ou même les Scrum Masters ne possèdent pas toujours. La méthode Scrum appliquée machinalement sans en comprendre le sens n'a que peu de chance de donner de véritables résultats.

Il existe heureusement une panoplie de ressources disponibles pour quiconque veut approfondir sa maîtrise de Scrum. L'été s'en vient et bien qu'il soit important de décrocher du boulot et de se changer les idées, c'est aussi un temps propice à l'apprentissage. Pourquoi ne pas profiter de la période estivale pour faire un peu de lecture et vous améliorer dans votre rôle de Scrum Master ?

Je me lance à moi-même ce petit défi. Pour ma part, j'ai décidé de relire un excellent bouquin paru en 2013 : Exploring Scrum : the Fundamentals. Bien qu'on retrouve le mot « fundamentals » dans le titre, les auteurs vont en profondeur et se basent sur des expériences concrètes. Le livre explore trois éléments fondamentaux du développement agile : les gens, le produit et les pratiques.

Si vous voulez des suggestions de livres sur le rôle de Scrum Master, sur Scrum ou l'agilité en générale, voici des listes qui vous inspireront peut-être :

Références agiles pour les coachs et Scrum Masters

5 books every Scrum Master should read

Top 100 agile books de Jurgen Appelo 

 

Mon appréciation des cours du Agile Coaching Institute

Publié par Louis-Philippe Carignan le mardi 2 juillet 2013 à 18:00

Depuis les 2 dernières années, j’ai eu l’occasion de suivre deux cours du Agile Coaching Institute (ACI). Cet institut fût fondé par Lyssa Adkins et Michael Spayd. Lyssa est l’auteure du livre « Coaching Agile Teams » tandis que Michael est sur le point de publier son propre livre, « Coaching the Agile Enterprise ». Grosso modo, l’objectif du ACI est de coacher les coachs Agile.

En juin 2011, j’ai suivi le cours « Coaching Agile Teams » qui est un bon condensé du livre de Lyssa mais avec beaucoup d’interactions. Par exemple, le manuel du participant ne tient que sur une vingtaine de pages. À chaque segment du cours, on voit un peu de théorie pour ensuite mettre la théorie en pratique. On se sert donc du manuel pour prendre quelques notes à propos de la théorie ainsi que noter nos propres expériences lors des exercices. Lors de ce cours, j’ai pu mieux comprendre toutes les facettes d’un coach Agile. Par exemple, j’ai pu faire la différence entre un mentor, coach et facilitateur, trois des postures demandées par un coach Agile. Dans un autre segment du cours, nous avons pratiqué l’écoute active par des exercices et en étant jumelé avec différents individus, on identifie rapidement nos forces et nos faiblesses en ce comparant à nos coéquipiers.

En juin 2013, j’ai alors suivi le cours « The Coaching Stance » qui est la suite du cours que j’avais suivi en 2011. Je me compte chanceux d’avoir suivi ce cours lors de la rencontre annuelle des formateurs de Scrum.org puisque j’ai pu travailler avec des coachs d’expérience. Par exemple, lors d’un exercice, on devait donner du feedback à notre coéquipier. J’ai pu voir comment un coach sénior donnait du feedback et ainsi cibler des points d’amélioration en ma propre personne.

Un point fort de cette formation est le détail d’une conversation qu’un coach a avec son client. Chaque conversation débute en ciblant le sujet dont on veut parler suivi d’une période d’exploration où le client doit répondre à une série de questions fortes posées par le coach. Lorsque le client identifie des pistes de solutions, le coach ferme la conversation en lui offrant une demande ainsi qu’un geste d’imputabilité pour faire un suivi dans des délais raisonnables.

Encore une fois, ce second cours est accompagné d’un manuel d’une vingtaine de pages qui sera remplit de nos propres expériences et commenté d’un peu de théorie. Lors de ce cours, le segment à propos du « Design Alliance » est un vrai bijou. Sans rentrer dans les détails, Lyssa qualifie ce sujet comme étant « Team norms on steroids ». Et c’est exactement ça. En résumé, on voudra dresser un code de conduire lorsque l’équipe va dérailler. Comme exemple pour mieux apprécier le concept, on raconte comment il peut être important de discuter avec les passagers qui sont à côté de nous dans l’avion. Lorsqu’il sera temps d’aller au petit coin, que ferons-nous si la personne à côté de nous dort? Il faudra bien la déranger pour se rendre aux toilettes. Pourquoi ne pas en parler avant pour déterminer comment gérer cette situation. Il est donc préférable d'eéchanger auparavant pour que tout le monde soit d’accord lorsque cela arrivera. C’est le même concept avec son équipe Agile. On se définit des règles pour gérer des conflits qui ne sont pas encore arrivés, question que toute l'équipe soit d’accord sur les mesures à prendre lorsque ceux-ci auront lieux.

Lors des deux cours, je n’ai pas eu le temps de regarder ma montre et j’avais le sentiment de bien avoir investi mon argent. Les formateurs interviennent lorsqu'on se pratique pour qu'on identifie nos points faibles. Certains exercices sont en groupe pour que tous puissent apprendre en même temps avec le feedback des formateurs.

Je recommande ces deux cours aux Scrum Masters et coachs Agile qui désirent améliorer leurs aptitudes au travail. Mais je conseille aussi ce cours aux gestionnaires et chargés de projets qui aimeraient inclure cette dimension à leur carrière. Par exemple, l’écoute active est une habileté fort utile pour un gestionnaire et le temps passé à la pratiquer lors de ces deux cours lui sera certainement bénéfique à son retour au travail. À plusieurs occasions, j’entends des gestionnaires me confier qu’ils aiment bien aider leurs subordonnés identifier leur profil de carrière. Je crois que plusieurs éléments dans les cours du ACI peuvent aider les gestionnaires qui désirent accompagner leur personnel. L’écoute active. Poser des questions fortes. Ces thèmes ne font, qu'à mon avis, améliorer l'étoffe des gestionnaires.

Le ACI offrira bientôt le cours « The Agile Facilitator » qui, vous l’avez deviné, tourne autour du thème de facilitateur. Puisque Michael est un Certified Professional Facilitator (CPF), il a sûrement monté un cours à cet effet. J’invite les Scrum Masters qui lisent ce blogue à garder un œil pour ce cours.

J’ai aussi une opinion favorable envers Lyssa, Michael et leur initiative. Ils ont cerné un créneau dans l’Agilité, coacher les coachs, qui était absent mais nécessaire dans notre profession. Grâce à leur leadership, ils vont définir ce qu’est un coach Agile. Par exemple, ils visent utiliser les « learning objectives » du International Consortium for Agile (IC Agile) pour définir les trois types de coach : Scrum Master (ou Team Facilitator), Agile Coach (ou coach de Scrum Masters) et Enterprise Agile Coach. L’image suivante, prise de leur site, résume bien ces trois niveaux de coaching :

Icagile Coaching 

Finalement, les gens du ACI ne saisissent jamais l’occasion pour ridiculiser les autres experts en Agilité. Dans les dernières années, j’ai souvent lu des chicanes entre Scrum et Kanban, le ridicule envers l'absence de pratiques d’ingénierie sous Scrum ou des moqueries à l’égard des certifications Scrum. Le ACI ne se permet pas une telle critique et cela est tout à son honneur. Ils s’élèvent au-dessus de la mêlée pour le bien de notre profession et non celui de leur porte-feuille.

La formation continue

Publié par Jean-Francois Gilbert le mardi 6 novembre 2012 à 00:00

En tant que développeurs, il est impératif tout au long de notre carrière de se garder informés de l’évolution de nos différents outils de travail. Au rythme où les frameworks et les langages évoluent, on peut rapidement se laisser distancer si on n’inclut pas des périodes d’apprentissage à notre routine. Même si on n’a qu’un nombre limité d’heures à consacrer à l’étude, on peut se maintenir à jour si l’on utilise ces heures à bon escient.

Certains d’entre nous ont la chance de travailler avec les outils les plus récents et dans des environnements nous permettant d’expérimenter différentes technologies. D’autres par contre n’ont pas cette chance et doivent développer avec des outils désuets. Afin de demeurer compétitif, employable et conseiller nos clients de la meilleure façon qui soit, nous devons fournir un effort afin de garnir notre boîte à outils. S’il est vrai que les employeurs doivent encourager et aider leurs employés à acquérir de nouvelles connaissances, le fait est que le monde du développement logiciel évolue très vite. Il n’est pas réaliste de croire que seul le temps alloué par l’employeur à l’apprentissage est suffisant. Si vous voulez demeurer pertinent dans le marché du travail, il faut mettre un minimum d’effort dans la formation continue.

Nous n’avons pas tous le loisir de pouvoir passer 20 heures par semaine de notre temps libre à expérimenter de nouvelles plates-formes. Certains développeurs qui ont un nombre d’heures limité à consacrer à l’apprentissage de nouvelles connaissances jettent la serviette, croyant qu’ils ne peuvent pas suivre la cadence qu’impose l’industrie du développement logiciel. Bien que cela demande un effort continu, il est important de comprendre que même un nombre d’heures modeste peut grandement contribuer à vous garder à jour.

Peu importe le temps dont vous disposez, la clé du succès repose sur les objectifs que vous vous serez fixés. Ces objectifs doivent être concrets et surtout réalisables dans un cours laps de temps. N’oubliez-pas que vos périodes d’apprentissage seront généralement assez courtes et possiblement irrégulières. Vous n’aurez probablement pas le temps de développer une application très élaborée, surtout si votre but est de toucher plusieurs technologies/frameworks différents.  Donc si vous voulez survoler différents outils, codez une simple fonctionnalité qui touche plusieurs technologies plutôt que de viser à créer une application complète avec une multitude de fonctionnalités.

N’oubliez-pas que vous n’avez pas nécessairement à devenir un expert de chaque technologie que vous étudiez. L’important est de comprendre les principes et de savoir que les fonctionnalités existent.  Quand vous devrez les utiliser, vous aurez tout le loisir de vous attarder aux détails d’implémentation. 

Mais comment décider sur quoi vous allez passer votre temps? Tout dépend évidemment du nombre d’heures dont vous disposez. Voici toutefois quelques idées qui vous aideront peut-être à démarrer.

Si vous avez vraiment peu de temps à votre disposition, concentrez-vous sur ce qui est directement relié à votre travail. Utilisez-vous la dernière version de votre IDE ? De votre langage de programmation ? Quelles sont les nouvelles fonctionnalités ? Y’a-t-il des plugins qui pourraient augmenter votre productivité (outils de refactoring, d’analyse de code etc )? Toujours dans le cadre de votre emploi, ciblez quelques aspects que vous maîtrisez moins. Vous êtes rouillé en SQL ? Vous ne comprenez rien au CSS ? Vous ne faites pas la distinction entre Java et Javascript ? C’est le temps d’y remédier.

Si vous avez plus de temps, revenez à la base : indépendamment du langage de programmation que vous utilisez, est-ce que votre code est SOLID? Connaissez-vous les design patterns les plus utilisés ? Connaissez-vous les enterprise patterns de Martin Fowler ? Ces connaissances sont pratiquement universelles en programmation. Cela risque de vous suivre tout au long de votre carrière.

Explorez également des méthodes ou architectures alternatives à celles que vous maîtrisez. Si vous excellez avec l’approche SOA, attaquez-vous aux services REST. Si vous êtes le roi incontesté des bases de données relationnelles, pourquoi ne pas découvrir l’approche NOSQL?

Il vous reste encore du temps? Tant mieux! Jetez un œil à un autre langage de programmation. Sortir de notre environnement de développement peut parfois nous faire faire des découvertes étonnantes. En apprenant un nouveau langage, vous allez vraisemblablement découvrir de nouveaux concepts ou façons de faire dont vous ne soupçonniez même pas l’existence.  Pourquoi ne pas importer ces concepts dans votre environnement de travail?

Ce ne sont que quelques exemples et les façons de perfectionner notre art sont nombreuses. Si vous avez l’intention de continuer à programmer encore un bout de temps et que vous avez votre métier à cœur, imposez-vous cette routine.  Nous avons la chance d’avoir un métier qui nous permet d’apprendre de nouveaux outils à l’année longue. Il faut voir cela comme une bénédiction et non un fardeau. Il est faux de croire qu’on doit renoncer à tous loisirs pour se garder à jour. Vous avez de l’expérience, vous avez les fondations sur lesquelles vont s’assoir vos nouvelles connaissances. Il suffit de se faire un plan de match et d’avoir la rigueur de le suivre.

 

Mots-Clés :

Conférence avec Bob Martin: Exiger du professionnalisme

Publié par David Beaumier le mardi 16 octobre 2012 à 16:09

L'équipe d'Elapse Technologies et la Communauté Agile de Québec sont fiers de rendre disponible la captation vidéo de la conférence prononcée par Robert C. Martin le 24 septembre dernier. Afin de rendre sa présentation des plus dynamique, Bob Martin a choisi de personnifier un CTO nouvellement arrivé dans une organisation. Il nous fait vivre ce que pourrait être la première rencontre du gestionnaire avec son équipe de développement.

Dans un style bien à lui, "Uncle Bob" explique par des exemples très concrets pourquoi exiger du professionnalisme d'une équipe de développement logiciel est devenu un impératif. Peu importe le rôle que vous exercez dans une équipe de développement il ne fait aucun doute que le contenu de ce vidéo saura vous apporter des pistes de réflexion.

N'hésitez pas à utiliser la fonctionnalité de sous-titrage offerte par YouTube si vous souhaitez suivre le texte en même temps que l'allocution. Il suffit de cliquer sur le bouton "CC" qui se trouve dans la barre d'outils situé au bas du vidéo.

D'autres extraits vidéos de Robert C. Martin sont offerts en exclusivité sur le blogue developpementagile.com

Archive