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.

Pourquoi vos résolutions ne tiennent pas

Publié par Marc Allard le mercredi 14 janvier 2015 à 16:00

Source: www.clevelandpersonaltraining.comS’il y a un moment dans l’année où Google doit nous trouver prévisibles, c’est bien en janvier. Chaque début d’année, le moteur de recherche enregistre une hausse marquée des recherches pour les appareils de mise en forme comme les tapis roulants et les exerciseurs elliptiques, selon Google Trends. L’engouement pour les marathons, le gym et… les régimes connaît le même genre d’envolée.

Le coupable? Les résolutions du Nouvel An. Gonflés d’espoirs à l’amorce d’une nouvelle douzaine de mois, nous nous promettons de bouger plus, de manger mieux, d’arrêter de fumer, de faire le ménage dans nos finances, d’être plus performants au travail, plus organisés à la maison, plus disponibles pour nos enfants, nos familles, nos amis. La liste est longue. Mais amenez-en! Notre futur soi, version 2015, peut en prendre!

Le problème, c’est qu’il ne tient pas le coup, notre futur soi. Selon une étude de l’Université Scranton, aux États-Unis, parue en 2014, environ 92 % des gens renoncent à leurs résolutions en cours de route, un taux de succès de 8%... Pourquoi sommes-nous aussi poches? Certains auteurs de psycho-pop ne se lassent pas de répéter que c’est parce qu’on manque de volonté, parce qu’on ne veut pas assez. Or, c’est le contraire : on en veut trop — ou du moins, trop en même temps.

Depuis la fin des années 90, c’est ce que le psychologue américain Roy F. Baumeister s’est acharné à démontrer. La volonté, explique-t-il dans son livre Willpower: Rediscovering the Greatest Human Strength, est une réserve d’énergie mentale limitée. Plus on l’exerce sur une chose, moins il en reste pour autre chose. Aussi simple que ça.

Si, par exemple, je prends les marches au lieu de l’ascenseur pour monter au bureau alors que n’en ai pas l’habitude, j’aurais ensuite moins de volonté pour résister à la Kit Kat de la machine distributrice à la pause. Appliqué aux résolutions du Nouvel An, ce concept d’épuisement de la volonté, aussi appelé la «fatigue décisionnelle», signifie qu’il n’y a rien de pire qu’une liste de résolutions adoptées simultanément.

«Parce que vous n’avez qu’une réserve de volonté, écrit Baumeister, les différentes résolutions du Nouvel An compétitionnent toutes entre elles. Chaque fois que vous vous consacrez à une, vous réduisez votre capacité à tenir les autres.»

Bref, si vous êtes déjà gênés en pensant aux promesses que vous vous êtes faites le 1er janvier, vaut mieux y aller une à la fois. 

Et pour vous aider, voici une humble suggestion.

Pourquoi ne pas commencer l’année en échafaudant un kanban personnel dédié à vos résolutions? Sans doute êtes-vous familier avec ce simple outil de visualisation du flux de travail. Armés de post-it, prenez une grande feuille de papier et divisez-la en trois grandes sections verticales. Dans la première, collez les résolutions qui vous semblent les plus importantes ; dans la deuxième, déplacez celle (il devrait y en avoir une à la fois!) qui est en cours ; dans la troisième, ne laissez que celles que vous avez réussi à tenir.

Comme exercice annuel, ça peut paraître un peu intimidant. Mais qui sait, votre futur soi pourrait vous en remercier.

D'autres billets qui pourraient vous intéresser

L'approche "5 S" en développement logiciel

Publié par David Beaumier le jeudi 8 janvier 2015 à 15:48

Il n’y a pas si longtemps, j’ai participé à un atelier Lean avec une équipe que j’accompagne. L’animatrice de l’atelier, une experte Lean, a présenté différentes pratiques que les équipes peuvent utiliser pour revoir leurs façons de faire. Parmi celles-ci se trouvait l’approche « 5 S ». La méthode des « 5S » est une technique basée sur l’organisation optimale de l’espace de travail afin d’augmenter l’efficacité du processus.

