Quelles sont les types activités de développement CRM ?

Nous avons en partie aborder le sujet dans l’article Architecture technique, les types d’activités sont les suivants :

1. Personnalisations
1. Personnalisation des métadonnées (ex : Création d’entités, modification de champ, …)
2. Personnalisation des écrans (ex : Modification de formulaire, création de tableau de bord, ajout de webresources …)
3. Personnalisation des processus ( ex : Création de workflow, création de dialogue, personnalisation de processus d’entreprise …)
2. Développements
1. Développement de WebResources
2. Développement de Plugins
3. Développement de Workflows
4. Développement de Batchs
3. Tests
1. Tests fonctionnels
2. Tests de performances
3. Tests unitaires

Comment optimiser ces activités ?

Personnalisations

Personnaliser CRM est un processus globalement assez optimisé, néanmoins dès qu’il s’agit d’appliquer des modifications de manière massive l’interface se trouve alors trop limitée.

Par exemple :

• Appliquer un paramétrage sur plusieurs attributs,
• Appliquer les mêmes paramètres de colonne sur plusieurs vues,
• Ajouter des privilèges sur plusieurs rôles de sécurité,
• …

Un grand nombre de ces actions est pris en charge dans l’outil XrmToolbox réalisé par Tanguy Touzard et ouvert au contributions de la communauté. A ce jour, c’est un outil incontournable pour accélérer la personnalisation de CRM.

Dans tous les cas, si aucun outil ne propose ce que vous souhaitez faire, vous pouvez tout à fait le réaliser en vous appuyant sur le SDK CRM, en effet, la majorité des actions réalisées via l’interface CRM sont faisables via code.

Développements

1. Développement du plugin dans Visual Studio
2. Compilation dans Visual Studio
3. Mise à jour de l’assembly dans CRM avec le Registration Tool
4. Tests dans CRM

Même si le développeur dispose d’une grande expérience, il s’y prendra à plusieurs reprises pour parvenir au résultat espéré et l’étape 3 est très consommatrice de temps car elle implique plusieurs actions manuelles qui peuvent être industrialisées.
En effet, une fois l’assembly générée par Visual Studio, il est très simple de la “pousser” dans CRM en utilisant le SDK et en minimisant les interactions manuelles.

Ce type d’optimisation présente un gain de quelques secondes mais si l’on considère le nombre d’occurrence journalière multiplié par le nombre de développeur et de plugin et en intégrant les erreurs humaines potentielles, cela peut représenter un gain avantageux sur la marge du projet.

C’est la même problématique pour les déploiements de Workflow, de rapport et de webresource.
Comme pour les personnalisations, des outils existent pour réaliser ce type d’opération, l’outil XrmToolbox  propose un Webresource Manager très utile pour simplifier la gestion des webresources.

Il existe également des scripts Powershell très simple pour réaliser les opérations basiques :

• Mettre à jour les assemblies de Plugins et Workflows : Deploy plugins / workflows assemblies with Powershell
• Synchroniser des webressources depuis un répertoire dans CRM : http://blogs.msdn.com/b/aymerics_blog/archive/2015/06/06/synchronize-a-webresources-folder-to-crm-with-powershell.aspx

A noter également, qu’il existe une technique très performante pour débugger les webresources sans les déployer, Thomas Canaple a décrit une procédure permettant de détourner l’appel HTTP de la webresource vers le fichier local grâce à l’autoResponder de Fiddler  : http://blog.canaple.fr/how-to-test-web-resources-without-publishing/ 

Tests

Concernant les tests, tout n’est pas automatisable mais il est possible de tirer partie des capacités des outils de test fournis par Visual Studio pour industrialiser au maximum ces opérations très couteuses en temps.

Concernant les tests fonctionnels, il est possible de mettre en œuvre des Coded UI Tests qui permettront de dérouler des scénarios préétablis de manière automatisée. En revanche, concevoir des Coded UI Tests est une tâche couteuse et complexe, cela nécessite donc d’établir au préalable la liste des scénarios critiques à vérifier.

En appliquant les recommandations d’architecture décrite dans l’article Solution de développement CRM, vous serez alors en capacité de réaliser des tests unitaires qui pourront être automatisés dans le cadre de la build TFS. Cela permet de garantir un minimum de qualité sur les développements et prévenir des régressions potentielles.

