• Aide
  • Eurêkoi Eurêkoi
Le Product Owner : maîtriser son rôle et ses missions
Livre Le Product Owner : maîtriser son rôle et ses missions

par Maillot, Edgard

ENI

-

  • Indisponible : En reliure

Livre

Le Product Owner : maîtriser son rôle et ses missions

Auteur(s) : Maillot, Edgard Découvrir l'auteur

Résumé

Une description du rôle du Product Owner, celui qui élabore sa vision du produit. L'auteur propose une méthode pour définir une stratégie et un plan opérationnel tout en stimulant la motivation de tous les acteurs d'une équipe agile. Les enjeux et les méthodes reposant sur le cadre de développement Scrum et le système SAFe sont expliqués. ©Electre 2024

  • Éditeur(s)
  • Date
    • 2024
  • Notes
    • Bibliogr. Glossaire. Index
  • Langues
    • Français
  • Description matérielle
    • 1 vol. (378 p.) : illustrations en noir et blanc ; 22 x 18 cm
  • Collections
  • Sujet(s)
  • ISBN
    • 978-2-409-04312-3
  • Indice
  • Quatrième de couverture

    • Le Product Owner

      Maîtriser son rôle et ses missions

      Dans une organisation agile, quel est le rôle exact du Product Owner ? Est-ce un chef de projet 2.0 ? Avec ce livre, l'auteur propose au lecteur de répondre à ces interrogations en décrivant ce métier de manière pragmatique. Il intéressera aussi bien les personnes souhaitant passer à l'agilité et devenir Product Owner que les Product Owners ou managers désireux de gérer plus efficacement le développement de leurs produits.

      Au fil des chapitres, le lecteur découvre ainsi comment ce véritable chef d'orchestre peut élaborer une vision du produit ainsi qu'une méthode permettant de définir une stratégie et un plan opérationnel faisant sens et nourrissant la motivation de tous les acteurs d'une équipe agile.

      La gestion du Backlog de produit est détaillée pour permettre d'en saisir les enjeux afin de s'adapter à un environnement évolutif tout en communiquant mieux grâce à des outils et des méthodes modernes.

      Enfin, un chapitre entier est dédié aux principales approches permettant au Product Owner de coordonner les efforts d'une ou plusieurs équipes. Scrum à l'échelle ou SAFe, les enjeux et implications de ces approches sont également décrits précisément afin d'être en mesure d'évoluer sereinement en tant que Product Owner dans différents types d'organisations.


  • Tables des matières

      • Le Product Owner

      • Maîtriser son rôle et ses missions

      • 2e édition

      • Éditions Eni

      • Chapitre 1
      • Le patron Scrum
      • 1. Les fondamentaux de Scrum15
      • 1.1 Introduction16
      • 1.1.1 Définition de Scrum17
      • 1.1.2 Théorie de Scrum18
      • 1.2 L'empirisme19
      • 1.3 La pensée Lean21
      • 1.3.1 Le modèle Shingo22
      • 1.3.2 Le modèle 3MU23
      • 1.3.3 Le modèle TIMWOOD(T)23
      • 1.4 Les rôles Scrum25
      • 1.4.1 Les Developers26
      • 1.4.2 Le Product Owner26
      • 1.4.3 Le Scrum Master28
      • 1.4.4 Les parties prenantes28
      • 1.4.5 Un mot sur les managers29
      • 1.5 Les évènements Scrum29
      • 1.5.1 Le Sprint29
      • 1.5.2 La planification de Sprint29
      • 1.5.3 L'objectif du Sprint31
      • 1.5.4 L'annulation du Sprint31
      • 1.5.5 Le Daily Scrum ou mêlée32
      • 1.5.6 La revue de Sprint32
      • 1.5.7 La rétrospective de Sprint34
      • 1.5.8 L'affinage du Backlog de produit35
      • 1.6 Les artefacts Scrum36
      • 1.6.1 Le Backlog de produit36
      • 1.6.2 Transparence du Backlog de produit37
      • 1.6.3 Le Backlog de Sprint38
      • 1.6.4 Transparence du Backlog de Sprint39
      • 1.6.5 L'incrément39
      • 1.6.6 Transparence et engagement de l'increment : la définition de « Fini »40
      • 1.7 Les piliers de Scrum41
      • 1.7.1 Transparence42
      • 1.7.2 Inspection43
      • 1.7.3 Adaptation45
      • 1.8 Les valeurs de Scrum46
      • 1.8.1 Focus47
      • 1.8.2 Ouverture48
      • 1.8.3 Respect49
      • 1.8.4 Courage49
      • 1.8.5 Engagement50
      • 1.9 Approfondir Scrum50
      • 2. Du projet au produit51
      • 2.1 Focus sur le produit52
      • 2.2 Le cycle itératif53
      • 2.3 Fin du diagramme de Gantt54
      • 2.4 La notion de valeur du produit54
      • 2.4.1 Impact de la valeur sur l'organisation55
      • 2.4.2 Calcul de la valeur55
      • Chapitre 2
      • Le métier de Product Owner
      • 1. Focus sur le rôle de Product Owner57
      • 1.1 Le Product Owner n'est pas un chef de projet57
      • 1.1.1 La responsabilité du Product Owner58
      • 1.1.2 De la vision projet à la vision produit58
      • 1.1.3 Les outils du Product Owner59
      • 1.2 Le Product Owner est un intrapreneur 60
      • 1.2.1 Le pouvoir du Product Owner62
      • 1.2.2 Les limites du Product Owner62
      • 1.3 Un manager atypique63
      • 1.3.1 La clarté des objectifs63
      • 1.3.2 L'ambiance au sein de l'équipe64
      • 1.3.3 La communication avec l'équipe65
      • 1.4 Le positionnement du Product Owner dans l'organisation65
      • 1.5 Le pilotage par la valeur66
      • 2. Focus sur le Backlog de produit67
      • 2.1 Définition du terme backlog70
      • 2.1.1 Étymologie70
      • 2.1.2 Du point de vue de Scrum70
      • 2.2 Une triple fonction.71
      • 2.2.1 Un outil de planification72
      • 2.2.2 Un outil d'organisation73
      • 2.2.3 Un outil de communication73
      • 2.3 Le Backlog, un répertoire unique74
      • 2.3.1 Le Backlog de produit est vivant74
      • 2.3.2 La durée de vie d'un Backlog de produit75
      • 2.3.3 Propriété du Backlog de produit75
      • 2.3.4 Pas de multiples Backlogs75
      • 2.3.5 Un Backlog d'une taille gérable77
      • 2.4 Un ordonnancement plus qu'une priorisation78
      • 2.4.1 Organiser en fonction de la valeur78
      • 2.4.2 Organiser dans le temps80
      • 2.4.3 Affiner à mesure81
      • 3. Les éléments du Backlog de produit82
      • 3.1 Les attributs des éléments83
      • 3.1.1 Les attributs essentiels83
      • 3.1.2 Les attributs récurrents84
      • 3.1.3 Utiliser d'autres attributs85
      • 3.2 Focus sur les attributs essentiels85
      • 3.2.1 Indicateur numérique86
      • 3.2.2 Une description86
      • 3.2.3 Une estimation88
      • 3.2.4 Une valeur90
      • 3.2.5 Un état92
      • 3.2.6 Affecter d'autres attributs94
      • 3.3 Créer des catégories96
      • 3.4 Maintenir une traçabilité97
      • 3.5 Lien fort ou lien faible98
      • 4. Focus sur la définition de « Fini »100
      • 4.1 Définition du guide Scrum101
      • 4.1.1 La définition de « Fini » est rédigée par les Developers102
      • 4.1.2 Elle s'applique au produit et à ses composants103
      • 4.2 Les vertus d'une définition de « Fini » claire104
      • 4.2.1 Les contraintes liées au produit105
      • 4.2.2 La définition de « Fini » impacte la capacité à délivrer106
      • 4.2.3 La définition de « Fini » clarifie le cadrage du produit107
      • 4.2.4 La définition de « Fini » évolue108
      • 4.2.5 Les évolutions de la définition de « Fini » se planifient110
      • 4.3 L'impact de la définition de « Fini » de la qualité logicielle112
      • 4.3.1 La qualité logicielle, un enjeu historique112
      • 4.3.2 L'impact d'une définition de « Fini » incomplète est d'ordre financier114
      • 4.3.3 L'agilité n'a pas permis de réduire significativement les coûts114
      • 4.4 L'implication du Product Owner dans la définition de « Fini »115
      • 4.4.1 Des critères d'acceptation à la définition de « Fini »116
      • 4.5 Convaincre les parties prenantes d'adopter une définition de « Fini » ambitieuse116
      • 4.5.1 Utiliser la rétrospective de Sprint117
      • 4.5.2 Utiliser la revue de Sprint117
      • 5. Focus sur la transparence118
      • 5.1 Définition118
      • 5.2 Les vertus de la transparence119
      • 5.3 L'effet de la transparence sur l'inspection et l'adaptation120
      • 5.3.1 Un exemple concret121
      • 5.3.2 Une controverse est une source d'inspection123
      • 5.4 Les effets d'une transparence complète ou incomplète123
      • Chapitre 3
      • Définir le produit
      • 1. La vision produit125
      • 1.1 La vision produit est la cible126
      • 1.2 Les trois principales typologies de produits127
      • 1.2.1 Un nouveau produit127
      • 1.2.2 Une évolution de produit128
      • 1.2.3 Une mise en conformité129
      • 1.3 Exemples de vision produit130
      • 1.3.1 Assurancetourix sous la contrainte RGPD130
      • 1.3.2 Roméo et ses masques130
      • 1.3.3 Siri131
      • 1.4 L'anticipation131
      • 1.4.1 L'anticipation rationnelle131
      • 1.4.2 L'anticipation émotionnelle132
      • 1.4.3 La nature de l'anticipation définit la communication132
      • 1.5 La vision est la rencontre du produit et du marché132
      • 1.5.1 Le cas Toyota134
      • 1.5.2 Le cas Haier134
      • 1.6 Co-construire la vision produit134
      • 2. La valeur du produit135
      • 2.1 Identifier les attributs de valeur136
      • 2.1.1 Le délai136
      • 2.1.2 La qualité137
      • 2.1.3 La fréquence137
      • 2.1.4 La récurrence137
      • 2.1.5 D'autres indicateurs137
      • 2.2 Identifier les objectifs et les contraintes138
      • 2.2.1 Qualifier les objectifs SMART139
      • 2.2.2 Exemple de référentiel d'exigences140
      • 3. Structurer le produit142
      • 3.1 La méthode descendante142
      • 3.1.1 Identifier les objectifs de base142
      • 3.1.2 Identifier les moyens143
      • 3.1.3 -Identifier les exigences143
      • 3.2 La méthode montante145
      • 3.3 Structurer le référentiel d'exigences146
      • 3.3.1 Prioriser les objectifs146
      • 3.3.2 Compter les liens des exigences147
      • 3.3.3 Organiser le référentiel d'exigences147
      • 3.3.4 Des exigences aux User Stories149
      • 4. Rédiger des critères d'acceptation149
      • 4.1 Rappel des rôles149
      • 4.2 Les critères d'acceptation basés sur les contraintes150
      • 4.2.1 Les contraintes métier151
      • 4.2.2 Les contraintes légales152
      • 4.2.3 Les contraintes techniques152
      • 4.2.4 Les contraintes fonctionnelles153
      • 4.3 Les critères d'acceptation basés sur l'usage153
      • 4.3.1 La syntaxe Gherkin154
      • 4.3.2 Cucumber156
      • 4.4 Le volume des critères d'acceptation156
      • Chapitre 4
      • De la stratégie au plan opérationnel
      • 1. Établir une stratégie produit159
      • 1.1 Les spécificités d'une stratégie produit dans un cycle itératif et incrémental160
      • 1.2 Exemple de stratégie produit160
      • 1.3 Utiliser les objectifs pour raconter l'histoire du produit163
      • 1.4 La stratégie s'inscrit dans le temps163
      • 1.4.1 Stratégie basée sur un cycle itératif et incrémental164
      • 1.4.2 La stratégie itérative implique de découper le produit165
      • 1.4.3 Ordonnancement basé sur la valeur167
      • 1.4.4 Ordonnancement basé sur les risques168
      • 1.4.5 Le MVP168
      • 1.5 La stratégie produit suppose des moyens168
      • 1.6 Les besoins des utilisateurs du produit169
      • 1.7 Maintenir le référentiel d'exigences170
      • 1.7.1 Qualifier les exigences171
      • 1.7.2 Initialiser le Backlog de produit171
      • 1.8 Valider sa stratégie172
      • 1.8.1 Vérifier les objectifs172
      • 1.8.2 Vérifier la cohérence des exigences173
      • 1.8.3 Ordonnancer les objectifs173
      • 1.9 Concrètement173
      • 1.10 Les SPOFs174
      • 2. Un plan opérationnel175
      • 2.1 Une vision à long terme175
      • 2.2 La planification de release176
      • 2.2.1 La contrainte de délai176
      • 2.2.2 La contrainte de coût177
      • 2.2.3 L'objectif d'efficience178
      • 2.2.4 L'intranet de Marie180
      • 2.2.5 Partager avec les parties prenantes181
      • 2.2.6 Partager avec l'équipe181
      • 2.3 Une vision à court terme132
      • 2.3.1 Rester focalisé sur les objectifs182
      • 2.3.2 Le plan de Marie vu par l'équipe182
      • 2.3.3 Déléguer à la Scrum Team184
      • 2.4 Planification agile185
      • 2.4.1 Planifier en fonction du produit185
      • 2.4.2 Inspecter et adapter185
      • 3. Affiner sa vision par rapport à la valeur du produit186
      • 3.1 Les gains du produit186
      • 3.1.1 À court terme186
      • 3.1.2 À long terme187
      • 3.2 Les coûts du produit187
      • 3.2.1 Les coûts de réalisation187
      • 3.2.2 Les coûts de maintenance188
      • 3.3 Identifier les bénéfices par thématique189
      • 3.3.1 Bénéfices directs ou financiers189
      • 3.3.2 Bénéfices de support, d'image ou de confort189
      • 3.3.3 L'exemple de Marie190
      • Chapitre 5
      • Gérer le Backlog de produit
      • 1. Organiser le Backlog de produit191
      • 1.1 Organiser en fonction de la valeur193
      • 1.1.1 La valeur liée aux gains194
      • 1.1.2 La valeur liée aux coûts194
      • 1.1.3 La valeur liée aux délais194
      • 1.1.4 La valeur liée à des objectifs ou contraintes secondaires194
      • 1.1.5 La valeur de quel point de vue ?195
      • 1.2 Organiser en fonction de la complexité195
      • 1.2.1 La complexité de mise en oeuvre196
      • 1.2.2 La complexité d'exploitation196
      • 1.3 Organiser en fonction de la prise de risque197
      • 1.4 Organiser selon d'autres critères198
      • 1.5 L'organisation du Backlog de Marie198
      • 2. Affiner le Backlog de produit199
      • 2.1 Rappel du principe itératif199
      • 2.2 Définition de l'affinage ...201
      • 2.2.1 Par où commencer l'affinage ?202
      • 2.2.2 Qui participe à l'affinage du Backlog de produit ?203
      • 2.2.3 Quand faut-il affiner le Backlog de produit ?204
      • 2.2.4 Jusqu'à quel niveau affiner ?204
      • 2.3 La règle des 10 %205
      • 2.4 Découper les éléments207
      • 2.5 Découpage vertical ou horizontal207
      • 2.6 Affiner les descriptions209
      • 2.7 Affiner les autres attributs210
      • 2.7.1 La valeur211
      • 2.7.2 La complexité212
      • 2.7.3 Le risque213
      • 2.8 Affinage et transparence213
      • 2.8.1 La règle des trois C214
      • 2.8.2 L'importance d'être compris214
      • 2.8.3 L'importance de la communication215
      • 2.8.4 L'importance du format carte215
      • 2.8.5 Rendre le Backlog de produit lisible et visible216
      • 2.9 Affiner l'ordonnancement du Backlog de produit217
      • 3. Faire face aux changements218
      • 3.1 Gérer les nouvelles demandes218
      • 3.1.1 Être proactif218
      • 3.1.2 Rappeler la planification agile219
      • 3.1.3 Vérifier les objectifs et les contraintes220
      • 3.1.4 Rechercher le sens220
      • 3.1.5 Un modèle opérationnel221
      • 3.1.6 Savoir dire non222
      • 3.1.7 Oser dire non222
      • 3.1.8 Exprimer son désaccord et donner son point de vue avec assertivité223
      • 3.1.9 Rester constructif223
      • 3.2 Nettoyer le Backlog de produit223
      • 3.2.1 Mesurer les objectifs224
      • 3.2.2 Les objectifs atteints225
      • 3.2.3 Les objectifs inaccessibles225
      • 3.2.4 Les objectifs changent226
      • 3.2.5 Passer en revue les contraintes227
      • 3.2.6 Faire le point sur les moyens227
      • Chapitre 6
      • Communiquer plus efficacement
      • 1. Introduction229
      • 2. Les bénéfices du management visuel229
      • 2.1 Accéder plus facilement à une information complexe230
      • 2.2 Réduire le délai de prise de décision233
      • 2.3 Maintenir plus facilement un référentiel complexe233
      • 3. Les outils de management visuel235
      • 3.1 La planification de produit237
      • 3.2 Le Backlog de produit239
      • 3.3 Le Backlog de Sprint243
      • 3.3.1 Comprendre le Backlog de Sprint243
      • 3.3.2 Savoir déceler les signaux d'alerte246
      • 3.4 Les comptes rendus de l'équipe de développement247
      • 3.5 Les Burndowns de release ou de produit253
      • 3.6 Le référentiel d'exigences255
      • 3.7 Les solutions informatiques255
      • 4. Communiquer efficacement258
      • 4.1 L'information visuelle259
      • 4.2 S'appuyer sur des faits ou des indicateurs259
      • 4.3 L'oral et l'écrit260
      • 4.3.1 Les cas favorables à l'oral261
      • 4.3.2 Les cas favorables à l'écrit262
      • 4.4 S'appuyer efficacement sur le Scrum Master262
      • 4.4.1 Le Scrum Master supprime les obstacles entravant la progression de l'équipe de développement263
      • 4.4.2 Le Scrum Master au service du Product Owner264
      • 4.5 Faire participer dès membres de l'équipe de développement264
      • 4.6 Faire participer des parties prenantes266
      • Chapitre 7
      • Maximiser la valeur
      • 1. Délivrer le produit267
      • 1.1 Le plus tôt possible268
      • 1.2 Livrer fréquemment270
      • 1.2.1 Le produit de Marie270
      • 1.2.2 À quelle fréquence ?272
      • 1.3 Scrum et DevOps273
      • 1.4 Délivrer le produit de plusieurs équipes274
      • 2. Inspecter régulièrement274
      • 2.1 Inspection du Backlog de produit275
      • 2.1.1 L'intranet de Marie276
      • 2.1.2 La qualité des éléments du Backlog de produit278
      • 2.1.3 Les retours des utilisateurs280
      • 2.2 Inspection des processus de la Scrum Team281
      • 2.2.1 Marie et ses User Stories281
      • 2.2.2 La rétrospective de Sprint282
      • 2.2.3 Inspecter en dehors de la rétrospective de Sprint284
      • 3. Adapter les processus285
      • 3.1 Pour accroître la valeur286
      • 3.1.1 Marie face au RGPD287
      • 3.2 Pour accroître la transparence288
      • 3.3 Pour améliorer l'efficience du travail collaboratif289
      • 3.3.1 Marie change la date de début des Sprints290
      • 4. Améliorer la transparence291
      • 4.1 La revue de Sprint293
      • 4.2 La compréhension des éléments du Backlog de produit294
      • 4.2.1 Par les parties prenantes295
      • 4.2.2 Par les Developers296
      • 5. Piloter le budget298
      • 5.1 Mesurer le coût total300
      • 5.1.1 Le TCO302
      • 5.1.2 La dette technique303
      • 5.1.3 La dette opérationnelle305
      • 5.2 La vélocité comme mesure de ROI306
      • 5.3 L'usage est la mesure ultime307
      • 5.3.1 Marie stoppe le développement du produit307
      • 6. Piloter les délais309
      • 6.1 Financer un Sprint supplémentaire310
      • 6.1.1 Marie prolonge le développement du produit310
      • 6.2 Réorganiser la planification311
      • 6.2.1 Le plan de release311
      • 6.2.2 Réorganiser le Backlog de produit312
      • Chapitre 8
      • Scrum à l'échelle
      • 1. Scrum et SAFe315
      • 1.1 SAFe316
      • 1.2 Scrum à l'échelle selon Scrum.org319
      • 2. Organisation des équipes multiples321
      • 2.1 Organisation horizontale : la Component Team322
      • 2.2 Organisation verticale : la Feature Team323
      • 3. Scrum avec deux ou trois équipes325
      • 3.1 La notion d'ambassadeur326
      • 3.2 La planification de Sprint327
      • 3.2.1 Le « Why »328
      • 3.2.2 Le « What »328
      • 3.2.3 Le « How »329
      • 3.3 La mêlée quotidienne330
      • 3.4 La revue de Sprint330
      • 3.5 La rétrospective de Sprint331
      • 4. Scrum à plus grande échelle333
      • 4.1 Les problèmes de dépendance333
      • 4.1.1 Dépendances et ordonnancement du Backlog de produit335
      • 4.1.2 Le poids de la dette technique336
      • 4.1.3 Marie soigne ses dépendances337
      • 4.2 Nexus338
      • 4.2.1 Nexus et SAFe339
      • 4.2.2 L'affinage du Backlog de produit avec Nexus340
      • 4.2.3 L'équipe d'intégration Nexus341
      • 4.2.4 La planification de Sprint Nexus342
      • 4.2.5 Les autres évènements Nexus342
      • 4.2.6 La limite de temps des évènements Nexus343
      • 5. Organisation du Backlog de produit343
      • 6. Déléguer efficacement345
      • Chapitre 9
      • Participer aux événements Scrum
      • 1. Introduction349
      • 2. Le Sprint planning349
      • 2.1 Le thème Why349
      • 2.1.1 Marie alerte sur la définition de « Fini »350
      • 2.1.2 L'intérêt de clarifier le Why351
      • 2.1.3 Respecter le Timebox351
      • 2.1.4 Le rôle du Product Owner351
      • 2.2 Le thème What352
      • 2.2.1 Marie collabore avec la Scrum Team353
      • 2.2.2 L'importance du Jidoka353
      • 2.2.3 Le rôle du Product Owner354
      • 2.3 Le thème How355
      • 2.3.1 Gérer le Timebox355
      • 2.3.2 Marie s'appuie sur un objectif clair356
      • 2.3.3 Le rôle du Product Owner356
      • 3. Le Daily Scrum357
      • 4. La revue de Sprint358
      • 4.1 Les bonnes pratiques358
      • 4.1.1 La revue de la Scrum Team358
      • 4.1.2 La revue avec les parties prenantes clés359
      • 4.1.3 La revue avec toutes les parties prenantes359
      • 4.2 Démythifier la revue de Sprint360
      • 4.2.1 Tenir des discours différents360
      • 4.2.2 Manquer de transparence360
      • 4.2.3 Oublier la Scrum Team361
      • 4.2.4 Oublier le Scrum Master361
      • 4.2.5 Croire que tout le monde est agile362
      • 4.3 Organiser une revue de Sprint362
      • 5. La rétrospective de Sprint365
      • Bibliographie367
      • Glossaire369
      • Index375

  • Origine de la notice:
    • Electre

  • Indisponible : En reliure

