View
1.498
Download
3
Category
Preview:
Citation preview
Titre du slideCollaboration en équipe Produit
Partie 1 : Culture Projet versus Culture Produit
Les caractéristiques du projet ITLes projets IT se caractérisent aussi souvent par leurs échecsPour réussir, les projets IT doivent adopter des bonnes pratiquesAujourd’hui, les projets IT ont une obligation de réussiteLes pratiques Agiles à la rescousse des projets ITLa nécessaire évolution de la collaboration au sein des organisations ITPrincipes structurants d’une culture de collaboration autour du produitStructure-type d’une équipe produitPour aller plus loin
Alexandre Estela (alexandre@estela.fr) Université Paris DauphineManagement & coaching d’équipes Produit Cours MIDO M2 SITN
Titre du slide
Les caractéristiques du projet IT
Partie 1 – Diapositive 3
Un projet se caractérise par :
Un ou plusieurs objectifs (les livrables)
Une date de début et une date de fin
Des contraintes de moyens et de qualité
Norme ISO et AFNOR,s’appliquant
notamment aux projets IT de
développement logiciel
DEBUT FIN ESTIMEE FIN REELLE
Retard (ou
abandon)Exécution
Cadrage
(avant-projet)
Qu’il soit un succès ou un échec, tout projet est un processus UNIQUE.
Un projet IT se caractérise comme un projet au sens ISO
Partie 1 – Diapositive 4
Un projet IT se caractérise par un besoin et un produit cible
Client (demandeur)client interne ou externe,
directions métier, marketing, … Equipes projet
Expression du besoin
Déploiement des programmes
Utilisation du produit fini
(logiciel, site web, …)
Transformation du besoin en exigences
Rédaction des spécifications
Codage des programmesTest et Recette des
programmesUtilisateurs
Partie 1 – Diapositive 5
Un projet IT se caractérise par une multitude d’équipes
Multi-Métiers Multi-Sites
Multi-Cultures Multi-Expériences
Multi-Equipes
Partie 1 – Diapositive 6
Un projet IT se caractérise par une succession de phases
Phase Acteurs clés Livrables
Cadrage(avant-projet)
Client,Chef de projet
Liste des exigences,Planning,Estimation des coûts
Conception Concepteurs fonctionnels,Concepteurs techniques,Architectes
Spécifications fonctionnelles,Spécifications techniques,Dossier d’architecture
Développement Développeurs Programmes,Guides d’exploitation
Recette Testeurs Cahiers de recette,Procès-verbal de recette
Mise en production Exploitants Produit finalisé, testé et déployé
Suivi de la production(exploitation)
Exploitants
Utilisation UtilisateursMaintenance(corrective et évolutive)
Chef de projet, Concepteurs, Architectes,Développeurs,Testeurs,Exploitants
Exéc
utio
n du
Pr
ojet
Titre du slide
Les projets IT se caractérisent aussi souvent par leurs échecs
Partie 1 – Diapositive 8
Même le plus simple des projets IT peut échouer
http://projectcartoon.com
Partie 1 – Diapositive 9
Au final, entre 25% et 75% des projets IT sont concernés
Entre 25% et 75% * des projets IT réalisés sont considérés en échec, c’est-à-dire qu’ils sont concernés par au moins l’une des affirmations suivantes :
Livraison en retard
Dépassement des estimations de coût
Abandon en cours de développement ou de recette
* Les statistiques dépendent des domaines d’activité, de la taille des sociétés et du périmètre des projets IT, mais toutes les études rapportent en conclusion un nombre inquiétant d’échecs.Sources : Gartner, IBM, McKinsey, Standish Group, …
Partie 1 – Diapositive 10
Les raisons de l’échec sont connues à plusieurs niveaux
Métier Technologie
Organisation Humain
Mauvaise compréhension
Collaboration insuffisante
Manque d’engagement
Mauvaise spécification
Défaut de compétences
Choix technologiques
non adaptés
Adaptabilité insuffisante
Mauvaise estimation
Mauvaise utilisation de modèles et
d’outils
Partie 1 – Diapositive 11
Les symptômes des projets IT en échec sont reconnaissables
« Organisation en silos »
? ??
« Effet tunnel »
Si vous constatez ces symptômes, le projet est probablement en voie d’échec…
Titre du slide
Pour réussir, les projets IT doivent adopter des bonnes pratiques
Partie 1 – Diapositive 13
L’histoire des projets IT est riche en publications structurantes
1970 – Modèle en cascade (« waterfall »)1975 – Livre « The Mythical Man-Month »1980 – Modèle du Cycle en V
1986 – Première mention des principes de « Scrum »
1996 – Principes de XP (« Extreme programming ») et d’intégration continue1999 – Popularisation conjointe du modèle RUP et du langage UML
1994 – Livre « Design Patterns : Elements of Reusable OO Software »
2003 – Principes du « Lean Software Development »2001 – Manifeste Agile
1991 – Débuts du modèle CMMI pour les fournisseurs de logiciels1989 – Débuts du modèle ITIL pour le management du Système d’Information
2009 – Manifeste du « Software Craftsmanship »
Partie 1 – Diapositive 14
Modèles et outils sont indispensables à tout projet IT
Les modèles et outils de gestion et de suivi de projet augmentent significativement les chances de réussite du projet IT en se basant sur des bonnes pratiques issues de nombreux retours d’expérience :
Définition d’étapes du projet à dérouler de manière successiveUtilisation d’indicateurs pour le suiviUtilisation de logiciels de gestion de documents et sources du projetMise en place de rituels d’équipe et de comités projetMise en place de gouvernance et d’éléments transverses aux projets
Partie 1 – Diapositive 15
Ces modèles et outils s’inscrivent dans une stratégie IT globale
22
Stratégie ITRéférencement des modèles et outils des projets
Equipes métier
Equipes fonctionnelles
Equipes applicatives
Equipes infrastructure :: : : : :
Partie 1 – Diapositive 16
Ces modèles et outils sont promus par des autorités reconnues
Organismes de standardisation, éditeurs de logiciels ou bien sociétés de conseil, fournissent de la documentation, des formations et des certifications sur ces modèles et outils aux équipes des projets.
Les logos et illustrations sont la propriété de leurs détenteurs respectifs.
Partie 1 – Diapositive 17
Exemples pour définir les étapes, rôles, et indicateurs…
Développement
Spécifications détaillées
Spécifications générales
Exigences
Tests unitaires
Tests d’intégration
Recette
Modèle du Cycle en V
Matrice RACI
Client Chef de projet Concepteur DéveloppeurExigences R A C IConception I A R IDéveloppement I A C RTest I A C RRecette I A R C
Diagramme de Gantt
Partie 1 – Diapositive 18
…et exemples pour accroître la collaboration et la valeur
Modèle Scrum
Kanban board
Codesource
ProduitINTEGRATION AUTOMATISEE
Plateforme d’intégration
continue
Pratiques dites « Agiles » propagées dans les années 2000 :
Titre du slide
Aujourd’hui, les projets IT ont une obligation de réussite
Partie 1 – Diapositive 20
Baisse des budgets, explosion des besoins
2008 2010 2014
Explosion des besoins : e-commerce, mobile apps, Big Data, Internet of things…Baisse et stagnationdes budgetsdes projets IT
Partie 1 – Diapositive 21
Les clients exigent un retour sur l’investissement rapide
La crise économique dans un contexte de nouveaux usages technologiques, exige des équipes projet de « faire davantage avec moins de moyens ».
Les clients demandent des produits avec uniquement les fonctionnalités utiles, livrées pour moins cher et plus rapidement.
Les projets IT se sont donc focalisés sur des modes de travail privilégiant :
Une meilleure prise en compte des besoins réels du client et du marchéUne livraison accélérée de versions viables du produitUne amélioration du « time-to-market », c’est-à-dire la capacité à être réactif pour fournir des évolutions et des corrections du produitUne réduction des coûts des projets à travers la simplification des processus internes et du mode de fonctionnement des équipes
Titre du slide
Les pratiques Agiles à la rescousse des projets IT
Partie 1 – Diapositive 23
Les pratiques Agiles sont d’abord et surtout un Manifeste
4 préceptes du Manifeste Agile, février 2001 :Les individus et leurs interactions avant les processus et les outilsDu logiciel qui fonctionne avant une documentation exhaustiveLa collaboration avec les clients avant la négociation contractuelleL’adaptation au changement avant le suivi d’un plan
Les pratiques Agiles sont l’application de ces préceptes qui ont pour objectif, sans dépendance aucune à un modèle ou à un outil, d’apporter : 1. Plus de collaboration2. Plus de valeur au produit3. Plus de satisfaction au client4. Plus de réactivité
Partie 1 – Diapositive 24
Le modèle Scrum en fer de lance des pratiques Agiles
Stand-up meeting
Product Backlog
Sprint Planning Sprint (Itération)
Burndown chart
# User Story Story points
1En tant que client, je veux pouvoir trouver les voitures classées par prix
5
2En tant que client, je veux pouvoir voir la fiche détaillée d'une voiture
5
3 En tant que client, je veux pouvoir acheter une voiture 8
4En tant qu'administrateur, je veux pouvoir voir la liste des clients
3
Rétrospectives
Partie 1 – Diapositive 25
Les pratiques Agiles sont bien plus que des modèles et outils
Utiliser le modèle et les outils Scrum (ou Kanban, etc) ne signifie pas nécessairement travailler selon les préceptes du Manifeste Agile !
Partie 1 – Diapositive 26
Les pratiques Agiles doivent être maîtrisées et personnalisées
Bien choisir les initiatives qui conviennent au contexte du projet, de l’équipe et de l’organisation, en les adaptant si nécessaire, au risque de mettre en péril le projet !
Partie 1 – Diapositive 27
Dans le giron des pratiques Agiles : les pratiques Lean et XP
Lean XP (« Extreme Programming »)
Mesure de la valeur à travers le code
« Pair programming »Tests complets et systématiquesIntégration et livraison continueRefactoring et re-design continu
Outillage automatisé
« Pas de gaspillage »« Build – Mesure – Learn »Démarche Incrémentale
Indicateurs de performanceAmélioration continue
Vision d’ensemble
Valeurs et leviers de l’Agilité
Titre du slide
La nécessaire évolution de la collaboration dans les organisations IT
Partie 1 – Diapositive 29
La vraie Agilité requiert une organisation IT décomplexée
Agilité niveau 1 Agilité niveau 2
© P
okem
on
Pratiques Agiles reposant sur…Pyramides & silos
Participants dispersésResponsabilités isoléesProcessus segmentés
Equipe(s) projet
Pratiques Agiles reposant sur…Organisation horizontaleParticipants rapprochés
Responsabilités partagéesProcessus minimaux
Equipe produit
Partie 1 – Diapositive 30
L’organisation IT doit se remettre en cause continuellement
L’organisation et son écosystème
EntitésMétier,
Marketing,RH, Légal…
EntitésDesign,
Technique,Qualité…
Concurrence& Partenaires
Acheteurs & Utilisateurs
Quelle collaboration pour délivrer
le meilleur produit au jour
d’aujourd’hui ?Par
fonctionnalité ?Par expertise ?
Par localisation ?
Par affinité ?
Par influence ?
Partie 1 – Diapositive 31
Abattre les murs des équipes, toujours dans l’intérêt du produit
Au final, le produit peut être un logiciel commercialisé autant qu’un service de support
technique interne.
Partie 1 – Diapositive 32
Les « grands acteurs du numérique » montrent la voie
Les logos sont la propriété de leurs détenteurs respectifs.
Titre du slide
Principes d’une culture de collaboration autour du produit
Partie 1 – Diapositive 34
Culture Produit = Culture + Produit
CULTURE, nf (définition UNESCO) : ensemble des traits distinctifs, spirituels et matériels, intellectuels et affectifs, qui caractérisent un groupe social ou société.
PRODUIT, nm (définition e-marketing.fr) : objet matériel, service (…) conçu, créé et offert à la consommation dans le but de satisfaire un besoin identifié.
Chaque culture produit est unique en fonction du produit et de l’équipe.Grandes sources d’inspiration dans le cadre du développement logiciel :
Pratiques Agiles, Lean, XP« Design Thinking »« Lean Startup »« Feature Teams »
Partie 1 – Diapositive 35
Centrer les objectifs de l’équipe sur le produit (pas le projet)
Produitviable,
désirable etréalisable
Objectif de Business
Satisfaire un besoin réel avec un
modèle économique viable
Objectif d’Usage
Proposer une expérience
utilisateur (UX) tangible et unique
Objectif de Technologie
Choisir les langages et plateformes
adaptés et disponibles
(Design Thinking)
Partie 1 – Diapositive 36
Impulser de la créativité et tester ses hypothèses avec le client
Découverte
Interroger les clients et
comprendre les attentes
Définition du problème
Formuler le besoin de manière simple
Idéation
« Brainstormer » et imaginer
plusieurs solutions
Prototypage
Implémenter une solution répondant
au besoin
Validation
Obtenir du feedback sur la solution auprès
des clients
(Design Thinking)
Partie 1 – Diapositive 37
Itérer en mesurant et en apprenant continuellement
DELIVRER
Produit
MESURER
Données
APPRENDRE
Idées
(Lean Startup)
Partie 1 – Diapositive 38
Livrer continuellement des versions de qualité
Version SNAPSHOT
« Produit Minimum Viable »(MVP)
Version SNAPSHOT
« Release »
Version 2
Version SNAPSHOT
« Release »
Version 3
Livraison incrémentale avec assurance qualité
(Lean Startup)
Partie 1 – Diapositive 39
Communiquer de manière visuelle et transparente
A faire En cours Fait
Partager les points de blocage
Annoncer ce qui sera accompli
aujourd’hui
Rappeler ce qui a été accompli
hier
1 2 3
Partie 1 – Diapositive 40
Réunir les talents requis au sein d’une équipe pluridisciplinaire
Représentant UX Représentant
Business
ClientEquipe Produit
Représentant Architecture
Production
Utilisateurs
Non-participants
aux objectifs du produit : ils restent en-
dehors !
Développeurs
Concepteur
Testeur
Partie 1 – Diapositive 41
Forger l’identité et la confiance de l’équipe
Les photographies sont la propriété de leurs détenteurs
respectifs.
Partie 1 – Diapositive 42
En résumé, les 7 fondements d’une équipe produit sont…
1. L’objectif d’un produit « Viable, Désirable et Réalisable »2. La créativité couplée à la possibilité de valider des hypothèses3. Les itérations, la mesure avec des KPIs et l’amélioration
continue4. Les livraisons régulières d’incréments de valeur et de qualité5. La communication permanente, transparente et visuelle6. L’équipe pluridisciplinaire et auto-organisée7. La culture de l’équipe forgée par ses membres
Titre du slide
Structure-type d’une équipe produit
Partie 1 – Diapositive 44
La démarche historique : réalisation d’un produit en mode projet
Equipe des Concepteurs
Equipe des Développeur
sEquipe des
Testeurs
Equipe des « UX »
Equipe des Exploitants
Equipe des Architectes
Utilisateurs
Conception Développement Test Production
Coordination par le chef de projet
Partie 1 – Diapositive 45
Passage de N équipes projet à 1 équipe produit
Les rôles historiques gagnent en responsabilité et en
autonomie :
ConcepteurDéveloppeur
ExploitantArchitecte
Chef de projet« UX »Testeur
Utilisateur
De nouveaux rôles apparaissent pour faire croître
la culture recherchée :
« Product Manager »« Technical Leader »
Partie 1 – Diapositive 46
Des concepteurs qui se focalisent sur les spécifications utiles
Le concepteur décrit la solution pour satisfaire le besoin exprimé par le client : les spécifications fonctionnelles décrivent les fonctionnalités
attendues, tandis que les spécifications techniques décrivent leur implémentation.
Avant Maintenant
Fournit le minimum nécessaire pour permettre aux développeurs de commencer leur travail
Dispose d’un contact privilégié avec le client et/ou les utilisateurs afin de décrire uniquement ce qui est utile
Produit des spécifications qui ne sont pas toujours utiles, maintenables ou comprises par les développeurs
Ne dispose pas d’une proximité avec le client et a du mal à bien décrire la solution requise pour le besoin
Partie 1 – Diapositive 47
Des développeurs proactifs, rigoureux et communicants
Le développeur implémente techniquement la solution sur la base des spécifications fonctionnelles et techniques. Il réalise des morceaux
(« incréments ») du produit qu’il teste de manière unitaire.
Avant Maintenant
Est intéressé de comprendre en profondeur la finalité du produit
Fournit des incréments testés et de qualité (« Software Craftsmanship »)
Propose des idées pour améliorer techniquement le produit : performance, maintenabilité, …
Ne dispose pas d’une proximité avec les concepteurs pour poser librement ses questions sur les spécifications
Ne teste pas systématiquement les incréments de produit qu’il délivre
N’est pas dans une démarche d’amélioration du produit
Partie 1 – Diapositive 48
Des exploitants rapprochés pour une mise en production rapide
L’exploitant est responsable de la mise en production et du suivi quotidien du produit déployé auprès des utilisateurs. Il surveille les activités, et remonte les incidents aux équipes de développement
pour des corrections de bug.
Avant Maintenant
Est intégré à l’équipe de réalisation et communique en amont ses besoins de surveillance, monitoring, sécurité, …
Echange facilement avec les développeurs pour déployer et suivre en production des versions viables (organisation en « Devops »)
Ne participe quasiment pas à la conception technique ou à l’architecture de la solution
Intervient toujours en fin de projet
« Sanctuarise » les environnements de Production en limitant les accès, y compris pour l’identification des bugs
Partie 1 – Diapositive 49
Des architectes accessibles et proches du terrain
L’architecte est responsables des choix de couches et solutions applicatives,
de frameworks, d’infrastructure, de configuration logicielle… Ses choix peuvent concerner aussi bien la phase de développement que
la phase de production.
Avant Maintenant
Est intégré à N équipes produit Participe à la création et à la
croissance du squelette du produit
Fournit des recommandations en fonction des besoins du produit
Tend à se confondre avec le rôle de développeur sénior
Suit N équipes projet Fournit des exemples de code Fournit des recommandations
indépendamment de l’avancée produit
Est considéré plus important que le développeur (« Syndrome de la tour d’ivoire »)
Partie 1 – Diapositive 50
Un chef de projet qui va au-delà de la coordination
Le chef de projet est responsable de la coordination des différentes équipes intervenant sur un projet IT. Il tient à jour les plannings et autres tableaux de bord permettant de suivre l’avancée du projet.
Avant Maintenant
Joue le rôle de facilitateur en cas de blocage
Tend à voir ses responsabilités redispatchées au sein de l’équipe produit unifiée et auto-organisée, non pas sur une durée projet mais continuellement
Est l’interface entre les différentes équipes participant à un moment donné au projet
Informe le client sur l’avancée du projet et ses points de blocage
Partie 1 – Diapositive 51
Participation accrue des « UX », Testeurs et Utilisateurs
Le référent « UX » (pour « User eXperience ») a la responsabilité de formaliser les usages des produits par les utilisateurs. Il guide l’équipe
produit sur les parcours des utilisateurs, les interfaces utilisateur (« UI »), la maniabilité, l’ergonomie, la performance attendue, etc.
Le testeur est en charge de la définition et de l’exécution de différents types de test de « bout-en-bout ». Dans une équipe produit, ces
travaux se déroulement continuellement, et pas seulement une fois le produit « jugé terminé ». Les tests sont ainsi définis dés la conception
et utilisés en phase de développement.
Un panel d’utilisateurs accessible en permanence (ou une représentation des utilisateurs) est important pour une équipe produit car il permet de valider des hypothèses à n’importe quel moment, par exemple en effectuant des démonstrations, et pas seulement une fois
le produit « jugé terminé ».
Partie 1 – Diapositive 52
Le « Product Manager » comme nouveau représentant du produit
Le « Product Manager » est l’interface entre l’équipe Produit et les autres parties prenantes : client(s), RH, légal, marketing, finance, etc.
Il est responsable de la vision et la feuille de route du produit.
Dispose de la double vision de la stratégie produit et des contraintes de réalisation
Priorise les fonctionnalités à ajouter dans le produit, après négociation avec les autres parties prenantes et évaluation de la faisabilité avec l’équipe produit
Peut être assimilé au « Product Owner » du modèle Scrum
Est responsable de la performance du produit au travers d’indicateurs publics
Peut également être responsable de l’équipe produit (au sens RH)
Partie 1 – Diapositive 53
Le « Technical Leader » comme nouveau référent des développeurs
Le « Technical Leader » est le référent principal au sein de l’équipe produit sur les aspects techniques. Il s’agit d’un développeur sénior, responsable de la définition des bonnes pratiques de développement
et de livraison continue.
Définit les bonnes pratiques techniques (normes de codage, outillage de développement, processus de livraison, gestion des versions de produit, …)
Encadre et forme les développeurs, effectue des relectures de code
Est le responsable principal de la qualité et de la maintenabilité des sources
Il peut assumer les responsabilités de « Scrum Master » du modèle Scrum
Peut également être responsable des développeurs (au sens RH)
Partie 1 – Diapositive 54
Comment réaliser un produit avec une culture de collaboration
Utilisateurs(heureux !)
Conception Développement Test Production
Coordination par le « Product Manager » (ou un chef de projet)
Concepteurs
« UX »
Développeurs
« Technical Leader »(ou Architecte)
Panel d’utilisateurs
Testeurs
ExploitantsEquipe produit auto-organisée
Titre du slide
Pour aller plus loin
Partie 1 – Diapositive 56
Bibliographie
Marty Cagan, 2008, Inspired: How To Create Products Customers Love Eric Ries, 2011, The Lean Startup: How Today's Entrepreneurs Use
Continuous Innovation to Create Radically Successful Businesses Mike Cohn, 2009, Succeeding with Agile: Software Development Using
Scrum Gojko Adzic, 2012, Impact Mapping: Making a Big Impact with Software
Products and Projects Jeff Gothelf, 2013, Lean UX: Applying Lean Principles to Improve User
Experience
Recommended