Plus précisément, selon Wikipédia, 5 S « tire son appellation de la première lettre de chacune de cinq opérations constituant autant de mots d'ordre ou principes simples :

  • Seiri: supprimer l'inutile (ordonner);
  • Seiton: situer les choses (ranger);
  • Seiso : [faire] scintiller (nettoyer);
  • Seiketsu : standardiser les règles;
  • Shitsuke : suivre et progresser (être rigoureux). »

Souvent, les exemples présentés pour illustrer les principes du 5 S sont en lien avec le classement des outils nécessaires au travail, à la réduction d’éléments d’inventaire peu fréquemment utilisés, au rangement des espaces de travail (tels que les bureaux). L’image ci-dessous présente un bon exemple d’un espace « 5 S ». Dans ce coffre, chaque chose va à sa place et le système apporte une rigueur qui évite le retour possible au désordre.

Boite-a-outil

Pendant que l’animatrice présentait le concept, je me disais qu’il serait intéressant d’arrimer les concepts 5S à la réalité du développement logiciel. 

  • Ordonner : Avez-vous du code qui ne sert plus ou de la duplication de code dans votre application?
  • Ranger : Le code est-il à la bonne place et facilement accessible? Les espaces de nom (packages) sont-ils bien nommés et cohérents entre eux?
  • Nettoyer : L’équipe met-elle en pratique la réingénierie du code pour améliorer le code existant lorsqu’elle en a l’occasion?
  • Standardiser : Votre équipe possède-t-elle un standard de développement (connu et commun)?
  • Suivre : Avez-vous des mécanismes en place vous permettant d’obtenir rapidement et facilement un portrait de la situation par rapport aux règles énoncées précédemment?

Si vous avez répondu par la négative à certaines de ces questions, il y a peut-être lieu de procéder à un examen de votre base de code afin d’identifier des améliorations potentielles dans un ou plusieurs des 5 axes.

Mettre en œuvre

Fondamentalement, les principes 5S nécessitent une volonté sincère d’individus désireux de faire mieux. En s’appuyant sur le côté itératif et empirique de l’agilité, on peut en venir à mettre en place en environnement 5S optimal tout en débutant avec des initiatives ciblées. En ce début d’année, période propice aux bonnes résolutions, je vous invite à inclure au moins une initiative liée aux principes 5S au carnet de votre prochain sprint. Qu'en dites-vous?

D'autres billets qui pourraient vous intéresser

La puissance des scénarios d’acceptation

Publié par David Beaumier le lundi 22 décembre 2014 à 13:08

Source: specflow.org

