Agile Tour Québec 2013

ATKiosk

Le 6 novembre dernier, a eu lieu la 5e édition du Agile Tour Québec. Étant bénévole, j’ai eu la chance d’assister à de belles conférences et aussi y faire de bons échanges avec les participants et présentateurs. Cette année, nous avons franchi le cap des 500 participants, ce qui est très bien pour la ville de Québec. Et encore une fois, de bons présentateurs sont venus donner leur temps pour nous parler de développement Agile.

Et voici le récapitulatif de ce que j’ai vu et entendu:

Rapid and Lasting Agile Adoption (conférenc principale)

J’ai été plus ou moins attentif à cette présentation étant donné l’effervescence du début de la journée et de l’inscription. Mais j’ai retenu quand même plusieurs points intéressants:

  • Passer d’une méthode de travail à une autre est comme un genre de deuil.
  • Un rite de passage est utile pour favoriser l’adoption « Agile » dans la culture d’entreprise.
  • Les gens doivent s’engager, idéalement, au lieu de se faire imposer une nouvelle manière de travailler.

Le conférencier a formalisé le tout autour du principe de « Open Agile Adoption ». Je trouve très intéressant tout cela et cela a plein de bon sens de faire des rencontres ouvertes ponctuelles pour discuter de l’adoption agile. On retrouve ici dans le schéma suivant l’essentiel de ce principe:

OAnA-fig1large1

Pour plus de détails, consulter les sites suivants:

À vos marques, prêts, codez!

Format un peu inusité pour cette présentation:

  • 2 développeurs programment avec sur un écran distinct.
  • Ils utilisent deux langages de programmation différents: le C# et le Python.
  • Un 3e présentateur est à l’arrière de la salle et fait l’animation.

Bien qu’inventif comme format, j’ai plus ou moins aimé. Malgré certains commentaires pertinents de l’animateur, il avait plutôt l’air de quelqu’un qui commente une game de hockey par moment.

Quand on présente un « Code Kata » dans une présentation, j’aime bien quand le développeur pense à haute voix et on peut ainsi comprendre son raisonnement et ses choix. Ce ne fut pas le cas ici. Seulement des interventions occasionnelles de l’animateur en questionnant les développeurs.

Aussi, l’introduction était un peu absente. Mettre le schéma du TDD au début aurait été utile pour certains.

Quelques points intéressants que j’ai notés:

  • Il y a de multiples chemins pour résoudre un Kata
  • Il est parfois utile de se mettre un minuteur pour nous rappeler à l’ordre afin de faire passer un test au « vert ».
  • Lors d’un refactoring ou perfectionnement du code, bien-être certain de l’intention.
  • Lors de l’étape « Rouge » ou faire un test qui échoue, au début il s’agit surtout d’améliorer le message d’erreur.
  • On est rarement assez agressif avec le refactoring.

Bref, un peu déçu, mais quand même bravo aux présentateurs, car ce n’est pas toujours facile de programmer « live » devant plusieurs personnes et d’essayer un nouveau genre de présentation.

Esclave de votre dette technique?

Présentation très dynamique de Pascal Roy et de Félix-Antoine Bourbonnais. Les deux gars sont des passionnés !

Les faits saillants:

  • Quadrant de la dette technique de Martin Fowler pour savoir quelle genre de dette technique on a affaire.
  • Des outils existent pour aider à identifier notre dette technique, comme la duplication par exemple.
  • Ne pas négocier votre dette
  • Faire du refactoring dans des endroits gagnants.
  • Prendre la responsabilité de cette dette.
  • Faire son bilan.
  • Chérissez votre code !

Voici la présentation intégrale sur Slideshare:

Javascript : Tester le code oublié

Bien que loin d’être un expert Javascript, j’ai fait à l’occasion, mais vraiment pas souvent, j’ai quand même aimé cette présentation.

L’interaction entre les deux présentateurs, Vincent Crépin (l’architecte) et Jean-Nicolas (le développeur) était intéressante. On voyait ainsi la réflexion de quelqu’un qui commence s’intéresser au Javascript avec l’aide d’un autre qui en mange tous les jours.

