Reprendre un projet Drupal
Au programme
> Introduction
> Anatomie d’un projet Drupal
> Etablir l’état des lieux
> Définir une stratégie de reprise
> Appliquer le plan de reprise
Introduc)on	
  

Présenta)on	
  Core-­‐Techs	
  2012	
  
Project recovery
Un	
  projet	
  est	
  en	
  difficulté	
  et	
  nécessite	
  la	
  mise	
  en	
  place	
  d’une	
  
stratégie	
  de	
  reprise	
  (project	
  recovery)	
  si	
  :	
  
	
  
•  Le	
  budget,	
  le	
  périmètre	
  ou	
  le	
  planning	
  ne	
  sont	
  plus	
  tenables	
  
•  La	
  qualité	
  globale	
  n’est	
  pas	
  sa)sfaisante	
  
•  Les	
  aKentes	
  client	
  (ou	
  u)lisateur)	
  ne	
  peuvent	
  être	
  sa)sfaites	
  
Chiffres clés
Terminated	
  
Failed	
  
Recovered	
  

6%	
  
12%	
  

Zone	
  de	
  risque	
  
25%	
  

Successful	
  

37%	
  des	
  projets	
  nécessitent	
  la	
  mise	
  en	
  place	
  
d’un	
  stratégie	
  de	
  recovery	
  

47%	
  
Anatomie	
  d’un	
  projet	
  Drupal	
  

Présenta)on	
  Core-­‐Techs	
  2012	
  
Approche classique en « V »

• Chef	
  de	
  projet	
  
• Lead	
  technique	
  

• Lead	
  technique	
  
• Développeur	
  
• Chef	
  de	
  projet	
  

• Spécifica)ons	
  
fonc)onnelles	
  
• Graphisme	
  
• Planning	
  

• Code	
  source	
  
• Documenta)on	
  
technique	
  
• Forma)on	
  

• Applica)on	
  en	
  
produc)on	
  
La phase de conception
Définir	
  le	
  périmètre	
  fonc1onnel	
  et	
  
technique	
  du	
  projet	
  
Prototype	
  

•  Circuits	
  de	
  
naviga)on	
  
•  Ergonomie	
  

Chef	
  de	
  projet	
  

• Produit	
  les	
  livrables	
  de	
  concep)on	
  en	
  
collabora)on	
  avec	
  le	
  client	
  
• Planifie	
  le	
  développement	
  

Spécifica1ons	
  
fonc1onnelles	
  

•  Modèle	
  
•  Règles	
  de	
  ges)on	
  

Lead	
  technique	
  

• Evalue	
  les	
  impacts	
  techniques	
  
• Evalue	
  la	
  charge	
  
• Planifie	
  le	
  développement	
  

Créa1on	
  
graphique	
  

•  Iden)té	
  visuelle	
  
•  Ergonomie	
  
Les indispensables spécifications
fonctionnelles
• décrivent	
  exhaus)vement	
  le	
  
périmètre	
  fonc)onnel	
  
• d’elles	
  découlent	
  :	
  
• Le	
  découpage	
  projet	
  
• Les	
  scénarios	
  de	
  test	
  
• Le	
  cadre	
  contractuel	
  
• deviennent	
  la	
  bible	
  des	
  
développeurs	
  
Chef	
  de	
  projet	
  
Lead	
  technique	
  (support)	
  
La phase de développement
Implémenter	
  les	
  documents	
  de	
  
concep1on	
  
Lead	
  technique	
  

• Affecte	
  les	
  tâches	
  
• Suit	
  l’avancement	
  et	
  les	
  temps	
  des	
  
développeurs	
  
• Est	
  responsable	
  des	
  points	
  client	
  

Chef	
  de	
  projet	
  

• Effectue	
  les	
  receKes	
  internes	
  
• Est	
  responsable	
  de	
  la	
  rentabilité	
  

Développeur	
  

