Le cycle itératif

AmauryOrganisation d'équipe4 commentaires sur Le cycle itératif

Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.

Cycle itératif

Définition

Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :

  • L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
  • Le coeur du processus itératif :
    • Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
    • Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
    • Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
    • Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
  • Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.

Le cycle en V

AmauryOrganisation d'équipe10 commentaires sur Le cycle en V

Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

Cycle en V - théorie

On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Les différentes étapes

Le cycle en V est constitué de 9 étapes qui ont toutes leur importance.

De la modélisation à la réalité

AmauryOrganisation personnelleLaissez un commentaire sur De la modélisation à la réalité

La gestion de projet – et l’organisation en général – est une discipline très intéressante. On rencontre rarement deux fois la même situation. Entre les clients, les demandes fonctionnelles, les ressources disponibles, le facteur humain… les variables sont trop nombreuses. Et pourtant, on continue à chercher à modéliser les flux d’information en entreprise, on tente d’améliorer sans cesse la manière dont les projets naissent et vivent, on espère secrètement trouver la formule miracle qui fonctionnera à tous les coups et qui nous permettra de gérer les choses de manière optimale dans toutes les conditions.

Mais entre nous, franchement, on sait que ce n’est pas possible, hein ? Eh bien… c’est ce qu’on va voir.

Un modèle ?

D’après le dictionnaire, un modèle est une « représentation théorique d’un système d’éléments et de relations plus ou moins complexes ». Si la définition vous intéresse, vous pouvez toujours aller lire l’article consacré à la théorie des modèles sur Wikipédia. Un exemple : En électronique, on utilise des modèles mathématiques pour simuler le comportement de composants ; ces modèles ne sont pas « vrais » dans la mesure où ces composants ont une réponse différente de celle du modèle, mais cela permet à la fois de simplifier les simulations et de savoir vers quoi doit tendre le fonctionnement des composants réels.

Échelle différente, problèmes similaires

AmauryVotre carrièreLaissez un commentaire sur Échelle différente, problèmes similaires

Une des choses que j’ai apprises au fil des années et des expériences professionnelles, c’est que les problèmes rencontrés sont globalement les mêmes quel que soit le niveau où l’on se situe. Ce n’est qu’une question d’échelle.

Prenons l’exemple qui nous intéresse particulièrement : la gestion de projet.

  • Un développeur éprouve souvent des difficultés à faire son travail dans de bonnes conditions. Ce qu’on lui demande de faire est très imprécis. Il a beau essayer de faire du mieux qu’il peut, ses supérieurs trouvent toujours quelque chose à lui reprocher (ce n’est pas fait assez vite, ce n’est pas fait assez bien, ce n’est pas fait dans le bon ordre…).
  • Un chef de projet s’arrache régulièrement les cheveux. Il a plusieurs projets à gérer simultanément, chacun étant classé « haute priorité ». Les demandes des clients sont systématiquement incomplètes. Les développeurs ne sont pas disciplinés et font ce qu’ils veulent quand ils le veulent.
  • Un directeur technique doit réussir à trier les différents projets, les affecter aux chefs de projets, suivre de près leur évolution. Il enrage souvent de ne pas avoir les remontées d’informations nécessaires pour anticiper les problèmes, de devoir pallier à la non-organisation de l’ensemble de ses collaborateurs et de passer plus de temps à « résoudre » et « corriger » qu’à « préparer » et « produire ».

Je ne vais pas expliquer maintenant comment il faut s’organiser pour gérer les projets (il y aura plusieurs autres billets sur ce blog à ce sujet). Mais ne voyez-vous pas qu’il y a des tendances qui sont les mêmes ?

Je vois 3 choses fondamentales :

  • L’information entrante : Elle n’est jamais satisfaisante. Si ce sont des spécifications, fonctionnelles ou techniques, elles sont incomplètes. Si c’est une liste de tâches à réaliser ou un ordre de mission, il n’est pas suffisamment clair. La question reste « Qu’est-ce que je dois faire ??? » (et par ricochet quand on doit gérer une équipe : « Qu’est-ce que je dois déléguer ? »).
  • L’organisation : Principalement, cela consiste à savoir qui fait quoi, et dans quel ordre. Et parce qu’elle est – à tort – considérée comme uniquement personnelle, l’organisation est souvent laissée à l’écart des processus globaux de gestion des projets. C’est une erreur, car c’est là que se joue la productivité des collaborateurs d’une entreprise.
  • L’information sortante : Il n’y a jamais de situation réellement insoluble en entreprise. Mais c’est par la qualité de nos remontées d’information que les problèmes pourront être anticipés, que les projets vivront correctement dans la durée, que nous devenons acteurs au lieu de spectateurs.

Ces trois points restent immuables, quels que soient votre poste et vos responsabilités.