Estimation de projets Drupal

Preview:

DESCRIPTION

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.

Citation preview

Business & Strategy · Maxime Topolov @mtopolov

Estimation de projets Drupalau forfait ou comment éviter de perdre

sa chemise

vendredi 6 décembre 13

Merci aux concurrents, clients et prospects de

quitter la salle ! ;-)

vendredi 6 décembre 13

100 Experts Drupal50 projets par an

@adyax

vendredi 6 décembre 13

Prévisions & Estimations

vendredi 6 décembre 13

vendredi 6 décembre 13

vendredi 6 décembre 13

vendredi 6 décembre 13

un projet de 4 taches

vendredi 6 décembre 13

vendredi 6 décembre 13

vendredi 6 décembre 13

vendredi 6 décembre 13

vendredi 6 décembre 13

"Some things are so unexpected that no one is

prepared for them."-- Leo Rosten

vendredi 6 décembre 13

Estimé par un “senior” développé

par un “junior”vendredi 6 décembre 13

Incompréhensions sur le périmètre

vendredi 6 décembre 13

Facteur humainvendredi 6 décembre 13

Que devons-nous estimer ?

vendredi 6 décembre 13

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.

COMPLEXITE DES SITES S1, S2 ET S3

vendredi 6 décembre 13

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

vendredi 6 décembre 13

INSTALLATION DE DRUPAL ET DES MODULES

S1 : 2 à 3 jours

S2 : 4 à 7 jours

S3 : 8 à 15 jours

vendredi 6 décembre 13

Quelques jours pour : Redmine,

Utilisateurs,Mailing lists,

etc...vendredi 6 décembre 13

PAGE TITLESURLS

ANALYTICS

AD

PANELS

MICRODATA

CONTEXTS

vendredi 6 décembre 13

SEO, URL, PAGE TITLES, ADS, ANALYTICS

S1 : 3 jours

S2 : 5 jours

S3 : 10 jours

vendredi 6 décembre 13

TEMPLATESvendredi 6 décembre 13

POURQUOI LES TEMPLATES SONT SI IMPORTANTS

Taches Heures F1 Heures F2 Heures F3

Sketching 1 2 4Wireframes & validation 2 4 8

Design 4 10 16HTML 3 6 16

Drupal templating* 8 12 16

TOTAUX 18 24 60* bullshit, les templates Drupal dépendent fortement des fonctionnalités

vendredi 6 décembre 13

Migration des données

vendredi 6 décembre 13

MIGRATION PAR TYPE DE CONTENU

Depuis Drupal : 1 jour

Depuis une BDD : 2-3 jours

Depuis HTML : enfer

vendredi 6 décembre 13

vendredi 6 décembre 13

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

Tests & QA

vendredi 6 décembre 13

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

Managementvendredi 6 décembre 13

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

Spécifications

vendredi 6 décembre 13

COMBIEN DE SPECS

S1 Jours S2 Jours S3 JoursTypes de contenus 2 4 7+Systèmes externes 0 3 10+

Workflow 0 1 5+Utilisateurs 0 2 5+

Back-office 1 3 5+

Front-end 3 5 15+SEO & Analytics 0,5 1 5+

Migration 0 4 15+Recherche 1 3 5+

vendredi 6 décembre 13

Attendez...vendredi 6 décembre 13

Fonctionnalitésvendredi 6 décembre 13

vendredi 6 décembre 13

AOsOrientés

User

vendredi 6 décembre 13

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

!

AOsWireframes

vendredi 6 décembre 13

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

AO Liste de fonctionnalités

vendredi 6 décembre 13

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

COSTS

vendredi 6 décembre 13

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

Comment éviter d’être le plus cher sur un AO

vendredi 6 décembre 13

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

Phase de build

vendredi 6 décembre 13

What's measured improves

vendredi 6 décembre 13

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

vendredi 6 décembre 13

PROJECT ‘BACKLOG’

Votre devis Votre projet

vendredi 6 décembre 13

SPRINT ‘BACKLOG’

vendredi 6 décembre 13

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

Credits & DebitsComment gérer les évolutions et garder un

client heureu

vendredi 6 décembre 13

CREDITS & DEBITS DOC

vendredi 6 décembre 13

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

The STOP day.vendredi 6 décembre 13

Recette sans fin...

vendredi 6 décembre 13

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

Support & Maintenance

vendredi 6 décembre 13

100 Drupal Experts50 projects per year

@adyax

vendredi 6 décembre 13