Overblog Suivre ce blog
Administration Créer mon blog

Articles avec #la gestion de projets tag

Retours sur l'Agile Tour 2011 (2/2)

4 Janvier 2012 , Rédigé par benkirane Publié dans #La gestion de projets

Je fais suite  à mon premier billet concernant l'Agile Tour 2011 pour vous faire part cette fois des conférences auxquelles j'ai assisté l'après-midi.

Améliorez l'efficacité de vos cérémonies agiles

Suite à la formation que j'ai suivi sur SCRUM, il m'avait paru que les différentes réunions n'étaient pas forcément évidentes à mener étant donné que chaque membre de l'équipe peut donner son avis. 7 à 10 personnes qui émettent chacune leur opinion pour à la fin prendre une décisionn,  cela ne doit pas être évident dans la vraie vie. J'ai donc décidé de suivre cette conférence qui devait me donner une partie des réponses à mes questions.

L'oratrice est une Coach (encore une) et certifiée SCRUM Master. Elle accompagne ou a accompagnée, depuis 15 ans, plusieurs équipes en phase de transition vers SCRUM. Tout au long de son discours, elle insiste sur la dimension humaine liée à la bonne gestion des cérémonies agiles. L'agilité nécessite un comportement et une façon d'être spécifique. Pour que tout se passe bien, il faut être ++ comme elle dit. ++ veut dire qu'on est soit même dans une idée plutôt positive de nous-même et avec les autres. On peut alors être constructif pendant la cérémonie agile puisqu'on est dans un pied d'égalité avec les autres membres de l'équipe. On est en phase de collaboration. Dans le cas contraire, la réunion ne pourra être constructive puisque les interactions entre nous et les autres membres de l'équipe seront parasytées par du négativisme (on se sent supérieur aux autres ou inférieur, on sent qu'on n'a pas notre place dans l'équipe).

Conduite du changement et gestion de conflits

Cette conférence est liée à la précédente toujours dans cette esprit des difficultés rencontrées par les équipes agiles. Cependant, l'oratrice, psychologue clinicienne, apparemment débutante dans la prise de parole en présence d'un public assez nombreux n'était pas vraiment à l'aise. Elle n'a fait que lire son support de présentation. On n'entendait parler de gestion de conflits, de stress mais cette lecture assez monotone  a complètement anihilé la conférence. Du coup, j'en ai pas retenu grand chose malheureusement. 45 minutes très longues en pure perte...

Ni Gladiateurs ni Bisounours - une équipe remarquable au quotidien

Avec la première conférence de l'après-midi, celle-ci était sans doute la meilleure de cette deuxième partie de journée. L'orateur, Christophe Thibaut, est un consultant senior ayant 20 ans d'expérience en développement et direction de projets. Il sait bien de quoi il parle et est plutôt très pragmatique.

Lors de cette session, il nous parle de la vie d'une équipe de développement en mode agile avec un focus sur les problèmes rencontrés dans ce mode de fonctionnement. Un des éléments qui revient souvent, et c'est le cas dans n'importe quelle équipe, est la gestion des conflits. Le problème dans l'agilité c'est que cela peut perdre un temps certain et créer une dynamique dans l'équipe très négative. En effet, l'efficacité d'une équipe agile réside dans la communication entre ses membres. Un conflit mal géré aboutit toujours à des blocages entre certains membres de l'équipe. Les interactions ne se font plus et l'équipe aura alors beaucoup de mal à s'autogérer et livrer dans les temps.

Christophe nous donne ainsi quelques élements pour éviter que les conflits fragilise une équipe agile. L'un des plus intéressants aspects de cette session fut alors la découverte des "core protocols" de communication. Je dis intéressant mais je ne l'utiliserais pas forcément dans la vie de tous les jours même en milieu professionnel. Pour ceux qui, comme moi, ne connaissent pas les "core protocols" c'est en fait un moyen de gérer la communication au sein d'une équipe à l'aide d'un protocole. Déjà pour moi, c'est pas l'idéal, s'il faut un protocole pour communiquer avec mon équipe c'est qu'il y a déjà un problème. Bref, ce n'est que mon point de vue après ce qui est important c'est la finalité des core protocols. Ils nous montrent qu'il est important dans une équipe que chacun de ses membres puissent indiquer à un autre membre que ce qu'il fait est bien ou pas bien, qu'une personne peut avoir envie de faire une pause, de faire autre chose, de demander de l'aide, etc...

Les core protocols permettent cela grâce à des mots clés. Je vais vous présenter dans la suite quelques exemples choisis par l'orateur.

Check in

C'est le mot clé qui est utilisé pour "entrer" dans l'équipe. Son utilisation indique aux autres membres de l'équipe que la personne est bien présente et motivée pour travailler sur ses tâches. Quand on arrive le matin, par exemple, la personne dit:

  • Check in
  • Je suis content d'arriver au boulot
  • Je suis content parce que j'ai trouvé dans la nuit la solution à mon problème d'hier
  • Je suis énervé car j'ai passé 2 heures dans les bouchons

L'équipe répond alors: Bienvenue!

Ask for help

Ce core protocol, comme son nom l'indique, est utilisé lorsqu'une personne de l'équipe a besoin d'aide. La personne dit alors:

  • Quelqu'un peut m'aider j'ai un problème avec un bug que je n'arrive ps à résoudre depuis deux jours ?

Le membre de l'équipe qui le souhaite peut répondre alors oui et prendre le temps d'aider la personne qui a demandé de l'aide.

Check out

Sans justification, ce core protocol peut être utilisé par n'importe quel membre de l'équipe pour "sortir" de l'équipe. Un membre de l'équipe est fatigué, énervé de travailler sur la même tâche depuis 2 jours sans arriver à une solution, ne peut pas tenir ses engagement, etc... Il dit alors:

  • Check out

Il va alors prendre une pause, boire un café et revient plus tard ou il rentre chez lui.

J'en ai présenté que trois mais il existe beaucoup d'autres core protocols comme Perfection Game, Pass, Protocol chec, Intention Check. L'avantage avec les core protocols c'est qu'ils forcent les membres d'une équipe à se parler et surtout à se dire ce qui va ou va pas. Ils nous apprennent qu'il est important de :

  • faire des retours positifs à quelqu'un ainsi que des négatifs,
  • de demander de l'aide à l'équipe,
  • de faire une pause quand on arrive plus à avancer,
  • ...

Cependant, à mon sens, leur utilisation rends l'individu proche d'une machine. De plus, ils aboutissent à des contraintes puisqu'on est obligé de les utiliser lorsqu'ils sont mis en place dans une équipe. Cela déshumanise les individus sans oublier le fait que vu de l'extérieur les autres personnes doivent prendre les membres de ce genre d'équipe pour des fous ou des membres d'une secte. En tout cas, c'était intéressant de savoir que ce genre de moyen existe.

Les frontières de l'équipe

L'orateur, un consultant de SFEIR, a commencé sa conférence par un petit jeu basé sur les fameux oeufs en chocolat Kinder. Il a partagé 6 personnes du public en deux équipes de 3 avec chacune 3 oeufs. La première, spécialisée sur une tâche, s'est organisée en une personne qui devait sortir l'oeuf de son papier alluminium, la seconde devait manger tous les chocolats et la dernière était spécialisée dans la réalisation de la Kinder surprise. La seconde équipe elle multi-disciplinaire dont chaque membre devait faire les 3 étapes d'affiler avec son oeuf. Bien sûr, c'est l'équipe multi-disciplinaire qui l'a emporté. L'orateur en conclut par l'efficacité en agile d'équipe multi-disciplinaire.

Pour la suite, se fut en résumé, une nouvelle formation à SCRUM avec des illustrations basées sur la bande-dessinée Asterix. Une équipe d'irréductible, les agiles, représentée par le village gaulois au milieu de tous les autres (PO, client, équipes non agiles, ...) que sont les différents camps retranchés romains.

Une session qui ne m'a pas vraiment laissée d'éléments instructifs.

Conclusion

Malgré certaines sessions très peu intéressantes, j'ai quand même eu beaucoup de retours intéressants sur l'utilisation de l'agilité dans le milieu professionnel. J'ai pu voir les difficultés rencontrées par les équipes agiles et surtout les moyens de les atténuer au maximum. En résumé, il n'est pas évident de mettre en place l'agilité mais, comme tout, l'important c'est d'adopter une attitude positive avec soi-même et les autres. Un élement important de l'agilité c'est qu'une équipe ne performe pas du jour au lendemain. Cela nécessite plusieurs mois de travail ensemble pour améliorer sans cesse les choses. Il est donc primordial, à mon sens, plus qu'avec des méthodes traditionnelles, que cette équipe ne soit pas dissoute après quelques mois. Cependant, l'agilité c'est aussi une façon d'être et de penser en équipe. Quelqu'un qui a une expérience dans l'agilité aura plus d'aisance à se réintégrer dans une nouvelle équipe agile puisqu'il aura, au moins, acquis l'état d'esprit agile. J'aurais aussi compris qu'au delà de l'équipe elle-même, le succès de la mise en oeuvre de l'agilité dans une entreprise est basé sur la confiance de ses dirigeants envers leurs équipes agiles.

Lire la suite

Ma compréhension de SCRUM: le déroulement d'un projet

4 Novembre 2011 , Rédigé par benkirane Publié dans #La gestion de projets

Dans mon billet précédent, j'ai présenté les fondamentaux du framework SCRUM. Aujourd'hui, je continue sur les aspects théoriques avec le déroulement d'un projet SCRUM.

Comment se déroule un projet SCRUM?

Dans les grandes lignes, un projet SCRUM se déroule en 5 étapes que je détaillerais dans la suite du billet:

  1. Etape 1: la Réunion de Planification de version ou Sprint 0,
  2. Etape 2: la Réunion de Planification du Sprint,
  3. Etape 3: le Sprint, cette étape ainsi que la précédente sont itératives. Elles peuvent donc être reproduites N fois jusqu'à la décision par le PO de terminer le produit.
  4. Etape 4: la Revue de Sprint,
  5. Etape 5: La Rétrospective.

Le schéma ci-dessous résume, visuellement, ces 5 étapes. Scrum Planning

Que fait-on pendant pendant la Réunion de Planification de version (Sprint 0) et qui sont les acteurs présents ?

Dans la réalité, avant la réalisation d'un projet SCRUM, il faut commencer, comme pour un projet traditionnel, par une analyse plutôt high level des besoins. La Réunion de Planification de version peut alors avoir lieu. L'objectif de celle-ci est d'élaborer le backlog initial et planifier la release. Pour cela on mettra en œuvre des pratiques comme la vision du produit, la priorisation du Backlog, l'identification des risques, la décomposition en user stories, l'estimation de l'effort en points, la définition de fini et de la durée des itérations, le planning de la release, la formation de l'équipe (s'il y a lieu), l'organisation de l'espace de travail. Pour chaque User Story, on devrait pouvoir calculer un ratio Valeur Business de la US / Effort qui est le ROI.

