Agile Tour 2011: Un beau défi réalisé !

IMG_0282

Pour une troisième année consécutive, l’Agile Tour était de retour à Québec mercredi dernier, le 26 octobre. Je m’étonne toujours de la qualité du travail que l’on peut faire pour organiser cette conférence en dépit des circonstances. Par exemple, le fait que personne ne travaille à temps plein là-dessus. Tous les organisateurs ont déjà un premier travail.

Aussi, cette année c’est un peu spécial, car un de mes auteurs préférés de livre, Robert “Uncle Bob” C. Martin, était notre conférencier principal.

J’ai adoré sa présentation, “Clean Architecture”, qui était instructive et divertissante, comme d’habitude dans son cas.

En passant, voici les nouveautés que nous avons amenées cette année:

  • La conférence a lieu dans un hôtel au lieu de l’université Laval
  • Nous avons quatre de salles de conférences + une grande salle pour la conférence principale et les repas.
  • Les conférences sont divisées par thème et par salle afin d’en avoir pour tous les goûts chez nos participants.
  • Un comité de programme a été établi afin d’évaluer et de choisir les soumissions de conférences.
  • 18 sessions différentes, en plus de la conférence principale, étaient offertes aux participants.

Aussi, en tant qu’OSBL (organisme sans buts lucratifs), nous nous efforçons de rendre accessible cet événement au plus grand nombre possible de personnes. Nous avons eu aussi un nombre record de participants (400) et nous avons dû en refuser plusieurs pour cause de logistiques et d’espace dans les salles. L’engouement pour le développement Agile est vraiment en hausse à Québec cette année !

Certaines petites choses sont encore à améliorer, mais ce fut selon moi un très bon événement de grande qualité et pour un prix modique (50$). Ce qui concorde parfaitement avec la mission de la communauté Agile de Québec.

Un gros merci particulier à mes collègues pour qui la plupart c’était la première fois qu’ils organisaient un « Agile Tour » :

  • David Beaumier
  • Félix-Antoine Bourbonnais
  • Patrice Caron
  • Louis-Joseph Foujieu
  • Dave Jacques
  • Amélie Turgeon

Au plaisir de vous retrouver à l’Agile Tour 2012 !

Publicités

Introduction à un Code Retreat par Corey Haines

Voici l’introduction d’un Code Retreat de Corey Haines que j’ai filmé lors de son passage au Code Retreat Québec 2011 en mai dernier.

J’ai téléchargé le tout sur YouTube en 3 parties pour ne pas perdre la qualité HD.:

Partie 1
Partie 2
Partie 3

Références :

Est-ce que votre code est S.O.L.I.D. ?

CrackDans ce billet, je vais vous décrire brièvement les principes SOLID pour la programmation orientée-objet avec quelques commentaires et vous suggérer quelques ressources pour approfondir ce sujet qui devrait être connu de tous les programmeurs sérieux et professionnels.

Je suis toujours surpris lorsque, la plupart du temps, à chaque fois que je parle de ces principes à de nouveaux collègues, mon interlocuteur hausse les épaules et ne sait pas de quoi je parle.

 

S.O.L.I.D. est acronyme regroupant les principes suivants:

  • Single Responsability Principle (SRP): Une classe devrait avoir une et une seul raison (responsabilité) d’être modifiée.
  • Open Closed Principle (OCP) : Chaque classe devrait être ouverte pour des extensions et fermé autant que possible pour des modifications.
  • Liskov Substitution Principle (LSK) : Les classes dérivées peuvent être substitué de leur classe de base
  • Interface Segregation Principle (ISP) : Nos classes ne doivent pas hériter, via une interface, de méthodes qu’elles n’utilisent pas.
  • Dependency Injection Principle (DIP) : On doit dépendre de classes abstraites et non de classes concrètes

De tous ces principes, le plus important à suivre selon moi est le Single Responsability Principle (SRP). Ne pas respecter ce principe peut apporter plusieurs maux, notamment lorsque l’on fait évoluer le code.  Dans mon équipe actuelle, nous avons fait du SRP le principe de base et le plus important à suivre. De cette manière nous l’avons toujours en tête et il nous sert en quelque sorte de règle de base lorsque l’on se questionne sur la grosseur de classes et de méthodes ou autre.

C’est important aussi de connaitre les autres, mais on y fait référence un peu moins souvent à mon avis.

Pour en savoir plus, sur SOLID, vous pouvez commencer par les deux références suivantes sur Internet :