Récemment, j’avais comme tâche de préparer les scénarios d’essais pour un récit (User Story) que l’équipe devait réaliser. Il faut savoir que l’équipe utilise des scénarios basés sur la syntaxe Gherkin (avec l'outil SpecFlow) pour définir le comportement attendu de l’application. Le récit en question étant très simple (il concernait l’accès une fonctionnalité selon les permissions de l’utilisateur), je vous avoue que je me suis demandé avant de débuter si ça valait la peine d’écrire ces quelques scénarios. Dans le fond, il y a seulement deux cas possibles : l’utilisateur a accès ou non. Simple n'est-ce pas?

Et pourtant, dès que j’ai entamé la rédaction du premier scénario, les questions fonctionnelles se sont mises à surgir… Par exemple, comment réagir si l’utilisateur n’a pas de droit d’accès à la fonctionnalité : désactiver l’écran, le vider ou bien rediriger l’utilisateur vers la page principale du module? Devrait-on arrimer la structure des permissions de ce module avec le nouveau modèle maintenant utilisé dans l’application? Cela a rapidement suscité un échange avec les collègues sur ce qui est facilement faisable, sur les standards dans l’application pour ce type de cas et sur l’expérience utilisateur. Tout ça pour en venir à la meilleure option en fonction des critères d’acceptation du récit.

Évidemment, les discussions n’ont durées que quelques minutes. Comme on le dit en anglais, ce n’était pas du « rocket science »! Par contre, l’écriture de ces scénarios a permis de clarifier en amont plusieurs aspects qu’il aurait fallu éclaircir de toute façon. Nous avons pu le faire en amont, en prenant le temps nécessaire et en impliquant toutes les personnes concernées. L'introduction des scénarios d'acceptation dans le cycle de développement permet d'avoir ce genre de discussions (en général plus poussées, mais vous voyez le genre) et évite les attentes implicites inconnues de l'équipier qui implémente la fonctionnalité.

Et vous, utilisez-vous les scénarios d'acceptation dans votre équipe? Quels sont les principaux bénéfices que vous en retirez? Je vous invite à partager votre expérience avec nos lecteurs en utilisant la section commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Pour aller plus loin

Si vous songez à introduire les scénarios d'acceptation dans votre équipe je vous suggère fortement la formation Tests d’acceptation: introduction à ATDD et au BDD. En plus d'introduire les concepts associés aux essais d'acceptation, cette formation vous permettra de prendre conscience des impacts que cette pratique pourrait avoir au sein de votre équipe et de votre organisation.

L'orienté objet en JavaScript, cheat sheet

Publié par Jean-Nicolas Viens le mercredi 17 décembre 2014 à 20:05

Avant de vous donner cette fameuse cheat sheet, qui saura être utile je l'espère, je voudrais vous montrer deux dernières possibilités avec les objets: les méthodes statiques et comment il est possible de manipuler le mot-clé this pour changer sa valeur avant d'invoquer une fonction.

Méthodes statiques

Ça ne faisait pas parti de l'exemple initial, mais ça peut être intéressant!

Comment faire une méthode statique? C'est simple, il faut juste se rappeler que tout est un objet! Donc on peut écrire :

var Cart = function() { ... }
Cart.methodeStatique = function() { return "méthode statique"; }

Un seule attrape : on ne peut pas invoquer une méthode statique sur un objet, on doit passer par le nom de la classe (i.e. Cart.methodeStatique(), et non uneinstanceDeCart.methodeStatique()).

Fait intéressant : essayez de faire afficher this à l'intérieur d'une fonction statique. Étrange non? Il y a une utilité à cela, je vous laisse y réfléchir!

Manipuler la valeur du this

Vous êtes-vous déjà demandé comment jQuery fait pour que, magiquement, this contienne l'élément du DOM lors d'événements? Par exemple:

$('.element').on('click', function() {
  // this prend la valeur de l'élément cliqué
});

Il y a trois fonctions disponibles en JavaScript pour arriver à cette fin.

Les deux premières sont très semblables; call prend une liste de paramètres, alors que apply prend un tableau d'arguments. La différence est mince, mais selon le cas d'utilisation une version peut s'avérer plus utile que l'autre. Par contre, dans les deux cas le premier argument est toujours la valeur qui sera associée à this! C'est de cette façon que jQuery manipule la valeur du this et permet ainsi un API plus concis.

Une autre fonction nommée bind permet d'associer des arguments (y comprit this) à une fonction, sans l'invoquer. C'est plutôt difficile au début de voir l'utilité de cette technique, mais sachez qu'elle est bien documentée dans le monde des langages fonctionnels sous le nom de curried functions ou currying. Ce concept est parfois également appelé partial application dépendamment du langage; ce sont deux concepts similaires, mais différents.

Manipuler la valeur du this est à faire avec précaution! Vous pourriez surprendre votre utilisateur, votre collègue et vous-même.

Cheat sheet

Je ne suis pas souvent en faveur des bouts de code à copier/coller sans prendre le temps de les comprendre, mais ici il y a beaucoup de code de base requis pour rien.

Je vous offre donc exceptionnellement cette cheat sheet, mais si vous essayez de faire quelque chose et que ça ne fonctionne pas, prennez le temps de relire cet article pour bien comprendre.

var Classe = (function() {

  var constanteOuStaticPrivee;

  function Classe() {
    this.public = 1;
    this._prive = 2;
  }

  Classe.prototype.fonctionPublique = function() { 
    return this.publique + this._prive;
  }

  Classe.fonctionStatic = function() {}

  return Classe;

})();

Simplement copier/coller ce bout de code et faire un rechercher/remplacer du mot Classe par le nom de votre classe! Encore mieux, il est possible d'en faire un "live template" dans la majorité des IDE modernes.

Exercice

Dans un callback jQuery, on sait que this vaut l'élément du DOM sur lequel l'événement est arrivé. Par exemple 

$('#element').click(function() {
  this.tagName; // Le nom du tag HTML, vu que this = l'élément du DOM
});

Dans ce cas, proposez une solution qui permet d'avoir accès aux attributs de notre objet puisque this ne peut pas valoir deux choses à la fois! Voici un exemple de ce qui ne fonctionne pas :

var Classe = (function() {

  function Classe() {
    this.message = "salut!";
  }

  Classe.prototype.fonction = function() {
    $('#element').click(function() {
      // 'this' ne peut pas valoir 2 choses en même temps!
      // Ici 'this' est l'élément du DOM, donc this.message est "undefined"
      $(this).text(this.message);
    });
  };

  return Classe;
})();

Conclusion

Essayez ces technique et dites-moi si votre code s'en porte mieux! N'oubliez pas que ces techniques d'orienté objet facilitent grandement les tests, avec Jasmine.js par exemple.

L'orienté objet en JavaScript, aller plus loin

Publié par Jean-Nicolas Viens le lundi 15 décembre 2014 à 07:08

Maintenant que nous avons solidifié quelques bases en JavaScript, il est temps de créer notre premier objet! Commençons par ce mot-clé souvent mal compris et qui cause bien des maux de tête : le mot-clé this. Ne vous inquiétez pas, le prochain billet contiendra une "cheat sheet" vous permettant de facilement revoir ces concepts!

Mot-clé: this

La façon la plus simple de voir this c'est de se dire qu'il est le propriétaire de la fonction qui est invoquée.

Par exemple :

var cart = function() {
  this.allo = "allo";
}

cart();

console.log(allo); // contient la chaine "allo";

Donc allo est disponible autour de la fonction cart(), car ici this == window (le propriétaire le plus haut niveau possible et par défaut dans le navigateur).

On pourrait donc essayer d'encapsuler ça dans une autre fonction :

(function() {

  var cart = function() {
    this.allo = "allo";
  }

  cart();

  console.log(allo); // contient la chaine "allo";
})(); // IIFE

console.log(allo); // contient la chaine "allo";

console.log(cart); // undefined

Hmm, allo est toujours défini dans window. La portée (scope) est bien respectée : cart n'est pas défini en dehors de la première fonction, mais allo reste défini sur window.

Par contre, si on était en mode strict (avec "use strict";), this serait undefined. Sans le mode strict et puisque this n'est associé à rien le navigateur utilise window par défaut.

Il y a bien sûr moyen d'associer this à une instance et non à window et c'est que nous allons voir.

Mot-clé: new

L'utilité du mot-clé new est d'assigner this à l'objet qu'on est en train de créer. Par convention, les fonctions sur lesquelles on peut exécuter new commencent par une majuscule. Par exemple :

var Cart = function() {
  this.allo = "allo";
  console.log(this); // log : Cart {allo: "allo"} au lieu de Window { ... }
}

var aCart = new Cart();
console.log(aCart.allo); // "allo"
console.log(allo); // undefined.

On dit donc que Cart est un constructeur.

Vie privée 

Par contre, on ne peut toujours pas définir de champ ou méthodes privées avec ce que nous avons. On pourrait utiliser le mot-clé var dans le constructeur, mais aucune des autres méthodes (celles qui sont dans le prototype) ne pourraient voir cette variable. On pourrait tout partager via this, mais alors tout serait public.

En fait, il n'y a pas vraiment de façon d'implémenter un champ privé dans un objet en JavaScript. La seule chose qui change entre les objets est le this. On a donc deux choix :

Idée #1: tout englober dans une fonction (IIFE) supplémentaire afin de créer une nouvelle portée (donc pouvoir utiliser var). Cette idée fonctionne bien, mais tout ce qui est déclaré sans le this et à l'intérieur de la fonction sera partagé entre chaque instance. Dans cet exemple, c'est la variable prive qui est partagée entre les instances a et b :

var Classe = (function() {
  var prive;

  function Classe() {
  }

  Classe.prototype.get = function() { 
    return prive;
  }

  Classe.prototype.set = function(uneValeur) { 
    prive = uneValeur;
  }

  return Classe;
})();
  • >> a = new Classe()
  • Classe {get: function, set: function}
  • >> b = new Classe()
  • Classe {get: function, set: function}
  • >> a.set(4)
  • >> b.get()
  • 4
  • >> b.set(10)
  • >> a.get()
  • 10

Quand on invoque le set() sur a alors le get() de b est affecté. Pas bien pratique pour garder un état. C'est cependant parfait pour définir des fonctions utilitaires à la classe (i.e. méthodes privées qui ne modifient pas l'état directement).

