Fortunes projet

En écho à l’article concernant une convergence possible (ou pas) entre agile et cmmi, vous trouverez ici les fortunes CMMi que j’avais évoqué. J’ai décidé de les renommer “fortunes projet” car je les ai passablement reformulées, et pour ne pas chagriner les anti de tous poils.

L’idée derrière ces fortunes est de donner aux équipes des éléments de réflexion pour les aider à la réussite de leurs projets (qu’ils soient agiles, classiques, ou autre).

Vous trouverez donc ici :

http://www.areyouagile.com/wp-content/uploads/2011/11/areyouagile_fortune_0_3.pdf

Les fortunes et une proposition de mode opératoire, mais sur ce dernier point je fais surtout appel à votre imagination, et je serai friand de vos retours.

ps : l’image du “make love, not bugs” vient de là.

This entry was written by pablo, posted on November 16, 2011 at 6:44 am, filed under cmmi, gestion projet, management, méthodes agiles and tagged agile, bonnes pratiques, cmmi, fortune, fortunes, projet. Leave a comment or view the discussion at the permalink.

Agile & CMMi, potion magique ou grand fossé ?

Je reviens sur la session Agile & CMMi : potion magique ou grand fossé que nous avons donné récemment Yassine (@yassinezakaria) et moi même lors de l’Agile Tour Toulouse 2011.  Les slides sont disponibles ici (ou intégrés plus bas) et je souhaitais les commenter un peu, même si des commentaires écrits remplacent rarement une session.

D’abord sachez que cette session nous a amené -Yassine & moi- a pas mal de discussions assez musclées.

Pourquoi avoir fait une session sur Agile & CMMi ? D’abord car nous trouvons un peu absurde les levées de boucliers et les préjugées dont font preuve une grande partie des gens de ces deux mondes vis à vis l’un de l’autre. Nous nous sommes amusés à mettre cela en forme au travers de différents slides. Mais la malheureuse réalité est que quand l’esprit des gens ces caricatures ne sont pas loin d’être vraies. Et d’ailleurs de nombreuses mauvaises applications de l’agile ou de CMMi les rendent souvent vraies ou les renforcent…

(more…)

This entry was written by pablo, posted on October 28, 2011 at 3:37 pm, filed under cmmi, kanban, méthodes agiles, scrum, XP and tagged agile, asterix, cmmi, obelix, toulouse. Leave a comment or view the discussion at the permalink.

Le serment de non allégeance de Mr Cockburn

Je suis en train de penser à un billet qui s’intitulerait “passe ton cycle en V d’abord” et qui souhaiterait mettre en évidence l’intérêt (l’importance ?) d’avoir pratiqué d’autres formes de gestion de projet pour mieux appréhender la gestion agile. Je repense à une pétition sur le web, signée il y a quelques temps, un très juste rappel de Alistair Cockburn : le serment de non allégeance.

http://alistair.cockburn.us/Oath+of+Non-Allegiance

Je promet de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

A méditer et mettre en pratique.

This entry was written by pablo, posted on December 16, 2010 at 1:38 pm, filed under cmmi, gestion projet, méthodes agiles and tagged serment. Leave a comment or view the discussion at the permalink.

Vos pratiques projets sous la loupe CMMi

Je voudrais prendre le temps de rappeler l’existence de cette fiche excel (trouvée un jour par hasard sur le web) en provenance directe de Richard Basque, et dont je me suis servi maintes fois dans le cadre d’audits (en citant ma source !). Car cette fiche mentionne : Permission de réutiliser mais avec la référence obligatoire: ” © 2006 Alcyonix (www.alcyonix.com)” . Voilà, c’est chose faîte une nouvelle fois. Merci Alcyonix (et au passage je ne sais pas si c’est encore d’actualité : “salut Eric ! salut Christian !”).

En 9 mots : CMMi est un très intéressant ensemble de pratiques projets (c’est un résumé très succinct que je fais là, lisez plutôt ceci). L’une de ses forces est de laisser chacun implémenter ces pratiques comme il le souhaite. Concernant certaines de ses faiblesses je vous laisse consulter certains de mes précédents billets. Pour ma part, et je l’ai déjà évoqué, j’utilise surtout mes connaissances et mon expérience CMMi dans le cadre d’audits (d’où aussi cette checklist). Je recommande à tous les chef de projets ou scrummaster ou autres de se plonger un peu dans les différentes questions proposées ici et qui -je l’espère- nourriront votre réflexion concernant vos projets informatiques. Merci encore Al’ !

Le lien vers la fiche excel : template-cmmi-v13-standard-piis

This entry was written by pablo, posted on November 20, 2010 at 1:28 pm, filed under cmmi, gestion projet and tagged cmmi, projet. Leave a comment or view the discussion at the permalink.

Conseils aux chefs de projet

Ouah. Quelle impudence ! donner des conseils à des chefs de projets. bon allez oui, osons. Juste quelques réflexions sur la façon de traiter certains aspects de votre projet. Ces réflexions viennent autant de mon expérience en la matière, et aussi de ce que je suis (ma personnalité), elles ne vont donc pas s’adapter à tous.

Savoir gérer les priorités

