Reprise projet Drupal Drupagora2013

1,169 views
972 views

Published on

Quelles que soient les raisons, vous pouvez être amené à changer d'équipe de prestataire de développement Drupal.
Retrouvez ici le support ayant servi lors de la conférence Drupagora (Reprise d'un projet Drupal).

Pour plus d'information retrouvez également la video de la conférence à cette adresse : http://www.youtube.com/watch?v=7qIZuBl7vcc#t=22

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,169
On SlideShare
0
From Embeds
0
Number of Embeds
149
Actions
Shares
0
Downloads
17
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Reprise projet Drupal Drupagora2013

  1. 1. Reprendre un projet Drupal
  2. 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. 3. Introduc)on   Présenta)on  Core-­‐Techs  2012  
  4. 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. 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. 6. Anatomie  d’un  projet  Drupal   Présenta)on  Core-­‐Techs  2012  
  7. 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. 8. 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  
  9. 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. 10. 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  
  11. 11. 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  
  12. 12. 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  
  13. 13. 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  
  14. 14. Nous  venons  de  décrire  le  meilleur  des   mondes…     Et  si  le  projet  déviait  de  sa  trajectoire  ini1ale?  
  15. 15. Etablir  l’état  des  lieux   Présenta)on  Core-­‐Techs  2012  
  16. 16. 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  
  17. 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. 18. 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é  
  19. 19. La « courbe d’amour »
  20. 20. Définir  une  stratégie  de   reprise   Présenta)on  Core-­‐Techs  2012  
  21. 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. 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. 23. 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  
  24. 24. Identifier l’urgent •  Iden)fier  et  prioriser  les  éléments  les  plus  bloquants   •  Iden)fier  les  difficultés  techniques  majeures  
  25. 25. 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%  
  26. 26. Appliquer  le  plan  de  reprise   Présenta)on  Core-­‐Techs  2012  
  27. 27. 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  
  28. 28. 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  
  29. 29. 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  
  30. 30. 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.  
  31. 31. Merci     Ques)ons?   Louis  Sicard  –  Core-­‐Techs   lsicard@core-­‐techs.fr  

×