Sur le même thème

Le projet Intranet : de l'analyse des besoins de l'entreprise à la mise en oeuvre des solutions

Le projet Intranet : de
l'analyse des […]

Alin, Frédéric,
Lafont, Denis, […]

La révolution e-business

La révolution
e-business

Amor, Daniel

Gouvernance des systèmes d'information dans la banque, l'assurance et la protection sociale : stratégies et exemples de réussites

Gouvernance des
systèmes […]

Le grand livre du DSI : mettre en oeuvre la direction des systèmes d'information 2.0

Le grand livre du DSI :
mettre en oeuvre la[…]

Challande,
Jean-François, […]

Les grandes approches théoriques du système d'information

Les grandes approches
théoriques du […]

Vaujany,
François-Xavier de

Le business assurance pour la performance de l'entreprise

Le business assurance
pour la performance[…]

Vanoverberghe, Didier

Manuel qualité pour les systèmes d'information

Manuel qualité pour les
systèmes d'information

Carlier, Alphonse

L'entreprise 2.0 : comment évaluer son niveau de maturité ?

L'entreprise 2.0 :
comment évaluer […]

Michel, Yvan
(19..-....), chef […]

Le web collaboratif : mutations des industries de la culture et de la communication

Le web collaboratif :
mutations des […]

