24
UE Communautés de Pratiques Séance 3 de l’UE mardi 9 février 2016 Céline JOIRON [email protected] http://home.mis.u-picardie.fr/~joiron/cdp/ IAE – Masters 2 MEGC 2015/2016

UE Communautés de Pratiquesjoiron/CoP-Cours3-CJ1516.pdf · 2016-02-12 · travail consiste à définir les caractéristiques de l’objet produit dans le détail pour en organiser

  • Upload
    vothien

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

UE Communautés de Pratiques

Séance 3 de l’UEmardi 9 février 2016

Céline JOIRON

[email protected]

http://home.mis.u-picardie.fr/~joiron/cdp/

IAE – Masters 2 MEGC 2015/2016

Rappels sur l’UE

• Jusqu’ici :

• 2 Cours sur les CoP

èDescripteurs de pratiques

èOrientations communautaires possibles (Wenger)

è9 problématiques de la stratégie de gestion des connaissances par les communautés (cycle en V)

• Elaboration de votre projet

• Constitution de binômes de travail, définition de deux contextes de pratiques

+ Sélection d’un des contexte pour fil conducteur du projet

• Proposition d’éléments descripteurs des pratiques dans ce contexte

• Choix d’une des problématique dans le cycle en V

• Premières pistes d’orientations communautaires

• Aujourd’hui

• Introduction à la Conception Avancement sur le projet 2

Rappels sur le projet…

Supporter les connaissances et les apprentissages d’une activité collective, de la conception à l’instrumentation

• Vous placer dans la situation d’un consultant :

• Proposer et étudier un cas concret, entreprise ou non, réelle ou fictive

• Préconiser la mise en place d’une infrastructure permettant de supporter les connaissances et les apprentissages de ses acteurs autour d'une activité collective.

• Choix d’une problématique en lien avec la théorie de la conception

• Description concrète de ce contexte, de l’activité collective.

• Description des tâches de prédilection de la communauté et les outils appropriés pour réaliser ces tâches dans le cadre d’une communauté en ligne

3

Théorie de la conception en lien avec les Communautés

4

En conception de Produits

• « Efforts collectifs destinés à créer des biens ou des services, des objets, des équipements, des techniques, voire des systèmes sociaux qui sont différents de ceux existants et qui répondent aux besoins collectifs » [Wikipedia]

• Mise en opposition de (selon le degré d’innovation du produit) :

• La conception réglée : objet connu au moment de la conception, le travail consiste à définir les caractéristiques de l’objet produit dans le détail pour en organiser la production

Vs

• La conception innovante : s’appuie sur la créativité, on ne sait pas ce qu’on crée au moment où débute la conception

• Théorie C-K (MINES Paris) : https://youtu.be/8Z24m_3FvGM

5

En Gestion de Projets (informatiques)

• Il existe des modèles de développement génériques appelés cycles de vie des projets (ou Cycles de développement)

• Des principes classiques :

èMéthodologies plus ou moins formalisées permettant d’appliquer ces cycles de vie

6

Exprimer un besoin, définir un périmètre

Concevoir la solution

Construire la solution

Tester Installer Surveiller

• Cycles de vie les plus connus

•Cascade

• En V

• En W

•Code and fix

•Développement évolutif

• En spirale

• Semi-itératif et Itératif

7

Niveau d’adaptabilité et de prise en compte de l’évolution des besoins

=> En corrélation avec le degré de créativité

En Gestion de Projets (informatiques)

• Cycle de vie en cascade• Issu des études de ROYCE

en 1970

• Processus composé d’une succession de phases

• Chaque phase est clôturée par une revue de fin de phase qui la valide officiellement

• on ne passe à la phase suivante qu’en cas de satisfaction

• Pas de retour possible sur les validations à des phases précédentes.

8

En Gestion de Projets (informatiques)

• Cycle de vie itératif (évolutif mais avec notion d’itérations)• Le projet est décomposé en itérations

• On applique un cycle de type (Planifier – Développer – Contrôler –Ajuster) sur chaque itération

• Itérations testées par le client et retours pris en charge pour la prochaine itération

• Cycle de vie semi-itératif

• Deux premières phases « classiques » d’expression des besoins et de conception de la solution.

• Troisième grande phase de construction du produit par d’itérations courtes

Plusieurs méthodes connues è LES METHODES AGILES 9

En Gestion de Projets (informatiques)

• Définitions des méthodes agiles• « Une méthode agile est une approche itérative et incrémentale, qui est menée

dans un esprit collaboratif, avec juste ce qu’il faut de formalisme. Elle génère unproduit de haute qualité tout en prenant en compte l’évolution des besoins desclients. » [Messager, 2013]

• « Le terme « Agile » définit une approche de gestion de projet qui prend lecontre-pied des approches traditionnelles prédictives et séquentielles de typecycle en V ou waterfall (en cascade). » www.agiliste.fr