Enfin Visual Studio propose l’outillage nécessaire pour réaliser des tests de performance, la composition des tests est très simple grâce à un enregistreur d’action intégré au navigateur, permettant ainsi de collecter le scénario cible. Ensuite l’interface propose un paramétrage poussé permettant de définir les conditions précises de la montée en charge (nombre d’utilisateur, palier, durée, scénarios à réaliser, simulation de la bande passante, simulation du navigateur …). Visual Studio permet également de recueillir les métriques de performances lors du tests et de collecter des indicateurs de performances sur les machines concernées. Au final, un rapport est produit, donnant tous les détails du test pour analyse, fournissant ainsi un gain de temps précieux.

Ressources :

• Why developers need to be organised and stop wasting time : https://crmbusiness.wordpress.com/2015/03/26/why-developers-need-to-be-organised-and-stop-wasting-time/

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet : 
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) : 
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements : 
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique : 
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM : 
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils : 
   Que font les développeurs ? Comment minimiser leur effort ?

Comment sont composés les développements CRM ?

Tout d'abord, il faut bien déterminer les différents niveaux de développements :

1. Paramétrages : Il s'agit ici de la configuration spécifique apportée à l'organisation (ex : numérotation automatique, paramètres régionaux …)
2. Personnalisations : Désigne toutes les opérations liées aux entités, vues, tableaux de bord, …
3. Développements : Concerne tous les éléments éditable dans Visual Studio, à savoir : plugins, workflows, webresources, …

Les paramétrages et personnalisations doivent être réalisés dans l'interface CRM dans une solution spécifique.
Une fois les modifications appliquées et publiées, il est possible de les exporter de CRM (fichier compressé .zip) pour les livrer dans les autres environnements.

Les développements (c#, js …) sont déclarés dans la solution CRM mais doivent être réalisés dans Visual Studio.
Ces développements sont de plusieurs types (en très synthétique) :

• Plugins / Workflows : Extensions des processus CRM par le biais d'assemblies (dll) qui sont développés en C#.
• Webresources : Extensions de l'interface CRM par le biais de pages HTML et de fichiers JavaScript (js).
• Rapports : Rapports SSRS (rdl) réalisés avec SSDT Business Intelligence for Visual Studio
• Batchs : Processus permettant le chargement et la reprise de données (en c#, Powershell, ou SSIS)

Pour optimiser les développements, tous ces éléments doivent être gérés depuis une même solution technique, cela simplifiera la gestion du cycle de vie des différents composants.

Comment architecturer les développements CRM ?

L’objectif est de structurer les développements de manière à faciliter la maintenance et exploiter au maximum les couches réutilisables.
Que vous développiez un plugin, un workflow ou un batch, vous allez probablement réaliser des opérations qu’il est possible de centraliser.
Une bonne pratique consiste donc à rendre les couches suivantes centrales :

• Modèle : Couche contenant la description du métadata CRM (Entités, OptionSets, …)
• Services : Couche logique contenant les processus métiers

Ce qui donne le diagramme de dépendances suivants :

Par la suite, dans le but de réaliser des tests unitaires sur le code, on peut envisager d’ajouter une couche d’abstraction (interface) qui dériverait la couche de service vers une couche “bouchon” (mock) ;

En adoptant ce type d’architecture technique, il est possible de garantir un taux de couverture de code très élevés si l’on décentralise un maximum des traitements dans la couche de services.

Et ensuite ?

Ensuite, il faut structurer la solution de façon logique :

Late Bound ou Early Bound ?

Afin d’architecturer au mieux vos développements, il faut déterminer le mode de liaison pour la couche Model : Early Bound ou Late Bound.
Ce mode caractérise la manière donc on manipule les entités CRM au travers du code :

• Early Bound : Les classes représentés les entités sont générées avec CrmSvcUtil et peuvent être utilisés dans le code comme des objets.
• Late Bound : Les entités sont manipulables par le biais de la classe Entity et l’on accède aux champs via un dictionnaire en mentionnant explicitement le nom.

L’avantage du mode Early Bound est la capacité à manipuler les objets simplement et d’avoir l'IntelliSense dans VS, mais l’avantage du mode Late Bound est un gain important en terme de performance.

Par expérience nous préconisions le mode Late Bound et l’utilisation de l’outil CRM Model Generator pour s’approcher au maximum des avantages du Early Bound.

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet : 
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) : 
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements : 
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique : 
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM : 
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils : 
   Que font les développeurs ? Comment minimiser leur effort ?

Qui travaille sur la plateforme de dév ?

Sur une plateforme de développement, nous retrouvons différentes populations :

• Customizers : Ils réalisent les paramétrage et personnalisations de l'interface CRM (création d'entités, de champs, de formulaires, de vues, de règles métier …). Son interaction avec le système est importante, il sollicite des processus qui ralentissent la plateforme (ex : publication des personnalisations).
• Développeurs : Ils développent des composants destinés à étendre le fonctionnement standard du produit (ressources web, plugins, workflows …)
  Leur interaction avec la plateforme est très forte et rend le comportement du système instable :
  • Débogage pouvant stopper les processus et bloquer l'interface
  • Processus non finalisés provoquant des erreurs
