Interviewer: 7 règles d’or

Posté par jc-QualityStreet le 30 juillet 2007

L’entretien est au coeur de nos métiers…
Quel que soit le contexte, l’ergonome, l’analyste ou encore le chef de projet ont tous le même objectif: ils souhaitent faire parler la personne qu’ils interrogent sur un sujet donné.
Mais conduire un entretien ne s’improvise pas:

• C’est de l’expérience et des savoirs-faire
• C’est la maîtrise et le choix des bonnes techniques
• C’est de la PREPARATION
• C’est avant tout une attitude, une écoute active et l’art de savoir montrer de l’intérêt et de la curiosité …

Voici donc mes 7 règles d’or:

1. Arrêter de parler et laisser l’autre sur le devant de la scène
2. Rester neutre sans juger ni critiquer le discours de l’autre
3. Proposer régulièrement des indices non verbaux (hochements de tête, regard attentif, buste en avant, prise de notes …), signes d’intérêt et de curiosité
4. Encourager votre interlocuteur à communiquer, à préciser ce qu’il dit par de courtes incitations verbales
5. Ne pas interrompre mais poser des questions appropriées quand il le faut (interrogations)
6. Ne pas interrompre mais réitérer dans les moments clés (sous forme d’écho, de résumé, d’élucidation)
7. Pratiquer et exploiter les silences

Votre expert UP n’en est pas un …

Posté par jc-QualityStreet le 25 juillet 2007

• S’il décrit les phases du processus comme des phases séquentielles et insiste pour que la plupart des tâches soient effectuées avant le développement proprement dit
• S’il vous suggère des itérations de plus de 6 semaines
• S’il vous recommande de planifier une longue phase d’inception
• S’il vous recommande d’élargir le nombre de livrables plutôt que de les réduire
• S’il diffère sans cesse les tests … plus tard … rien ne presse
• S’il vous invite à produire toujours plus de diagrammes UML ….

Processus Unifié : 10 bonnes façons de se planter …

Posté par jc-QualityStreet le 18 juillet 2007

Adapter le Processus Unifié et basculer vers les méthodes Agiles ne se fait pas en un mois (c’était mon précédent billet); la démarche doit être rigoureuse, nécessite un vrai plan d’accompagnement du changement et passe par des jalons importants: Convaincre - Préparer et Planifier - Mettre en oeuvre - Evaluer, Raffiner et Améliorer.

Sinon, voici 10 bonnes façons d’échouer dans la mise en place du Processus Unfié :

1. Vous ne vous faites pas accompagner par un expert du Processus Unifié, et de ses différentes instanciations (RUP; AUP; Open UP …)
2. Vous adoptez trop d’éléments, votre process est trop lourd, et manque de souplesse
3. Vous faites une adoption Big Bang: on change tout et tout de suite, sans préparation, sans méthode et sans accompagnement !
4. Vous analysez vite fait votre processus de développement existant (type cascade) et croyez qu’UP s’y adapte parfaitement : y a presque rien à changer, vous dites-vous !
5. Au fond, vous n’adhérez pas : itérations, risques, intégration continue, c’est juste des concepts à la mode !
6. Vous pensez que ça prendra 3 mois et considérez votre Development case (la configuration du Processus Unifié à votre contexte) comme un aboutissement, une fin en soi !
7. Vous conservez des vieux noms de livrables, de vielles recettes au détriment de nouvelles techniques, de la nouvelle et bonne terminologie
8. Vous ne pouvez vous appuyer sur les bonnes personnes (niveau organisation) et des acteurs clés ne jouent pas le jeu
9. Vous ne disposez pas de chefs de projet formés et motivés
10. Vous continuez de faire des spécifications excessives avant de commencer le dév, de prévoir les tests à la fin, de fixer des plans détaillés de A à Z, modifier vos objectifs en cours d’itération, de bouger vos dates d’itération, vous faites les choses dans votre coin : bref vous n’avez rien compris !

Adopter le Processus Unifié, Basculer vers les méthodes Agiles

Posté par jc-QualityStreet le 16 juillet 2007

Un nouveau processus de développement est un changement culturel majeur qui doit être préparé et accompagné.
La transition sera longue… les enjeux sont forts:

• Enjeu Humain : C’est une nouvelle façon de travailler, donc l’abandon de certaines habitudes, et la nécessité de compter sur des personnes motivées et formées.
• Enjeu Organisationnel: Le nouveau processus doit se fondre dans l’organisation existante (ce qui ne signifie pas se fondre dans les méthodes de développement existantes, bien au contraire !!!)
• Enjeu Technologique : Les nouvelles pratiques Agiles peuvent (mais ce n’est pas obligatoire) nécessiter l’investissement dans des outils facilitant par exemple la gestion de configuration, l’intégration continue, les tests automatisés, la gestion des exigences …
• Enjeu Business : Pour nous autres Editeurs, comme pour beaucoup, c’est faire le “BON PRODUIT, AU BON MOMENT, AU MEILLEUR COUT“, et le processus Unifié maximise les chances d’atteindre cet objectif.

