Il existe plusieurs techniques pour améliorer la qualité de code de vos équipes, mais aussi leurs performances. Après les tests unitaires, les méthodes agiles, le TDD et l’intégration continue, que reste-t-il ? Ajouté un programmeur ? Rendu à un certain nombre de personnes, la performance décente. Reste a améliorer la qualité de votre force de travail. Intervient l’amélioration continue de vos équipes directement en entreprise et hors entreprise. Dans cette présentation, je vais parler des formations internes et externes, des groupes d’usagers, les conférences, les « Lunch and Learn », les dojos de code, les revus de codes et encore plus.

1. Kaizen ou l’Amélioration Continue

2. Philippe Gamache
Développeur Web (+20 ans) PHP (+15
ans) et Symfony (~10 ans)
Co-Auteur : Sécurité PHP 5 et MySQL
Formateur PHP, Symfony et sécurité
Audit en performance, sécurité et
qualité du code

3. C’est quoi?
Nom d'une méthode de gestion de la qualité.
Processus d'amélioration continue basé sur des
actions concrètes, simples et peu onéreuses.
État d'esprit qui nécessite l'implication de tous les
acteurs.

4. Objectifs du Kaizen
Simplification des flux
Amélioration de la qualité
Amélioration des délais
Amélioration de la productivité
Amélioration des conditions de travail

5. Méthodologies
principales
5S; ORDRE (Ordonner, Ranger,
Dépoussiérer (Découvrir des
anomalies), Rendre évident, Être
rigoureux)
Six Sigma
Juste-à-temps
Kanban
Lean management
Maintenance productive totale
(TPM)
Roue de Deming (PDCA)
Poka-yoke
Qui ? Quoi ? Où ? Quand ?
Comment ? Combien ? Pourquoi ?
(8w)
Qualité totale (TQM)
SMED

6. Amélioration de la qualité,
délais et productivité
Cycle de
développement
Tests unitaires
Développement piloté
par les tests (TDD)
Conception pilotée par
le comportement (BDD)
Conception pilotée par
le domaine (DDD)
Réunissage de code
Intégration continue
Méthodes agiles

7. L'acquisition de
compétences est un
processus continu...

8. Amélioration continue de
vos équipes
ou Formation Continue

9. Félicitations

10. Hypothèse
Un bon développeur apprend toujours et se ré-
évalue en vue de s’améliorer.

11. Réalité
Ce n’est pas toujours le cas. Nous devons forcer
la main de certaines personnes.

12. Les groupes
d’utilisateurs

13. Pourquoi?
Souvent la première ressource;
Important d’encouragé vos équipes à les visiter;
Différents niveaux techniques;
Nouvelles sur les technologies.

14. Plus d’informations…
Certains sont mensuels, hebdomadaires, …
Certains sont le soir, d’autres le matin ou le midi;
Sur semaine ou la fin de semaine;
En groupe ou en ligne;
Certains sont filmés et disponibles en direct ou à la
demande.

15. Différents sujets
Langages : js-montreal, Nomade PHP, PHP Québec, W3Québec;
Cadres d’application et librairies : Association Drupal Montréal, Joomla!
User Group Montréal, JQuery Meetups, Symfony Montreal;
Logiciels : Atlassian User Group, Wordpress, PHPBB, Montreal - InDesign
User Group, Montreal Linux Users Group, Montreal - Photoshop User Group;
Technologies: 2600 Montréal, Linux Québec, Montréal Android, Montreal
Business Intelligence User Group, Montreal NewTech, OpenStack Montreal,
OWASP (sécurité applicative);
Groupe spéciaux: Association québécoise des informaticien(ne)s
indépendants (AQIII), devLAB Montréal, Fédération Québécoise des
Communautés et des Industries du Libre (FQCIL), IGDA Montreal, IGDA
Montreal, Laboratoires Foulab, Montreal Girl Geek Dinners, Montreal IT
Professionals Community.

16. Conférences

17. Sous d’autres noms…
Camps
Congrès
Conventions
Déjeuner-causerie
Dîner-conférence
HackDays
Réunion
Séminaires
Professionnels
Groupe d’usagers

18. Pourquoi et comment?
Important! dans la formation de vos équipes;
Par après, partager les présentations à l’interne;
Le retour est plus grand que le risque de perdre
un employé.