Que fait-on pendant pendant la Réunion de Planification du Sprint et qui sont les acteurs présents ?

Une fois le Backlog initial élaboré, la Planification du Sprint peut alors commencer. L'équipe sous la Direction du SM (Direction dans le sens orientation) choisit les US qui ont les ROI les plus élevés comme premières à réaliser dans le premier Sprint. Une fois ce que l'équipe a accumulée une somme d'effort qu'elle est capable de fournir pendant la durée d'un Sprint, elle positionne les autres US dans les Sprints suivants. L'équipe construit alors le Sprint Backlog qui représente l'ensemble des fonctionnalités à réaliser pendant le Sprint. Chaque US est alors découpée en tâches techniques élémentaires qui seront à leur tour estimée. L'élaboration de cet artefact est le principal objectif de cette Réunion. Le PO peut y assister à titre consultatif.

Comment se déroule un Sprint ?

Le Sprint est l'étape de réalisation du projet SCRUM par excellence. Il peut durer de 2 semaines à 2 mois en fonction du contexte de projet et de sa complexité. Ceci dit il faut bien garder à l'esprit que le principe est de livrer à la fin du Sprint une première version du logiciel qui fonctionne incluant l'ensemble des fonctionnalités contenues dans le Sprint Backlog. Pendant le Sprint, tous les matins (de préférence), pendant 15 mins maximum, un Daily Scrum Meeting a lieu pour voir l'état d'avancement des tâches. Chacun doit répondre à trois questions: quelles sont la(les) tâche(s) terminée(s) la veille s'il y en a ? quelles sont la(les) tâche(s) du jour ? quels problèmes ont été rencontrés ? En cas de problème, le SM doit mettre en oeuvre des actions pour les résoudre au plus vite. Pendant toute la durée du Sprint, les résponsabilités suivantes sont attribuées:

  • le SM doit garantir que l'équipe n'est pas perturbée par des sollicitations extérieures. Il doit aussi garantir qu'elle a sa disposition tous les moyens pour travailler et faire avancer les différentes tâches.
  • le reste de l'équipe réalise concrètement chacune des tâches qu'il a indiqué effectuer pendant le Daily Scrum Meeting.

