mathieu boisvert
Articles de mathieu :
- : Connaître un langage majeur (ex: .NET, Java, PHP)
- : Connaître une technologie de client riche (RIAs)
- : Connaître le développement web
- : Connaître les services web
- : Avoir des compétences humaines (Soft skills)
- : Connaître les langages dynamiques
- : Connaître les méthodes Agile
- : Avoir de l’intérêt pour les domaines d’affaire
- : Avoir une bonne hygiène de développement
- : Connaître le développement embarqué (Mobile)
- http://codekata.pragprog.com/codekata/
- http://codingdojo.org/
- http://butunclebob.com/ArticleS.UncleBob.TheProgrammingDojo 
- http://www.pyxis-tech.com/fr/dojo/
- Recommencer à zéro: on ne cherche pas vraiment à résoudre un problème, mais plutôt à pratiquer. Les problèmes rencontrés dans un cas simple réalisable en une heure seront similaires à ceux que l’on rencontre dans la réalisation de plus gros projets.
- Prévoir une courte pause au milieu de l’atelier pour inspecter et ajuster l’exercice en cas de besoin. On pourra y définir de nouvelles règles ou s’entendre sur la ligne directrice de conception.
- Où peut-on trouver des exemples de défis?
- Quel est le but du dojo si ce n’est pas la résolution du défi?
- A quel moment on doit changer le binôme au commandes d’un randori?
- les sprints apportent une cadence et établissent la capacité des équipes. Ceci ajoute de la visibilité et de la prévisibilité pour le client et l’entreprise.
- les sprints définissent des points de synchronisation. Ceci donne des occasions pour s’intégrer avec d’autres équipes, des occassions au client d’exprimer sa satisfaction et des occasions pour changer l’affectation des ressources.
- les sprints régularisent la période sur laquelle une équipe doit s’engager.
- Une période de célébration
- Un moment d’introspection
- Une granularité utile à la haute direction
- Une cadence durable.
- Un instant pour mesurer le succès (ou l’insuccès) d’une équipe.
Adaptation du rôle d’analyste d’affaires dans une équipe Agile
Le Agile Extention to the BABOK® Guide apporte une piste de réflexion intéressante à propos des analystes d’affaires en dressant une liste des rôles naturellement tenus par un analyste au sein des équipes Agiles. Le document se concentre sur les analystes d’affaires, mais selon moi cela s’applique également aux analystes fonctionnels et, en partie, aux analystes organiques.
Voici ce que la liste indique :
Kanban vs Scrum de Henrik Kniberg
Je suis en mandat avec une équipe de développement qui ne peut d’emblée adopter toutes les pratiques de Scrum. Le domaine d’affaire de l’application est si complexe qu’il est difficile pour le PO de présenter à l’équipe l’équivalent de quelques semaines de travail. Pour le moment, nous avons décidé de contourner le problème sans se priver des valeurs d’amélioration et de collaboration de l’Agilité en adoptant la méthode Kanban. Isabelle Therrien m’a référé un très bon article de Henrik Kniberg à propos du Kanban versus Scrum. C’est la meilleure vulgarisation de la méthode que j’ai lu à ce jour. Contrairement à d’autres articles, il explique bien le Kanban comme une méthode Agile à part entière, et pas seulement une adaptation de Scrum.
L’article explique notamment que: – Scrum est dirigé par l’engagement et les boîtes de temps alors que le Kanban est dirigé par un flux tendu et le périmètre. – Kanban permet la ré-introduction de spécialités impossibles à diffuser au sein d’une équipe pluri-disciplinaire – Kanban permet au PO de planifier les items à développer à l’unité alors que Scrum permet la planification d’items en lot
Attention! Kanban est moins restrictif que le Scrum. Il faut prendre garde de respecter l’esprit Agile.
Avez-vous des mises en garde ou des opinions à propos de Kanban?
Les compétences techniques qu’un développeur devrait améliorer selon Justin James
J’aime bien cet article qui liste les compétences passe-partout que les développeurs devraient chercher à améliorer. Voici la liste des thèmes, lire l’article pour le détail.
Les temps changent; il me semble qu’à mes débuts, la liste aurait aussi inclus des connaissances du SQL avec un SGBD, et au moins un langage script (utile entre autres pour faire des scripts de build et des batchs).
Dans tout les cas, je vois d’un bon œil d’avoir une liste d’axes de compétences avec laquelle je peux me mesurer dans mon processus d’amélioration continue.
Quand la mêlée quotidienne sonne faux.
 |