Les faits saillants:

  • Tester les fonctions qui sont au coeur du langage
  • Jasmine est le framework recommandé pour faire des tests style TDD/BDD. Il est assez simple de l’installer et de commencer à s’en servir.
  • Le concept de « closure » peut paraître complexe au premier abord, mais est très important à maîtriser.
  • Knockout.js est un framework Javascript intéressant pour faire une interface web avec le patron Model-View-ViewModel (MVVM).

Plus qu’une équipe : bâtir une entreprise Lean

George Saad a toujours des choses intéressantes à raconter. Cette fois-ci, c’est un peu plus personnel, car il nous explique le fonctionnement de sa boîte de développement web: Spektrum Media.

Avec une équipe réduite d’une dizaine de personnes où pratiquement tout le monde fait du code, il est possible d’être efficace outre les budgets.

En appliquant les principes Lean de bout en bout de son entreprise, il se permet de brasser la cage et de compléter des projets bien en deçà des budgets préliminaires. Comment fait-il exactement ?

  • Évite le gaspillage au maximum.
  • Se permettre de choisir les projets, car la demande est plus grande que l’offre de service de son entreprise.
  • Trouve le juste milieu entre le prix et la qualité
  • 1 seul développeur est nécessaire pour l’évaluation de la proposition. Par la suite, un analyste/chargé de projet y met son grain de sel.
  • Procède toujours en commençant petit, morceau par morceau, afin d’obtenir le feedback ou rétroaction le plus rapide du client. De cette manière, on valide régulièrement si on est sur la bonne voix et si cela vaut la peine de continuer.
  • Côté recrutement, cherche les meilleurs développeurs, le genre qui se foutent un peu du langage et de la technologie.

J’aime particulièrement le concept du "vendredi innovation". À cette journée, les employés travaillent sur des projets personnels à moins qu’il y ait du retard dans un des projets pour des clients. Quand cela arrive, c’est une forme d’indicateur de gestion indiquant qu’il y’a peut-être des problèmes à l’horizon.

Référence:

Est-ce que votre architecture est organique ?

greek-house-1428553-m

Bon, il fallait que j’en parle, cela me tracasse depuis longtemps. Est-ce que vous savez que le terme « organique »  est inapproprié lorsque l’on parle d’une architecture en informatique ou du rôle architecte organique ? C’est un de mes anciens collègues, Guy Larochelle, qui m’avait déjà expliqué cela il y a quelque années.

En passant, noter que cette opinion, comme dans tous mes billets, est la mienne et ne représente pas nécessairement celle de mon employeur actuel.

Pour répondre à la question qui fait le titre de ce billet, Est-ce que votre architecture est organique, je répondrai : j’espère bien que non !  Votre architecture (logicielle) ne devrait pas idéalement être organique.  Je m’explique :

Au Québec et en particulier dans la région de la ville de Québec, chez les organismes gouvernementaux et certaines grandes compagnies, ce terme est associé régulièrement aux noms suivants:

  • Architecture organique
  • Architecte organique
  • Analyste organique
  • Concepteur d’architectures organiques

Pourtant, si on regarde la définition « officielle »  sur Wikipédia (français) de l’architecture logicielle, qui est le vrai terme ici en passant, on retrouve une mention de ce qu’est une architecture organique:

Bien des logiciels ont été créés sans architecture par plusieurs générations de développeurs ayant chacune usé d’une imagination débordante pour réussir à maintenir l’intégrité du système. Une telle absence d’architecture peut être qualifiée d’architecture organique. En effet, un développeur confronté à une telle architecture a plus l’impression de travailler avec un organisme vivant qu’avec un produit industriel. Il en résulte que la complexité du logiciel fait en sorte que celui-ci est extrêmement difficile à comprendre et à modifier. À la limite, modifier une partie du système est plus proche, en complexité, de la transplantation cardiaque que du changement de carburateur.

Rien de bien élogieux ici. Je ne crois pas qu’au Québec, nous sommes les champions de ce genre d’architecture, aussi parfois appelé « big ball of mud architecture ». Je pense que nous ne sommes pas mieux, pas pire qu’ailleurs.

Bien que les origines de cette erreur remontent à plusieurs années et je crois qu’il est inutile de déterrer tout cela et de blâmer quiconque.  Vaut mieux se concentrer à corriger cette expression erronée. Mais comment faire ? Bonne question. Pour commencer, pourquoi ne pas y aller avec simplement ainsi:

  • Expliquer à notre entourage que le terme « architecture organique » est erroné et qu’il vaut mieux utiliser « Architecture logicielle ».
  • Dans nos titres, rôles, affichage de poste ou dans nos CV, remplacer « architecte organique » par « architecte logiciel » lorsque c’est le cas.

