L'estimation des projets Drupal n'est pas plus simples ou plus complexe que celle des projets web en général. La gestion des projets au forfait est dangeureuse sur de gros projets et peut couter cher aux agences et SSII. Nous proposons de partager ici les points importants, metrics et outils que nous utilisons à Adyax pour l'estimation et la gestion des projets Drupal au forfait.

1. Estimation de projets Drupal
au forfait ou comment éviter de perdre
sa chemise
Business & Strategy · Maxime Topolov @mtopolov
vendredi 6 décembre 13

2. Merci aux concurrents,
clients et prospects de
quitter la salle ! ;-)
vendredi 6 décembre 13

3. 100 Experts Drupal
50 projets par an
@adyax
vendredi 6 décembre 13

4. Prévisions &
Estimations
vendredi 6 décembre 13

5. vendredi 6 décembre 13

6. vendredi 6 décembre 13

7. vendredi 6 décembre 13

8. un projet de 4
taches
vendredi 6 décembre 13

9. vendredi 6 décembre 13

10. vendredi 6 décembre 13

11. vendredi 6 décembre 13

12. vendredi 6 décembre 13

13. "Some things are so
unexpected that no one is
prepared for them."
-- Leo Rosten
vendredi 6 décembre 13

14. Estimé par un
“senior” développé
par un “junior”
vendredi 6 décembre 13

15. Incompréhensions sur le périmètre
vendredi 6 décembre 13

16. Facteur humain
vendredi 6 décembre 13

17. Que devons-nous
estimer ?
vendredi 6 décembre 13

18. COMPLEXITE DES SITES S1, S2 ET S3
S1 : Site simple : pas de trafic connecté, moins de 10 types de contenu,
moins de 20 templates, pas d’intégration de flux externes, pas ou peu
de workflow
S2 : Site moyen : des fonctionnalités utilisateur simples comme des
commentaires, vote, partages, de 10 à 20 types de contenu, quelques
intégrations simples en XML, un workflow et quelques régles métier,
migration simple des données
S3 : Site complexe : site transactionnel avec du fort trafic (e-commerce,
réseau social, intranet), plus de 20 types de contenu, plus de 50
templates, beaucoup de logiques métier et plusieurs sources de
données complexes, migration avancée de contenus non structurés.
vendredi 6 décembre 13

19. COMPLEXITE FRONT-END F1, F2 ET F3
F1 : Desktop uniquement. Site composé principalement de blocs avec
une structure simple, pas d’animations, pas trop de javascript. Pas
d’accessibilité, pas de support mobile, IE10+, Firefox, Chrome & Safari
uniquement
F2 : Front-end plus avancé, avec un support mobile pour certains
templates. Quelques animations JS. Accessibilité niveau bronze. IE8+ est
supporté. 2 dernières version de iOS et Android.
F3 : Responsive design sur toutes les pages avec 3 break-points.
Accessibilité argent ou or. Support de IE6 en mode dégradé. Responsive
testé sur iOS, Android, Windows Phone, UC Browser, Opera mini.
vendredi 6 décembre 13

20. vendredi 6 décembre 13

21. INSTALLATION DE DRUPAL ET DES MODULES
S1 : 2 à 3 jours
S2 : 4 à 7 jours
S3 : 8 à 15 jours
vendredi 6 décembre 13

22. Quelques jours pour :
Redmine,
Utilisateurs,
Mailing lists,
etc...
vendredi 6 décembre 13

23. PAGE TITLES
AD
URLS
CONTEXTS
PANELS
ANALYTICS
MICRODATA
vendredi 6 décembre 13

24. SEO, URL, PAGE TITLES, ADS, ANALYTICS
S1 : 3 jours
S2 : 5 jours
S3 : 10 jours
vendredi 6 décembre 13

25. TEMPLATES
vendredi 6 décembre 13

26. POURQUOI LES TEMPLATES SONT SI IMPORTANTS
Taches
Heures F1 Heures F2 Heures F3
Sketching
1
2
4
Wireframes & validation
2
4
8
Design
4
10
16
HTML
3
6
16
Drupal templating*
8
12
16
18
24
60
TOTAUX
* bullshit, les templates Drupal dépendent fortement des fonctionnalités
vendredi 6 décembre 13

27. Migration des données
vendredi 6 décembre 13

28. MIGRATION PAR TYPE DE CONTENU
Depuis Drupal : 1 jour
Depuis une BDD : 2-3 jours
Depuis HTML : enfer
vendredi 6 décembre 13

29. vendredi 6 décembre 13

30. CHAQUE DÉPLOIEMENT VOUS COUTE €€€
Drupal Clouds* : 0,5 jours
A la Capistrano : 1 jour
Old School : 3 jours
* Acquia Managed Cloud, Commerce
Platform, Pantheon
vendredi 6 décembre 13

31. Tests & QA
vendredi 6 décembre 13

32. COMBIEN TESTEZ-VOUS ?
S1 : 15% jours de dev
S2 : 20% jours de dev
S3 : 25 to 30% jours de devs
vendredi 6 décembre 13

33. Management
vendredi 6 décembre 13

34. COMBIEN DE TEMPS DE GESTION DE PROJET
S1 : 10% de jours dev+qa
S2 : 15% de jours dev+qa
S3 : 25% de jours dev+qa
vendredi 6 décembre 13