19. Conférences locales
25th World Wide Web
Conference
Agile Tour
C2 Montréal
Colloque-rsi
Confoo
DrupalCamp Montréal
GoSecure
Hackfest
SQIL
Web à Québec

20. Conférences PHP
China PHP
Conference
Dutch PHP
Conference
Forum PHP
International PHP
Conference
Lone Star PHP
Midwest PHP
Northeast PHP
Conference
Pacific Northwest PHP
PHP Barcelona
Conference
PHPBenelux
PHPConf.Asia
PhpConference Brasil
PHPConf Taiwan
PHP Craft
Johannesburg
phpDay
PHP Tour Luxembourg
php[world]
True North PHP
SunshinePHP
ZendCon

21. Conférences Framework
CakeFest
CakePHP
Conference
Drupal Camp
DrupalCon
Drupal Day
Laracon
PHP Frameworks
Day
Symfony CMF
SymfonyCon
SymfonyDay
SymfonyLive
ZendCon
Zend Framework
Day

22. Conférences Frontend
Async
ConnectJS
dotCSS
jDays
JSConf
SmashingConf
O'Reilly Design
Conference 2016
UX Camps
UX Summit
World IA Day

23. Conférences autres
CoderDojo
DevConf
GOTO
SOLIDay
OSCON
O'Reilly Design
Conference 2016
OWASP AppSec
OWASP Day
Privacy &
Security Forum
XP Days

24. Formations spécialisées

25. Quand et pourquoi?
Lors d’un grand changement;
Changement de cadre d’application;
Passage à Agile;
Grande sortie d’un langage (ie. PHP 7);
Amélioration de votre équipe;
Quand les formations courtes ne sont pas suffisantes.

26. Qui?
Formation hors lieux pour une petite équipe;
Formation sur les lieux par un spécialiste (3
personnes ou plus);
Formation sur les lieux par un des développeurs
séniors (attention à la préparation ~1-2 semaines
par jour).

27. Lunch and Learn

28. C’est quoi?
Présentation durant l’heure du repas;
Durant les heures d’ouvrage et payé;
Avec un présentateur, professeur, expert,
quelqu’un qui a un intérêt;
Avec des vidéos ou des présentations
enregistrées ou en direct en ligne.

29. Hebdomadaires
Pour une petite équipe (< 10 personnes);
Diviser les grosseurs équipes en plus petits groupes;
Toujours la même journée de la semaine;
60 à 90 minutes, mais réserver la salle pour 30 minutes de
plus;
Les gens apportent leur repas, mais il est recommandé
d’en offrir environ une fois par mois.

30. Qui, quand et comment?
Encourager tous les membres de l’équipe a faire
au moins un ou deux présentations par année;
Faire un horaire des présentations en avance;
Avoir une ou deux présentations prêtes;

31. On y présente quoi?
Tout ce qui affecte une équipe directement;
C’est le temps de revoir les présentations vues dans
les conférences;
Nouvelles technologies ou veille technologique;
Sujet très précis;
Retours sur la base.

32. Exemples
Nouvelles
Technologies:
PHP 7
Symfony 3
Sujets précis:
RabbitMQ
Cryptographie
Retours à la base:
Les vecteurs
Les chaînes de
caractères
Les flux

33. Mensuels
Une fois par mois pour plusieurs petites équipes
ou une grande équipe;
Durée de 3 à 4h avec un arrêt pour le repas;
Toujours le faire la même journée, par exemple le
dernier ou premier vendredi du mois;
Offrir le repas est de bonne forme.

34. On y présente quoi?
Des formations qui incluent toute la compagnie;
Des formations qui incluent toutes les
équipement de développement;
Mieux comprendre les autres équipes: marketing,
ressources humaines, assurance qualité…

35. Exemples
Passage à Agile
La théorie sur les tests unitaires
Théorie de la qualité de code

36. Qui?
Formateurs externes;
Experts sur le sujet;
Membre d’une autre équipe;
Et des vidéos, présentation en direct ou à la
demande en ligne.

37. Dojo

38. C’est quoi?
Rencontre pour travailler sur un défi:
• Problème algorithmique à résoudre;
• besoin à implémenter;
Se concentre sur un sujet particulier;
Permettre d'apprendre de façon collective.

39. L’intérêt
Apprendre de nouvelles techniques;
• Grâce aux connaissances des autres;
• Progressant ensemble face à un problème.
Tester et parfaire des techniques de façon sûre;
Partager avec les autres membres son savoir.