Entendez-vous les violons stridents qui annoncent un meurtre? Ils annoncent la mort de la mêlée quotidienne. Même si on a déjà posté sur ce sujet sur le blog de Pyxis, j’en rajoute une couche. Le problème avec l’intervention citée plus haut, c’est qu’elle n’a aucune valeur ajoutée; j’aurais pu obtenir la même information en regardant le tableau des tâches. Si vous tenez votre mêlée en face de votre tableau des tâches et de votre graphique d’avancement, et que les participants continuent de tenir de mêlées aussi insipides, vous gaspillez tous les jours 15 minutes de temps de travail. Au moins, vous aurez réduit à 15 minutes le massacre quotidien. Quel est le contexte d’une mêlée? Ça ressemble un peu à un article de journal; je veux savoir ce qui a progressé depuis hier à propos des élections américaines. Si rien n’a changé, je ne tiens pas à le savoir. Dans le cadre d’une itération, en tant que membre impliqué, je veux savoir où nous en sommes et je veux partager avec mes coéquipiers mes contributions, mes observations et les risques que j’ai identifiés. Ce n’est pas moi le sujet de cette rencontre, mais notre engagement. En quoi ma journée a contribué au projet? En quoi j’ai affecté NOTRE itération? En quoi j’ai amélioré la qualité de NOTRE produit? Qu’est-ce qu’ON peut faire pour adresser un obstacle?
Voilà! Si vous avez de la difficulté à secouer vos troupes, changez la formulation de vos questions ou jetez-les par la fenêtre! Préférez une question qui s’adresse à tous le groupe sur la progression de votre itération. |
Les Dojos de Développement (Coding Dojo)
L’amélioration continue est un concept clé des pratiques agiles. Les livres, les blogues et les formations sont de bonnes façons de se perfectionner. La tenue de dojos est une autre façon ludique et motivante de partager et se perfectionner sur le développement logiciel.
Les Dojos
Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.
Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.
Cherchez l’erreur.
Laurent Bossavit
Se donner des périodes pour pratiquer la programmation nous éveille à de nouvelles techniques et nous fait découvrir de nouveaux langages sans amputer sur nos mandats professionnelles. De le faire en groupe nous encourage et nous aide à nous défaire de nos pratiques routinières.
Références
Statégies
Foire aux questions
Un défi populaire dans la communauté, c’est le fameux pointage du jeu de quilles . Le catalogue du site Coding Dojo  est une bonne source d’inspiration. Pragmatic Dave propose également d’autres katas .
Le défi se doit de rester simple et réalisable dans un court laps de temps. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable.
Le but est de se perfectionner dans une discipline du développement logiciel. On peut perfectionner une pratique comme le TDD ou l’orienté-objet, un langage comme Ruby, ou encore l’utilisation d’un framework comme Rails.
Une boîte de temps est sûrement la technique la plus simple (ex. entre 5 et 7 minutes). On aussi peut utiliser le cycle normal du TDD; chaque binôme est responsable de faire passer un nouveau test.
Le Coding Dojo de Pittsburg a une autre approche; tous les participants binôment simultanément sur le défi et l’atelier se termine par une rétrospective de groupe.
Réactions au fameux article de James Shore sur le déclin de l’agilité.
En parcourant les archives pyxissiennes, nous avons retrouvé une intéressante discussion à propos de l’article The Decline and Fall of Agile de James Shore.
Je la retranscris pour votre bon plaisir! 
Est-ce que les sprints/itérations sont pertinents?
Dans mon précédent billet, j’avais mentionné que chez OLM les sprints étaient un frein dans nos planifications: certaines stories avaient des pré-requis qui allaient se résoudre pendant le sprint, mais qui ne pouvaient pas attendre la fin du prochain sprint pour être sélectionnées. On ajoutait consciemment des facteurs de risque à nos sprints.
Dans quelques billets, Naresh Jain critique les sprints de Scrum et les itérations de XP:
Lorsqu’elle remplace les sprints avec une gestion par flux-tiré (go!, Scrum-Ban, go!), ses équipes n’ont pas de regrets. Elle explique que la planification et le suivi des sprints sont coûteux en effort et en temps et n’ajoute pas réellement de valeur. Pour elle, l’utilisation des sprints est un artifice qu’une équipe se donne pour corriger un dysfonctionnement, en citant Sutherland qui explique la raison d’être des itérations:
Jeff Sutherland about why he decided to have Sprints as fixed time boxes, he will tell you that at that point the developers were constantly being interrupted by their customers/managers, leading to a context switch. This was yielding very poor productivity and lack of focus.The time box addressed this issue by keeping the customers and managers “out of the room†for the time box duration and also helped the developers to set a clear focus on what needs to be achieved.
Un billet sur InfoQ leur reconnait tout de même quelques qualités:
Sans recommander les sprints, on conseille dans le même billet d’être prudent à ne pas perdre les bienfaits qu’apportent les sprints:
J’ai l’impression que l’utilisation des sprints soit un passage obligé que l’on peut abondonner qu’après avoir atteint un certain dégré de maturité. Pensez vous que votre entreprise/équipe bénificie vraiment de l’utilisation des sprints? Etes-vous prêts pour la gestion par flux tendu?