• Testeurs : Ils vérifient le bon fonctionnement de la solution mais également la performance des processus.
• Release Managers : Ils préparent les packages et réalisent des déploiements afin de vérifier les étapes nécessaires à la procédure d'installation.

Et quels sont les impacts ?

Ces différents acteurs interagissent sur des axes différents qui rend leur cohabitation difficile voire impossible.
En terme d'organisation, il est donc nécessaire d'envisager la décomposition suivante :

• Customizers : Ils doivent travailler en amont, avant les développeurs. 
  Ils peuvent être répartis sur différents serveurs CRM Web pour limiter les effets de ralentissement.
  Ils doivent travailler sur des solutions contenant des composants différents représentant les différents domaines fonctionnels.
• Développeurs : Ils interviennent après les customizers. Idéalement, ils doivent travailler sur des serveurs séparés.
  Si ils sont nombreux, l'idéal est de leur dédier une machine virtuelle disposant de tous les composants nécessaires.
  Ainsi ils peuvent héberger leur propre environnement de développement, ce qui leur confère une certaine mobilité.
  L'avantage de la virtualisation est la capacité de restaurer un environnement complet à un instant T en un simple clic, facilitant ainsi les retours en arrière en cas de problème.
• Testeurs : Ils interviennent après les développeurs. Il est important qu'ils puissent travailler sur un environnement isolé des activités de développement.
  En effet, l'environnement doit être stable pour permettre de valider le fonctionnement de la solution mais également d'évaluer les performances.
• Release Managers : Ils interviennent à toutes les étapes de conception pour déployer les environnements nécessaires.
  Il est nécessaire de leur fournir les binaires à jour pour qu'ils puissent

Comment structurer la plateforme pour assurer les différentes activités ?

Cela nécessite donc de définir une architecture tenant compte de ces différentes problématiques mais de limiter les efforts en déploiement et maintenance.
Donc si l'on avance par étape :

1. Les customizers doivent travailler sur un même environnement CRM mais sur des serveurs Web différents.
   Ainsi, avec 2 customizers, on peut envisager la topologie suivante :
2. Les développeurs doivent être sur des environnements isolés.
   Ainsi avec 3 développeurs, l'idéal est d'héberger leur environnement de développement dans une machine virtuelle en synchronisant leur développement avec TFS :
3. Les testeurs doivent travailler sur un environnement stable.
   Supposons que nous ayons 2 testeurs, cela signifie qu'ils doivent travailler sur un environnement CRM indépendant :

Tout ça c'est très bien, mais quelle est l'architecture globale ?

Nous avons vu comment chaque type de population interagissait avec le système et les contraintes imposées à l'architecture mais à présent il nous manque la vision d'ensemble.

En effet, comment réunir toutes ces composantes et faciliter leur interaction ?

Si l'on réunit simplement les précédentes topologies nous obtenons :

Il reste donc à répondre aux questions suivantes :

1. Comment synchroniser le travail réalisé sur l'organisation 1 vers les VM de développement ?
   En effet, les développeurs ont besoin des personnalisations pour travailler.
   Par exemple, si le modèle de données évolue, les modifications doivent pouvoir être transmises rapidement sur les VM des développeurs.
2. Comment déployer les développements depuis les VM vers l'organisation 1 ?
   Il existe des dépendances entre les développements et les personnalisations comme par exemple les liens entre les formulaires et les ressources Web.
3. Comment synchroniser la dernière version stable de la solution sur l'organisation 2 ?
   Les testeurs ont besoin d'avoir l'ensemble des personnalisations et développement mais avec la garantie qu'ils soient à jour et stables.