Vous avez d’autres idées ?

Références :

Top 5 – Lectures 2012

J’ai fait plusieurs lectures en 2012 et sur des sujets diverses. Je vous propose ici une compilation Top 5 des meilleurs ouvrages liés au domaine de l’informatique que j’ai lu dans le courant de l’année 2012:

1. Software Architecture for Developers par Simon Brown

Excellent résumé de ce que fait (et devrait faire) un architecte logiciel et comment partager sa structure et sa vision à l’équipe. L’auteur, Simon Brown, nous montre son côté pragmatique dans cette vue d’ensemble. J’ai apprécié particulièrement les parties sur le rôle d’architecte et la façon de concevoir et de communiquer le logiciel.

On y parle aussi de l’agilité et de son impact sur l’architecture ainsi que la notion qu’un diagramme UML n’est pas toujours nécessaire. Noter que ce livre est publié de manière indépendante sur "Leanpub" et est toujours en évolution. Un "Must" à lire pour tout développeur ou un architecte logiciel!

Lien du livre sur LeanPub

 

2. Specification By Example par Gojko Adzic

Gojko Adzic nous a écrit un 2e livre sur les spécifications.  Son premier, Bridging the communication gap, était surtout de nature théorique. Cette fois-ci, on nous présente les expériences de personnes et organismes différents avec l’utilisation de la spécification par l’exemple. En plus de cela, nous voyons comment Gojko a fait évoluer sa pensée sur la spécification et après quelques chapitres, nous allons au-delà des notions de base.

Soit dit en passant, ce livre ne parle pas de code ou d’outils. Seulement des principes et des pratiques utilisées pour communiquer les spécifications dès le début d’un projet logiciel jusqu’à sa fin.
Un des beaux résultats de cette approche est que tout le monde dans une équipe de développement logiciel travaille à avoir une "Documentation vivante" au lieu d’un tas de papiers classés quelque part dans un classeur.

Je recommande cette lecture à toute personne impliquée dans la création de logiciels. En particulier si utilisez les approches suivantes:  Behaviour Drive Development (BDD), Acceptance Test-Driven Development (ATDD), Test-Driven Development (TDD) et le Domain Driven Design (DDD).

Liens commandités du livre sur Amazon : France | Canada | USA

 

3. Techical Blogging par Antonio Cangiano

Si vous êtes sérieux à propos des blogues, ce livre est pour vous. L’auteur, Antonio Cangiano, couvre de nombreux aspects liés à l’écriture de blogue tels que la planification, la création de contenu, la promotion, le référencement, les avantages et les médias sociaux. Certains aspects sont directement liés à l’outil de blogage WordPress, mais la plus grande partie du contenu de ce livre peut être appliqué à n’importe quel type de blogue.

Liens commandités du livre sur Amazon : France | Canada | USA

 

4. Steal like an Artist par Austin Kleon

L’auteur, Austin Kleon, nous donne 10 règles pour développer notre créativité. Ces règles peuvent être utiles à toute personne, artiste ou non. En fait, pourquoi voler comme un artiste ? Parce que rien n’est original finalement… Le livre est aussi magnifiquement illustré et le papier utilisé pour imprimer le livre est de grande qualité. Le résultat: un excellent livre sur la créativité et la productivité qui se lit très bien. Inspirant !

Liens commandités du livre sur Amazon : France | Canada | USA

 

5. Impact Mapping par Gojko Adzic

Un 2e livre de Gojko Adzic dans mon Top 5 (eh oui !). Celui-ci est un peu différent toutefois. En fait, il s’agit plutôt d’un guide qu’un d’un livre en soit. L’auteur nous présente une technique pour mieux comprendre, mesurer et aligner les objectifs de l’entreprise avec la planification de la livraison d’un produit logiciel. Voici le "Impact Mapping" qui est une sorte de schéma heuristique (ou "Mind Map") pour représenter les aspects suivants: But (pourquoi), Acteur (qui), Impacts (comment) et  le Livrable (quoi). Aussi, le livre est magnifiquement illustré. Je recommande vivement d’obtenir la version papier.

Liens commandités du livre sur Amazon : France | Canada | USA