Pour approfondir SOLID, je recommande fortement le livre suivant (Liens Amazon.ca commandités) de Bob Martin qui se décrit en deux versions, tout dépendant si vous êtes de type Java/C++ ou .Net:

Agile Software Development, Principles, Patterns, and Practices

Type .Net (C#/VB)

Type Java/C++

Dans ce livre, l’oncle Bob nous explique les pratiques agiles, on y voit un peu de modélisation et aussi de nombreux chapitres sont dédiés aux principes orientés-objet. Ce livre d’environ 700 pages fait un très beau livre de référence à mettre sur son bureau pour le lire au complet ou le consulter à l’occasion.

En passant, nous aurons la chance de recevoir Bob Martin en tant que conférencier principal lors de l’Agile Tour Québec 2011. Les inscriptions devraient commencer en septembre. Pour info sur l’Agile Tour : http://at2011.agiletour.org/fr/at2011_Quebec.html

Autres articles intéressants avec exemples d’application de SOLID:

Référence pour l’image utilisée:

http://www.sxc.hu/photo/954598

C’est quoi un Lean Startup ?

En gros, c’est un mélange de développement Lean et Agile avec une bonne dose d’entrepreneurship. Le but est d’éviter le plus possible de faire du gaspillage  et de livrer un produit innovateur avec succès. On y dénote les principes suivants:

  • Les entrepreneurs sont partout (Entrepreneurs are Everywhere)
  • L’entrepreneurship c’est aussi de la gestion (Entrepeneurship is Management)
  • L’Apprentissage est validé (Validated Learning)
  • L’innovation doit être comptabilisée (Innovation Accounting)
  • Construire-Mesurer-Apprendre (Build-Mesure-Learn)

Eric Ries est à l’origine de ce terme et il en parle depuis quelque temps. Je trouve sa démarche forte intéressante et cela m’a incité à me tenir informer sur ce sujet. En passant, le concept de Lean Startup peut aussi bien être appliqué à l’intérieur d’une compagnie existante que pour une entreprise en démarrage. Pour en savoir davantage sur Eric Ries, je vous recommande le vidéo suivant d’une de ses conférences qu’il a données récemment :

 

D’ailleurs, son livre sur le Lean Startup sera publié en septembre. J’aime beaucoup le graphique suivant qui montre le cycle de développement dans un Lean Startup:

25255_387440405880_387431575880_4176788_6681867_n (1)

On peut aussi se poser la question suivante, en quoi le Lean Startup est différent du développement Agile ? Le tableau suivant  de Joshua Kerievsky résume fort bien les différences et les similitudes entre le développement Agile et le Lean Startup:

Agile Lean Startup
Product Roadmap Business Model Canvas
Product Vision Product Market Fit
Release Plan Minimal Viable Product
Sprint Kanban
Sprint Review Pivot or Persevere Decision
On-Site Customer « Get Out Of The Building »
User Story Hypothesis
Backlog « To Learn » List
Definition of Done Validated Learning
Red-Green-Refactor Learn-Measure-Build
Customer Feedback Customer Validation
Acceptance Test Split Test
Velocity AARRR
Mock Object Feature Fake
Continuous Integration Continuous Deployment
Certified Scrum Master Customer Success Manager

 

Est-ce que vous pensez que ce genre de modèle peut réussir ici au Québec ?

Est-ce qu’il y a vraiment des entrepreneurs un peu partout ici ou c’est seulement réservé à nos voisins du sud ?

Est-ce que vous connaissez des exemples de compagnies d’ici qui ont appliqué ce modèle ?

 

Références:

La place des Business Objects dans le MVP

Où doit-on placer nos composants d’affaires (i.e Business Objects) lorsque l’on utilise les designs patterns du genre Model-View-Presenter (MVP) ou Model-View-Controller (MVC) ?

C’est une bonne question et  je la retrouve régulièrement dans les projets auxquels j’ai travaillé.

Mais avant de poursuivre, voici une conversation forte intéressante que j’ai observée sur twitter il y a quelque temps entre Robert « Uncle Bob » Martin et Martin Fowler à ce sujet:

Image@unclebobmartin Views should have no knowledge of business objects. Presenters should create data structures from business objects & views should use them.
Image@martinfowler @unclebobmartin disgree. It’s both traditional and effective for views to see domain objects
Image(1)@RonJeffries @unclebobmartin i’d wanna see one or more examples showing why views shouldn’t see domain objects but instead … what, « views « of them?
Image@unclebobmartin @martinfowler The problem is that views become coupled to business logic. Changes to BOs imply changes to views.
Image@martinfowler @unclebobmartin I think the relationships between view, model and other elements is too context-specific for a general rule
Image(2)@GBGames @unclebobmartin @martinfowler To be clear, I know MVC, but it seems there’s debate about what the V knows about the M?
Image[4]@martinfowler @GBGames @unclebobmartin There are many forms of MVC with different trade-offs. I said more at http://martinfowler.com/eaaDev/uiArchs.html
Image@unclebobmartin @peter_bugge BOs change for reasons of business logic. Views need not be affected.
Image@unclebobmartin @sebasmonia A change to the BO will often cause change to presentation logic, but hopefully not to the views.
Image@unclebobmartin An object has private state and public methods. A data structure has public data and no methods. Getters and setters make data public.
Image@unclebobmartin @MahasenBandara Views are concrete. Models are abstract. Views should depend on Models.
Image@unclebobmartin Business interactions are also business objects. Controllers should invoke interactions not _be_ interactions.

En résumé, Uncle Bob mentionne que pour éviter le couplage, le presenter devrait se refaire de nouveaux objets et les passer à la vue. Martin Fowler nuance un peu le tout en mentionnant que ce n’est pas vrai tout le temps et que cela dépend du contexte.

Le fait de se refaire de nouveaux objets pour la vue peut amener certains problèmes. Exemple, j’ai vu très souvent ce genre de code qui, pour moi, est un beau cas de duplication:

 public ViewObject ConvertObject(BusinessObject objectFromModel)
        {
            var viewObject = new ViewObject() ;
            viewObject.Name = objectFromModel.Name;
            viewObject.Adress = objectFromModel.Adress;
            viewObject.PhoneNumber = objectFromModel.PhoneNumber;
            viewObject.City = objectFromModel.City;

            return viewObject;
        }
    }