A quoi sert la Revue de Sprint et qui sont les acteurs présents ?

La Revue de Sprint sert principallement à faire une démonstration du produit réalisé pendant le Sprint. Ceci même si le produit n'impémente pas toutes les fonctionnalités ciblées dans le Product Backlog. En ce basant sur ce dernier comme support, l'objectif est de montrer les fonctionnalités terminées à 100%, les fameuses User Stories afin de déterminer celles qui sont achevées. Dans l'idéal, c'est au PO de faire cette démonstration mais n'importe quel membre de l'équipe pourra la faire. Dans tous les cas, l'équipe doit être présente afin d'écouter, en direct, les remontées de l'assistance et d'intéragir avec elle. Il faudra veiller à bien préparer la démonstration avant que le public n'arrive. Ceci afin d'éviter les temps d'attente trop long avant le début de la démonstration. Celle-ci est destinée à un public parfois extérieur au projet, il faudra donc bien expliquer son contexte, celui de la démonstration, les données utilisées (données les plus explicites possibles), les fonctionnalités implémentées, etc... En cas de bug ou de problème lors de la démonstration, il faut le dire explicitement, éviter les "ça marchait il y a 10 minutes". La transparence est une valeur importante de la Revue de Sprint. Elle permet aussi de voir les fonctionnalités qui marchent bien et celle qu'il faudra revoir pendant le Sprint suivant ou tout simplement abandonner à l'initiative du PO.