Toutes ces questions trouvent une réponse avec TFS pour plusieurs raisons :

• Grâce à l'outil SolutionPackager il est possible de synchroniser les personnalisations de CRM dans TFS.
  Ce qui permet de :
  • Faciliter la gestion des versions applicatives au travers des branches TFS
  • Suivre et comparer les modifications des entités CRM au travers de l'historique fourni par TFS
  • Gérer les conflits lorsqu'un même élément est modifié par 2 personnes
• Avec TFS il est possible de faire de l'intégration continue, autrement dit, on peut automatiser des taches autour des sources et ainsi :
  • Déclencher des builds automatisés lors de l'archivage des modifications des customizers / développeurs afin de générer un fichier contenant la solution CRM à jour
  • Déclencher des builds régulières pour vérifier la qualité des développements (tests unitaires) et les déployer sur un environnement de test
• Et aller plus loin :
  • Provoquer l'injection de données de référence sur un environnement cible
  • Réaliser des Coded-UI Tests afin de confirmer la non-régression sur l'environnement de tests

Au final, TFS est bien au centre de notre architecture, cela devient notre référentiel des personnalisations et développements sur CRM.

En savoir plus :

• Synchronize Dynamics CRM customizations to TFS Source Control : http://blogs.msdn.com/b/aymerics_blog/archive/2015/06/06/synchronize-dynamics-crm-customizations-to-tfs-source-control.aspx
• Intégration continue et Team Foundation Server (1/2) : http://blog.soat.fr/2012/07/integration-continue-et-team-foundation-server-12/
• Intégration continue et Team Foundation Server (2/2) : http://blog.soat.fr/2012/08/integration-continue-et-team-foundation-server-22/
• Architecture applicative Dynamics CRM 2011 : http://blogs.msdn.com/b/frmcsdynamics/archive/2013/05/23/architecture-applicative-dynamics-crm-2011.aspx
• Organize your team to develop solutions : http://msdn.microsoft.com/en-us/library/gg328392.aspx

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet : 
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) : 
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements : 
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique : 
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM : 
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils : 
   Que font les développeurs ? Comment minimiser leur effort ?

Tout d'abord, comment déterminer les tâches ?

A la base, la solution technique s'élabore au regard du besoin exprimé.
Pour cela, un cahier des charges doit être rédigé pour détailler ce que la solution doit proposer.
Puis, de manière à représenter la solution en fonction de ce qu'il est possible de faire avec le produit, des ateliers sont organisés avec les référents métiers pour aboutir aux spécifications.

Toute cette partie est très bien décrite par Michael dans l'article : http://blogs.msdn.com/b/frmcsdynamics/archive/2013/02/07/animer-un-atelier-fonctionnel-crm-les-cl-233-s-de-la-r-233-ussite-partie-1.aspx

Une fois les spécifications rédigées et validées, il suffit de décomposer chaque fonctionnalités en taches.

Une tache correspond à un élément d'implémentation qui ne peut pas être réalisé par plusieurs développeur.

Par exemple, une tache peut être :

• la personnalisation d'un formulaire
• La création d'une vue
• Le développement d'un plugin
• La réalisation d'une règle métier
• …

Ensuite, où lister ces tâches ?

En méthodologie Agile, le principe est de rédiger les tâches sur des post-it.
Cela fonctionne très bien sur des petits projets où l'on peut identifier rapidement la progression globale.
Mais dans un projet plus complexe où les développeurs sont nombreux il est nécessaire de s'appuyer sur un outil.
Comme nous l'avons vu précédemment [Référence article 3], TFS propose exactement ce qu'il nous faut : les WorkItems (ou Eléments de travail).

Les WorkItems peuvent être de différents types :

• Bug
• Change Request
• Feature
• Requirement
• Risk
• Task
• Test Case
• …

Les types dépendent de la méthodologie définie pour le projet TFS, par exemple MSF for CMMI Process Improvement ou MSF for Agile Software Development.
L'injection de ces workitems peut être grandement simplifié grâce à l'intégration entre TFS et Excel ou Project.

Grâce aux types, il est possible de représenter réellement les taches à réaliser de manière structuré, car les workitems peuvent être liés les uns aux autres avec des notions de hiérarchie.
Ce qui peut donner lieu à des enchainements de ce type :

