4. SharePoint Saturday
Montréal
Plan de la présentation
• Partie 1: L’agilité et SharePoint
• Partie 2: Démarrer un projet agile
• Partie 3: Se donner les moyens d’être agile
5.
6. SharePoint Saturday
Montréal
Petits rappels SCRUM
• « …cadre de travail permettant de répondre à des problèmes
complexes et changeants tout en livrant de manière productive et
créative des produits de la plus grande valeur possible… »
Scrum guide
7. SharePoint Saturday
Montréal
Comment nous l’appliquons
BACKLOG
GROOMING
DU BACKLOG SPRINT
BACKLOG
USER STORY 5
USER STORY 3
USER STORY 8
2 semaines
SPRINT
REVIEW
SPRINT
BACKLOG
DAILY
SCRUM
SPRINT
PRODUCT
BACKLOG
GROOMING
SPRINT
PLANNING
TESTS
SPRINT
REVIEW
SPRINT
RETRO
8. SharePoint Saturday
Montréal
• SCRUM et l’agilité, ce sont des trucs de développeurs ça, nous on parle business!
• SCRUM n’est pas une méthode de gestion de projet rigoureuse permettant un contrôle
précis des coûts. En gros, SCRUM = anarchie!
• Être agile, c’est tester souvent, or avec SharePoint ce n’est pas possible ou beaucoup trop
coûteux. L'investissement n’en vaut donc pas la peine.
• La plupart des fonctionnalités sont déjà "OOTB", c'est juste de la configuration et pas du
développement, pas la peine de découper ça en « story » car les besoins sont déjà
comblés par l’outil
• Les projets SharePoint sont trop liés à l'infrastructure et fait intervenir une multitude
d’équipes. La mise en place de l’agile est d’autant plus complexe.
• SCRUM n’est pas adapté à mon projet, car mon projet n’est pas un projet « classique » de
développement logiciel
• Projet de migration, gouvernance, sites de collaboration etc.
Idées reçues sur SharePoint et l’agile
11. SharePoint Saturday
Montréal
Démarrer un projet agile
Comprendre SCRUM Définir le pourquoi du
projet, sa vision et son
contexte
Évaluer le besoin
global
Analyser les
besoins et définir
le backlog
Définir le plan de
livraison
Estimer les coûts de
développement
Contractualiser Développer la solution
de manière itérative
Livrer les solutions
selon le plan
Livrer la solution
12. SharePoint Saturday
Montréal
Un démarrage de projet
• Format
• 2 à 3 jours consécutifs en mode « War Room » (5 à 6 personnes)
• Ateliers interactifs successifs
• En sortie
• Backlog priorisé selon un plan de livraison
• Information minimale nécessaire pour permettre une estimation réaliste
• Charte de projet
• Nom de projet
• Vision
• Objectifs d’affaires (S.M.A.R.T)
• Équipe
• Variables d’ajustements
• Événements probables
• Wireframes et maquettes
• Estimation selon la technologie cible (ici SharePoint)
13. SharePoint Saturday
Montréal
Quid de la contractualisation agile
Dans la théorie, le modèle de contractualisation d’un projet agile serait plutôt du type
« paiement à l’utilisation »
« Fixed bid » VS « Time & Materials »
MAIS
15. SharePoint Saturday
Montréal
Définir ses stories
• Quelques règles générales
• Tout est une story! (technique, documentation, …) = Avant tout, on cherche une répartition
optimale de la charge de travail!
• Format « En tant que…je veux + action », pas de justification
• Indépendant de toute technologie
• Critères I (Independant) N (Negotiable) V (Valuable) E (Estimable) S (Small) T (Testable)
• Obligation de critères d’acceptations = contrat entre le PO et l’équipe = Périmètre fonctionnel =
Plan de tests
• Toutes les stories sont soumises à la DoD (« Definition of Done ») et la DoR (« Definition of
Ready »)
• Une story est différente d’un cas d’utilisation (explication juste après)
16. SharePoint Saturday
Montréal
Définir ses stories
• Gérer le syndrome SharePoint
• Important de distinguer:
• Les tâches des stories
• Les contraintes des stories
• Le besoin du moyen
• La fonctionnalité principale et ses éventuels « add-ons » INVEST (Indépendant)
• Actions métier VS actions SharePoint: pas la peine de lister toutes les actions de bases de l’outil!
• « Créer une version de document », « Check-In », « Check-Out », etc..
Se gère en critères d’acceptations. Si trop gros, en faire une story à part (« Archiver un
document »)
• Savoir faire des compromis
17. SharePoint Saturday
Montréal
Définir ses stories
• Gérer le syndrome SharePoint
• Orientés rôles et responsabilités : les
profils ≠ groupes de sécurité
SharePoint !
Raisonnez au niveau métier!
19. Comment démarrer?
Énumérer les actions sous un format
libre (existantes et/ou souhaitées)
Identifier les profils/personnes/rôles
réalisant ces actions
Faire des regroupements en « Epics »
(thématiques fonctionnelles ou
métiers)
Appliquer le schéma typique
précédent pour déduire les stories
Avec quel outil?
User Story Mapping
Définir ses stories
20. SharePoint Saturday
Montréal
La gestion des contraintes
• Une contrainte est une particularité à prendre en compte lors de la réalisation
d’une story pour livrer une fonctionnalité finale.
• Savoir si une contrainte s’applique réellement sur
une story: « est-ce que il y a une tâche particulière
à faire pour répondre cette contrainte dans le
cadre de la story? »
• S’entendre sur la définition et la portée d’une
contrainte = critère d’acceptation pour chaque
contrainte
21. SharePoint Saturday
Montréal
Estimer une user story
Quel Format?
En points et non en heures
ou jours
Ordre de complexité relative
entre les stories
Comment? Quand? Qu’estime t-on? Quelques Règles
22. SharePoint Saturday
Montréal
L’estimation: passer de l’abstrait à la réalité
• Les variables fondamentales de calcul des coûts pour un projet agile
• La vélocité
• La durée d’un sprint
• Le taux horaire des différents intervenants
• Formule (très) théorique
• Toujours un sprint supplémentaire pour la correction et l’ajustement du
dernier sprint de développement.
Nombre de sprints = Nombre de points / Vélocité estimée par sprint
Effort de développement (heures ou jours) = (Nombre de sprints * Durée d'un sprint)
Coût de développement = Taux horaire * Durée de développement * Nombre d’intervenants
23.
24. SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• La livraison de « valeur » comme leitmotiv
Environnement technique approprié: avoir un setup de développement qui roule…!
Machines de développement SharePoint identiques (version SP et Visual Studio,
configuration, etc...)
Gestionnaire de code source (Git, TFS) + Outils de gestion de projet agile (JIRA, TFS)
Serveur de build (TeamCity): contrôle des versions et intégration du code +
outils de qualité (FxCop / StyleCop)
Versionning du code mutualisé (Nuget)
Déploiement entièrement automatisé de la solution (PowerShell) (tous
environnements confondus)
Nightly builds: Déploiement QA (Remote PS) Tests unitaires +Tests fonctionnels de non
régression
25. SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• La gestion des déploiements
• Objectif: livrer une solution fonctionnelle à la fin de chaque sprint
• Gestion des différentiels en SharePoint (XML vs Code) ALM
DAILY
SCRUM
SPRINT
PRODUCT
TESTS
SPRINT
REVIEW
SPRINT
RETRO
26. SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• Les tests avec SharePoint
Quoi tester?
› Tests unitaires: Framework, code
mutualisé, algorithmes métiers
› Tests fonctionnels: validation des
comportements à travers les critères
d’acceptations de la story
› Aucune valeur a simuler un contexte
SharePoint pour un test!
Comment?
› C#: Microsoft Fakes
› PowerShell: Pester (Lien) DÉMO
› Intégration au serveur de build
27. SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• De manière générale, les tests avec SharePoint, c’est…
• Couteux en temps et en apprentissage des outils
• Plus efficace lorsque c’est réalisé via l’approche TDD
• Long à s’exécuter (distinction « Slow/Fast »)
• Impossible de couvrir tous les cas
28. Faire d’un projet SharePoint agile un
succès
OUI MAIS
Nécessite une volonté à tous les niveaux
Nécessite une discipline d’abstraction des
possibilités de l’outil en lui-même pour se
concentrer sur les besoins réels.
Nécessite de savoir faire des compromis
Nécessite un setup et des processus de
développement (très) bien rodés
Impose un modèle de contractualisation
adapté
Sans Product Owner TI ;)
En résumé…
Notez bien que SCRUM n’est pas quelque chose qui s’applique à la lettre mais bel et bien un ensemble de pratiques et outils qui peuvent être adapté à de nombreuses réalités.
Concrètement SCRUM c’est:
Un cadre de travail qui peut être adapté bien au-delà d’un projet IT
Un mode de livraison incrémental qui met l’accent sur la valeur d’affaires
Un modèle de projection empirique laissant place aux changements de manière contrôlée et réfléchie.
L’agilité n’est pas seulement une affaire de développeurs. Elle s’applique du tout début d’un projet jusqu’à sa livraison. C’est d’ailleurs un gros facteur de succès.
Les échecs peuvent intervener à tout les niveaux, pas forcément que au niveau du développement.
La particularité des projets SharePoint est que l’on sait déjà que cela va se faire en SharePoint donc nous avons tendance à prendre beaucoup de choses pour acquises.
Votre pire ennemi: Un backlog porté par les TI ;)
Qui?
Idéalement des personnes connaissant le domaine d’affaires de la solution à développer. Pas de développeurs ni de personnes aux profils “technique”
L’analyse est faite dans les phases de grooming pour les stories qui suivent et non lors du démarrage de projet!
La particularité des projets SharePoint est que l’on sait déjà que cela va se faire en SharePoint
Mode de contractualisation « Fixed bid » + projet agile = Fail assuré
Le product owner ne devrait jamais être quelqu’un de TI…
Tout est une story avant tout pour permettre la repartition du travail dans les sprints.
Le plus difficile dans une story, c’est de savoir le moment ou elle se termine vraiment. On définit alors des critères d’acceptation qui sont un contrat entre le PO et l’équipe.
Critères INVEST
Independant = Correspond au découplage des fonctionnalités. Fortement lié avec la notion de « Valuable ». Avec SharePoint plus ou moins facile (Voir slide suivante pour la méthodologie de définition).
Testable = Critères d’acceptation qui décrivent le plan de test
Estimable/Small: Selon le pointage par l’équipe de développement.
Tout est une story avant tout pour permettre la repartition du travail dans les sprints.
Le plus difficile dans une story, c’est de savoir le moment ou elle se termine vraiment. On définit alors des critères d’acceptation qui sont un contrat entre le PO et l’équipe.
Consistance des stories: évitez les stories pas vraiment finie qui seront vraiment complétées une fois une autre terminée (genre il manque le branding qui viendra à la fin…)
Critères INVEST
Independant = Correspond au découplage des fonctionnalités. Fortement lié avec la notion de « Valuable ». Avec SharePoint plus ou moins facile (Voir slide suivante pour la méthodologie de définition).
Testable = Critères d’acceptation qui décrivent le plan de test
Estimable/Small: Selon le pointage par l’équipe de développement.
Tout est une story avant tout pour permettre la repartition du travail dans les sprints.
Le plus difficile dans une story, c’est de savoir le moment ou elle se termine vraiment. On définit alors des critères d’acceptation qui sont un contrat entre le PO et l’équipe.
Consistance des stories: évitez les stories pas vraiment finie qui seront vraiment complétées une fois une autre terminée (genre il manque le branding qui viendra à la fin…)
Critères INVEST
Independant = Correspond au découplage des fonctionnalités. Fortement lié avec la notion de « Valuable ». Avec SharePoint plus ou moins facile (Voir slide suivante pour la méthodologie de définition).
Testable = Critères d’acceptation qui décrivent le plan de test
Estimable/Small: Selon le pointage par l’équipe de développement.
Avec SharePoint la difficulté est de découpler les fonctionnalités pour en faire des stories réalistes sans trop rentrer dans le technique…
Quid de la granularité?
Séparation des opérations de création et de visualisation (mise en valeur des flux d’information).
Schéma représentant 90% des stories d’un projet informatique.
Création = Types de contenus, Colonnes,
Visualisation: Page Layouts, Master pages, Display Templates, ...
Une story est différente d’un cas d’utilisation classique. Pour faire le parallèle avec le cas d’utilisation, celui-ci serait un agrégation de toutes les actions possibles sur une information. La story elle est une action parmi le autres.
Exemple:
Nous gérons le « Branding » en tant que contrainte sur les stories plutôt que de faire une story technique « Design ».
Compliqué: un avion est compliqué dans sa finalité. En revanche, il peut êre subdivisé en une multitudes de sous systèms jusqu’au plus élémentaire (le boulon)
Complexe: qui ne peut être subdivisé en plus petit système (exemple un être humain)
Pas de formule magique pour la vélocité. Variable multi factorielle (compétences, nombre de développeurs, expérience, existant, etc…)
Perdre le moins de temps possible dans considérations qui n’apportent pas de valeur au client:
Mise en place des environnements de développement
Correction de bugs liés au setup, etc…
Les tests unitaires sont davantage utiles pour valider des algorithmes métier et valider une partie précise de la solution
Les tests fonctionnels (boite noire) valide un comportement sans se soucier de la solution en elle-même. Dans le cas d’agile, les tests fonctionnels sont utilisés pour valider une story au complet via ses critères d’acceptations. Ils permettent également de s’assurer de la non régression entre les sprints!
Les tests sont longs à éxécuter car ils interagissent directement avec le produit. Pour une meilleure isolation, il est impératif de reconstruire un nouvel environnement de tests “clean” à chaque fois (Site collection, site, etc).