Description

Aujourd’hui, les grands du web nous rappellent qu’être un développeur est une carrière aussi prestigieuse que celle de manager ou de consultant. Pourquoi ? Ces entreprises ont dès le début orienté leur métier sur la satisfaction des utilisateurs afin de maintenir un cercle vertueux dans le développement de leurs produits.

Les grands du web mettent tout en œuvre pour garder une forte satisfaction de leurs utilisateurs. Cette situation les conduit généralement à créer un cadre pour que leurs équipes techniques restent focalisées sur les besoins de leurs utilisateurs finaux. On y retrouve généralement des développeurs heureux de leurs travaux, qui voient leur motivation augmenter de paire avec leur efficacité à livrer un produit et leur capacité d’apprendre en continue de nouvelles techniques et compétences. On y voit souvent une culture forte s’installer, permettant à l’équipe de perdurer, et cela même après le départ de personnes clés.

(Lire la suite…)

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

(Lire la suite…)

Dans son livre « Clean Code », Robert C. Martin nous présente un principe essentiel pour écrire du beau code, la fameuse règle des boy-scouts (« The Boy Scout Rule ») qui se résume en une phrase : « Toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé ».  

Si nous livrons tous du code dans un état plus propre que  celui où nous l’avons trouvé, alors le code ne risque pas de se détériorer. Le nettoyage de code n’a pas besoin d’être immense, il suffit souvent de changer un nom de variable, de découper une méthode trop longue, d’éliminer de la duplication de code, de nettoyer une instruction qui comprend trop de if, pour que le code soit meilleur.
(Lire la suite…)

La scène se passe dans le métro parisien.

- Tu prends la ligne 9 toi aussi ? Alors comment ça se passe sur ton projet en ce moment ?

- Ca avance … Tiens, faut que je te raconte, nous avons commencé de travailler avec des méthodes agiles !

- J’ai fait la même chose il y a un an et demi … Vous devez être en plein changement alors ! Où en êtes vous, toi et ton équipe, dans ces changements ?

- Nous sommes accompagnés par un consultant, il a commencé à nous parler de feedback, je n’ai pas bien compris où il voulait en venir …

- Que sais-tu du feedback ?

(Lire la suite…)

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

Le « Test Driven Development » est une pratique de développement issue d’eXtreme Programming, dont le but consiste à améliorer la productivité et la qualité des développements en écrivant les tests avant l’implémentation d’une fonctionnalité. Ceci permet de construire conjointement et justement le logiciel ainsi que sa suite de tests de non-régression. Le principe du TDD est le suivant: écrire un test qui échoue, écrire du code pour que le test fonctionne, remanier le code écrit, puis recommencer.

Nous vous proposons une formation de deux jours pour pratiquer le TDD, par le biais de différents ateliers de programmation.

La prochaine session aura lieu le 24 et 25 Octobre. Inscrivez-vous sur notre site dédié à la formation :http://formation.octo.com/methodologie/tdd/inscription-tdd

OCTO étant un organisme de formation, ce stage peut être pris en charge par le DIF.

Programme

1ère journée

• Présentation de TDD, premier atelier de programmation collectif
• Présentation Acceptance Test Driven Developpement (ATDD), puis deuxième atelier de programmation collectif
• Bilan de cette première journée

2ème journée

• Premier atelier pour apprendre comment continuer à pratiquer TDD, même avec des frameworks complexe (type Spring et Hibernate)
• Présentation des problématiques de code « legacy », et atelier de programmation collectif pour apprendre à tester ce genre d’application. Le code étudié pourrait être le vôtre ! Contactez nous deux semaines à l’avance pour en savoir plus.
• Bilan de cette deuxième journée

Situation n°1 : Vous regardez votre agenda, combien de réunions ont déjà été posées pour résoudre les problèmes en cours. Vous vous dites que « Ca fait beaucoup pour la journée »  en terminant votre tasse de café. Et d’ailleurs combien de fois avez-vous posé une réunion pour comprendre ce problème sur la vélocité de cette équipe ? Une vélocité qui ne décolle toujours pas, mais ces réunions vous auront permis, au choix, de rajouter des développeurs, de changer des développeurs, de changer d’architecture. Beaucoup de décisions pour, au final se rendre compte que la vélocité n’augmente toujours pas … Bref, le problème est toujours là.

Situation n°2 : C’est la fin de l’année, combien de produits avez vous lancé ? Combien de ses produits ont apportés de la satisfaction pour un client ? Et combien de réunions avez vous fait pour définir ces produits ? Combien de brainstorms et d’ateliers ? Beaucoup et à chaque fois énormément d’idées et de concepts sur comment tout ça va s’articuler, pour au final se rendre compte que peu de personnes utilisent vos produits …

Si vous avez rencontré l’une des situations présentées, et qu’après toutes ces réunions vous vous demandez encore ce qui se passe réellement, alors il est temps de sortir votre chapeau de détective privé pour aller enquêter sur le terrain !

(Lire la suite…)

A l’occasion de l’édition 2011 de la conférence Agile France qui aura lieu les 26 et 27 mai à Paris, OCTO présentera les sessions suivantes :

• « La Pilule Rouge, des pistes pour la collaboration distante » par Guillaume Duquesnay
• « L’Agiliste et l’Iphoniste, une histoire de couple » par Jean-François Grang
• « Transition Agile – Culture du changement ou changement de culture ? » par Thomas Lissajoux
• « Comment réussir un projet Agile très court » par Jonathan Scher
• « Agilité et modèle de changement » par Mathieu Gandin

(Lire la suite…)

UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

(Lire la suite…)

11h41, nous sommes en plein pendant l’atelier de construction de la vision partagée du projet MyNewSI 2.0. Si on tend l’oreille nous pouvons entendre les discussions suivantes :

« Oui le projet est stratégique, mais il y a en a trois autres de prévu en parallèle cette année »

« Oui cette idée est géniale, mais nos clients ne vont pas y adhérer »

« Oui le 12 Octobre est une bonne date pour la release, mais on n’aura jamais l’environnement de recette à temps ! »

(Lire la suite…)

En tant que consultant, il m’est arrivé d’intervenir au sein de plusieurs équipes de développement pour les aider à devenir Agiles. Alors que ce type de méthode trouve une certaine popularité au sein du monde informatique, j’ai eu l’occasion d’observer quelques comportements assez différents dans la manière dont l’agilité s’installe dans ces équipes.

On peut dire que c’est le contexte, mais on peut aussi allez plus loin. Jean-François Helie vous avait présenté les différentes phases de développement d’une équipe en mars derniers, je vous propose à mon tour de creuser un autre modèle avec celui de Bruce Tuckman.
(Lire la suite…)