35. Spécifications
vendredi 6 décembre 13

36. COMBIEN DE SPECS
S1 Jours
Types de contenus
2
Systèmes externes
0
Workflow
0
S2 Jours
4
3
1
S3 Jours
7+
10+
5+
Utilisateurs
0
2
5+
Back-office
1
3
5+
3
0,5
0
1
5
1
4
3
15+
5+
15+
5+
Front-end
SEO & Analytics
Migration
Recherche
vendredi 6 décembre 13

37. Attendez...
vendredi 6 décembre 13

38. Fonctionnalités
vendredi 6 décembre 13

39. vendredi 6 décembre 13

40. AOs
Orientés
User
vendredi 6 décembre 13

41. APPELS D’OFFRES ORIENTÉS UTILISATEURS
Description détaillée des fonctionnalités...
...mais répartis sur plusieurs user stories.
Il faudra faire attention aux templates et à la structure du
site...
...ainsi qu’avec le SEO, Analytics, Contexts, etc...
vendredi 6 décembre 13

42. AOs
Wireframes
vendredi 6 décembre 13

43. APPELS D’OFFRES “WIREFRAMES”
Simple de compter les templates
Il faudra faire très attention aux règles métier (pourquoi ce
petit bloc apparait sur cette page en particulier) ainsi qu’au
back-office (ah il vous fallait un tableau de bord pour gérer
ça ?)
vendredi 6 décembre 13

44. AO Liste de
fonctionnalités
vendredi 6 décembre 13

45. APPELS D’OFFRES “LISTE AU PÈRE NOËL”
Simple de déduire les fonctionnalités
Il faut imaginer les templates, contextes et probablement
les fonctionnalités back-office ne seront pas décrites. C’est
le pire des appels d’offres...
vendredi 6 décembre 13

46. COSTS
vendredi 6 décembre 13

47. COUTS CACHES
Back-office : habillage et néttoyage
Workflow, notifications et permissions utilisateurs
WYSIYWG, CSS clean up
Optimisations et tuning d’architecture
vendredi 6 décembre 13

48. Comment éviter d’être le
plus cher sur un AO
vendredi 6 décembre 13

49. COMMENT EVITER D’ETRE LE PLUS CHER
Soyez très précis dans vos estimations. Décrivez précisement ce que
vous allez faire. Le nombre de lignes classiques : 20 (S1), 50 (S2) or 100
(S3)
Ajoutez autant d’options que possible
En cas de fonctionnalités pas claires, prenez l’hypothèse basse et
expliquez précisément ce que vous allez fabriquer.
...ou sous-estimez et faites un pari sur le run (stratégie dangereuse
utilisée par les grosses SSII qu’on ne va pas nommer :-)
vendredi 6 décembre 13

50. Phase de build
vendredi 6 décembre 13

51. What's measured
improves
vendredi 6 décembre 13

52. REDMINE & TIMELOGS
1 ligne dans votre devis = 1 super tache dans redmine
Chaque tache dans redmine doit être rattachée à une super-tache du
devis.
Forcez chacun à logger le temps passé (surtout les chefs de projet)
vendredi 6 décembre 13

53. vendredi 6 décembre 13

54. PROJECT ‘BACKLOG’
Votre devis
vendredi 6 décembre 13
Votre projet

55. SPRINT ‘BACKLOG’
vendredi 6 décembre 13

56. A RETENIR
Everybody chacun doit logguer son temps
Garder le lien entre votre devis et les bugs et taches du projet
Partagez vos estimations avec vos développeurs, intégrateurs et QA pour
qu’ils puissent vous avertir en cas de dépassement
Gardez la tete froide, surtout quand c’est la panique à bord (Ouais Ouais
je vais logger mon temps plus tard, je doit déployer un hot-fix là...)
vendredi 6 décembre 13

57. Credits & Debits
Comment gérer les évolutions et garder un
client heureu
vendredi 6 décembre 13

58. CREDITS & DEBITS DOC
vendredi 6 décembre 13

59. A RETENIR SUR LES EVOLUTIONS
Etre précis dans le devis initial rend l’acceptation des évolutions plus
simples.
Si possible n’envoyez pas plein de petits devis mais gardez une trace
centralisée de l’ensemble des évolutions..
Quand vous estimez une évolution, gardez en tête que le prix doit
inclure le temps de développement de l’évolution en soi et le temps
d’intégration de l’évolution sur un site existant (ce qui peut être plus
long que le développement de la fonctionnalité)
vendredi 6 décembre 13

60. The STOP day.
vendredi 6 décembre 13

61. Recette sans fin...
vendredi 6 décembre 13

62. COMMENT EVITER UNE RECETTE SANS FIN
Vous êtes agile, SCRUM, bla bla, vous avez toujours une recette finale.
La recette doit être définie dans le temps. Vous DEVEZ définir avec le
client une période précise de recette.
Quelques jours / semaines avec le début de la recette définissez avec le
client ce que sont les “blockers”
Expliquez au client ce qui se passe pendant la période de garantie.
Evitez de développer de nouvelles fonctionnalités non bloquantes
pendant la recette (code freeze rule)
vendredi 6 décembre 13

63. Support & Maintenance
vendredi 6 décembre 13

64. 100 Drupal Experts
50 projects per year
@adyax
vendredi 6 décembre 13