• «…Les méthodes agiles sont des groupes de pratiques de projets dedéveloppement en informatique (conception de logiciel), pouvant s'appliquer àdivers types de projets. Elles ont pour dénominateur commun l'Agile Manifesto. ... »Wikipédia

10

En Gestion de Projets (informatiques)

• Les méthodes agiles sont construites sur les failles (avérées ou non) du cycle de vie en cascade• Rigidité de l’approche cascade car pas de retours arrière possibles

• Peu de marge laissée au client pour préciser et faire évoluer ses attentes

• Effet tunnel (boite noire) :

• Des besoins è ??? èUn produit

• Nécessite de connaître à priori l’ensemble des besoins !!!

• Une mauvaise communication

• Levée tardive des facteurs de risques

• Tests d’intégrité ou de performance à la fin par exemple

• Documentation pléthorique

• Pour se prémunir contre les risques, on documente tout, car une fois le codage commencé, c’est « irréversible » 11

En Gestion de Projets (informatiques)

• Les méthodes agiles reposent sur une approche itérative et incrémentale• Découpage du projet en itérations = étapes d’une durée de quelques semaines

• Au cours d’une itération une version minimale du produit attendu est développée puis soumise, dans sa version intermédiaire, au client pour validation

• Les fonctionnalités sont intégrées au fur et à mesure du cycle de vie èmode incrémental

• Le système s’enrichit progressivement pour atteindre le niveau de satisfaction et de qualité requis.

• Chaque itération est un mini-projet qui comporte les activités d’analyse, de conception, de codage, de tests et de gestion de projet.

• A l’issue de chaque itération, on a un sous-ensemble opérationnel du système cible

• Au terme de la dernière itération, la version finale du produit

• Les itérations se succèdent et ne peuvent être parallélisées, leur date de fin est généralement fixe

• Mobiliser les efforts sur des objectifs clairs à courts terme

• Si les objectifs ne sont pas atteints, les enseignements en sont tirés lors du bilan de l’itération pour corriger les conditions de l’itération suivante

12

En Gestion de Projets (informatiques)

• L’esprit des méthodes agiles

• Collaboratif• Placer les individus et leurs interactions au centre du dispositif

• Privilégier la communication entre l’équipe mais aussi avec les interlocuteurs tels que client ou utilisateur

• Partage d’information, échange de points de vue différents ou complémentaires, entraide et non concurrences

• Formalisme léger• Seulement quelque livrables à produire en plus de l’essentiel (ie les versions

intermédiaires de produits)

• Quelques rôles, quelques étapes, quelques réunions… et la démarche est formalisée

• Ne pas doter l’équipe d’outils complexes auxquels elle devra s’adapter et se former è approche adaptative 13

En Gestion de Projets (informatiques)

• Produit de haute qualité• Niveau de qualité minimal d’un produit = capacité à satisfaire le client, tant sur le plan

fonctionnel que sur celui des exigences de performance, de facilité d’utilisation ou d’évolutivité

• Sélection des fonctionnalités à implémenter en priorité

• Feedback permanent recueilli du client

• Campagnes de tests et contrôle qualité à chaque itération

• Nettoyage régulier (quotidien ? ) du code et respect de normes de codage partagées

• Adoption d’un approche adaptative

• Comprendre les méthodes agiles en image :

• http://youtu.be/AdEOHwgRYSI

• https://youtu.be/vis8cWMm_ww 14

En Gestion de Projets (informatiques)

• En 2001, 17 experts en développement logiciel trouvent un socle commun de valeurs et de bonnes pratiques

è « Manifeste pour le développement logiciel agile » - 13 principes des méthodes agiles – Manifeste agile www.agilemanifesto.org

èCréation de l’Agile Alliance (www.agilealliance.org) chargée de promouvoir l’agilité dans les organisations et d’apporter du soutien aux équipes qui veulent démarrer un projet agile

• Les valeurs du Manifeste

• Les individus et leurs interactions avant les processus et les outils

• Des fonctionnalités opérationnelles avant la documentation

• Collaboration avec le client plutôt que contractualisation des relations

• Acceptation du changement plutôt que conformité aux plans

è Cela ne signifie pas qu’aucun processus n’est défini, qu’on ne se dote d’aucun outil Jè Des plans et une documentation, plus réduits, sont produits

15

En Gestion de Projets (informatiques)

• En 2005 a été publié la « déclaration d’interdépendance », signée par les acteurs majeurs de l’Agile Alliance

• 6 concepts doivent être considérés de façon interdépendante : valeur, incertitude, client, individus, équipe, contexte

• « Vous ne pouvez créer de la valeur si vous ne collaborez pas avec un client, qui précisément, définit ce qu’est sa valeur;

• vous ne pouvez attendre d’une équipe qu’elle soit performante si vous ne reconnaissez pas la contribution des individus qui la composent;

