Issues du Management 3.0 (tout comme le Moving Motivators et le Delegation Poker ), les Kudo Cards sont un must have dans une entreprise (ou un projet) qui est centrée collaborateur.

Le principe

Le principe est simple, il s’agit de remercier les personnes de l’équipe pour leur travail, attitude ou tout ce que vous jugerez bon de pointer du doigt (de positif, bien entendu).

Pourquoi ? Parce que rien de mieux que la gratitude pour faire avancer un projet et se sentir bien.
Nous avons trop tendance à  pointer du doigt quand quelque chose ne va pas mais à ne rien dire si le travail est bon ce qui a tendance à accentuer une démotivation et perte de confiance.

Pour y remédier, il suffit de dire merci ;).

Les cartes

Les cartes se présentent sous ce format :

Mode d’emploi

Il y a plusieurs façons de faire, le but étant que chacun distribue les cartes de remerciement /félicitations à autrui dès qu’il le juge nécessaire.

Méthode 1 : La boîte à remerciements (Kudo Box)

On fait une jolie boite de ce style et on y dépose une Kudo Cards dès que le besoin s’en fait ressentir.

Une fois par mois, on procède a une cérémonie de dépouillements où tous les remerciements sont lus à tous.

Méthode 2 : Le mur des remerciements

Un mur visible de tous affiche l’ensemble des Kudo Cards et on en rajoute au fur et à mesure.

Un nettoyage du mur peut être fait fréquemment avec une petite cérémonie de remerciements.

Méthode 3 : Donner la carte à la personne

On peut très bien faire simple et tout juste donner la Kudo Cards à la personne concernée à l’instant T ;), cela fait plaisir et reste dans le privé.

Petit + :

Pour donner encore plus envie d’être remerciés, vous pouvez attribuer des prix pour les top receveurs (exemple un petit dej offert ;)). 

Le Delegation Poker fait parti du kit d’outils du Management 3.0 (tout comme le Moving Motivators ici). Il sert à partager les responsabilités dans l’équipe autour de discussions de confiance . 

L’un des fondements du Management 3.0 dit « La gestion est trop importante pour être laissée aux managers » ce qui implique de « déléguer », cela tombe bien on parle ici de Delegation poker ;).

Matériel

Le jeu de cartes du Delegation Poker se constitue comme suit :

1 – Tell : Le manager prend la décision et informe son équipe de celle-ci.

2 – Sell : Le manager prend la décision mais va convaincre l’équipe que c’est la bonne.

3 – Consult : Le manager prend la décision mais après avoir consulté son équipe pour être conseillé.

4 – Agree : Le manager et l’équipe prennent la décision d’égal à égal.

5 – Advise : Le manager conseille et peut influencer mais la décision revient à l’équipe.

6 – Inquire : L’équipe prend la décision et informe le manager de celle-ci.

7 – Delegate : L’équipe prend seule la décision, le manager n’a pas d’influence.

Déroulement

Tout le monde (équipe et manager) se voit attribuer un set de carte de Delegation Poker. L’animateur va ensuite proposer une situation qui peut avoir lieu, exemple :

• Qui valide les congés ?
• Qui est responsable de l’embauche d’une nouvelle recrue ?
• Qui décide de la deadline des projets ?

Suite à cela, comme un « Planning Poker« , chaque personne va choisir une des cartes de son jeu correspondant à la personne qui prendra la décision pour la situation.

L’animateur compte jusqu’à 3 et l’ensemble des cartes est dévoilé.

L’équipe échange sur la situation et les opposés donnent leurs avis sur le pourquoi de leur choix jusqu’à se mettre d’accord sur la carte correspondante (soit par moyenne, nombre majoritaire… le but étant surtout de partager).

L’objectif n’est pas de tout déléguer (carte 7) mais de communiquer et de progresser au sein de l’équipe.

Une fois terminé, on passe à la prochaine situation. Chaque personne est libre d’en proposer une 😉

Tout développeur ,s’il veut respecter certains concepts du software craftmanship, a la possibilité d’utiliser des patterns.

Cet article va vous expliquer de manière simple dans quelles occasions certains patterns peuvent être utilisé.

Une boite à outils

Lorsque vous êtes en train de bricoler chez vous avec votre boite à outils préférée, vous vous apercevez qu’une vis doit être retirée. Pour cela, vous ouvrez votre boite à outils et prenez l’outil permettant de résoudre cette problématique : à savoir un tournevis.

Un problème détecté a été résolu par l’utilisation d’un outil.

Et bien en terme de programmation, c’est exactement la même chose. Lorsque vous êtres confronté à un problème d’algorithmie, un design pattern peut être la solution pour résoudre votre soucis. Dans ce cas, si je veux faire une comparaison, le pattern que vous utiliserez est tout simplement votre tournevis.

