Tâche: Définir l'organisation et le personnel du projet
Cette tâche aborde la nécessité de déterminer le personnel requis pour un projet, ainsi que son organisation.
Disciplines: Gestion de projet
Objet
  • Définir une structure organisationnelle pour le projet
  • En fonction des efforts estimés, définir le personnel nécessaire (nombre, type et expérience) pour la prochaine itération (avec un niveau de confiance élevé) et pour les itérations suivantes (avec un niveau de confiance moins élevé), afin de pouvoir planifier le recrutement, si nécessaire
Relations
Etapes
Définition de l'organisation du projet
Objet Définir la structure organisationnelle du projet en termes de postes, d'équipes, de responsabilités et de hiérarchie. 

Le choix de la structure organisationnelle du projet dépend des caractéristiques du projet et de contraintes extérieures comme les règles organisationnelles existantes. Par conséquent, il est difficile d'être trop précis dans la définition de cette structure, car ce qui est applicable, ou même réalisable, dépend beaucoup du contexte. Les  Instructions : Plan de développement du logiciel énumèrent les questions à aborder et proposent une structure de projet par défaut qui peut être adaptée en fonction des besoins spécifiques du projet. Cette structure par défaut suggère aussi une correspondance des rôles RUP (Rational Unified Process) avec les postes définis dans l'organisation. La forme et la taille de l'organisation du projet varie selon les phases, et le Plan de développement logiciel est un document dynamique qui est mis à jour en fonction de ces changements.

Définition des exigences en termes de personnel
Objet Définir le personnel nécessaire pour le projet : nombre, type (compétences, domaine), expérience et niveau 

En fonction des efforts estimés pour le projet, du planning souhaité, de la structure organisationnelle choisie et de la correspondance des rôles, le responsable de projet détermine le profil du personnel (nombre et compétences requises) pour le projet. Bien évidemment, l'estimation des efforts n'est pas indépendante de la taille de l'équipe, de son expérience, de ses compétences et de son niveau : dans la plupart des cas, le responsable de projet a déjà une idée des capacités de l'équipe avant d'estimer les efforts nécessaires. Dans le Modèle d'estimation COCOMO (voir Tâche : Planifier les phases et les itérations), les capacités et l'expérience du personnel sont des éléments clés. Par conséquent, le choix d'un effort total acceptable (grâce à l'ajustement des paramètres d'effort COCOMO) et d'un planning réalisable seront déterminants pour la définition du profil du personnel.

Parfois, le responsable de projet sait à l'avance de combien de personnes et de quelles compétences il pourra disposer. Dans ce cas, si le nombre de personnes et les compétences sont fixes, seul le planning est variable (en supposant que la portée du projet ne change pas).

Le responsable de projet doit également être conscient des perturbations qui peuvent être occasionnées par une augmentation trop rapide du nombre d'employés, ainsi que des effets catastrophiques que peut produire une réduction importante des délais associée à une multiplication du personnel.

Définition du personnel nécessaire pour les phases de création et d'élaboration

Lors de la phase de création, il s'agit de définir et de délimiter la portée et de développer une étude de rentabilité pour le projet. Par conséquent, l'équipe est relativement réduite : un responsable de projet, un architecte logiciel et éventuellement un ou deux développeurs, surtout si un prototype du concept est nécessaire pour clarifier les exigences ou mettre en place un support pour le produit.

Lors de l'élaboration, l'équipe se concentre sur l'architecture et sur le prototype d'architecture. Par conséquent, les tâches de conception au début de l'élaboration sont principalement liées aux aspects architecturaux : les classes et leurs attributs sont identifiés mais ne sont pas détaillés car ils présentent peu d'importance sur le plan architectural. Lors de ces itérations, les principaux acteurs sont votre équipe architecturale et une équipe de prototypage que vous aurez désignée. Cette dernière est généralement composée de programmeurs expérimentés. A ce stade, vous disposez d'une équipe de conception très restreinte, qui se concentre sur les technologies et les mécanismes génériques. Le groupe de test se charge de la création de l'environnement de test et du test des premiers cas d'utilisation.

Il convient de choisir soigneusement les membres de l'équipe d'architecture : ils doivent présenter de bonnes compétences d'analyse et de conception, mais également faire preuve de capacités de leadership. Pour communiquer l'architecture choisie à une équipe plus vaste lors de la phase de construction, il peut être judicieux de répartir les membres de l'équipe d'architecture entre les différentes équipes de construction. Les membres de l'équipe d'architecture doivent également justifier d'une solide expérience en ingénierie logicielle : la conception et l'implémentation de logiciels, l'ajustement des performances, la gestion de bases de données, la gestion de réseaux et la gestion de la configuration sont des compétences essentielles qui doivent être représentées au sein de l'équipe d'architecture.

Définition du personnel nécessaire pour la phase de construction