Routine de lecture

J’aime beaucoup les livres et peut-être même un peu trop. Je ne sais pas trop si vous être comme moi, mais je suis du genre à lire plusieurs choses en même temps.

Je commence des lectures au gré de mes besoins de connaissances à approfondir pour le travail, envies ou feeling du moment. Aussi, tout dépendant à quel moment de la journée je m’installe pour lire, le type de lecture peut varier. Exemple le soir, je préfère lire de la fiction ou quelque chose de léger. Une lecture théorique me fera la plupart du temps simplement m’endormir . Pour ce qui est de la fiction, un général je me limite à un livre de ce genre en même temps.

Par contre, je viens de me rendre compte que j’ai plus de huit livres en cours de lectures ! D’ailleurs, on le voit bien sur mon profil du site "GoodReads":

Ouin, je ne sais pas trop si c’est une bonne chose, mais bon, je suis comme cela. Afin de m’améliorer, je crois que je devrais limiter mes lectures simultanées afin d’en finir plus rapidement.

Et vous est-ce que vous avez des routines manières particulières de lecture ? Un seul livre à la fois ou plusieurs ?

Côté objectif, j’essaye de lire entre 15 et 20 livres par années. C’est certain qu’ils ne sont pas tous de la même longueur, mais cela me donne un ordre de grandeur.

Avez-vous des façons de vous fixer des objectifs de lectures ?

 

N’hésitez pas à commenter ce billet !

 

Référence:

Agile Tour 2012: Les sessions Partie 2

Voici mon compte rendu des sessions de l’après-midi lors de l’Agile Tour Québec 2012. La partie 1 est ici.

Le Programmeur Lean Startup par Olivier Gourment

Olivier Gourment nous a offert une bonne présentation avec quelques touches d’humour. Parfait pour ne pas s’endormir après le repas du midi. Trois thèmes principaux étaient présentés. Les voici donc avec mes commentaires:

  • Lean Startup : Une introduction au Lean Startup est faite ici en expliquant le cycle "Construire – Mesurer – Apprendre".  Le but dans un Lean Startup est d’apprendre le plus rapidement possible afin de construire le produit minimal viable. Très intéressante approche, que ce soit pour une entreprise en démarrage ou un projet interne dans une compagnie bien établie.
  • Code: Le code est souvent trop "gras" et nous ralentit. Il faut alors l’amincir avec du "Refactoring". On fait la revue de quelques autres bonnes pratiques de programmation. Classique, mais toujours bon d’en faire le rappel.
  • Programmeur: On parle ici qu’il faut un peu du rôle de programmeur dans la vie de tous les jours. Olivier recommande d’adopter les pratiques d’ingénierie agile, prévoir la formation continue. Il a mentionné aussi un fait avec lequel je ne suis pas totalement d’accord: avoir des juniors dans notre équipe pour permettre l’innovation. Je crois davantage que l’on peut innover à tout âge. Pour favoriser l’innovation, j’irais en ayant simplement une équipe diversifiée et variée avec des gens différents, peu importe l’âge.

En conclusion, plusieurs sujets très intéressants ont été survolés. Mais je trouve que les sujets manquaient un peu de profondeur par moment. Aussi, les liens entre les trois thèmes principaux sont plus ou moins directs, mais bon ce n’est pas trop grave. Bonne prestation d’Olivier Gourment somme toute.

Références :

Le rôle de l’Architecte Agile par Jean-René Rousseau et Mathieu Boisvert

Sujet fort intéressant pour moi. Je ne pouvais me résoudre à aller voir toute autre présentation.

Question intéressante posée d’amblée: peut-on faire de l’architecture en amont en Agile ? Bien sûr que oui, on peut en faire un peu. L’architecture est quand même nécessaire afin d’avoir un aperçu des risques et complexités des problèmes à résoudre. Les approches Agiles occasionnent plusieurs impacts sur le rôle de l’architecte. Deux ont été ciblés et discutés lors de cette présentation:

  • Émergence et Incrémentalité: Il s’agit ici de bien balancer Anticipation et Adaptation afin de, sans trop tout détailler, avoir une architecture souple et ouverte aux changements.  On parle aussi d’établir des patrons de démarrage de projet. Aspect intéressant qui a été mentionné aussi: prévoir une stratégie pour gérer et planifier les considérations d’architecture.
  • Collaborer avec les équipes: L’architecte a son lot de responsabilité au sein d’une équipe. Il se doit de prévoir une stratégie de communication et accompagner son équipe. Il arrive souvent qu’il doive s’occuper de plusieurs projets en même temps. Mais, si la disponibilité le permet, la meilleure place pour lui est d’être équipier. Et je suis très en accord avec ce point. Ainsi, en étant équipier, il pourra davantage transmettre son savoir, guider l’équipe et aussi programmer à l’occasion. Ou mieux, faire de la programmation en paire histoire de se mettre à jour et faire un transfert de connaissance. Car un architecte qui ne code jamais risque de devenir un architecte dans sa tour d’ivoire.