40. Besoin de trois éléments
Envie d'apprendre de nouvelles techniques, de
nouveaux concepts de programmation;
Envie de partager avec les autres ses
connaissances;
Bénéficier d'une amélioration continue de ses
compétences.

41. Caractéristiques
Tous les niveaux de compétences en
programmation sont acceptés.
Seule une personne volontaire peut participer à
un Coding Dojo.
Ce n'est pas une compétition.

42. Caractéristiques
L'erreur est humaine.
Il n'y a pas de jugement.
Le Coding Dojo doit être un moment convivial.
Tout le monde doit participer.

43. Caractéristiques
Chacun doit pouvoir s'améliorer à son rythme.
Le but n'est pas de terminer l'exercice mais bien
d'apprendre.
Il permet un apprentissage continu/régulier.
Il permet un apprentissage par petits pas.

44. Les types de dojo
Kata préparé
Randori Kata

45. Kata préparé
Un présentateur montre comment résoudre le défi à
partir de zéro, en utilisant le développement piloté
par les tests et en faisant les étapes pas à pas.
Chaque étape doit être comprise par toutes les
personnes présentes.
Les gens devraient interrompre seulement s’ils ne
comprennent pas ce qui se passe.

46. Randori Kata
Le défi est résolu par une paire de programmeur (pilote et
copilote).
Tout le monde présent est invité à aider.
Chaque paire a un certain temps (5 ou 7 minutes) pour faire
avancer, en utilisant le développement piloté par les tests et en
faisant les étapes pas à pas.
À la fin du temps requis, le pilote retourne parmi le reste du
groupe, le co-pilote devient pilote, une personne du groupe
devient co-pilote.

47. Comparé au Lunch and
Learn
Plus participatif;
Meilleur apprentissage;
Peut être utilisé de façon dépendante ou non;
Apprentissage d’équipe.

48. Besoins
Une table (au moins).
Des chaises pour
l'ensemble des
participants
Un video projecteur.
Un ordinateur portable.
Un tableau à papier ou
tableau blanc.
Des post-its.
Des stylos.
Un appareil photo
(optionnel)
Une Caméra (optionnelle)

49. Plus d’information
http://codingdojo.org
http://codingdojo.org/cgi-bin/index.pl?
KataCatalogue

50. Revue de code

51. C’est quoi?
Examen systématique du code source;
Trouver des bugs ou des vulnérabilités
potentielles;
Corriger des erreurs de conception;

52. On fait déjà la revue
Sur une partie du code;
Collecte et présentation des modifications
apportées aux fichiers sources qui nécessitent
une relecture.

53. L’intérêt
Améliorer la qualité du code;
Améliorer la sécurité du logiciel;
favoriser la collaboration, le travail en équipe;
Appliquer un standard;
Détecter et corriger les défauts (bogues mais aussi lisibilité) au
plus tôt dans le cycle de vie du code pour économiser les coûts;
Formation des développeurs.

54. Hebdomadaires
Pour une petite équipe (< 10 personnes);
Diviser les grosseurs équipes en plus petits
groupes;
Toujours la même journée de la semaine;
90 minutes, mais réserver la salle la salle pour 30
minutes de plus.

55. Bimensuel
Pour une petite équipe (< 10 personnes);
Diviser les grosseurs équipes en plus petits groupes;
Alterner les personnes dans chacun des groupes;
Toujours la même journée de la semaine;
180 minutes, mais réserver la salle pour 30 minutes
de plus.

56. Besoins
Une table (au moins).
Des chaises pour
l'ensemble des
participants
Un video projecteur.
Un ordinateur
portable.
Statistiques et
métriques (vitesse de
relecture, taux de
détection des
défauts…)

57. Caractéristiques
Tous les niveaux de compétences en programmation
sont acceptés.
Ce n'est pas une compétition.
L'erreur est humaine.
Il n'y a pas de jugement.
Tout le monde doit participer.

58. Caractéristiques
Chacun doit pouvoir s'améliorer à son rythme.
Le but n'est pas de terminer la revue mais bien
d'apprendre.
Il permet un apprentissage continu/régulier.
Il permet un apprentissage par petits pas.

59. Philippe Gamache
@philoupedia
kaizen.philoupedia@ph-il.ca
https://joind.in/16496