La phase de construction a pour vocation de garantir l'intégrité architecturale du système, tout en lui ajoutant de nouvelles fonctionnalités. Elle nécessite un affinage de l'architecture (c'est pour cette raison que suite à la phase d'élaboration, on crée une référence plutôt que de "geler" l'architecture) et un suivi des activités des concepteurs de la part de l'équipe d'architecture.

Généralement, l'équipe d'architecture est répartie entre les différentes équipes de développement, chacun de ses membres jouant le rôle de responsable technique et coordonnant les problèmes entre les groupes avec les autres responsables techniques. Les équipes de construction doivent être inter-fonctionnelles et réunir à la fois des compétences de conception et de développement, car elles sont chargées de la conception et de l'implémentation des fonctionnalités dont elles ont la responsabilité. Généralement, une équipe de construction est responsable d'un ou plusieurs sous-systèmes avec des interfaces bien définies : toute modification apportée à l'interface ou tout ajout d'un nouveau sous-système entraîne des changements architecturaux et doit donc faire l'objet d'une attention particulière. Au sein du sous-système, l'équipe est relativement libre de concevoir et d'implémenter comme elle l'entend, mais une bonne communication entre les équipes est nécessaire pour s'assurer qu'un même mécanisme d'implémentation n'est pas mis en place en parallèle.

Les équipes de construction sont généralement organisées de manière horizontale, selon les couches. Par exemple, une équipe peut être responsable des interfaces avec la base de données ou de l'infrastructure de communication, alors que d'autres équipes se concentrent sur les fonctionnalités de l'application. Par conséquent, les équipes chargées de la couche "supérieure" doivent avoir davantage d'expérience dans le domaine, mais aussi en termes de conception d'interface utilisateur et d'interface avec les systèmes extérieurs. Les équipes chargées de la couche "inférieure" sont davantage tournées vers les technologies d'implémentation. La composition des équipes doit tenir compte de ces compétences requises.

Définition du personnel nécessaire pour les tâches de test

Il convient dans un premier temps de déterminer la quantité de tests formels à exécuter. Vous devez ensuite évaluer le nombre de tests à effectuer pour remplir vos objectifs de qualité tout en restant dans des limites raisonnables du point de vue du coût et du planning. Il est rare qu'un projet dispose du budget nécessaire pour effectuer tous les types de tests prévus. Vous devez donc déterminer le niveau de test envisageable. N'oubliez pas que chaque spécification de test doit être contrôlée et gérée. Il n'est pas bon pour le moral de l'équipe de prévoir le développement d'un grand nombre de spécifications de test, puis de ne pas pouvoir les implémenter par manque de temps.

Créez une équipe de test spécifique. Au moins une personne de l'équipe de test doit venir de l'équipe de définition des exigences. L'équipe de test est responsable des :

  • Tests fonctionnels. Il s'agit de tester les cas d'utilisation en dehors du système, en utilisant le flux d'événements du cas (voir Produit : Cas d'utilisation).
  • Tests structurels. Il s'agit de tester l'envoi de messages dans le cas d'utilisation, en utilisant les vues de séquence des scénarios.
  • Tests système. Il s'agit d'accroître la charge du système pour révéler sa véritable nature.

N'oubliez pas qu'il ne s'agit pas simplement d'exécuter les tests : vous devez également préparer l'environnement de test et contrôler les spécifications de test.

Il est souhaitable qu'un groupe indépendant teste les cas d'utilisation et l'ensemble du système. Ce groupe devra également exécuter les tests et rédiger les rapports de test. Il convient d'organiser le test des cas d'utilisation, de telle sorte qu'une personne soit responsable de chaque cas d'utilisation.

Pour les petits projets, il n'est pas toujours réalisable de faire tester les cas d'utilisation par un groupe indépendant. Dans ce cas, vous devez au moins vous assurer que le cas d'utilisation n'est pas testé par une personne qui a participé à sa conception.

Pour les projets de moyenne ou de grande envergure, il est préférable d'avoir recours à des tests de régression automatisés. Dans ce cas, l'équipe de test aura besoin de l'assistance de quelques programmeurs. Cela est particulièrement important pour le développement itératif, pour éviter de réexécuter les mêmes suites de tests.

Définition du personnel nécessaire pour la phase de transition

Au stade de la phase de transition, le travail de développement est terminé. Le test de la version bêta est effectué et une version finale est préparée. Si la phase de construction s'est déroulée dans de bonnes conditions, l'équipe projet peut alors commencer à se restreindre et notamment le nombre de développeurs et de testeurs peut diminuer. L'équipe sera désormais constituée en majorité de formateurs et d'experts en logistique d'infrastructure, responsables du déploiement du produit au sein de la communauté d'utilisateurs.

L'architecte du logiciel, ou l'équipe d'architecture, travaille en "mode suivi", pour aider à résoudre les rapports de problème, hiérarchiser les propositions de changement et s'assurer que les problèmes ne sont pas résolus dans l'urgence au détriment de l'architecture. Les tâches de conception deviennent plus rares lors de la phase de transition et se limitent à la correction des problèmes ou à l'ajout d'améliorations de dernière minute.