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

Franck Cornu Spécialiste SharePoint Blog: http://thecollaborationcorner.com/ Publication: « Réussir son analyse fonctionnelle SharePoint: Guide méthodologique » Twitter: @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 SharePoint Idées reçues Processus Microsoft SharePoint Server 2013 L’agilité et SharePoint Idées reçues Processus © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 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… »  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. Scrum guide © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Comment nous l’appliquons Microsoft SharePoint Server 2013 Comment nous l’appliquons TESTS 1 Semaine USER STORY s 5 CONTRAINTE USER STORY s 3 USER STORY s 8 2 semaines BACKLOG DAILY SCRUM SPRINT PRODUCT BACKLOG GROOMING 2h-4h SPRINT PLANNING 2h-4h SPRINT BACKLOG 2h-4h SPRINT REVIEW 1h – 2h SPRINT RETRO GROOMING DU BACKLOG SPRINT REVIEW SPRINT BACKLOG © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Idées reçues sur SharePoint et l’agile Microsoft SharePoint Server 2013 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

L’agilité, d’abord une philosophie Microsoft SharePoint Server 2013 L’agilité, d’abord une philosophie 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Démarrer un projet agile La phase de démarrage L'art de la story Estimation

Démarrer un projet agile Microsoft SharePoint Server 2013 Démarrer un projet agile Définir le plan de livraison Analyser les besoins et définir le backlog Contractualiser Développer la solution de manière itérative Estimer les coûts de développement Évaluer le besoin global Définir le pourquoi du projet, sa vision et son contexte Comprendre SCRUM Livrer la solution Livrer les solutions selon le plan 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 ;) © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 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) 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 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Quid de la contractualisation agile Microsoft SharePoint Server 2013 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 » MAIS Dans la pratique, les entreprises doivent débloquer des budgets avant la réalisation de leurs projets… « Fixed bid  » VS « Time & Materials » Mode de contractualisation « Fixed bid » + projet agile = Fail assuré Budget Périmètre Date © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Recette d’un backlog de projet Microsoft SharePoint Server 2013 Recette d’un backlog de projet Quoi? Avec qui? Le product owner ne devrait jamais être quelqu’un de TI… © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 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) 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 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 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 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! 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Schéma typique d’une user story Quid de la granularité? Microsoft SharePoint Server 2013 Schéma typique d’une user story Quid de la granularité? Actions fondamentales (relation de précédence inévitable) 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. Story ≠Cas d’utilisation ! © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 Définir ses stories Avec quel outil?  User Story Mapping 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 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

La gestion des contraintes Microsoft SharePoint Server 2013 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 Exemple: Nous gérons le « Branding » en tant que contrainte sur les stories plutôt que de faire une story technique « Design ». © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 Estimer une user story Quel 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. 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) © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

L’estimation: passer de l’abstrait à la réalité Microsoft SharePoint Server 2013 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 Pas de formule magique pour la vélocité. Variable multi factorielle (compétences, nombre de développeurs, expérience, existant, etc…) © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Se donner les moyens d’être agile Setup Déploiements Tests

Les prérequis à l’agilité et SharePoint Microsoft SharePoint Server 2013 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) 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… 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 + © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Les prérequis à l’agilité et SharePoint Microsoft SharePoint Server 2013 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 TESTS DAILY SCRUM SPRINT PRODUCT SPRINT REVIEW SPRINT RETRO © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Les prérequis à l’agilité et SharePoint Microsoft SharePoint Server 2013 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 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! © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Les prérequis à l’agilité et SharePoint Microsoft SharePoint Server 2013 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 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). © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Microsoft SharePoint Server 2013 En résumé… 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 ;) Faire d’un projet SharePoint agile un succès OUI MAIS © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Merci!  Questions?