close

Se connecter

Se connecter avec OpenID

2015 - Franck Cornu - SharePoint et Agilité

IntégréTéléchargement
Agilité et SharePoint: Incompatible? On
gage que non!
SharePoint Saturday
Montréal
Franck Cornu
Spécialiste SharePoint
23 mai 2015
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éthodologique
@FranckCornu
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
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
SharePoint Saturday
Montréal
Comment nous l’appliquons
USER STORY
5
USER STORY
3
USER STORY
BACKLOG
BACKLOG
GROOMING
TESTS
8
GROOMING
SPRINT
DU BACKLOG
PLANNING
SPRINT
BACKLOGSPRINT
BACKLOG
DAILY
SCRUM
SPRINT
SPRINT
REVIEW
REVIEW
SPRINT
SPRINT
RETRO
PRODUCT
2 semaines
SharePoint Saturday
Montréal
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.
SharePoint Saturday
Montréal
L’agilité, d’abord une philosophie
SharePoint Saturday
Montréal
Démarrer un projet agile
Comprendre SCRUM
Évaluer le besoin Définir le pourquoi du
Analyser les
global
projet, sa vision et son besoins et définir
le backlog
contexte
Estimer les coûts de Contractualiser Développer la solution
développement
de manière itérative
Livrer
solution
Livrerlales
solutions
selon le plan
Définir le plan de
livraison
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)
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 »
MAIS
« Fixed bid » VS « Time & Materials »
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, 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)
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
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!
SharePoint Saturday
Montréal
Schéma typique d’une user story
Quid de la granularité?
SharePoint Saturday
Montréal
Définir ses stories
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
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
SharePoint Saturday
Montréal
Estimer une user story
Quel Format?
Comment?
Quand?
Qu’estime t-on?
Quelques Règles
En points et non en heures
ou jours
Ordre de complexité relative
entre les stories
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
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
•
Toujours un sprint supplémentaire pour la correction et l’ajustement du
dernier sprint de développement.
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
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
TESTS
DAILY
SCRUM
SPRINT
REVIEW
SPRINT
SPRINT
RETRO
PRODUCT
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
Comment?
› C#: Microsoft Fakes
› PowerShell: Pester (Lien) DÉMO
› Intégration au serveur de build
› Aucune valeur a simuler un contexte
SharePoint pour un test!
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
SharePoint Saturday
Montréal
En résumé…
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 ;)
SharePint !
Ce soir à 18h
Le Trèfle, 3971 Rue Ontario E
Auteur
Document
Catégorie
Uncategorized
Affichages
7
Taille du fichier
5 927 KB
Étiquettes
1/--Pages
signaler