A quoi sert la Retrospective et qui sont les acteurs présents ?

A la fin du Sprint, l'équipe dans son ensemble se réunit avec les développeurs, le SM, le PO et même le client. Cette réunion permet de faire un point sur le Sprint qui vient de se dérouler dans sa globalité. Les éléments suivants sont discutés:

  • ce qui s'est bien passé pendant le Sprint,
  • ce qui ne n'est pas bien passé et qu'il faudra améliorer:mettre en place un plan d'actions à la charge de l'équipe à suivre pour cette amélioration,
  • ce qui reste de l'ordre de l'inconnu.

Cette réunion est un axe d'amélioration important pour l'équipe toujours dans le but de satisfaire au mieux, non seulement, les exigences du client mais aussi le travail de l'équipe elle-même.

Lire la suite

Ma compréhension de SCRUM: les fondamentaux

3 Novembre 2011 , Rédigé par benkirane Publié dans #La gestion de projets

J'ai participé la semaine dernière à une formation de 2 jours sur SCRUM. Ne pouvant mettre en pratique tout de suite mon apprentissage, je me suis dis qu'il serait intéressant d'en faire quelques billets qui résument ma comprehension de SCRUM. Les deux premiers présenteront les aspects théoriques de SCRUM avec un premier billet sur les fondamentaux de SCRUM et un second sur le déroulement d'un projet SCRUM. Les billets qui suivront seront plus axés sur ma vision de SCRUM dans la pratique.