Hmm, redondant n’est-ca pas ?

Si les objets sont pratiquement semblables, je suis d’accord avec le point de Martin Fowler et que ce genre d’objets peut être visible au niveau de la vue.

Par contre, s’il y a quelques différences ou des champs non utiles qui sont tout de même transférés à la vue, je crois qu’il vaut mieux y aller avec de nouveaux objets comme le mentionne Uncle Bob.

Bref, la règle à suivre selon moi est de toujours voir selon les besoins du contexte.

Et vous, qu’est-ce que vous faites dans ce cas avec les Business Objects ?

Mon expérience au Code Retreat

IMG_0040

Le 21 mai dernier, moi et deux autres collègues (Félix-Antoine Bourbonnais et Amélie Turgeon) avons organisé le premier Code Retreat à Québec. Tout cela a commencé en début février lorsque le nouveau conseil d’administration de la communauté Agile de Québec s’est réuni.

Lors d’un tour de table, il a été suggéré de tenter d’organiser cet événement. Je trouvais qu’il n’y avait pas assez d’événements de ce genre pour les programmeurs. En particulier des événements qui ne parlent pas de produit d’un vendeur ni d’une technologie particulière. Juste du code orienté-objet sans égards à un langage particulier.

Comme nous n’avions jamais fait ce genre d’événement, il nous fallait un facilitateur de calibre et qui en avait fait beaucoup auparavant: Corey Haines. Ce dernier habite Chicago  et le faire venir ici comporte certains frais, mais rien de trop astronomique. Donc, on s’est rendu compte que c’était possible de le faire venir. Dans notre planification, l’aide des commanditaires serait aussi importante et permettrait de définir le prix d’entrée, le lieu et la nourriture et les rafraichissements servis aux participants durant la journée.

Donc, au fil des mois tout s’est tranquillement mis en place pour réaliser l’événement qui fut un bon succès selon moi. Une grande majorité des participants ont apprécié. On a aussi pu noter certains aspects qui seront à améliorer la prochaine fois que l’on réalisera cet événement. Car nous avons bien l’attention d’en refaire un. Mais avec l’Agile Tour 2011 qui s’en vient cet automne, c’est bien possible que cela ait lieu qu’en 2012.

Aussi, organiser tout cela nous a permis de tester ou d’approfondir certaines technologies qui pourraient nous être utiles dans le futur :

  • WordPress: Nous avons fait un blogue pour contenir toute l’info de l’événement.
  • Eventbrite: Pour la gestion des inscriptions
  • Google Documents: Pour l’échange de documents entre les organisateurs
  • Survey Monkey: Définition et compilation des sondages d’appréciation de l’événement.

