Le banquet

Pour clore la conférence, un impressionnant banquet fut organisé. Durant le souper, Jared M. Spool nous a livré un discours digne des grands orateurs de ce monde. Une présentation soignée avec trois grands objectifs à retenir : vision, feedback et culture.

Pour la vision à long terme je vous invite à voir cette petite vidéo tournée en 1987.
http://www.theheretech.com/2009/08/apples-mistaken-mystique.html

Pour ce qui est du feedback, je vous invite à lire mes derniers posts.

Finalement, pour ce qui est de la culture, il faut apprendre de ses erreurs. Si personne de l’équipe n’a fait d’erreur depuis les dernières semaines, posez-vous des questions. Vous voulez un bon exemple, savez-vous comment déterminer le sexe d’un poussin? Les poussins male et femelle sont pratiquement identiques. Cependant, il existe des professionnels dont la tâche consiste à les différencier. Lorsqu’une personne commence ce métier, il a un taux de réussite autour de 50%. C’est seulement après plusieurs mois (voire des années) de pratique qu’ils finissent par obtenir un taux de réussite au dessus de 90%. Et pourtant, ils sont incapables de vous dire comment ils font. Est-ce vrai? Allez voir sur wikipedia : chicken sexing.

L’approche Toyota

La dernière présentation auquel j’ai assisté fut: Set-based Design: Anti-Agile or Agile’s Future? Comment pouvons-nous établir une base solide tout en étant Agile? Il faut avoir une vision à long terme, une base solide. Cependant, il ne faut pas juste essayer une solution. Il faut commencer par ratisser large et réduire la zone. Plusieurs conférenciers nous ont dit qu’il faut faire des choix logiques pour l’entreprise. Il faut cibler quel produit nous donne les meilleurs retombées, séparer les gros produits en petits livrables et faire plus de tests, plus vite, plus tôt. J’ai l’impression d’avoir déjà écrit ça :-)

Principe de gestion Agile

Toyota s’est dit que s’ils produisent plus vite, ils auront du feedback plus rapidement. Ils pourront corriger leur produit plus tôt et ainsi produire encore plus vite.

CI Vendor Cape-Flight!

Durant cette semaine de conférences, les sponsors et vendeurs sont très présent. Plusieurs d’entre eux offrent des outils ALM (Application Lifecycle Management) qui nous facilite l’intégration continue. (Continous Integration). Certain semble très intéressant mais il est difficile de les comparer sans les avoir utilisés. Alors, j’ai cru bon d’assister à cette présentation (CI Vendor Cape-Flight!) dans le but d’aider notre compagnie dans le choix de l’un de ces outils. Ce que je ne savais pas, c’est que nous avons déjà fait l’acquisition de Concerto. Pour les curieux, voici quand même quelque uns des autres produits :
AntillPro
Meister
Mojo
Parabuild
Hudson
Bamboo
Visual Studio Team System

Des requirements qui changent !

Dans le domaine aéronautique, nos clients semble très Waterfall ce qui nous restreint à l’interne, principalement avec les requirements. Cependant, dans le cas de mon département (et division), nos clients sont principalement deux autres divisions de notre compagnie. Nous aurions intérêt à plus souvent tenir compte de la rétroaction de nos clients et ainsi adapter certains requirements en fonction du feedback reçu. Les requirements devraient aussi être mieux associés aux différents issues (dans JIRA) et livrables (Package Repository).

Continuous Integration: Your New Best Friend

Le principe est simple, un changement au début du projet coûte moins cher qu’à la fin du projet. Donc, comment trouver un problème plus tôt : Continuous Integration. Il y a 3 sortes de tests : via les requirements, via les unit tests et via l’interface usager. Il faut faire les 3 types de test en continu durant le développement. Nous allons ainsi réduire les coûts en réduisant les problèmes d’intégration de dernière minute.

Lien sur la présentation.

Agile Metrics

Avoir une bonne méthode de mesure est important pour la gestion afin de comprendre où nous sommes, connaitre le progrès de l’équipe et voir les projections futures.

Dans ma compagnie, nous voulons migrer vers une méthode plus Agile. Est-ce vrai?

La direction a implanté la méthode Scrum, probablement la méthode la plus populaire dans Agile. Nous l’utilisons de plus en plus et de mieux en mieux (sprints, backlog, metrics, meetings). Cependant, l’esprit Agile n’est pas là. J’ai l’impression que nous n’utilisons Scrum que pour les métriques, pour que la direction puisse mieux mesurer et avoir un business value associé aux produits software. Voici quelques exemples de pratiques que nous avons et qui ne sont pas Agile : nos requirements ne s’adaptent pas, les unit tests sont presque absents, la plupart des programmeurs travaille individuellement, le feedback du client n’est pas présent durant les sprints.

Il faudrait se poser la question : Voulons-nous rester Scrum sans être Agile?

La présentation, Agile Metrics, est disponible en pdf.

Blitz Planning

Imaginez un petit exemple très simple d’organisation matinale. Nous avons deux parents et deux enfants (un de 12ans et un bébé) et nous voulons organiser l’horaire : brossage de dents, faire les lits, réveil des enfants, déjeuner, lunch… L’exercice devient rapidement compliqué. Il faut prévoir qui peut faire quoi, quelle tâche dépend d’une autre, prévoir le temps… Le but est de prévoir et placer les tâches dans le bon ordre sans en bloquer une autre. De plus, il sera possible de prévoir un premier livrable le plus tôt possible et ainsi avoir un retour sur l’investissement le plus tôt possible. Cette présentation nous démontre, par des exercices simples, les avantages de bien planifier afin d’obtenir le plus tôt possible les bénéfices qui en découle.