Agilité et SharePoint: Incompatible? On gage que non!
-
Upload
franck-cornu -
Category
Software
-
view
2.299 -
download
0
Transcript of Agilité et SharePoint: Incompatible? On gage que non!
Online Conference
June 17th and 18th 2015
WWW.COLLAB365.EVENTS
Agilité et SharePoint: Incompatible? On gage que non!
Franck CornuGSoft
WWW.COLLAB365.EVENTS
Franck Cornu
Email : [email protected] : @FranckCornu
5 ans d’expérience avec SharePointSpécialisation en intranet/portail d’entrepriseAnalyse/Architecture/Développement
Blog: http://thecollaborationcorner.com/Publication: « Réussir son analyse fonctionnelle SharePoint: Guide méthodologique » (http://bit.ly/1GsrJwd)
Contact
Montréal, QC, Canada
WWW.COLLAB365.EVENTS
Plan de la sessionPartie 1: L’agilité et SharePoint
Partie 2: Démarrer un projet agile
Partie 3: Se donner les moyens d’être agile
WWW.COLLAB365.EVENTS
L’agilité et SharePointIdées reçuesProcessus
WWW.COLLAB365.EVENTS
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… »
WWW.COLLAB365.EVENTS
Comment nous l’appliquons
BACKLOG BACKLOGGROOMING
2h-4h
SPRINTPLANNING
2h-4h
SPRINT BACKLO
G
DAILY SCRU
M
SPRINT
2h-4h
SPRINTREVIEW
1h–2h
SPRINTRETRO PRODUCT
TESTS
1 Semaine
2 semaines
USER STORY 5
USER STORYUSER STORY
38
CONTRAINTE
WWW.COLLAB365.EVENTS
Idées reçues sur SharePoint et l’agile
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.
WWW.COLLAB365.EVENTS
L’agilité, d’abord une philosophie
WWW.COLLAB365.EVENTS
Démarrer un projet agileLa phase de démarrageL'art de la storyEstimation
WWW.COLLAB365.EVENTS
Démarrer un projet agile
Analyser les besoins et définir le backlog
Estimer les coûts de
développement
Contractualiser Développer la solution de
manière itérative
Livrer la solution
Comprendre SCRUM
Évaluer le besoin global
Définir le pourquoi du projet, sa vision et son
contexte
Définir le plan de livraison
Livrer la solutions selon le plan
WWW.COLLAB365.EVENTS
Exemple de démarrage de projet agile
Format2 à 3 jours consécutifs en mode « War Room » (5 à 6 personnes)Ateliers interactifs successifs
En sortieBacklog priorisé selon un plan de livraison
Information minimale nécessaire pour permettre une estimation réaliste
Charte de projetNom de projetVisionObjectifs d’affaires (S.M.A.R.T)ÉquipeVariables d’ajustementsÉvénements probables
Wireframes et maquettesEstimation selon la technologie cible (ici SharePoint)
WWW.COLLAB365.EVENTS
Quid de la contractualisation agileDans la théorie, le modèle de contractualisation d’un projet agile serait plutôt du type « paiement à l’utilisation » mais dans la pratique, les entreprises doivent débloquer des budgets avant la réalisation de leurs projets…
« Fixed bid » VS « Time & Materials »
Budget
PérimètreDate
WWW.COLLAB365.EVENTS
Recette d’un bon backlogUn backlog comprenant:
Des rôles ou profils (qui va utiliser l’application?)Des user stories (que vont-ils faire avec?)Des epics (quelles sont les grandes fonctionnalités du sytème?)Des contraintes (il y-a t-il des contraintes particulières à respecter?)
Les bonnes personnesUn product owner (pas TI)Des conseillersUn « Coach agile » ou analyste
WWW.COLLAB365.EVENTS
Définir ses storiesQuelques règles générales
Tout est une story! (technique, documentation, …) = Avant tout, on cherche une répartition optimale de la charge de travail = Unité de découpage du travailFormat « En tant que…je veux + action », pas de justificationIndépendant de toute technologie (particulièrement difficile à faire comprendre avec SharePoint)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 = Détermination de la fin d’un story = Plan de tests
« Lorsque je fait ça je m’attend à ça »« La fonctionnalité doit être disponible sur mobile »
Toutes les stories sont soumises à la DoD (« Definition of Done ») et/ou la DoR (« Definition of Ready »)Une story est différente d’un cas d’utilisation (explication juste après)
WWW.COLLAB365.EVENTS
Définir ses storiesGérer le syndrome SharePoint
Important de distinguer:Les tâches des stories (Exemple: « Créer une bibliothèque »)Les contraintes des stories (Exemple: « Implémenter l’interface mobile »)Le besoin du moyen («Exemple: « En tant qu’utilisateur je voudrais une bibliothèque pour stocker mes documents »)La fonctionnalité principale et ses éventuels « add-ons » INVEST (Indépendant)
Voir une liste de nouvellesAdd-ons:
Voir une liste de nouvelles sous forme carrousselVoir une liste de nouvelle en 3D sur une carte interactive (?!?!)
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
WWW.COLLAB365.EVENTS
Définir ses storiesOrientés rôles et responsabilités : les profils ≠ groupes de sécurité SharePoint !
Raisonnez au niveau métier!
WWW.COLLAB365.EVENTS
Un exemple de méthode
Story ≠Cas d’utilisation !
Actions fondamentales (relation de précédence
inévitable)
WWW.COLLAB365.EVENTS
Définir ses storiesComment 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
WWW.COLLAB365.EVENTS
La gestion des contraintesUne 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
WWW.COLLAB365.EVENTS
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.
WWW.COLLAB365.EVENTS
L’estimation: passer de l’abstrait à la réalité
Les variables fondamentales de calcul du coût de développement pour un projet agileLa vélocité (Évolue tout au long du projet!)La durée d’un sprintLe 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.Distinguer le coût de développement des coûts fixes ou semi fixes (maquettes, gestion de projet, déploiement, etc.)
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
WWW.COLLAB365.EVENTS
Se donner les moyens d’être agileSetupDéploiementsTests
WWW.COLLAB365.EVENTS
Les prérequis à l’agilité et SharePoint
La livraison de « valeur » comme leitmotivEnvironnement 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
+ +
WWW.COLLAB365.EVENTS
Les prérequis à l’agilité et SharePointLa gestion des déploiements
Objectif: livrer une solution fonctionnelle à la fin de chaque sprintGestion des différentiels en SharePoint (XML vs Code) ALM (SharePoint Online avec PnP)
DAILY SCRUM
SPRINT PRODUCT
TESTS
SPRINTREVIEW
SPRINTRETRO
WWW.COLLAB365.EVENTS
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)
• Intégration au serveur de build
WWW.COLLAB365.EVENTS
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 outilsPlus efficace lorsque c’est réalisé via l’approche TDDLong à s’exécuter (distinction « Slow/Fast »)Impossible de couvrir tous les cas
WWW.COLLAB365.EVENTS
En résumé…
Faire d’un projet SharePoint agile un succès
OUI MAIS
• Nécessite une volonté à tous les niveaux, pas qu’au niveau des développeurs.
• 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 la rigueur dans la définition des user stories et de leurs critères d’acceptations
• 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 ;)
Faire d’un projet SharePoint agile un succès
OUI MAIS
WWW.COLLAB365.EVENTS
Stay tuned for more great sessions …
Merci!