• Réalise	
  les	
  développements	
  
• Remonte	
  ses	
  temps	
  par	
  tâche	
  
La phase de développement
Le	
  document	
  d’architecture	
  
• Documente	
  la	
  structure	
  technique	
  
du	
  développement	
  
• Explique	
  let	
  liste	
  les	
  modules	
  
u)lisés	
  
• Sert	
  de	
  base	
  de	
  connaissance	
  au	
  
desk	
  de	
  TMA	
  

Lead	
  technique	
  
La phase de développement
Le	
  respects	
  des	
  bonnes	
  pra1ques	
  de	
  développement	
  Drupal	
  
• 	
  Ne	
  jamais	
  modifier	
  le	
  cœur	
  de	
  Drupal	
  ni	
  les	
  modules	
  communautaires	
  
• 	
  Eviter	
  les	
  paramètres	
  «	
  harcodés	
  »	
  
• 	
  Packager	
  les	
  paramétrages	
  et	
  les	
  objets	
  du	
  site	
  avec	
  le	
  module	
  Features	
  
• 	
  Ne	
  pas	
  «	
  réinventer	
  la	
  roue	
  »	
  et	
  chercher	
  des	
  solu)ons	
  dans	
  la	
  
communauté	
  
• 	
  Respecter	
  les	
  standards	
  de	
  qualité	
  de	
  code	
  
La phase de réception
Accompagner	
  l’équipe	
  cliente	
  dans	
  la	
  mise	
  
en	
  conformité	
  des	
  livrables	
  
Chef	
  de	
  projet	
  
• Organise	
  la	
  receKe	
  
• Qualifie	
  les	
  anomalies	
  
• Priorise	
  le	
  traitements	
  des	
  
anomalies	
  

Lead	
  technique	
  
• Organise	
  le	
  transfert	
  de	
  
compétence	
  de	
  l’équipe	
  de	
  
développement	
  à	
  l’équipe	
  de	
  TMA	
  
Nous	
  venons	
  de	
  décrire	
  le	
  meilleur	
  des	
  
mondes…	
  
	
  
Et	
  si	
  le	
  projet	
  déviait	
  de	
  sa	
  trajectoire	
  ini1ale?	
  
Etablir	
  l’état	
  des	
  lieux	
  

Présenta)on	
  Core-­‐Techs	
  2012	
  
Les causes les plus fréquentes
•  Spécifica1ons	
  fonc1onnelles	
  :	
  pas	
  assez	
  claires,	
  manque	
  d’adhésion,	
  ne	
  définit	
  
pas	
  les	
  priorités,	
  contradictoires,	
  ambiguës,	
  peu	
  précises	
  

•  Ressources	
  :	
  trop	
  peu	
  nombreuses,	
  conflits,	
  turnover	
  important,	
  mauvaise	
  
planifica)on	
  

•  Plans	
  de	
  charge	
  :	
  trop	
  serrés,	
  irréalistes,	
  trop	
  op)mistes	
  
•  Planning	
  :	
  n’intègre	
  pas	
  toutes	
  les	
  contraintes,	
  éléments	
  manquants,	
  mauvaises	
  
es)ma)ons	
  

•  Risques	
  :	
  non	
  iden)fiés	
  ou	
  non	
  adressés,	
  non	
  gérés	
  
Mener un audit
•  Fonc1onnel	
  :	
  Revue	
  du	
  périmètre	
  et	
  des	
  aKentes	
  de	
  l’équipe	
  cliente.	
  Analyse	
  de	
  
la	
  qualité	
  des	
  documents	
  de	
  concep)on	
  

•  Technique	
  :	
  Revue	
  de	
  code.	
  Analyse	
  de	
  la	
  qualité	
  des	
  développements	
  et	
  du	
  
respect	
  des	
  standards	
  Drupal	
  