Première chose à savoir faire c’est gérer les priorités. Dans la liste des actions à réaliser pour le projet vous devez savoir avec une certaine précision, ou une certaine intuition, dans quelle ordre les actions doivent s’agencer. Je ne vais pas donner d’exemple vous avez tous en tête les problématiques d’agencement et de dépendances soient techniques, soient organisationnelles, pour comprendre cela. En tant que chef de projet votre capacité à bien ordonner, a bien”prioriser” les tâches sera cruciale. Les tâches étant liées entre elles, les équipes affectées aux tâches, la somme des erreurs (qui sont inéluctables) peut s’avérer fatale à votre productivité. Il faut une certaine vision (globale) sur le projet, une certaine expérience, une compréhension des différents enjeux : un schéma mental du projet qui regroupe un peu tous ses axes (techniques, fonctionnels, planning, relation client, dispo des équipes, etc etc etc).Surtout ne pas avoir la “grille MS Project” complètement incrustée en mémoire,  un projet est une chose qui évolue constamment -contrairement à votre planning/découpage initial- et donc cela ne marche pas ainsi. D’autant que  les bonnes priorités sont aussi liées au rythme de votre client, à sa façon d’aborder le projet. En tous cas :

1. N’hésitez pas mais basez vos choix sur une réflexion logique : je déclenche cela parce ça ça et ça (=> votre “schéma mental du projet”).
2. Tout le monde peut se tromper, sachez revenir en arrière si besoin, ou stopper une tâche en cours dès que les premiers “feedback” montrent que ce n’était pas le bon choix (ou parce qu’un autre critère est venu changer la donne).
3. Soyez prêt à dire oui,non à tout instant. Surtout “non” en fait, car il faut éviter de démarrer des tâches qui seront mieux appréhendées plus tard dans le projet. Gardez sous le coude des tâches “buffer/tampon”, pas complexes, incompressibles (qui devront être réalisées quoi qu’il arrive), qui n’ont pas besoin d’être réalisées par un profil particulier, et qui n’ont pas de dépendances, ceci afin de vous donner un peu le temps de la réflexion si besoin.

Savoir déléguer

Ahh ça c’est dur. hein. Combien de fois vous êtes vous dit : “bon ok, si je le fais cela va prendre 30mn, si je lui donne, hum… 4h”. Donc vous le faites… J’y décèle deux grosses erreurs : d’abord fini la gestion des priorités évoquée plus haut puisque vous vous lancez dans une tâche inattendue qui devient priorité 1 (pour de très mauvaises raisons) et vous empêche de garder assez de recul et assez de temps pour continuer à bien mener le projet.

Deuxièmement, vous faites un très mauvais pari pour l’avenir.  Ce choix indique que vous n’avez pas confiance en vos équipiers.  Peut-être à juste titre, mais le minimum est de leur donner leur chance une ou plusieurs fois. Si effectivement vous ne pouvez pas avoir confiance en certains de vos équipiers il faut le dire et prendre une décision à ce sujet (j’y reviendrai). Mais il faut se baser sur des faits concrets et responsabiliser les gens. Affecter les tâches. Dans de nombreux cas cela va se révéler payant : des gens vont progresser, vous aurez confiance en eux, vous pourrez déléguer de plus en plus souvent, ils en seront contents (voire fiers).

Même cas de figure : je commence le tâche pour qu’elle parte sur “de bonnes bases” puis je la délègue. Même problème. Sachez juger a posteriori : ce jugement sera basé sur des faits ! (c’est quand même indispensable non ? )

Savoir dire à vos collaborateurs que les choses vont mal au moment ou elles se produisent

Je rebondis sur le paragraphe précédent. On juge les gens sur des faits.  Donc A) pas de jugement a priori. Le boulot se déroule mal : trop de retard, pas de qualité, etc. On le dit. On ne porte pas de jugement, on dit les choses. Nous avons du retard. Pourquoi ? discutons. sachons pourquoi. Cela n’est pas forcément lié à la personne naturellement : elle n’a pas été formée, les specs ou exigences sont pourries, un problème inattendue a surgit. etc etc. C’est vraiment lié à la personne (elle n’est pas motivée, ne fait aucun effort, a des problèmes personnels qui la rendent acariâtre, etc. ) : on lui dit. Je ne suis pas satisfait pour telle et telle raison. J’attends de toi ça ça et ça. Peux-tu faire un effort sur ces points. merci. Si les problèmes se reproduisent régulièrement et sont vouées a ne pas évoluer je vous recommande de sortir la personne du projet. Cela arrive rarement si à intervalles réguliers on dit les choses. Dire les choses est la première façon d’instaurer une certaine confiance ou a minima un certain contrat. Quoi de plus injuste que de se faire sortir d’un projet sans avoir vu venir le boulet ? Quoi de plus normal d’être prévenu lors que l’on est pas satisfait de votre travail ? Quoi de plus grisant que de s’observer progresser ? (je vous renvoie sur le même sujet à ce post)

Et son corollaire : faire comprendre qu’un jugement sur une personne n’est ni définitif ni personnel

Je vois trop de chef de projet qui ne disent pas les choses car ils ont le sentiment que leur jugement est définitif et global. Si je dis à X qu’il a mal fait cette tâche c’est comme si je lui disais qu’il est mauvais. Rien de plus faux ! Répétez le autant qu’il le faudra à vos collaborateurs, mais soyez convaincu vous même : oui il y a des bons, oui il y a des mauvais, mais chacun peut changer de catégorie selon les projets, avec le temps (dans les deux sens), selon les interlocuteurs, selon le contexte etc. Ce n’est pas à vous d’avoir un jugement : c’est à vous de leur laissez l’occasion de faire leur preuve. Je reviens au point précédent : ne pas dire les choses quand elles se produisent mais plus tard, trop tard, ne fait qu’accentuer ce sentiment et ce trouble que le jugement est global. Si vous dites les choses ponctuellement en liaison directe avec un évènement présent cela évite beaucoup de quiproquo.

photo de : http://www.flickr.com/photos/atomicshed/161716498/sizes/s/

This entry was written by pablo, posted on May 8, 2010 at 9:42 am, filed under cmmi, gestion projet, méthodes agiles, scrum and tagged chef de projet, gestion, projet. Leave a comment or view the discussion at the permalink.