• vous ne pouvez maîtriser l’incertitude si vous ne prenez pas en considération la spécificité du contexte. »

16

En Gestion de Projets (informatiques)

• Les méthodes les plus reconnues s’appuient sur les principes du manifeste

• Se différencient par leurs degrés de formalisme

• Poids de la méthodologie dans la documentation, étapes formelles, revues d’itération, rythme du projet ou durée des itérations

• Principales méthodes agiles

• RAD : Rapid Application Development

• ASD : Adaptive Software Development

• DSDM : Dynamic Software Development Method

• XP : eXtreme Programming

• Processus Unifié (PU) ou Unified Porcessing (UP)

• Scrum17

En Gestion de Projets (informatiques)

En EIAH

• …le terme “conception des EIAH” renvoie aux problématiques liées à la conception des artefacts informatiques qui embarquent des fonctionnalités liées à l’objectif de susciter ou d’accompagner un apprentissage humain et aux problèmes particuliers qui pose la conception de ces artefacts... [Tchounikine 2004 – Platon-1 : quelques dimensions pour l’analyse des travaux de recherche en conception d’EIAH, Rapport de l’Action Spécifique “Fondements théoriques et méthodologiques d ela conception des eIAH”, département STIC du CNRS

• La dimension Théorie de la conception d ePlaton-1 : • Théorie de conception utilisée pour la projet de recherche en EIAH :

• Linéaire, itérative, participative, sur l’utilisateur, centrée usages

• Forme de prise en compte des usages dans la conception (comment, par qui, à quel moment, etc.)

18

Dans le domaine des CoP ?

• Les contextes de mise en œuvre sont variés

• Comment la problématique CoP se pose-t-elle dans l’organisation ?

• On cherche à s’appuyer sur une stratégie de gestion des connaissances

èPas uniquement proposer un produit !

Donc..

• Il n’y a pas forcément de besoin à priori !

• On ne dispose pas forcément de personnes ressources pour exprimer un besoin

• Adoption d’une approche plus ou moins diagnostique, participative, créative, et incrémentale ! 19

Dans le domaine des CoP ?

• Eléments constitutifs possibles de la mise en place de communautés de pratiques en ligne

• Analyse des communautés

• Inventaire des connaissances

• Conception d’un environnement d’apprentissage authentique

• Outillage de la communauté

20

Dans le domaine des CoP ?

• 3 approches identifiables et différenciables en fonction du contexte :• 1 – LE CONTRAT :

• On a un besoin explicite, un commanditaire, des moyens, on s’appuie sur une contractualisation entre les acteurs, avec des outils de GdP classiques, et un Cahier des Charges

• 2 – LA MISSION CONSEIL :

• On est plus sur du diagnostic ou de l’analyse, avec la question des domaines de connaissances tacites et structurelles, on cherche à identifier, caractériser par cette approche diagnostique, le besoin !

• 3 – L’ANALYSE D’USAGE :

• On part d’analyse d’usages, on adopte une démarche de concpetionparticipative où l’on implique les usagers dès le départ, on est dans une logique d’animation, d’agilité, avec travail sur des cas exemplaires à monter en généralités

21

Le projet aujourd’hui

• Vérification des fiches descripteurs de pratiques, choix de la problématique de KM, et des grandes orientations communautaires

• Choix d’une approche de Conception

• Retranscrire dans le tableau partagé sur GGDrive• Une URL vers la fiche pratique en pdf à télécharger, une fois mise

à jour

• Une colonne précisant la problématique choisie

• Une colonne précisant les grandes orientations communautaires choisies

• Une colonne précisant l’axe de Conception adopté

• https://docs.google.com/spreadsheets/d/1FDXhk80yY0t5fJV0ukwbtiuuVO87z9u9Pg1ltJLIgKo/edit?usp=sharing 22

A faire pour le 1er MARS

• Fiche Orientation KM :

• Décrire dans une fiche recto-verso maximum la problématique de Knowledge Management choisie (parmi les 9 identifiées dans le cours) + justification des choix + liste des sources bibliographiques et webographiques utilisées pour étayer le travail.

• Fiche Design et Orientation Communautaire :

• Décrire dans une fiche recto-verso maximum le choix de la démarche de Design (Conception) choisie, et les grandes orientations communautaires de votre CoP

23

Séances suivantes• Séance du 1er mars : E. SOULIER • Présentation de la cartographie des outils

• Avancement sur le projet

• Séance du 15 mars : C. JOIRON• Pré-soutenance : 10 min par groupe

• Plan global de votre note final

• Présentation du Cas

• Présentation de la problématique et des ressources qui vont appuyer

• Présentation des outils explorés

• Avancement sur le projet

• Séance du 25 mars : C. JOIRON & E. SOULIER• Soutenance et rendu du dossier projet

24