Bouquillion, Philippe,
Matthews, Jacob Thomas

Urbanisme des SI et gouvernance : bonnes pratiques de l'architecture d'entreprise

Urbanisme des SI et
gouvernance : […]

Le management de projet appliqué aux SI

Le management de projet
appliqué aux SI

Schmitt, Geoffray

CMMI 1.3 : guide complet de CMMI-DEV et traduction de toutes les pratiques CMMI-ACQ et CMMI-SVC

CMMI 1.3 : guide complet
de CMMI-DEV et […]

Basque, Richard

ITIL V3 : préparation à la certification ITIL Foundation V3 : plus de 300 questions-réponses

ITIL V3 : préparation
à la certification[…]

Baud, Jean-Luc

Estimation des projets de l'entreprise numérique : approche systémique, coûts, qualité et délais

Estimation des projets
de l'entreprise […]

Printz, Jacques,
Trèves, Nicolas […]

Les référentiels du système d'information : données de référence et architecture d'entreprise

Les référentiels du
système […]

Bizingre, Joël,
Paumier, Joseph […]

Business models, coproduction de valeur et systèmes d'information

Business models,
coproduction de […]

Conduire un projet informatique

Conduire un projet
informatique

Taché, Philippe

L'ingénierie système d'une ligne de produits

L'ingénierie système
d'une ligne de produits

Association française
d'ingénierie système

Ingénierie des exigences : méthodes et bonnes pratiques pour construire et maintenir un référentiel

Ingénierie des
exigences : […]

Badreau, Stéphane,
Boulanger, […]

Le big data dans l'assurance

Le big data dans
l'assurance

Dupuis, Marc
(1967-....), […]

Voir tout les résultats (134)