Un problème que je remarque parfois dans les organisations, c’est que l’architecte logiciel est davantage un titre qu’un rôle.  Au lieu d’être un titre attribué, l’architecte logiciel ne devrait-il pas être un rôle, comme le ScrumMaster, qui est attribué selon le projet et peut changer à l’occasion ? J’imagine bien une équipe de programmeurs qui fait la rotation de ce rôle ou encore mieux, que ce rôle soit partagé par tous les membres de l’équipe. Cela ferait de très bons échanges de connaissances tout en permettant à tous de faire du code régulièrement. Bon, c’est peut-être une idée utopique, mais bon, cela fait du bien d’en parler.

Bref, malgré le fait qu’on dirait par moment que nous avons davantage le point de vue d’un architecte fonctionnel que d’un architecte logiciel, plusieurs points intéressants ont été amenés dans cette présentation. J’espère que d’autres présentations de ce genre suivront, car je crois que le sujet mérite d’être encore débattu, discuté et approfondi.

Références :

Agile Tour Québec 2012: Les sessions Partie 1

Bien que j’étais un organisateur, j’ai pu assister à plusieurs sessions lors de l’Agile Tour qui a eu lieu le 6 novembre dernier à Québec. Voici donc mes impressions sur ce que j’ai vu dans les sessions du matin (ceux de l’après-midi seront dans le billet Agile Tour 2012: Les sessions Partie 2):

Développement orienté comportement et automatisation des essais d’acceptation (BDD)

par Christian Roy et Jean-François Nadeau

Je connais bien le sujet (Behavior Driven Development ou BDD) et aussi l’outil Specflow que j’ai recommandé et appliqué sur un de mes projets. Specflow est comme une sorte de version .Net de l’outil "Cucumber" qui est utilisé pour automatiser des tests d’acception qui fonctionne avec le langage Ruby. J’étais curieux de voir comment les présentateurs avaient utilisé le tout dans leur contexte. La présentation se divisait en trois parties:

  1. Théorie
  2. Démonstration
  3. Leçons apprises

Présentation très dynamique et amusante au début pour expliquer la théorie. Cela a fait un peu contraste avec la démo, mais bon c’était très intéressant somme toute. Dans la démo, on montrait l’utilisation de Sélénium Web Driver avec Specflow. Le tout était réalisé avec le patron du "PageObject". C’était très intéressant. Par contre, je reste avec l’impression que c’est toujours un peu lourd de tester la couche graphique, et ce peu importe l’outil. On a peu parlé du TDD et de comment il s’intègre avec le BDD. Je m’interroge toujours un peu sur cet aspect que je trouve important et négligé. Je crois que les tests unitaires ne doivent pas être ignorés même si on a des tests d’acceptation automatisés grâce au BDD. J’aimerais bien voir un bel exemple pratique de tests BDD et de tests unitaires côte à côte dans un projet. Dans les leçons apprises, on a parlé de l’outil Amnesia pour aider l’exécution de tests avec une BD. Je suis intrigué, autre chose à regarder plus tard. Et un aspect que je trouve très important, les développeurs étaient impliqués dans la création des scénarios. En bref, une bonne présentation et de bonnes discussions ont eu lieu.

Références:

Propulsez votre architecture avec les TDD et les Mocks

par Félix-Antoine Bourbonnais

Mon collègue de Agile Québec, Félix-Antoine, n’est pas seulement dynamique lors de nos rencontres, il l’est aussi comme présentateur. C’est donc avec passion qu’il nous présente les différents styles de TDD avec les termes style "Classique/Chicago" ou style "Mock/London". Je ne connaissais pas trop cette distinction, mais elle est similaire à d’autres termes comme le "State-Based testing" ou basé sur l’état et le "Interaction-Based Testing" centré sur les interactions.