Qu'est ce que SCRUM ?

SCRUM est un framework qui décrit un ensemble d'acteurs et leur rôle, d'artefacts (les inputs et outputs de projet) et de time-boxes (événements à durée fixe). Ceci dans le but de mettre en oeuvre, de manière itérative et incrémentale, un projet complexe (informatique ou pas) dans des les meilleurs délais avec la meilleure satisfaction du client puisque la priorité est donnée à ce qui a le plus de valeur pour lui. Dans la suite, je décrirais les différents éléments qui le compose principalement pour des projets informatiques.

A qui s'adresse SCRUM ?

SCRUM est composé de plusieurs principes dont je ferais la liste plus tard dans ce billet. L'un de ces principes est qu'une équipe SCRUM doit s'auto-organiser pour gérer un projet. J'en ai conclu qu'il faut que les personnes qui participent à une équipe SCRUM doivent avoir une certaine expérience en développement. Je dirais au moins 2/3 ans. Dans le cas contraire, une auto-organisation prendrait beaucoup trop de temps ainsi que la prise de décision. Une équipe SCRUM a une taille idéale de 7 personnes +- 2. Je dirais qu'à partir de 5 personnes pour des projets de taille raisonnable, on peut inclure un seul développeur junior. Celui-ci commencerait le projet par du peer-programming (programmation à 2) dans le but de monter en compétences et connaître les bonnes pratiques rapidement.

Quels sont les acteurs d'un projet SCRUM et leurs rôles?

Les acteurs principaux d'un projet réalisé en SCRUM sont le client et l'équipe SCRUM. Le client ou son représentant est appelé Product Owner (PO). Il a la charge de la mise en oeuvre des besoins du client et de leur priorisation. L'équipe SCRUM est elle composée d'un capitaine de navire qu'est le Scrum Master (SM) et des autres membres de l'équipe, les développeurs, les acteurs principaux. Comme au Rugby dont Scrum tire son nom (mêlée en français), la réussite d'un projet SCRUM est liée, essentiellement, à la performance de l'équipe. C'est l'une des raisons qui me poussent à dire qu'elle doit avoir, de manière globale, une certaine expérience en développements. Le SM a la résponsabilité de l'avancement du projet, de sa qualité et est un pare-feu entre l'équipe et son environnement (principalement le client). Il doit faire en sorte que l'équipe ne soit pas parasitée par autre chose que la réalisation des tâches qui lui incombe. C'est un facilitateur et un animateur. Enfin, l'équipe est responsable des estimations de charges, de la réalisation du projet et de sa propre amélioration dans son efficacité et la qualité de ses développements.

Quelles sont les valeurs de SCRUM?

SCRUM est basé sur une ligne directrice qu'il faut toujours concervée à l'esprit. C'est le Manifeste Agile qui est composé des quatre valeurs suivantes:

  • privilégier les Individus et leurs interactions,
  • privilégier la collaboration avec le client,
  • privilégier la disponibilité immédiate des logiciels,
  • privilégier la réactivité face aux changements.

En résumé, SCRUM ce sont des individus qui travaillent ensemble pour rendre un service, rapidement disponible et très changeant, au client.

Quels sont les principes de SCRUM?

Des valeurs de SCRUM découlent 12 principes qui font les fondements de ce framework:

  1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  2. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  4. Les experts métier et les développeurs doivent collaborer quotidiennement au projet.
  5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  6. La méthode la plus efficace pour transmettre l'information est une conversation en face à face.
  7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  8. Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
  10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
  11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
  12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

