Partilhar via

ALM - Industrialisation des développements CRM - Organisation des développements

  • Artigo

Nous avons à présent un projet qui démarre, une équipe motivée et un outil permettant de centraliser les réalisations.
A présent, il est nécessaire de répartir la charge de travail et d'associer les taches de manière à avancer efficacement.

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 : https://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.

clip_image001

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 :

clip_image002

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 :
    clip_image003
  • 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 : clip_image004

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 :

clip_image005

Exemple :

clip_image006

En savoir plus :

 

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 ?

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 .