Ce qui représente parfaitement l'enchainement d'action auquel nous devons aboutir en réalité et simplifie l'exercice de planification et d'ordonnancement.

Mais, comment ventiler les tâches et éviter les conflits ?

TFS propose 3 axes de ventilation des WorkItems :

• Discipline : analyse, développement, déploiement …
• Area : L'area peut être le domaine fonctionnel CRM, comme par exemple :
  
• Iteration : L'itération peut-être la phase du projet (ex : Sprint 1, Lot 1, …) et la phase de réalisation technique, comme par exemple :

Ainsi les éléments de travail sont répartis de manière à faciliter leur assignation.
Par exemple, les taches de personnalisation d'un domaine fonctionnel spécifique peuvent être attribué à un consultant fonctionnel.
Et en parallèle, les développements de plugin d'un autre domaine fonctionnel à un autre consultant.

Dans tous les cas, les taches de personnalisation doivent être réalisées en amont des développements pour plusieurs raisons :

1. Les développements de plugin / workflow / webresource s'appuient sur le modèle de donnée et les formulaires
2. Les actions de personnalisations ralentissent la plateforme
3. Sans développements, la plateforme peut être présentée au client pour qu'il se familiarise avec et éviter l'effet tunnel
4. Les consultants fonctionnels seront plus disponibles pour assister les développeurs dans leur question sur les règles de gestion ou le client sur ses questions

Enfin, comment suivre la progression ?

Les WorkItems portent des informations relatives à leur planification :

• Priority: indique le poids de l'élément (de 1 à 4) au regard des autres
• Triage : indique par exemple si l'élément nécessite des informations de la part d'une personne
• Blocked : indique si la personne en charge de l'élément est bloquée.

Et à la charge:

• Original Estimate : Charge estimée
• Remaining Work : Charge restante
• Completed Work : Charge réalisée

Ces indicateurs offrent des informations précieuses sur la progression qui peuvent facilement être exploitées en mettant en œuvre des tableaux croisés dynamiques sous Excel :

Exemple :

En savoir plus :

• Get started using work items : https://msdn.microsoft.com/en-us/library/hh409275.aspx
• Reporting in Team Foundation Server – Part 7: Excel Reports from Work Item Queries : http://blogs.msdn.com/b/sunder/archive/2010/03/02/reporting-in-team-foundation-server-part-7-excel-reports-from-work-item-queries.aspx

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet : 
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) : 
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements : 
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique : 
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM : 
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils : 
   Que font les développeurs ? Comment minimiser leur effort ?

Tout d'abord, TFS qu'est-ce que c'est ?

Team Foundation Server est la "forge logicielle" de Microsoft.
C'est un outil permettant d'intégrer les activités liées à la gestion de cycle de vie logiciel.

TFS propose les fonctionnalités suivantes :

• Contrôle de version
• Collaboration et planification Agile
• Version
• Gestion de cas de test
• Création de rapports

De plus, TFS s'intègre à Visual Studio, Office, SharePoint et Project : ce qui décuple ces capacités de collaboration dans les processus du projet.

Mais qu'est que la gestion de cycle de vie logiciel ?

L'ALM (Application Lifecycle Management) décrit tous les processus par lesquels passe un logiciel depuis l'idée et la fin de vie.

Ainsi la gestion de cycle de vie logiciel traduit toute les activités menées à l'élaboration du logiciel selon des phases qui peuvent être cycliques :

• Analyse
  • Recueil des besoins
  • Etude de faisabilité
  • Définition des prérequis, des risques …
  • …
• Conception
  • Spécifications fonctionnelles
  • Spécifications techniques
  • Documentations d'architecture
  • …
• Réalisation
  • Paramétrages
  • Développements
  • …
• Tests
  • Tests d'intégration
  • Tests de non régression
  • Tests d'adoption utilisateur
  • …
• Déploiements
  • Livraisons
  • Mise en intégration / recette / homologation / pré-production / production
  • …

Ces phases varient selon la méthodologie adoptée en amont du projet.

Par exemple, la méthodologie Agile a pour objectif de réduire les phases décrites précédemment au plus court en procédant par itération (ou "sprint").

Cette méthodologie est souvent plébiscitée sur les projets de CRM car elle évite les effets "tunnel" en permettant aux utilisateurs de suivre de près l'évolution de la solution et d'y contribuer.

Et en quoi TFS peut nous aider ?

