Monday, September 21, 2009

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

Friday, September 18, 2009

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.

We Didn't Quite Get It

Cette présentation couvre les problèmes et solutions rencontrée par deux développeurs (Brian Victor et Noah Jacobson) qui implantent Agile dans leur petite compagnie sans avoir d’expérience avec Agile.

Pour ceux que ça intéresse, je vous suggère ce lien : http://brianhv.org/temp/agilenotes/
Il y a quelques parallèles intéressants à faire, cependant il faut garder à l’esprit qu’il y a aussi des différences entre les 2 compagnies; entre autre la grosseur et le produit final (hardware & software).

Activity Theory for Manifesting Agile

Agile est probablement la méthode de travail la plus actuelle pour ce qui est de la programmation. Agile est vivant et comme toute chose vivante, ça continue à s’adapter, à évoluer. Robert Biddle, un professeur (Human-Computer Interaction) à l’université de Carleton à Ottawa, a développé un framework qui s’applique à Agile. Son framework qu’il qualifie de « psychological framework » sert à comprendre la collaboration et les tensions entre les personnes, les projets, les outils, le code… Son framework tient aussi compte qu’une personne n’est pas uniquement impliquée dans une seule activité (travail, famille, projets…), tout en incluant les groupes et les règles. Il est possible d’étendre son framework pour tenir compte des autres systèmes autour : client, département, fournisseurs… Son framework peu ainsi servir à comprendre et améliorer le développement software qui est agile.

Programming with the stars

Pendant l’heure du lunch, 6 équipes de 2 personnes (une vedette de la programmation avec un partenaire) s’affrontent dans un jeu d’élimination pour trouver les meilleurs programmeurs. Cette petite activité de programmation fonctionne un peu comme les jeux télévisés. Il y a un jury de 3 personnes (Liz Keough, Brian Marick & Jim Newkirk) qui compte pour 50% et le public vote pour compléter l’autre 50%. L’idée est bonne et ça fonctionne très bien. J’ai beaucoup apprécié l’ambiance, par exemple, l’un des juges travaillait chez Microsoft et quelques participants s’amusaient à narguer les outils de Microsoft au risque de perdre des points auprès de ce juge cependant, ils ont gagné la faveur du public et même celle d’un autre juge.

Lors de cette activité, je me suis posé la question suivante : un programmeur moyen-fort de ma compagnie serait-il à la hauteur? J’en doute. Une bonne partie des points était attribuée pour la façon de faire le CI (Continuous integration). Chaque nouvelle ligne de code était testée avant de continuer à coder.

Lien: Programming with the stars

Wednesday, September 2, 2009

How to run 4.5 Million tests per day, and why

If you had to guess what software company has the expertise (and plain guts) to scale up the CI (continuous integration) concept to running almost 5 Millions tests per day, what would you say? Google, of course. This short talk by Mark Striebeck (a Google employee) was very interesting and somewhat illustrative of what Google is capable of when it sets its collective mind to something.

People at Google were finding it harder to apply CI because of the large size of their test base. Tests were taking a long time to run so they were run less often. To solve this problem, they decided to leverage the Google infrastructure and implemented their test harness as a scalable web service. The test execution is distributed on more than 1500 CI servers!

The interface to the test system is a nice dynamic web page where you can filter and display the results in many different ways, giving you the exact view you want on your test results. And as you would expect, the search works pretty well, too.