Ne pas négliger le facteur humain
•  Difficulté	
  de	
  la	
  prise	
  de	
  responsabilité	
  par	
  les	
  acteurs	
  du	
  projet	
  :	
  jeu	
  de	
  
«	
  ping	
  pong	
  »	
  
•  Mener	
  l’audit	
  de	
  façon	
  objec)ve	
  et	
  dépassionnée	
  en	
  évitant	
  la	
  recherche	
  
systéma)que	
  de	
  responsabilités	
  
•  Sensibiliser	
  le	
  management	
  sur	
  la	
  nécessité	
  de	
  faire	
  face	
  à	
  la	
  réalité	
  et	
  de	
  
rechercher	
  des	
  solu)ons	
  pragma)ques	
  et	
  réalistes	
  è	
  Sor)r	
  du	
  
management	
  «	
  Débrouillez-­‐vous	
  pour	
  que	
  cela	
  fonc)onne	
  »	
  

Dans	
  un	
  contexte	
  de	
  project	
  recovery,	
  un	
  changement	
  de	
  
chef	
  de	
  projet	
  est	
  souvent	
  préconisé	
  
La « courbe d’amour »
Définir	
  une	
  stratégie	
  de	
  
reprise	
  

Présenta)on	
  Core-­‐Techs	
  2012	
  
Améliorer la communication
•  Interviewer	
  les	
  acteurs	
  du	
  projet	
  
•  Affirmer	
  le	
  leadership	
  du	
  chef	
  de	
  projet	
  
•  Désamorcer	
  les	
  conflits	
  personnels	
  ou	
  poli)ques	
  
•  Convaincre	
  de	
  la	
  faisabilité	
  de	
  la	
  reprise	
  
Revoir les périmètres
Redéfinir	
  avec	
  les	
  acteurs	
  du	
  projet	
  de	
  nouveaux	
  périmètres	
  en	
  termes	
  de	
  :	
  
•  Planning	
  
•  Budget	
  
•  Fonc)onnalités	
  

Dans	
  60%	
  des	
  cas,	
  une	
  diminuDon	
  du	
  périmètre	
  foncDonnel	
  
du	
  projet	
  est	
  préconisée	
  
Modifier le staffing des ressources
•  Iden)fier	
  les	
  ressources	
  nécessaires	
  
•  Définir	
  des	
  plans	
  de	
  charge	
  réalistes	
  pour	
  chaque	
  ressource	
  
•  Planifier	
  les	
  interven)ons	
  
Identifier l’urgent
•  Iden)fier	
  et	
  prioriser	
  les	
  éléments	
  les	
  plus	
  bloquants	
  
•  Iden)fier	
  les	
  difficultés	
  techniques	
  majeures	
  
Modifier le pilotage du projet
•  Changer	
  le	
  chef	
  de	
  projet	
  
	
  ou	
  revoir	
  son	
  posiDonnement	
  
•  Impliquer	
  un	
  consultant	
  spécialisé	
  pour	
  accompagner	
  la	
  phase	
  de	
  
recovery	
  

Pas	
  important	
  du	
  tout	
  
Pas	
  important	
  
Important	
  
Très	
  important	
  

1%	
  

Importance	
  du	
  chef	
  de	
  projet	
  
quant	
  à	
  la	
  réussite	
  de	
  la	
  
phase	
  de	
  recovery	
  

7%	
  
28%	
  
64%	
  
Appliquer	
  le	
  plan	
  de	
  reprise	
  

Présenta)on	
  Core-­‐Techs	
  2012	
  
Faire acter l’adoption du plan de
reprise
Recueillir	
  l’approba)on	
  de	
  l’ensemble	
  des	
  acteurs	
  du	
  projet	
  sur	
  l’intégralité	
  
du	
  plan	
  de	
  reprise	
  :	
  
	
  
•  Planning	
  
•  Budget	
  
•  Staffing	
  
•  Périmètre	
  fonc)onnel	
  