Un plan d’accompagnement du changement doit donc être initié; mesuré, progressif, celui-ci devra permettre de saisir les avantages, opportunités, et leviers, mais aussi les freins et résistances potentielles.

L’accompagnement du changement sera telle une course de fond, car l’adoption du processus unifié (”UP”, comme “Unified Process”) et des bonnes pratiques Agiles va se faire sur de nombreux mois …

Votre programme :

• Convaincre (courts séminaires pour vos cadres et dirigeants; mise en avant des bonnes pratiques; messages clés ciblés)
• Préparer et planifier en gardant l’Esprit Agile (réflexion sur les processus, formations et coaching, analyse du contexte, activités, rôles, livrables actuellement en place, configuration de votre Development case “UP socièté xxx”, qui sera lui même décliné pour chaque projet; argumentaires, formations à dispenser)
• Mettre en œuvre (d’abord sur des projets pilotes puis progressivement sur d’autres projets)
• Evaluer, Raffiner et Améliorer (bilan et rétrospective, pour moi ce fut le Processus Unifié 2.0)

Mais dans tous les cas, FAITES VOUS COACHER PAR UN EXPERT “UP” !!!; et si celui-ci peut participer à certains de vos projets, c’est encore mieux…
Bon, tout cela a l’air compliqué, mais au final, dites vous qu’adopter “UP” (”Unified Process”) à votre contexte, c’est concrètement:

• Découper vos projets en de courtes itérations
• Piloter vos projets par les risques
• Opter pour les bonnes techniques de gestion des exigences (vision, use cases / user stories, base d’exigences)
• Mettre le paquet sur les tests de tout type (tester tôt et fréquemment)
• Et aller plus loin que le processus Unifié lui-même en intégrant les pratiques agiles les plus performantes (UP et une dose de SCRUM) et une démarche de conception centrée utilisateurs (vers le chef de projet et l’Ergonome agile)

En quoi puis-je t’aider ?

Posté par jc-QualityStreet le 6 juillet 2007

… Qu’est ce qui t’empêche de faire ton travail ? Comment te faciliter la vie ?

Peu importe sa forme, cette question est aujourd’hui centrale dans la vie des projets. Elle est posée par le Chef de projet à chaque membre de son équipe, notamment au moment des scrums (« mêlées »), ces réunions d’équipe projet qui ont lieu tous les jours (c’est mieux) ou 2 à 3 fois par semaine et qui durent environ 15 minutes (et si possible debout : « We stand up to keep the meeting short »).

Le SCRUM est, à bien des égards, symbolique, et véhicule pas mal de valeurs (UP et une dose de SCRUM), mais il est aussi le reflet d’un chef de projet devenu, par nécessité, facilitateur et protecteur. C’est une vraie tendance (le chef de projet Agile) mais aussi et surtout l’ingrédient essentiel pour la réussite du projet, un élément tout simplement indispensable dans une perspective Agile où les itérations sont souvent serrées.
Concrètement, l’Organisation (au sens large) et les événement extérieurs doivent donc le moins possible interférer dans vie du projet : le chef de projet est là pour y veiller (mais quel est le poids du chef de projet au sein (face) de l’Organisation, quelle est sa marge de manœuvre, me direz-vous ?. ).
Facilitation et Protection sont donc deux dimensions, parmi les bonnes pratiques de management, que les méthodes Agiles ( SCRUm) ont su mettre en avant, mais dont elles n’ont pas le monopole : Scott Berkun , 10 ans de projets Microsoft derrière lui, et auteur de « The art of project management », l’une des références pour la gestion de projet informatique, va lui aussi dans ce sens en comparant le chef de projet (Project Manager) au fameux « Blocker » du Football Américain, celui qui permet au « Running Back » de mener à bien ses plus belles actions (rôle ô combien ingrat). L’art de la gestion de projet est un peu l’art du sacrifice :

If you look carefully at any highlight reel where someone runs for 70 yards, you’ll see another guy lying flat on the ground, buried under various large people, who was responsible for making the play possible. Good PMs make plays possible. They seek out and eliminate issues that are slowing the team down

Rugby (Scrum), Football Américain … décidément, le sport est une vraie source d’inspiration pour le management de projet !!!

Agile vs Cascade

Posté par jc-QualityStreet le 3 juillet 2007

Une comparaison trés intéressante (en anglais), proposée par Chris Woodill, de deux projets de développement menés au sein de son organisation, auxquels il a participé :

• le premier en mode « Traditionnel » (cascade),
• le second dans un mode Agile (itératif, incrémental, priorisé par les risques …).

Le contexte et les deux approches sont détaillés, et l’auteur nous donne sa conclusion (argumentée) :

“Agile projects are good for customers” …