Collaboration en Equipe Produit - Partie2

979 vues

Publié le

Deuxième partie du cours sur la culture produit, pour la formation MIDO M2 SITN de l'Université Paris Dauphine.

Cette partie présente la boîte à outils à disposition de l'équipe Produit, c'est-à-dire un ensemble de solutions à piocher judicieusement pour atteindre les objectifs du produit, en agissant sur l'humain et/ou la technique.

Plan de la partie :
- Comment utiliser la boîte à outils de l’équipe Produit
- Outils pour créer de la valeur en réunion
- Outils pour structurer et suivre le travail de l’équipe
- Outils pour faire parler les clients et utilisateurs
- Outils pour faire progresser l’équipe
- Outils pour communiquer à distance
- Outils pour gérer et partager les connaissances
- Outils pour documenter les développements
- Outils pour améliorer la qualité des développements
- Pour conclure sur l’utilisation de la boîte à outils
- Pour aller plus loin

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
979
Sur SlideShare
0
Issues des intégrations
0
Intégrations
13
Actions
Partages
0
Téléchargements
117
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Le mot « outil » est utilisé au sens large, il concerne les modèles/outils vus en partie 1, des stratégies, des démarches, etc

    Piocher judicieusement en fonction :
    De la culture produit (les personnes)
    De l’organisation (notamment les contraintes géographiques)
    Du moment (problèmes rencontrés, …)
    Du type de produit (par exemple mobile)

    Un même outil ne fonctionnera pas de la même manière sur deux équipes.

    Certains outils sont INDISPENSABLES (toute équipe doit en être doté, un peu comme un tournevis)

    Privilégier des assemblages « manuels » d’outil plutôt que des modèles tout faits
  • SPECIALISE = fonctions précises plutôt que « usine à gaz »
    SIMPLE = outil clair, cohérent, facile à prendre en main et à comprendre (« même une grand-mère doit comprendre »)
    VISUEL = des images et des dessins plutôt que des longs textes
    OUVERT = donne la parole à un maximum de participants
    EPROUVE = des retours d’expérience positifs existent, il est maintenu par une communauté
    PERSONNALISABLE = il peut être personnalisé pour l’équipe / produit / organisation
  • Les outils sont présentés sous forme de fiches

    Certains outils sont spécifiques au monde du développement logiciel, d’autres génériques pour n’importe quel produit (en particulier les 2 premières catégories)

    Certains outils sont des « must have » (fortement conseillés)
  • Les outils présentés ci-après se positionnent en complément de ces 7 fondements, pour faciliter leur mise en oeuvre
  • Eviter la caricature de la réunion :
    Où quelques personnes monopolisent la parole et l’attention, et tout le monde ne participe pas
    Où l’ordre du jour n’est pas respecté (ou il n’y a pas d’ordre du jour / agenda)
    Qui est sans fin

    Compréhension du résultat recherché : chercher à amener à un résultat, qui doit être clair et compris par les participants
    Facilitation de la prise de parole : permettre à chacun d’émettre des idées, mêmes les plus saugrenues
    Contrôle du temps imparti : associer des durées maximales (« time-boxing »)

    Les outils présentés peuvent constituer un sujet à part entière pour une réunion, ou servir à amorcer une réunion pour mettre les participants dans des conditions propices à la discussion, ou encore fournir du feedback utile en fin de réunion.

    Par réunion on entend aussi : présentation, formation, etc
  • EXPLORATEURS : ceux qui ont envie de découvrir de nouvelles choses, d’apprendre toujours plus
    SHOPPER : ceux qui vont jeter un œil à toute l’info disponible et qui seront heureux de sortir de là avec une bonne idée
    VACANCIERS : ceux qui ne sont pas vraiment intéressés par le contenu de l’atelier mais plutôt contents de sortir de leur quotidien
    PRISONNIERS : ceux qui ont le sentiment d’avoir été forcés à assister à l’atelier et qui pensent avoir mieux à faire ailleurs

  • Gamification, Serious games

    4 phases : DISCOVER > SHAPE > PRIORITIZE > ACT

    Exemple Innovation Game
  • Lean canvas
    Business model canvas
    SWOT
  • 0 = "J'aurais mieux fait d'aller boire un café. J'ai carrément perdu mon temps" 1 = "Vous auriez dû me laisser à mon bureau en train de coder" 2 = "Ce fut une bonne réunion. Autant de valeur ajoutée que si j'avais écrit du code" 3 = "De façon surprenante, ça m'a apporté plus de valeur que si j'avais écrit du code" 4 = "Super, cette réunion m'a permis de gagner énormément de temps. Dieu merci, je ne suis pas allé écrire du code à la place"
  • Notion héritée du modèle Scrum, très populaire
  • L’équipe peut piocher dans les backlogs des nouvelles « User stories » à implémenter si celles déjà prévues pour l’itération sont terminées

  • Alias Kanban board
  • Nouvelles fonctionnalités : en phase d’idéation
    Fonctionnalités implémentées : en phase de prototypage / release
  • Aussi appelées « Empathy maps »

    Erreurs fréquentes : Personas trop génériques, pas assez détaillées (connaissance du marché nécessaire), trop de personas
  • A dérouler sur des environnements dédiés !
  • Wireframes
  • Le terme est d'origine japonaise, le redoublement indiquant un effet d'onomatopée, "niko" signifie "sourire" (proposé par Akinori Sakata dans cet article début 2006)

    C'est une excellente illustration du "Principe de Gilb": "Si vous avez besoin de quantifier quelque chose, il existe toujours une manière de le faire qui soit préférable à ne pas le quantifier du tout." En d'autres termes, il n'est pas nécessaire qu'une mesure soit parfaite ou très précise, dès lors que votre objectif est de rendre quantifiable quelque chose qui ne l'est pas encore: l'essentiel est de commencer.

  • Dans un monde idéal qui n’existe pas, les membres de l’équipe Produit sont regroupés sur un lieu de travail commun afin de maximiser la collaboration, notamment à l’oral.

    En pratique, certains membres peuvent être répartis dans d’autres zones géographiques (cas du off-shore) ou bénéficier du télé-travail. Ou encore, certains membres peuvent être en déplacement pour des visites, démonstrations, etc.

    Enfin, même sur un lieu de travail commun, les gens peuvent vouloir fournir des liens, exemples de code ou encore des billets d’humeur, et ils ont besoin pour ça d’outils de communication électronique, plus simple et moins formelle que la communication via des e-mails.
  • Envoi de liens, d’exemples de code, de questions, etc, avec des réponses plus rapides qu’avec des emails.

    Slack : multi-usages
    Skype for enterprise : remplaçant de Link et de Microsoft Communicator
    Telegram : apprécié pour la confidentialité (chiffrement)

    Pas de version entreprise de What’s app
  • Webex, skype, hangouts
  • Yammer, facebook at work
  • Permet aux nouveaux arrivants de ne pas réinventer la roue
  • Pas de gestion des versions, pas forcément d’accès Internet
  • Exemples : Gdrive, Dropbox
    Attention aux tarifs pour des besoins importants en volume de données
  • Portails (Sharepoint), blogs (Wordpress)
  • JIRA
    Corrections et évolutions peuvent être représentées sous la forme de User Stories !
    Les bug trackers peuvent être connectés aux gestionnaires de sources.
  • JIRA
    Corrections et évolutions peuvent être représentées sous la forme de User Stories !
    Les bug trackers peuvent être connectés aux gestionnaires de sources.
  • Notion de dette technique
  • Collaboration en Equipe Produit - Partie2

    1. 1. Titre du slide Collaboration en équipe Produit Partie 2 : Boîte à outils de l’équipe Produit Comment utiliser la boîte à outils de l’équipe Produit Outils pour créer de la valeur en réunion Outils pour structurer et suivre le travail de l’équipe Outils pour faire parler les clients et utilisateurs Outils pour faire progresser l’équipe Outils pour communiquer à distance Outils pour gérer et partager les connaissances Outils pour documenter les développements Outils pour améliorer la qualité des développements Pour conclure sur l’utilisation de la boîte à outils Pour aller plus loin Alexandre Estela (alexandre@estela.fr) Université Paris Dauphine Management & coaching d’équipes Produit Cours MIDO M2 SITN
    2. 2. Titre du slide Comment utiliser la boîte à outils de l’équipe Produit
    3. 3. Partie 2 – Diapositive 3 L’ensemble des modèles et outils référencés constituent une boîte à outils où chaque équipe Produit doit piocher judicieusement selon les besoins. Pourquoi l’image d’une boîte à outils ?
    4. 4. Partie 2 – Diapositive 4 Un outil inapproprié ou mal personnalisé finit par coûter cher en termes de :  Budget pour l’acquisition et la formation à l’outil  Temps passé par les participants sur l’outil  Motivation des participants après de mauvaises expériences Les outils choisis doivent être appropriés et personnalisés
    5. 5. Partie 2 – Diapositive 5 Ces outils doivent privilégier certaines caractéristiques Spécialisé Simple Visuel Ouvert Eprouvé Personnalisable
    6. 6. Partie 2 – Diapositive 6 Ces outils peuvent reposer sur l’Humain et/ou la Technique Outils dont le succès repose sur le facteur Humain Outils dont le succès repose sur le facteur Technique
    7. 7. Partie 2 – Diapositive 7 Ces outils reposent sur les 7 fondements d’une équipe produit Rappel Partie 1 : « Culture Projet versus Culture Produit » 1. L’objectif d’un produit « Viable, Désirable et Réalisable » 2. La créativité couplée à la possibilité de valider des hypothèses 3. Les itérations, la mesure avec des KPIs et l’amélioration continue 4. Les livraisons régulières d’incréments de valeur et de qualité 5. La communication permanente, transparente et visuelle 6. L’équipe pluridisciplinaire et auto-organisée 7. La culture de l’équipe forgée par ses membres
    8. 8. Titre du slide Outils pour créer de la valeur en réunion
    9. 9. Partie 2 – Diapositive 9 Que signifie « créer de la valeur en réunion » ? Les résultats atteints en fin de réunion doivent pouvoir être valorisés, au même titre que le temps de chaque participant à la réunion. Objectifs des outils permettant de créer de la valeur en réunion : Pertedetemps =pasdevaleur Annoncer le résultat recherché Faciliter la prise de parole Chercher à respecter le temps imparti
    10. 10. Partie 2 – Diapositive 10 « Ice breakers » : pour libérer la parole et apprendre à se connaître Les « Ice breakers » sont généralement des activités ludiques qui amènent TOUS les participants à se présenter et/ou à découvrir les autres participants. Les « Ice breakers » sont idéaux pour mettre les participants dans des conditions de détente, avant de traiter le véritable sujet de la réunion. Ils peuvent également servir à initier les relations des membres d’une équipe (« kick-off »). « Trading cards» « Marshmallow challenge » gamestorming.com marshmallowchallenge.com « Two truths and a lie » www.thebolditalic.com
    11. 11. Partie 2 – Diapositive 11 « ESVP » : pour comprendre les motivations des participants « ESVP » (pour « Explorateur, Shopper, Vacancier, Prisonnier ») consiste en un exercice anonyme en début de réunion, où chacun écrit sur un papier la catégorie dans laquelle il se positionne, ce qui indique son niveau de motivation. L’objectif de l’exercice est d’identifier les tendances du groupe en termes de motivation et d’implication. Les résultats, une fois agrégés et partagés, doivent permettre de réorienter éventuellement l’objectif et/ou le déroulement de la réunion.
    12. 12. Partie 2 – Diapositive 12 « Jeux d’innovation » : pour trouver et organiser des idées Les « Jeux d’innovation » sont des jeux animés qui ont cependant l’objectif très sérieux d’amener les participants à proposer des idées innovantes pour leurs produits, et/ou à prioriser la mise en œuvre de ces idées. Les variantes sont nombreuses mais les grands principes sont les mêmes : favoriser une participation maximale, permettre l’émergence d’idées originales (même non applicables) puis faire converger les participants sur leur priorité. LEGO®par ex. « Give Them a Hot Tub » (Innovation Games®) par ex. « Design the box » (Gamestorming®)
    13. 13. Partie 2 – Diapositive 13 « Canvas » : pour aider à définir des stratégies Les « Canvas » sont des guides visuels (« templates ») pour aider à rechercher ou à documenter des stratégies : modèles économiques des produits, acteurs clés, forces & faiblesses, avantages & inconvénients, etc. Il existe de nombreux « canvas », plus ou moins détaillés ou compliqués. Ils doivent être choisis bien sûr en fonction du type de stratégie recherchée, mais aussi en fonction de l’organisation (cas des « start-ups »). « Lean canvas » « SWOT »
    14. 14. Partie 2 – Diapositive 14 « ROTI » : pour obtenir le feedback des participants Le « ROTI » (pour « Return On Time Invested ») est un vote effectué en fin de réunion concernant l’intérêt de la réunion, afin de donner du feedback à l’animateur. L’objectif de l’animateur est de pouvoir mesurer la pertinence de son intervention. S’il s’agit d’un vote à main levée, les participants ayant donné les notes les plus basses peuvent être invités à détailler le sens de leur vote.
    15. 15. Titre du slide Outils pour structurer et suivre le travail de l’équipe
    16. 16. Partie 2 – Diapositive 16 Quels sont les impacts de la structuration et du suivi du travail ? Ajouter de la valeur au produit, à chaque livraison d’incrément Faciliter la résolution de problèmes Communiquer sur les livraisons à venir Les 7 fondements de l’équipe produit ne peuvent être respectés que si l’outillage employé met en avant la valeur du produit, les itérations et la transparence sur l’avancement. Objectifs des outils pour structurer et suivre le travail de l’équipe :
    17. 17. Partie 2 – Diapositive 17 « User stories » : pour valoriser et prioriser les fonctionnalités Les « User stories » sont la description d’un cas d’usage du produit par un utilisateur. Elles décrivent ainsi une fonctionnalité qui apportera plus ou moins de valeur au produit une fois implémentée. Les « User stories » peuvent être classées en fonction de leur valeur estimée, afin de prioriser les tâches nécessaires à leur implémentation. En tant que… Visiteur Je veux… Consulter Pour… Acheter Tâche 1 Tâche 2 Tâche 3 Comment estimer les « User stories » ? Quand considère-t-on que l’implémentation de la « User story » est terminée ?
    18. 18. Partie 2 – Diapositive 18 « Backlogs » : pour annoncer le périmètre du produit / incréments Les « backlogs » regroupent les « User stories » déjà décrites pour le produit (« backlog du produit ») et celles que l’équipe a choisi d’implémenter dans l’itération en cours (« backlogs de l’itération »). Les « backlogs » permettent ainsi de voir les fonctionnalités en attente, et celles qui vont être proposées lors de la prochaine livraison d’incrément. ID USER STORY ESTIM. 1 En tant qu’étudiant, Je veux accéder à la liste des cours Pour la consulter 2 2 En tant qu’étudiant, Je veux accéder à la liste des cours Pour télécharger un cours 3 3 En tant que professeur, Je veux accéder à la liste des étudiants Pour mettre à jour les notes 5 4 En tant que secrétaire, Je veux accéder à la liste des étudiants Pour imprimer les notes 2 Backlog du produit ID USER STORY ESTIM. 1 En tant qu’étudiant, Je veux accéder à la liste des cours Pour la consulter 2 2 En tant qu’étudiant, Je veux accéder à la liste des cours Pour télécharger un cours 3 Backlog de l’itération Arbitrage avec l’équipe et le client
    19. 19. Partie 2 – Diapositive 19 « KPIs » : pour mesurer la performance de l’équipe Les « KPIs » (« Key Performance Indicators ») sont des indicateurs reflétant le niveau de performance de l’équipe à de multiples niveaux : productivité, bugs, bien-être, etc. Ils sont essentiels pour mesurer des écarts et s’améliorer. Les « KPIs » peuvent être objectifs (points, pourcentages) ou subjectifs (ressenti), mais ils ont vocation à être connus de toute l’équipe, afin que chaque membre puisse contribuer le cas échéant à l’amélioration de la performance. Mesure de la valeur ajoutée au produit à chaque incrément Criticité Description de l’anomalie Forte L’application s’arrête après 30 minutes d’utilisation Faible Le texte devrait être affiché en rouge en cas d’erreur Normale Le bouton de validation n’est pas assez visible Faible Il y a une faute d’orthographe à l’écran d’accueil Mesure du nombre de nouveaux bugs apparus par semaine
    20. 20. Partie 2 – Diapositive 20 « Daily Stand-Up » : pour partager avancées et blocages Le « Daily Stand-Up » est un point d’équipe rapide de 15 minutes maximum, où chaque participant prend la parole à son tour pour indiquer ce qu’il a réalisé la veille, ce qu’il compte réaliser aujourd’hui, et les difficultés rencontrées. Le « Daily Stand-Up » permet de synchroniser tous les membres de l’équipe, ainsi que d’éventuels externes, avec le même niveau d’information. Il permet aussi de mettre en relation les participants pour traiter les problèmes communiqués. www.scrumhub.com
    21. 21. Partie 2 – Diapositive 21 « Board » de management visuel : pour montrer ce qui se passe Le « board » de management visuel est un tableau de suivi des tâches de l’itération en cours. Les tâches, marquées sur des post-its, sont déplacées sur le tableau en fonction de l’avancée de leur traitement. L’objectif du « board » est de permettre d’un seul coup d’œil de voir le contenu et l’avancée de l’itération, notamment pour les personnes externes à l’équipe et/ou celles ne participant pas au « Daily Stand-up ».
    22. 22. Titre du slide Outils pour faire parler les clients et utilisateurs
    23. 23. Partie 2 – Diapositive 23 Quel besoin de faire parler les clients et/ou les utilisateurs ? Permettre de valider la valeur des nouvelles idées Permettre de valider la valeur des dernières implémentations Illustrer schématiquement les expériences attendues des utilisateurs Pouvoir obtenir et illustrer aisément le point de vue des clients et/ou des utilisateurs est indispensable pour valider la création de valeur proposée par l’équipe et pouvoir l’implémenter correctement. Objectifs des outils pour faire parler les clients et/ou les utilisateurs :
    24. 24. Partie 2 – Diapositive 24 « Personas » : pour intégrer le point de vue des utilisateurs Les « Personas » sont des représentations fictives d’utilisateurs, à qui l’on confère un prénom, un contexte, des besoins… afin de pouvoir s’imaginer à la place de cet utilisateur en cas de questionnement sur une fonctionnalité. Les « Personas » permettent de palier en partie à l’absence d’un vrai panel d’utilisateurs ; leur mise en œuvre requiert de l’imagination, mais permet à l’équipe de se questionner avec un angle de vue qui a de la valeur : celui des utilisateurs. welovelean.com
    25. 25. Partie 2 – Diapositive 25 Démonstrations : pour valider progressivement ce qui est produit Les démonstrations sont des présentations de fonctionnalités nouvelles du produit, effectuées comme rituel de fin d’itération auprès du client et/ou d’un panel d’utilisateurs. Les démonstrations permettent de valider des implémentations, même partielles (prototypes), de fonctionnalités de produit ; ceci afin de pouvoir bâtir les fonctionnalités suivantes sur des fondations validées (UX, code, etc). leblogdumanagementdeprojet.com
    26. 26. Partie 2 – Diapositive 26 « Wireframes » : pour illustrer l’expérience utilisateur Les « Wireframes » sont des maquettes fonctionnelles simples (schémas, croquis) qui illustrent les points clés de l’expérience utilisateur associée au produit. Leur objectif n’est pas de fournir le graphisme final du produit, mais de montrer les grands principes, blocs d’information, liens, interactions, comportements, etc, afin que le reste de l’équipe puisse se projeter dans l’expérience utilisateur à fournir. balsamiq wirify
    27. 27. Titre du slide Outils pour faire progresser l’équipe
    28. 28. Partie 2 – Diapositive 28 Que signifie « faire progresser l’équipe » ? Améliorer l’organisation en interne et avec l’externe Améliorer la gestion des problèmes et des conflits Améliorer l’ambiance et la culture de l’équipe La performance d’une équipe dépend directement de ce que produit cette équipe, et dans quelles conditions. Les outils qui font « progresser l’équipe » visent à améliorer la productivité et les conditions de travail. Objectifs des outils visant à faire progresser l’équipe :
    29. 29. Partie 2 – Diapositive 29 Rétrospectives : pour faire le bilan d’une itération Les rétrospectives sont des réunions de l’équipe en fin d’itération, qui donnent à chaque membre de l’équipe l’occasion de revenir sur les bonnes et mauvaises expériences (tâches, organisation, interactions, etc) vécues lors de l’itération. L’objectif des rétrospectives est d’identifier les points positifs à reproduire et les points à améliorer dans les prochaines itérations, ainsi que de proposer concensuellement des solutions pour mettre en œuvre ces améliorations. « Speed boat »« Drop, Add, Keep, Improve » funretrospectives.com
    30. 30. Partie 2 – Diapositive 30 « Niko-niko » : pour suivre le bien-être de l’équipe L’équipe affiche sur un mur visible de tous, un calendrier de type journalier. A la fin de chaque journée, chaque membre indique sur le calendrier son évaluation de la journée avec un dessin ou en collant une gommette de couleur. www.geocities.jp/nikonikocalendar Le but recherché est de mesurer subjectivement la motivation et le bien-être de l’équipe, de déceler des changements au niveau d’un ou plusieurs membres, et de d’initier des actions pour améliorer la situation.
    31. 31. Titre du slide Outils pour communiquer à distance
    32. 32. Partie 2 – Diapositive 32 Dans quels cas doit-on encore communiquer à distance ? Permettre le partage de toutes sortes d’informations rapidement et de manière peu formelle Garder le contact en cas de multi-sites, de télé-travail ou de déplacement Fournir de nouveaux canaux d’échange, en-dehors de l’oral et du mail, pour créer une culture d’équipe La communication à distance par voie électronique est parfois nécessaire dans le cadre d’équipes multi-sites, en cas de déplacement, ou pour fournir plus aisément certaines informations comme des liens, bouts de code, etc Objectifs des outils permettant de communiquer électroniquement :
    33. 33. Partie 2 – Diapositive 33 « Mailing lists » : pour échanger dans un groupe « à peu de frais » Une « mailing list » ou liste de diffusion, consiste en une adresse e-mail de groupe, configurée pour diffuser tout e-mail reçu à un ensemble de destinataires prédéfinis. Les « mailing lists » offrent une solution de collaboration à « peu de frais » pour certaines équipes Produit, dans des organisations ayant peu de moyens d’investissement ou ayant un fort attachement à la culture de l’e-mail.
    34. 34. Partie 2 – Diapositive 34 Messageries instantanées : pour faire vite, simple et informel Les messageries instantanées existent depuis les débuts d’Internet, mais se sont réinventées ses dernières années pour permettre aux équipes de collaborer plus aisément et de manière plus riche qu’avec des échanges d’e-mails. Les outils modernes permettent ainsi de voir la disponibilité des personnes, d’inclure des illustrations et des documents, de créer des groupes de discussion, rapidement et simplement, sans le formalisme associé habituellement à un e-mail. Lync(remplacéparSkype) Telegram Slack
    35. 35. Partie 2 – Diapositive 35 Visio-conférence : pour humaniser les échanges à distance Les outils de visio-conférence permettent d’associer des visages et des gestes à l’expression orale lors de la communication autour du produit. Pouvoir associer visuellement des personnes à des noms contribue grandement à la connaissance des membres au sein de l’équipe, et par conséquent au sentiment d’appartenance au groupe. WebEx Skype
    36. 36. Partie 2 – Diapositive 36 Réseaux sociaux d’entreprise : pour fédérer un groupe Un réseau social d’entreprise vise les mêmes usages que les réseaux sociaux entre particuliers, mais en entreprise : présentations, annonces, discussions, etc. Les réseaux sociaux d’entreprise sont idéalement accessibles via un maximum de canaux (desktop, mobile) afin de donner accès en permanence à l’actualité de l’organisation. Yammer Facebookatwork
    37. 37. Titre du slide Outils pour gérer et partager les connaissances
    38. 38. Partie 2 – Diapositive 38 Quelles connaissances une équipe veut-elle gérer et partager ? Donner des accès publics ou restreints, avec un système de gestion des droits adapté aux groupes de participants Permettre de gérer et de visualiser des documents de nature diverse avec des éditeurs appropriés Offrir des fonctions avancées pour la recherche, le « versioning », le partage, etc. Toute équipe ou organisation a besoin d’une base de connaissances, afin notamment de centraliser et/ou diffuser les pratiques projet ou de la société, l’architecture technique, les nouvelles fonctionnalités, l’organigramme, etc. Objectifs des outils visant à gérer et partager une base de connaissances :
    39. 39. Partie 2 – Diapositive 39 « Dossiers réseau » : pour partager des fichiers « à peu de frais » Les dossiers sur des serveurs de fichiers (SAMBA, FTP, HTTP…) accessibles depuis le réseau local de l’entreprise, offrent un espace de partage simple d’emploi (« glisser-déposer ») pour toutes sortes de documents. Ces « dossiers réseau » reposent sur des solutions techniques historiques et permettent une centralisation des fichiers « à peu de frais » avec des investissements minimes (par exemple avec un simple NAS).
    40. 40. Partie 2 – Diapositive 40 Stockage sur le Cloud : pour sécuriser le partage de documents Les solutions de stockage sur le cloud, comme Dropbox ou Google Drive, permettent de disposer de dossiers partagés sur Internet, potentiellement sans limite de stockage, et sans avoir à traiter les problématiques de hardware. Ces solutions sont prisées pour leur modèle économique évolutif, la possibilité d’accéder aux fichiers en multi-canal, le suivi des versions de document et la gestion étendue des droits d’accès pour les utilisateurs.
    41. 41. Partie 2 – Diapositive 41 « CMS » : pour créer des portails et des blogs thématiques Les « CMS » (pour « Content Management System ») sont des éditeurs de contenu accessibles à des non-techniciens, permettant de créer des sites web potentiellement complexes pour l’Intranet ou l’Internet. Les « CMS » permettent notamment de mettre en place des « vitrines », tels que des portails d’entreprise ou des blogs, afin de gérer des informations publiques ou privées pouvant être catégorisées et recherchées.
    42. 42. Partie 2 – Diapositive 42 Wikis : pour créer des pages web collaboratives Un wiki est un système de gestion de contenu visant à favoriser la collaboration dans la complétion de l’information. La modification des pages web, accessible aux non-techniciens, peut être effectuée par potentiellement n’importe quel visiteur. Les wikis se veulent moins formels et moins restreints que d’autres « CMS », et sont davantage prisés par les équipes de développement pour l’enrichissement quotidien de la documentation des pratiques et de l’organisation de l’équipe.
    43. 43. Partie 2 – Diapositive 43 Agendas partagés : pour avoir une vision commune du calendrier Les agendas partagés sont visibles et/ou alimentables par plusieurs membres de l’équipe ou de l’organisation. Ils permettent de partager facilement des évènements internes ou externes susceptibles d’intéresser un groupe d’inscrits. A l’inverse de la simple page web recensant les évènements à venir, les agendas partagés s’intègrent dans les solutions de gestion d’agenda et peuvent bénéficier ainsi des fonctions de rappel et de visibilité sur la participation.
    44. 44. Titre du slide Outils pour documenter les développements
    45. 45. Partie 2 – Diapositive 45 Que signifie « documenter les développements » ? S’intégrer à l’environnement de travail des développeurs (en particulier l’éditeur de code) Permettre de distinguer des versions de travail et les développeurs ayant travaillé dessus Faire le lien avec les autres activités de l’équipe (conception, test, maintenance, etc) Les développements produisent des livrables, les sources des programmes ; ces fichiers et les résultats de leur utilisation constituent de la documentation qui doit être gérée au même titre que la base de connaissances de l’équipe. Objectifs des outils accompagnant les développements :
    46. 46. Partie 2 – Diapositive 46 Gestionnaires de sources : pour gérer les versions des sources Les gestionnaires de sources sont des espaces de stockage spécifiques pour les sources des programmes, où chaque développeur dépose régulièrement le code réalisé dans le cadre du produit. Ces gestionnaires de sources sont essentiels pour sauvegarder le travail des développeurs mais également, gérer les conflits entre plusieurs modifications effectuées sur un même fichier, et suivre les différentes versions des fichiers.
    47. 47. Partie 2 – Diapositive 47 « Bug trackers » : pour gérer les corrections et évolutions Les « bug trackers », ou gestionnaires d’anomalies, permettent à l’équipe de proposer des corrections ou des évolutions pour le produit (sous forme de « tickets ») pour une prise en compte par les développeurs. Les « bug trackers » sont un outil pour toute l’équipe : les « tickets » ont typiquement plusieurs statuts et chaque rôle (concepteur, testeur, etc) peut être responsable du passage au statut suivant (« analysé », « testé », etc).
    48. 48. Partie 2 – Diapositive 48 Revues de code : pour tracer et valider les changements de code Les revues de code sont des relectures des modifications apportées sur le code par un ou plusieurs autre(s) membres(s) de l’équipe. Elles peuvent être effectuées dans des outils liés au gestionnaire de sources ou plus simplement dans Word. Les revues de code sont effectuées par des développeurs et architectes afin de valider essentiellement les pratiques techniques. Elles peuvent être basées notamment sur des votes afin d’amener une amélioration collaborative.
    49. 49. Titre du slide Outils pour améliorer la qualité des développements
    50. 50. Partie 2 – Diapositive 50 Pourquoi chercher à augmenter la qualité des développements ? Etre assez faciles à prendre en main pour pouvoir devenir des automatismes pour les développeurs Permettre de mesurer régulièrement le niveau de qualité effectivement atteint par l’ensemble du code Permettre de prendre en compte l’expertise d’autres rôles que celui de développeur Afin d’être viable, la qualité du produit, et donc des développements, est essentielle. Plusieurs bonnes pratiques, notamment issues de l’« Extreme Programming », permettent de tirer vers le haut la qualité des sources livrées. Objectifs des outils visant à augmenter la qualité des développements :
    51. 51. Partie 2 – Diapositive 51 « Pair programming » : pour bénéficier d’un deuxième regard Le « pair programming » consiste à mettre ensemble deux développeurs pour travailler sur un même développement : bien qu’un seul effectue le codage, les deux sont invités à échanger sur les problèmatiques et les solutions possibles. La pratique du « pair programming » offre les avantages d’une revue de code immédiate et d’une recherche optimisée des meilleures implémentations. Elle permet d’éviter les bugs liés à des incompréhensions isolées et des étourderies.
    52. 52. Partie 2 – Diapositive 52 Tests : pour valider les résultats des développements Les tests sont des activités déroulées à l’issue des développements, souvent par les développeurs mais pas exclusivement, pour valider que les développements sont conformes selon plusieurs critères techniques et fonctionnels. Il existe plusieurs types de test (unitaire, intégration, acceptation) pouvant être déroulés lors d’étapes variables, manuelles ou automatisées. Leur point commun doit toujours être la détection « au plus tôt » de non-conformités avec le besoin.
    53. 53. Partie 2 – Diapositive 53 Qualimétrie : pour mesurer la qualité du code selon le contexte La qualimétrie est l’activité de mesure de qualité du code fourni par les développeurs, selon plusieurs indicateurs : pourcentage de code testé, respect des règles de nommage, complexité algorithmique, etc. Il importe de toujours personnaliser les indicateurs de mesure et les seuils minimums demandés aux développeurs, dans la mesure où la qualité est une notion contextuelle, en partie subjective, qui requiert des efforts maîtrisés.
    54. 54. Partie 2 – Diapositive 54 Intégration continue : pour assembler et livrer continuellement L’intégration continue est une pratique qui consiste à récupérer toutes les sources fournies par les différents développeurs, à les assembler sous forme d’applications, qui sont ensuite mises à disposition du reste de l’équipe (testeurs, production, etc). Le principe de l’intégration continue est de faciliter et d’accélérer les tâches récurrentes de compilation et de packaging des applications, généralement de manière automatisée, évitant ainsi les erreurs liées aux manipulations manuelles.
    55. 55. Titre du slide Pour conclure sur l’utilisation de la boîte à outils
    56. 56. Partie 2 – Diapositive 56 Ne pas démultiplier inutilement les outils
    57. 57. Partie 2 – Diapositive 57 Déployer, expérimenter et valider les outils au fur et à mesure
    58. 58. Partie 2 – Diapositive 58 Faire attention aux leviers dont dépend chaque outil Outils pour structurer et suivre le travail d’équipe Outils pour communiquer à distance Outils pour gérer les connaissances Outils pour améliorer la qualité des développements Outils pour documenter les développements Outils pour créer de la valeur en réunion Technique Outils pour faire progresser l’équipe Outils pour faire parler les clients et utilisateurs Humain
    59. 59. Partie 2 – Diapositive 59 Utiliser du coaching pour faciliter la conduite de changement
    60. 60. Partie 2 – Diapositive 60 Inclure des membres expérimentés dans l’équipe «Batman&Robin»,1997
    61. 61. Partie 2 – Diapositive 61 Accompagner l’équipe avec les formations appropriées
    62. 62. Titre du slide Pour aller plus loin
    63. 63. Partie 2 – Diapositive 63 Bibliographie  Jez Humble & David Farley, 2010, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation  Luke Hohmann, 2006, Innovation Games: Creating Breakthrough Products Through Collaborative Play  Robert C. Martin, 2002, Agile Software Development, Principles, Patterns, and Practices  Gojko Adzic, 2009, Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing  Mike Cohn, 2004, User Stories Applied : For Agile Software Development

    ×