De ma compréhension de SCRUM, l'agilité consiste à l'habilité de mettre en oeuvre tel ou tel principe en fonction du contexte du projets, des individus qui le composent, de l'environnement du client, du degré de maturité de l'agilité dans l'entreprise, ... Il faudroit voir cela comme un programme, basée sur une librairie, et qui fait appel à l'une ou l'autre de ses méthodes en fonction du besoin.

Que sont les artefacts dans SCRUM?

Les artefacts sont des éléments en entrée et en sortie d'un projet SCRUM. En entrée de la réalisation d'un projet SCRUM par une équipe, on aura ainsi les éléments suivants:

  • Le ProductBacklog (Panier de Produit): liste priorisée des fonctionnalités à réaliser. Celles-ci sont, généralement, appelées User Stories.
  • Le SprintBacklog (Panier de Sprint): User Stories à réaliser dans un Sprint découpées en tâches élémentaires.

En sortie, pour avoir une vue simple du reste à faire et du réalisé, on a :

  • Les BurnDown Charts: Représentation graphique très simple de l'état d'avancement du projet basé sur le Reste à faire.

Ci-dessous, un exemple de ce que peut être un Product Backlog: Exemple de Product Backlog

Qu'est ce qu'une User Story?

Une User Story (US) est une fonctionnalité qui, comme son nom l'indique, raconte une histoire. Celle-ci est sensée pouvoir être spécialisée à l'infini. Elle est décrite de la manière suivante: En tant qu'<acteur>, je peux <réaliser une fonctionnalité>.

Que sont les time-boxes?

Les time-boxes sont des événements à durée fixe qui ponctuent le déroulement d'un projet SCRUM. On en décompte 6:

  1. La Réunion de Planification de version (Release Planning),
  2. La Réunion de Planification du Sprint (Sprint Planning),
  3. La Réunion Quotidienne (Scrum Daily Meeting), aussi connue sous le nom de Stand-up meeting (car elle se fait debout généralement),
  4. Le Sprint,
  5. La Revue de Sprint (Sprint Review),
  6. La Rétrospective.
Lire la suite

La gestion de projets

16 Mars 2011 , Rédigé par benkirane Publié dans #La gestion de projets

Dans cette partie de mon blog, je rédigerais des articles en rapport avec la gestion de projets au quotidien. Par exemple, j'ajouterais des templates de documents qui me servent à faire des chiffrages de charge d'un projet ou tout élément publiable et nécessaire pour effectuer le travail d'un chef de projet au quotidien.

Lire la suite

Le modèle CMMI

4 Mars 2011 , Rédigé par benkirane Publié dans #La gestion de projets

Le modèle CMMI est un modèle de référence destiné à améliorer les processus informatiques dans une entreprise. Il permet de penser au futur des projets et de les industrialiser par la mise en place de bonnes pratiques. Il est d'autant plus important si l'entreprise qui le met en œuvre vend du service informatique au forfait.

Un des premiers leviers vers l'évolution du niveau CMMI d'une entreprise est la mise en place de modèles de projets, de documentations et de guides. Un modèle de projet peut-être, par exemple, la création d'un archetype Maven. Un modèle de documentation consiste en la création de templates. Ceux-ci doivent décrire ce que doit contenir chacun de leurs paragraphes. Les guides servent à expliquer comment mettre en oeuvre des bonnes pratiques en matière de tests (usine et integration), de normes de développement, etc... Une charte de développement peut aussi être rédigée. Elle doit être acceptée (voir signée) par l'ensemble des ingénieurs d'études et développement d'une équipe présent ou primo-arrivant. Tout ceci permet déjà d'atteindre le niveau 3 du modèle CMMI.

La quantification et l'optimisation de ces procédures peuvent alors être réfléchies après chaque projet afin de tendre vers les niveaux 4 et 5 de CMMI. Ces niveaux n'étant vraiment atteignable qu'à la suite des différentes expériences en gestion de projets d'une entreprise.

Pour plus d'informations sur ce modèle, vous pouvez vous rendre à l'adresse suivante: http://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration

Lire la suite