Successfully reported this slideshow.
SharePoint Saturday
Montréal
23 mai 2015
SharePoint Saturday
Montréal
Agilité et SharePoint: Incompatible? On
gage que non...
SharePoint Saturday
Montréal
Or
Argent
Bronze
Web
Merci à nos commanditaires !
SharePoint Saturday
Montréal
http://thecollaborationcorner.com/
Réussir son analyse fonctionnelle
SharePoint: Guide méthod...
SharePoint Saturday
Montréal
Plan de la présentation
• Partie 1: L’agilité et SharePoint
• Partie 2: Démarrer un projet ag...
SharePoint Saturday
Montréal
Petits rappels SCRUM
• « …cadre de travail permettant de répondre à des problèmes
complexes e...
SharePoint Saturday
Montréal
Comment nous l’appliquons
BACKLOG
GROOMING
DU BACKLOG SPRINT
BACKLOG
USER STORY 5
USER STORY ...
SharePoint Saturday
Montréal
• SCRUM et l’agilité, ce sont des trucs de développeurs ça, nous on parle business!
• SCRUM n...
SharePoint Saturday
Montréal
L’agilité, d’abord une philosophie
SharePoint Saturday
Montréal
Démarrer un projet agile
Comprendre SCRUM Définir le pourquoi du
projet, sa vision et son
con...
SharePoint Saturday
Montréal
Un démarrage de projet
• Format
• 2 à 3 jours consécutifs en mode « War Room » (5 à 6 personn...
SharePoint Saturday
Montréal
Quid de la contractualisation agile
Dans la théorie, le modèle de contractualisation d’un pro...
SharePoint Saturday
Montréal
Recette d’un backlog de projet
Quoi?
SharePoint Saturday
Montréal
Définir ses stories
• Quelques règles générales
• Tout est une story! (technique, documentati...
SharePoint Saturday
Montréal
Définir ses stories
• Gérer le syndrome SharePoint
• Important de distinguer:
• Les tâches de...
SharePoint Saturday
Montréal
Définir ses stories
• Gérer le syndrome SharePoint
• Orientés rôles et responsabilités : les
...
SharePoint Saturday
Montréal
Schéma typique d’une user story
Quid de la granularité?
Comment démarrer?
 Énumérer les actions sous un format
libre (existantes et/ou souhaitées)
 Identifier les profils/perso...
SharePoint Saturday
Montréal
La gestion des contraintes
• Une contrainte est une particularité à prendre en compte lors de...
SharePoint Saturday
Montréal
Estimer une user story
Quel Format?
En points et non en heures
ou jours
Ordre de complexité r...
SharePoint Saturday
Montréal
L’estimation: passer de l’abstrait à la réalité
• Les variables fondamentales de calcul des c...
SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• La livraison de « valeur » comme leitmotiv
 Enviro...
SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• La gestion des déploiements
• Objectif: livrer une ...
SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• Les tests avec SharePoint
Quoi tester?
› Tests unit...
SharePoint Saturday
Montréal
Les prérequis à l’agilité et SharePoint
• De manière générale, les tests avec SharePoint, c’e...
Faire d’un projet SharePoint agile un
succès
OUI MAIS
Nécessite une volonté à tous les niveaux
Nécessite une discipline d’...
SharePint !
Ce soir à 18h
Le Trèfle, 3971 Rue Ontario E
Agilité et SharePoint: Incompatible? On gage que non!
Agilité et SharePoint: Incompatible? On gage que non!
Agilité et SharePoint: Incompatible? On gage que non!
Agilité et SharePoint: Incompatible? On gage que non!
Prochain SlideShare
Chargement dans…5
×

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

827 vues

Publié le

Les choses à savoir avant de démarrer un projet SharePoint en mode agile.

Publié dans : Logiciels
  • Soyez le premier à commenter

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

  1. 1. SharePoint Saturday Montréal 23 mai 2015 SharePoint Saturday Montréal Agilité et SharePoint: Incompatible? On gage que non! Franck Cornu Spécialiste SharePoint
  2. 2. SharePoint Saturday Montréal Or Argent Bronze Web Merci à nos commanditaires !
  3. 3. SharePoint Saturday Montréal http://thecollaborationcorner.com/ Réussir son analyse fonctionnelle SharePoint: Guide méthodologique @FranckCornu
  4. 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. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. SharePoint Saturday Montréal L’agilité, d’abord une philosophie
  9. 9. 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
  10. 10. 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)
  11. 11. 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
  12. 12. SharePoint Saturday Montréal Recette d’un backlog de projet Quoi?
  13. 13. 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)
  14. 14. 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
  15. 15. 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!
  16. 16. SharePoint Saturday Montréal Schéma typique d’une user story Quid de la granularité?
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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é…
  26. 26. SharePint ! Ce soir à 18h Le Trèfle, 3971 Rue Ontario E

×