Le TDD doit se voir avant tout comme un outil de découverte et d’aide à la conception de l’architecture logicielle. Les tests qui en résultent sont un peu comme un effet secondaire. Félix-Antoine nous a partagé son expérience en nous montrons ce qui est fondamental avec les tests, soit : Tester les modules en isolation. L’utilisation des mocks est une technique qui aide à cela. Encore faut-il que notre code soit bien organisé pour en profiter sans trop de "douleur". C’est là, que l’application de bonnes pratiques comme l’utilisation d’abstraction (c.-à-d. les interfaces) , du "Clean Code", les principes SOLID et le "Tell don’t ask" sont très importantes pour réaliser de bons tests unitaires. L’idée est de combiner ces différentes techniques selon ce que l’on veut découvrir (conception ou algorithme). Pour finir, Félix-Antoine nous recommande fortement le livre "Growing Software Oriented by Tests" qui semble s’appliquer, malgré que les exemples sont en Java, aux différents langages orientés-objet.

Références:

Agile Tour 2012: Des gens passionnés au rendez-vous

Nous étions plus de 400 participants, bénévoles, présentateurs et organisateurs à l’Agile Tour Québec 2012 cette année. 400 passionnés, curieux et avides d’information et d’échanges avec ses pairs.

Ce fut une belle journée et un plaisir de côtoyer tous ces gens pour cette 4e édition (!) pour la ville de Québec de cette journée de conférences consacrées au développement Agile.

(Cette photo a été prise par Isabelle Therrien, Coach Agile chez Agile Partnership)

J’ai bien aimé la conférence principale, ou "Keynote", de cette année à l’Agile Tour 2012. Le conférencier, Jonathan Rasmusson, nous a servi une plénière forte intéressante. Il nous a partagé son expérience avec les deux histoires suivantes:

"Who moved my Agile cheese ? / Qui a déplacé mon fromage Agile"

En s’inspirant un peu du livre "Who moved my cheese ?", Jonathan abordait le thème du changement. Même les gens "Agiles" peuvent être confrontés à celui-ci et parfois, l’agilité n’est pas toujours la solution. En écrivant son livre, Agile Samurai, il a tenté de le faire à la sauce Agile, en itérations, "User Stories" et autres artéfacts de l’agilité. Mais, ce qui a marché le mieux, c’est d’aller à son café de 6h00 à 8h00 et de travailler sur son livre avant de se rendre au travail. Il a du changé sa manière de faire "Agile" pour y aller d’une autre manière plus efficace pour lui. Pourquoi cela a marché ? Selon lui, c’était tellement une idée personnelle, que ce n’était pas pour lui vraiment du travail. Le travail avait arrêté d’être du travail est était devenu une forme d’art pour lui.

Le changement est un phénomène naturel et cela va nous arriver un jour ou l’autre. Même l’agilité risque changer dans les années à venir.

"Tests unitaires = Qualité. Vraiment ?"

JonRasmussonEst-ce que les tests unitaires sont les seules garanties de qualité ? En s’introduisant dans la communauté des développeurs d’applications avec iOS, Jonathan a découvert que les tests unitaires et l’intégration continue n’étaient pas pratiqués régulièrement. Seul le "refactoring" semble être présent. Pourtant, la qualité du travail était au rendez-vous, et ce, sans tests unitaires… Comment est-ce possible ? L’attention et le souci du détail de Apple dans ses produits ainsi que sa communauté de développeurs attentionnés y est pour quelque chose selon lui.

Bien qu’il croit toujours à l’importance des tests unitaires dans certains contextes, un autre aspect vient influencer davantage la qualité: La passion et l’attention des "artisans" à faire le meilleur produit qui soit.  Bref, la qualité est plus que des tests unitaires (mais ces derniers sont toujours très important). Il a mentionné aussi quelque chose d’intéressant. La communauté Agile et la communauté des développeurs de logiciels Apple (ou iOS) pourraient s’échanger un truc ou deux pour que chacun s’améliore.