Les facteurs clés du succès
•  Posi)onner	
  un	
  chef	
  de	
  projet	
  expérimenté	
  et	
  sensibiliser	
  sur	
  les	
  
aspects	
  de	
  project	
  recovery	
  
•  Augmenter	
  la	
  surface	
  budgétaire	
  (et/ou	
  le	
  staffing	
  du	
  projet)	
  
•  Communiquer	
  en	
  clarifiant	
  les	
  aKentes	
  des	
  différents	
  acteurs	
  et	
  en	
  
reconstruisant	
  la	
  mo)va)on	
  des	
  acteurs	
  clés	
  du	
  projet	
  
•  Replanifier	
  intégralement	
  le	
  projet	
  
Mettre en place des outils de suivi
•  Définir	
  un	
  fréquence	
  de	
  réunion	
  de	
  suivi	
  physique	
  ou	
  téléphonique	
  
•  Tenir	
  un	
  tableau	
  de	
  bord	
  de	
  recovery	
  qui	
  informe	
  sur	
  :	
  
•  L’avancement	
  des	
  travaux	
  
•  La	
  tenue	
  des	
  objec)fs	
  
•  La	
  probabilité	
  de	
  réalisa)on	
  des	
  risques	
  iden)fiés	
  
•  Enrichir	
  le	
  référen)el	
  de	
  documenta)on	
  du	
  projet	
  
Fin de la phase de recovery
•  Analyser	
  si	
  les	
  nouveaux	
  objec)fs	
  sont	
  aKeints	
  
•  Garder	
  l’équipe	
  de	
  recovery	
  en	
  place	
  pendant	
  quelque	
  temps	
  pour	
  
monitorer	
  le	
  projet	
  
•  Effectuer	
  une	
  analyse	
  rétrospec)ve	
  de	
  la	
  phase	
  de	
  recovery	
  afin	
  
d’évaluer	
  l’impact	
  et	
  la	
  per)nence	
  des	
  ac)ons	
  menées.	
  
Merci	
  
	
  
Ques)ons?	
  

Louis	
  Sicard	
  –	
  Core-­‐Techs	
  
lsicard@core-­‐techs.fr	
  