Dans tous projets de développement, il est impératif de s'appuyer sur un outil de gestion de source (ou "forge logicielle" ou "contrôle de code source" ou "gestion de configuration" … ).

Ce type d'outil est indispensable pour sécuriser les développements, faciliter leur maintien et permettre la collaboration en équipe grâce aux fonctions de gestion :

• de configuration,
• de build,
• de branches,
• d'usine de tests,
• d'intégration continue,
• …

En décrivant tous les processus et activités liés à la réalisation d'un logiciel, il est alors possible d'optimiser les actions et ainsi de collaborer efficacement en s'appuyant sur les fonctions offertes par un outil de gestion de sources.

Ainsi toutes les fonctionnalités présentes dans TFS font écho aux besoins que nous rencontrons dans notre contexte de développement CRM :

• Faciliter la collaboration sur les mêmes sources
• Suivre la progression des développements
• Valider la qualité de la solution

TFS doit donc être au cœur de notre architecture de développement.

En savoir plus :

• Qu’est-ce que Visual Studio Online ? https://www.visualstudio.com/products/what-is-visual-studio-online-vs
• Visual Studio ALM Ranger Solutions Catalogue : https://aka.ms/vsarsolutions
• Introducing Application Lifecycle Management Using Visual Studio : http://bit.ly/1eeqNNP
• TFS & Application Lifecycle Management : http://bit.ly/1eeqDWL
• Agile and Team Collaboration : http://bit.ly/1h8eXL3

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet : 
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) : 
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements : 
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique : 
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM : 
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils : 
   Que font les développeurs ? Comment minimiser leur effort ?

L'équipe projet est composée de différents acteurs disposant d'un rôle spécifique.

Ce rôle permet de définir précisément :

• Le périmètre d'action : ce qui diminue les risques de conflits.
• Les responsabilités : ce qui diminue les risques de "trou dans la raquette"

Ce qui permet d'assurer :

• Un bon flux de communication : chacun sait qui détient l'information et donc qui solliciter.
• Une bonne coordination : chaque rôle définit un engrenage pour le système et garantit ainsi son bon fonctionnement

Ainsi, on identifie les rôles suivants :

• Chef de projet
  Le chef de projet assure les aspects contractuels et relationnels avec le client.
  Il se charge de la définition du périmètre d'intervention, de la mise en place du planning en accord avec les contraintes du client,
  du staffing, du suivi du budget et de la consommation … etc
• Architecte
  L'architecte est le garant de la solution.
  Il se charge d'assurer la cohérence technico fonctionnelle des choix qui sont proposés au client au regard de ses besoins.
• Responsable fonctionnel (Functional Lead)
  Le responsable fonctionnel est en charge de l'intégration des besoins clients et de leur restitution dans la solution CRM.
  Son plus gros challenge et de répondre au maximum aux attentes des utilisateurs par des solutions proposées en standard.
• Responsable technique (Technical Lead)
  Le responsable technique est en charge du pilotage de l'équipe de développement.
  Il s'assure du respect du planning et de la validation technique des développements en accord avec les choix de l'architecte.
  Et enfin il définit le cadre de réalisation des développements.
• Développeur
  Le développeur a le rôle le plus important car c'est le dernier maillon de la chaine, c'est sur lui que tout repose

Mais il ne faut pas oublier aussi les rôles suivants qui peuvent être secondaires mais indispensables :

• Responsable des tests (Test Manager)
  Le responsable des tests vérifie la cohérence des développements en réalisant des scénarios fonctionnels en accord avec les spécifications.
  Ce rôle peut être réalisé par une ou plusieurs personnes, le plus important est de s'assurer que la personne qui teste une fonctionnalité ne l'ait pas développée.
• Responsable des livraison (Release Manager)
  Le responsable des livraisons assure la préparation du package avant de le fournir pour déploiement.
  Il doit au préalable rédiger et dérouler la procédure de déploiement et indiquer les étapes spécifiques aux nouvelles versions.

Ainsi, en définissant clairement les rôles (qui fait quoi) on assure une bonne coordination des acteurs du projet.
Cela évite les conflits, car les périmètres d'actions sont plus clairs.
Il faut être vigilant à toujours désigner un backup pour garantir la continuité des activités.
Cette forme de hiérarchie entre les acteurs n'est pas destinée à définir qui obéit à qui mais plus pour représenter le flux de communication.