Le gros avantage est que ces outils (en l’occurrence les design pattern) sont connus de tout développeur (provenant des Etats-Unis, d’Europe, de Chine…etc). Cela permet ainsi d’avoir du code standardisé, plus maintenable et surtout plus facile à reprendre pour le développeur qui passera derrière vous (car il faut toujours penser à la personne qui reprendra votre travail).

Des exemples…

J’imagine que vous êtes tous impatients de savoir quand utiliser ces patterns…Je précise juste que je ne vous expliquerai pas l’implémentation de chaque pattern (qui fera peut être l’objet d’un autre article de ma part) mais dans quels conditions l’utilisation de tel où tel pattern pourra résoudre votre problématique.

• Vous êtes dans la nécessité de créer une instance unique de classe en session au niveau de votre code. Le pattern Singleton peut répondre à votre besoin
• Vous souhaitez centraliser l’instanciation de vos objets, d’avoir une classe qui s’occupe uniquement de faire ce travail. Le pattern Factory peut répondre à votre besoin.
• Vous travaillez sur une application développée en couches et vous souhaitez que celles-ci soient faiblement couplées. Le pattern Facade peut répondre à votre besoin.
• Vous êtes dans la nécessité de rajouter des fonctionnalités à une classe. Le pattern Decorateur peut répondre à votre besoin. D’autant plus, qu’en utilisant ce pattern, on sera cohérent avec le O (Open) des paramètres SOLID qui préconise d’éviter le plus possible de modifier une classe existante mais de l’étendre.
• Vous devez développer un algorithme et vous vous rendez compte que celui-ci doit être appelé plusieurs fois mais avec des paramètres différents à chaque fois. Le pattern Stratégie peut répondre à votre besoin. L’exemple typique du pattern stratégie est la météo (quand vous demandez dans une application Météo les prévisions pour demain, après demain, la semaine prochaine…d’un point de vue technique vous demandez toujours la même chose mais avec des paramètres différents).

Le BDD, qu’est ce que c’est ? 

Ce que l’on entend souvent, c’est que le BDD(Behavior Driven Developement) est un langage (Gherkin) permettant par la suite d’écrire les TDD (Test Behavior Developement) .

Faux ! Le BDD est une méthode de travail qui consiste avant tout  à mettre en forme des scénarios de tests dans un langage compréhensible par toutes les parties du projet (techniques ou non).

Oui, parfois (souvent), ces scénarios sont mis sous forme de Gherkin dans un outil comme SpecFlow pour ensuite aller vers du TDD mais il s’agit surtout de communiquer ensemble sur tous les cas possibles d’une fonctionnalité afin de couvrir (fonctionnellement) l’intégralité des possibilités.

« Three Amigos »

Ce que l’on appelle le « Three Amigos » lors d’un atelier BDD, c’est le fait de se mettre autour de la table avec à minima 3 personnes qui porteront une casquette différente pour répondre aux question suivantes :

• Métier (souvent un BA ou PO): Quel problème essayons nous de résoudre ?
• Développement (Dev) : Quelle solution pouvons-nous apporter ?
• Test (QA): Doit trouver les défauts à cette solution pour creuser la totalité des cas et se poser la question du « Et si … ? ».

Exemple :

Métier : « Je veux que mon utilisateur puisse laisser des commentaires »

Développement : « Nous aurons un champs commentaire dans le formulaire »

Test : « Ok, et si l’utilisateur envoie un roman dans le champs ? »

Métier : « Ah mais non c’est logique, on ne veut pas de trop gros commentaires ! »

Développement : « Donc nous dirons 1000 caractères ? »

Métier : « Parfait »

Test : « Et qu’arrivera t-il s’il les dépasse ? »

Métier : « Un message d’erreur ? »

Développement : « Ok ! »

Donnera :

• Étant donné (Given) qu’un utilisateur laisse un commentaire
• Quand (When) le commentaire dépasse 1000 caractères
• Alors (Then) le commentaire ne doit pas être sauvegardé
• Et ( And) l’utilisateur doit voir un message d’erreur

On ne pense pas tous de la même manière, quelque chose qui paraît évident pour quelqu’un, ne l’est pas forcément pour un autre. Si le BDD n’avait pas eu lieu, le développeur aurait possiblement créé une zone de texte sans limite et le métier serait revenu vers lui plus tard pour la lui demander.

Le BDD permet donc de parer à tout éventualité et de pouvoir anticiper les retours possibles.

On pourrait s’arrêter là, vous avez compris le principe. En atelier, nous mettons sur papier tous ces scénarios afin de partir sur de bonnes bases pour les développements.

Cependant, il existe certains outils permettant d’intégrer ces BDD dans le code pour ensuite en faire des BDD comme « SpecFlow ».