Au niveau du contenu de l’événement, j’ai aussi bien adoré. J’ai été surpris du nombre de personnes qui n’avaient jamais vraiment pratiqué le TDD avant. Mais c’est le but de ce genre d’événement, donner du temps pour pratiquer des techniques et langages qu’on n’a pas l’occasion de pratiquer au travail.  L’apport de Corey Haines a aussi été excellent. Cela nous guidera lors des prochains Code Retreat.  Car ce sera nous de jouer le rôle de facilitateurs la prochaine fois. J’ai bien aimé aussi mes différentes sessions de pairage. J’ai pu me remettre au C# (car je fais du VB.Net habituellement), voir un peu de Ruby à l’œuvre et appris quelques trucs ici et là. J’ai aussi montré l’outil Resharper à quelques-uns et du C# à un gars de Java. Bref, it was a blast !

En résumé, je suis bien content de voir qu’à partir d’une idée, et entouré de bonnes personnes, on peut voir un projet se réaliser. Il ne faut pas toujours avoir peur de commencer des choses, mais il faut plutôt oser le faire. On y découvre alors plein de choses…

Références :

Outils de productivité partie 3: Agile Results

imagePour faire suite à la série de billets sur les outils de productivité, nous allons parler aujourd’hui d’une technique intéressante qui nous permet d’être « Agile » avec nous-mêmes, et ce sur différents niveaux.

Cela fait quelques années que je lis régulièrement les articles de J.D. Meier. Ce dernier travaille chez Microsoft, mais on ne parlera pas ici de son côté technique, mais plutôt de ses trucs pour obtenir des résultats.

De son blogue, Source of Insight, il a publié plusieurs articles très intéressants sur la productivité, comment atteindre nos buts et améliorer la balance entre travail et vie à la maison. Il a récemment formalisé toute sa méthode dans un livre intitulé « Agile Results ». Ce dernier est gratuit en ligne et on peut se procurer aussi une version papier.

 

Les grandes lignes de sa méthode sont les suivantes:

  • La règle de trois: Toujours y aller avec trois objectifs à la fois dans vos planifications.
  • Adopter le concept de « Monday Vision, Daily Outcomes, Friday Reflection« , qui est en gros:
    • Vision du lundi: On identifie nos 3 résultats souhaités pour la semaine
    • Résultats Journalier: On révise nos 3 objectifs de la semaine et on regarde comment les faire avancer aujourd’hui en priorisant nos tâches.
    • La Rétrospective du vendredi: On regarde notre semaine en se posant les deux questions suivantes:
      • Quelles sont les trois choses qui vont bien ?
      • Quelles sont les trois choses à améliorer ?
  • Trouver ses « hotspots » afin de savoir comment on distribue notre temps et se fixer des limites. Le tout afin de bien balancer notre vie. C’est un peu philosophique, mais assez important pour se questionner sur quoi investir en priorité et les conséquences à ne pas investir à d’autres endroits.

Le livre mentionne aussi un paquet de stratégies et de points clefs obtenir des résultats. Très intéressants à lire. La version du web du livre est très pratique et on s’y retrouve bien. Il y a un résumé de la méthodologie et  des « Cheat Sheets », posters et autre.

iStock_000001342452LargeDe mon côté, je pratique régulièrement la règle de trois et le « Monday Vision, Daily Outcomes, Friday Reflection ». C’est vraiment la base de mon rythme pour réaliser un paquet de trucs, comme écrire ce billet. Pour ce qui est des hotspots, je m’y suis attardé une fois je crois pour bien les connaître et c’est tout. Bref, cette méthode marche bien pour moi. D’ailleurs la section « Mes points clefs » que l’on retrouve régulièrement à la fin de mes billets, est tirée de cette technique.

Si les « Agile Results » vous branchent, n’hésitez pas à lire aussi le blogue « Source of Insight » qui publie régulièrement de bons articles et résumés. J’en ai d’ailleurs aussi inscrit, dans les références au bas de ce billet, des liens sur des articles intéressants de J.D. Meier et de E-Books gratuits qu’il a déjà écrits.

 

Mes points clefs :

  • Planifier nos tâches et ce que l’on veut accomplir, et ce de manière journalière, hebdomadaire, mensuelle et annuelle
  • Apprendre à mieux se connaître et important pour se fixer des objectifs
  • Nos résultats guident nos actions

 

 

Références :