Important : Ces différents rôles et responsabilités doivent être clairement décrits dans un RACI, partagé au sein de l'équipe mais également avec le client.

Dans le prochain article, nous verrons comment Team Foundation Server peut faciliter le pilotage du projet.

En savoir plus :

• Key Customer Roles needed for a Successful Dynamics CRM Implementation Project : http://www.crmsoftwareblog.com/2014/03/key-customer-roles-needed-for-a-successful-dynamics-crm-implementation-project/
• How To Assemble a CRM Project Team : http://www.crmsearch.com/projectteam.php

Les articles de la série “ALM - Industrialisation des développements CRM” :

1. Définition de l'équipe projet :
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) :
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements :
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique :
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM :
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils :
   Que font les développeurs ? Comment minimiser leur effort ?

Tout est en place : le budget, le planning, les ressources … Mais comment avez-vous prévu la phase de développement ?

En effet, les ressources sont prêtes et motivées mais les délais sont courts avec des coûts maitrisés et il n'y a pas de place pour l'improvisation.

C'est pourquoi nous vous proposons une série d'article destinée à vous partager les retours d'expériences que nous avons pu acquérir sur les différentes problématiques que l'on peut rencontrer dans la mise en œuvre technique d'un projet avec Microsoft Dynamics CRM.

L'objectif est de fournir les méthodes permettant de garantir les délais de réalisation et d'assurer la qualité des développements en minimisant les efforts.

Cette série d'article s'articule sur les sujets suivants :

1. Définition de l'équipe projet :
   Quels sont les différents rôles des membres d'une équipe de développements ?
2. Team Foundation Server (TFS) :
   Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
3. Organisation des développements :
   Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
4. Architecture technique :
   Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
5. Solution de développement CRM :
   Qu'impliquent ces développements et comment les structurer ?
6. Activités de développement et outils :
   Que font les développeurs ? Comment minimiser leur effort ?

Bonne lecture !

Les équipes Microsoft Services se tiennent prêtes à vous accompagner tout au long de la mise en place de votre outil CRM. Pour en savoir plus, n'hésitez pas à nous contacter, via notre formulaire de contact ou à l'adresse : servicesfr@microsoft.com.

Mais la réalisation de cette application console vous implique alors de :

• lancer Visual Studio
• créer un nouveau projet d’application console
• ajouter les références d’assemblies du SDK
• compiler
• debugguer

Ce qui est légèrement frustrant pour un besoin simple et à traiter rapidement.

Cette situation arrive régulièrement sur un projet CRM et nous avons identifié une solution permettant de répondre à cette problématique de réactivité et de flexibilité : Powershell est une technologie de Scripting intégré à Windows qui offre la possibilité d’interagir avec des assemblies .NET mais également de manipuler des objets facilement.

Ainsi il est possible de scripter ces reprises de données, simplifiant grandement la mise en œuvre de ce type d'opération.
La mise en œuvre d’un tel script est décrite dans l’article :

CRM Data Management With Powershell

La réalisation et l’exécution de script Powershell étant fulgurante, nous vous recommandons quelques précautions :

1. Exécutez en premier lieu votre script sur un environnement de test pour valider son impact sur les données
2. Pensez à afficher les informations de traitement (write-host, write-debug, ou write-progress) pour contrôler où en est et ce que fait le script

Nous vous souhaitons un excellent Scripting!

L’équipe Dynamics CRM

Les équipes Microsoft Services se tiennent prêtes à vous accompagner tout au long de la mise en place de votre outil CRM. Pour en savoir plus, n'hésitez pas à nous contacter, via notre formulaire de contact ou à l'adresse servicesfr@microsoft.com.

Rexel

Majencia

Le Havre Développement

Lacroix Electronics

Le Comité d'organisation des JO

Sinequanone

Et j’en profite aussi pour vous donner le liens de l’article du site IndiceRH.Net sur Rexel mène sa transformation numérique avec Microsoft

Les sessions des Techdays 2014 sont sorties en vidéos dernièrement, vous pourrez donc suivre l’excellente session délivrée par MCS sur la migration CRM 2013.

En effet, nos amis nous avaient concoctés cette session en abordant les différentes études à mener pour une bonne migration de CRM 2011 vers CRM 2013, nous avions eu en prime le témoignage d’un client : Rexel, que nous remercions encore pour sa participation.