En conclusion, c’était moins flamboyant que l’an passé avec Robert C. Martin, mais la conférence m’a touchée davantage. C’est bien beau parfois d’avoir des gourous qui nous montre leur savoir et la bonne manière de faire les choses, mais c’est bien aussi de faire changement dans le type de présentation. Jonathan nous a plutôt ramené à la base en nous parlant de ses récentes expériences professionnelles. Et je résume cette base à retenir de cette manière:

Avoir des gens passionnés et qui veulent prendre soin de leur travail, c’est un pas de plus pour obtenir un résultat de qualité. On peut apprendre toute sorte de notions sur l’agilité à pratiquement n’importe qui. Mais on ne peut pas leur apprendre à prendre soin de leur travail.

Références :

La pause est terminée

PlayMon dernier billet remonte à quelques mois déjà…

L’été a passé vite, puis la rentrée scolaire des enfants, des rénovations à la maison, un bébé chien à éduquer. L’habitude d’écrire s’est perdue un peu.  C’est un de mes vieux amis, Laurent, qui me le fait remarqué l’autre jour:

Heille Karl, je me suis abonné à ton blogue, mais je trouve qu’il n’y pas trop de publications ces temps-ci…

Ouch, cela m’a réveillé d’un coup. Mais, au lieu de repartir rapidement, je voulais prendre le temps d’avoir plusieurs idées de billets. C’est là que je suis rendu.

Donc, vous verrez dans les prochaines semaines de nouveaux billets. Je vais aussi faire un sondage sur les sujets de mon blogue qui vous intéressent le plus, histoire de mieux cibler mes efforts.

Mon objectif est de publier environ une dizaine de billets d’ici le reste de l’année.

Les habitudes viennent et repartent. C’est à nous d’être vigilant et voir lesquelles garder, reprendre ou abandonner.  C’est donc important de revoir régulièrement ses objectifs.

Refonte de mon blogue

OpenPour commencer, quelques statistiques sur mon blogue:

  • 72 billets rédigés, quelques pages et plusieurs commentaires
  • 2 ans sur WordPress et six années au total pour mon blogue.

Après tout cela, une petite refonte s’imposait…

Alors, je vous souhaite la bienvenue dans mon nouveau blogue !

Voici en gros les quelques changements

Et voilà !

Qu’en pensez-vous ?

Référence :

Quelques lectures gratuites

J’ai fait quelques lectures intéressantes dans le dernier mois et je voulais vous en parler. Les petits documents mentionnés dans le tableau plus bas sont à mi-chemin entre un article et un petit e-book. Donc, assez facile à lire.  Les trois couvrent des sujets totalement différents, mais qui peuvent intéresser plusieurs. De plus, ils sont tous gratuits et téléchargeables. Les voici donc:

Getting Started with Kanban par Paul Kipp

Get started with Kanban, a free eBook by Paul Klipp

Petit document qui résume bien ce qu’est l’outil ou la technique Kanban. Utile si vous ne connaissez rien au Kanban ou pour le résumer à quelqu’un d’autre.Issue de la méthodologie "Lean", le Kanban peut être appliqué dans plusieurs domaines: informatique, ingénierie, vente, tâches familiales, études, gestion, etc.

En gros, le Kanban consiste à suivre les 3 règles suivantes:

  • Visualize Workflow
  • Limit Work in Progress (WIP)
  • Measure and Improve Flow

 

The New Time Management

par Francis Wade

45

Intéressante lecture qui nous suggère de revoir les 7 principes fondamentaux de la gestion du temps. Malgré les outils et techniques, si on ne maîtrise et si on ne pratique pas la base, on risque d’être davantage stressé et plus ou moins productif.L’auteur mentionne qu’il est normal d’essayer de nouvelles techniques, de se mesurer et de s’ajuster régulièrement. Tout cela dans le but de trouver la bonne solution selon notre style de vie professionnelle et personnelle.

Donc, pas de recette unique pour tout le monde.

The Accountability Effect

par Basam Tarazi

image

Introspection pertinente sur qui nous sommes, nos buts dans la vie et l’importance de prendre soin de nous même. Sinon, la vie passe vite et on risque d’accumuler plusieurs regrets.Aucun "timming" n’est parfait pour faire les choses dont on parle souvent. L’auteur nous montre ce qu’il faut être "présent" et prendre les responsabilités de nos actions ou le manque de celles-ci.

Lecture très intéressante qui amène des réflexions que nous n’avons malheureusement pas assez souvent.

 

Bonne Lecture !