Agilité et SharePoint: Incompatible? On gage que non!

SharePoint Saturday Montréal

23 mai 2015


Agilité et SharePoint: Incompatible? On gage que non!Franck CornuSpécialiste SharePoint


Pla

tine

Or

Arg

ent

Bro

nze

Web

Merci à nos commanditaires !


Franck CornuSpécialiste SharePoint

Blog: http://thecollaborationcorner.com/Publication: « Réussir son analyse fonctionnelle SharePoint: Guide méthodologique »Twitter: @FranckCornu

http://thecollaborationcorner.com/

http://thecollaborationcorner.com/

http://thecollaborationcorner.com/?wpdmdl=11570

http://thecollaborationcorner.com/?wpdmdl=11570

https://twitter.com/FranckCornu

https://twitter.com/FranckCornu


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

L’agilité et SharePointIdées reçuesProcessus


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

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf


Comment nous l’appliquons

BACKLOG GROOMING

DU BACKLOG SPRINTBACKLOG

USER STORY

s5

USER STORY

s3

USER STORY

s8

CONTRAINTE

2 semaines

SPRINT REVIEW

SPRINT BACKLOG

DAILY SCRUM

SPRINTPRODUCT

BACKLOGGROOMING

2h-4h

SPRINTPLANNING

2h-4h

TESTS

1 Semaine

2h-4h

SPRINTREVIEW

1h – 2h

SPRINTRETRO


• 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


L’agilité, d’abord une philosophie

Démarrer un projet agileLa phase de démarrageL'art de la storyEstimation


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


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)


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 »

Dans la pratique, les entreprises doivent débloquer des budgets avant la réalisation de leurs projets…

MAIS

Budget

PérimètreDate


Recette d’un backlog de projetQuoi? Avec qui?


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)


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


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!


Schéma typique d’une user storyQuid de la granularité?

Story ≠Cas d’utilisation !

Actions fondamentales (relation de précédence

inévitable)

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


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


Estimer une user storyQuel

Format?

En points et non en heures ou jours

Ordre de complexité relative entre les

stories

Comment?

Planning poker entre les membres de l’équipe de

développement

Établir un étalon

Quand?

Au démarrage de projet pour

l’estimation initiale globale

À chaque sprint planning

Qu’estime t-on?

Compliqué VS Complexe

Durée de réalisation

La prise en compte des contraintes

Quelques Règles

Le pointage 0 n’existe pas(« SharePoint le fait déjà » ou « Le code existe déjà »)

L’échelle de pointage est la même pour toutes les

équipes

Pointage trop haut = subdivision systématique

L’estimation d’une story ne peut dépasser la vélocité de

l’équipe…

Une story ne peut être implémentée dans deux

sprints différents.


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 sprintEffort 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

Se donner les moyens d’être agileSetupDéploiementsTests


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

+ +


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

SPRINTPRODUCT

TESTS

SPRINTREVIEW

SPRINTRETRO


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

https://github.com/pester/Pester


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

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é…

Merci! Questions?

SharePint !

Ce soir à 18h

Le Trèfle, 3971 Rue Ontario E

Agilité et SharePoint: Incompatible? On gage que non!

Software

Transcript of Agilité et SharePoint: Incompatible? On gage que non!