Idée #2: on invente une convention. En JavaScript, tout ce qui commence par un souligné (underscore) est considéré comme privé ou un API interne. C'est la solution qui est la plus souvent utilisée.

Et pour terminer...

Voici la classe initiale :

var Cart;

Cart = (function() {
  function Cart() {
    this.items = [];
  }

  Cart.prototype.addItem = function(item) {
    return this.items.push(item);
  };

  return Cart;

})();

Dans ce code , tout est englobé dans une fonction pour obtenir une portée (scope) privée. Tout ce qui est défini dans cette portée n'en sortira pas, sauf via le return.

Le "punch" de la fin est de retourner le constructeur! Il n'est pas invoqué, juste retourné; c'est ce qui fait que la variable à l'extérieur (le premier Cart) agit comme le constructeur qu'elle contient, mais possède une portée privée.

Attention! Le Cart à la ligne 1 et 3 n'est pas le même qu'à la ligne 4, 8 et 12. On donne simplement le même nom au constructeur qu'à la fonction qui l'entoure par convention.

Vous devriez maintenant pouvoir expliquer chaque ligne de cette classe, à la parenthèse près! Il nous reste par contre quelques sujets supplémentaires qui peuvent s'avérer intéressants à explorer, alors allons-y!

En conclusion

J'espère que ce billet explique bien toutes les techniques requises pour arriver à la solution générée par coffeescript. Ce n'est pas si simple, j'en conviens, alors n'hésitez pas à expérimenter dans un REPL! Vous pouvez également consulter le prochain billet pour un dernier sujet un peu plus poussé, mais surtout une "cheat sheet" récapitulant tout ce que nous avons vu.

Vous pouvez également essayer avec TypeScript si vous préférez. Vous obtiendrez un résultat similaire! Essayez-le ici : http://www.typescriptlang.org/Playground

Voici la version TypeScript :

class Cart {
    items: string[];

    constructor() {
        this.items = [];
    }

    addItem(item: string) {
        this.items.push(item)
    }
}

Si vous avez quelques minutes, n'oubliez pas de remplir ce sondage sur notre formation dédiée aux technologies client (frontend). Vos suggestions aideront à mieux préparer cette formation en fonction de vos besoins!

Archive