Reprise projet Drupal Drupagora2013

  • 1.
  • 2.
    Au programme > Introduction >Anatomie d’un projet Drupal > Etablir l’état des lieux > Définir une stratégie de reprise > Appliquer le plan de reprise
  • 3.
  • 4.
    Project recovery Un  projet  est  en  difficulté  et  nécessite  la  mise  en  place  d’une   stratégie  de  reprise  (project  recovery)  si  :     •  Le  budget,  le  périmètre  ou  le  planning  ne  sont  plus  tenables   •  La  qualité  globale  n’est  pas  sa)sfaisante   •  Les  aKentes  client  (ou  u)lisateur)  ne  peuvent  être  sa)sfaites  
  • 5.
    Chiffres clés Terminated   Failed   Recovered   6%   12%   Zone  de  risque   25%   Successful   37%  des  projets  nécessitent  la  mise  en  place   d’un  stratégie  de  recovery   47%  
  • 6.
    Anatomie  d’un  projet  Drupal   Présenta)on  Core-­‐Techs  2012  
  • 7.
    Approche classique en« V » • Chef  de  projet   • Lead  technique   • Lead  technique   • Développeur   • Chef  de  projet   • Spécifica)ons   fonc)onnelles   • Graphisme   • Planning   • Code  source   • Documenta)on   technique   • Forma)on   • Applica)on  en   produc)on  
  • 8.
    La phase deconception Définir  le  périmètre  fonc1onnel  et   technique  du  projet   Prototype   •  Circuits  de   naviga)on   •  Ergonomie   Chef  de  projet   • Produit  les  livrables  de  concep)on  en   collabora)on  avec  le  client   • Planifie  le  développement   Spécifica1ons   fonc1onnelles   •  Modèle   •  Règles  de  ges)on   Lead  technique   • Evalue  les  impacts  techniques   • Evalue  la  charge   • Planifie  le  développement   Créa1on   graphique   •  Iden)té  visuelle   •  Ergonomie  
  • 9.
    Les indispensables spécifications fonctionnelles • décrivent  exhaus)vement  le   périmètre  fonc)onnel   • d’elles  découlent  :   • Le  découpage  projet   • Les  scénarios  de  test   • Le  cadre  contractuel   • deviennent  la  bible  des   développeurs   Chef  de  projet   Lead  technique  (support)  
  • 10.
    La phase dedéveloppement Implémenter  les  documents  de   concep1on   Lead  technique   • Affecte  les  tâches   • Suit  l’avancement  et  les  temps  des   développeurs   • Est  responsable  des  points  client   Chef  de  projet   • Effectue  les  receKes  internes   • Est  responsable  de  la  rentabilité   Développeur   • Réalise  les  développements   • Remonte  ses  temps  par  tâche  
  • 11.
    La phase dedéveloppement Le  document  d’architecture   • Documente  la  structure  technique   du  développement   • Explique  let  liste  les  modules   u)lisés   • Sert  de  base  de  connaissance  au   desk  de  TMA   Lead  technique  
  • 12.
    La phase dedéveloppement Le  respects  des  bonnes  pra1ques  de  développement  Drupal   •   Ne  jamais  modifier  le  cœur  de  Drupal  ni  les  modules  communautaires   •   Eviter  les  paramètres  «  harcodés  »   •   Packager  les  paramétrages  et  les  objets  du  site  avec  le  module  Features   •   Ne  pas  «  réinventer  la  roue  »  et  chercher  des  solu)ons  dans  la   communauté   •   Respecter  les  standards  de  qualité  de  code  
  • 13.
    La phase deréception Accompagner  l’équipe  cliente  dans  la  mise   en  conformité  des  livrables   Chef  de  projet   • Organise  la  receKe   • Qualifie  les  anomalies   • Priorise  le  traitements  des   anomalies   Lead  technique   • Organise  le  transfert  de   compétence  de  l’équipe  de   développement  à  l’équipe  de  TMA  
  • 14.
    Nous  venons  de  décrire  le  meilleur  des   mondes…     Et  si  le  projet  déviait  de  sa  trajectoire  ini1ale?  
  • 15.
    Etablir  l’état  des  lieux   Présenta)on  Core-­‐Techs  2012  
  • 16.
    Les causes lesplus fréquentes •  Spécifica1ons  fonc1onnelles  :  pas  assez  claires,  manque  d’adhésion,  ne  définit   pas  les  priorités,  contradictoires,  ambiguës,  peu  précises   •  Ressources  :  trop  peu  nombreuses,  conflits,  turnover  important,  mauvaise   planifica)on   •  Plans  de  charge  :  trop  serrés,  irréalistes,  trop  op)mistes   •  Planning  :  n’intègre  pas  toutes  les  contraintes,  éléments  manquants,  mauvaises   es)ma)ons   •  Risques  :  non  iden)fiés  ou  non  adressés,  non  gérés  
  • 17.
    Mener un audit • Fonc1onnel  :  Revue  du  périmètre  et  des  aKentes  de  l’équipe  cliente.  Analyse  de   la  qualité  des  documents  de  concep)on   •  Technique  :  Revue  de  code.  Analyse  de  la  qualité  des  développements  et  du   respect  des  standards  Drupal  
  • 18.
    Ne pas négligerle facteur humain •  Difficulté  de  la  prise  de  responsabilité  par  les  acteurs  du  projet  :  jeu  de   «  ping  pong  »   •  Mener  l’audit  de  façon  objec)ve  et  dépassionnée  en  évitant  la  recherche   systéma)que  de  responsabilités   •  Sensibiliser  le  management  sur  la  nécessité  de  faire  face  à  la  réalité  et  de   rechercher  des  solu)ons  pragma)ques  et  réalistes  è  Sor)r  du   management  «  Débrouillez-­‐vous  pour  que  cela  fonc)onne  »   Dans  un  contexte  de  project  recovery,  un  changement  de   chef  de  projet  est  souvent  préconisé  
  • 19.
    La « courbed’amour »
  • 20.
    Définir  une  stratégie  de   reprise   Présenta)on  Core-­‐Techs  2012  
  • 21.
    Améliorer la communication • Interviewer  les  acteurs  du  projet   •  Affirmer  le  leadership  du  chef  de  projet   •  Désamorcer  les  conflits  personnels  ou  poli)ques   •  Convaincre  de  la  faisabilité  de  la  reprise  
  • 22.
    Revoir les périmètres Redéfinir  avec  les  acteurs  du  projet  de  nouveaux  périmètres  en  termes  de  :   •  Planning   •  Budget   •  Fonc)onnalités   Dans  60%  des  cas,  une  diminuDon  du  périmètre  foncDonnel   du  projet  est  préconisée  
  • 23.
    Modifier le staffingdes ressources •  Iden)fier  les  ressources  nécessaires   •  Définir  des  plans  de  charge  réalistes  pour  chaque  ressource   •  Planifier  les  interven)ons  
  • 24.
    Identifier l’urgent •  Iden)fier  et  prioriser  les  éléments  les  plus  bloquants   •  Iden)fier  les  difficultés  techniques  majeures  
  • 25.
    Modifier le pilotagedu projet •  Changer  le  chef  de  projet    ou  revoir  son  posiDonnement   •  Impliquer  un  consultant  spécialisé  pour  accompagner  la  phase  de   recovery   Pas  important  du  tout   Pas  important   Important   Très  important   1%   Importance  du  chef  de  projet   quant  à  la  réussite  de  la   phase  de  recovery   7%   28%   64%  
  • 26.
    Appliquer  le  plan  de  reprise   Présenta)on  Core-­‐Techs  2012  
  • 27.
    Faire acter l’adoptiondu plan de reprise Recueillir  l’approba)on  de  l’ensemble  des  acteurs  du  projet  sur  l’intégralité   du  plan  de  reprise  :     •  Planning   •  Budget   •  Staffing   •  Périmètre  fonc)onnel  
  • 28.
    Les facteurs clésdu succès •  Posi)onner  un  chef  de  projet  expérimenté  et  sensibiliser  sur  les   aspects  de  project  recovery   •  Augmenter  la  surface  budgétaire  (et/ou  le  staffing  du  projet)   •  Communiquer  en  clarifiant  les  aKentes  des  différents  acteurs  et  en   reconstruisant  la  mo)va)on  des  acteurs  clés  du  projet   •  Replanifier  intégralement  le  projet  
  • 29.
    Mettre en placedes outils de suivi •  Définir  un  fréquence  de  réunion  de  suivi  physique  ou  téléphonique   •  Tenir  un  tableau  de  bord  de  recovery  qui  informe  sur  :   •  L’avancement  des  travaux   •  La  tenue  des  objec)fs   •  La  probabilité  de  réalisa)on  des  risques  iden)fiés   •  Enrichir  le  référen)el  de  documenta)on  du  projet  
  • 30.
    Fin de laphase de recovery •  Analyser  si  les  nouveaux  objec)fs  sont  aKeints   •  Garder  l’équipe  de  recovery  en  place  pendant  quelque  temps  pour   monitorer  le  projet   •  Effectuer  une  analyse  rétrospec)ve  de  la  phase  de  recovery  afin   d’évaluer  l’impact  et  la  per)nence  des  ac)ons  menées.  
  • 31.
    Merci     Ques)ons?   Louis  Sicard  –  Core-­‐Techs   lsicard@core-­‐techs.fr