Release Les délais sont souvent fixes et imposés par des facteurs externes tels que les salons professionnels, les contraintes comptables ou les obligations contractuelles. Cependant, l'objectif étant de mettre un logiciel fonctionnel à la disposition des utilisateurs le plus rapidement possible afin d'apporter des corrections au plus vite, tout est mis en œuvre pour réduire au maximum les cycles de développement. Les cycles de développement agiles doivent impérativement être inférieurs à un an et sont souvent de six ou trois mois. Une version est composée d'itérations. Pour un projet donné, la durée d'une itération est généralement fixée entre une semaine et un mois. Si la version est prévue dans six mois et que les itérations durent deux semaines chacune, la version comportera 13 itérations.
Dans certains environnements, le logiciel peut être déployé auprès des utilisateurs, ou d'un sous-ensemble d'utilisateurs, de manière incrémentale à la fin de chaque itération ou toutes les deux ou trois itérations. Après avoir identifié, priorisé et, le cas échéant, estimé une liste initiale de fonctionnalités, l'équipe organise une réunion de planification des versions afin d'établir le calendrier global des déploiements et de déterminer les fonctionnalités susceptibles d'être livrées. Ce plan de déploiement global, établi en fonction des fonctionnalités priorisées, alimente ensuite directement les plans de chaque itération.
Certaines méthodes agiles insistent sur une séparation claire des responsabilités entre les développeurs et les clients. Lors de la planification, seul le client est responsable des décisions commerciales et de la priorisation, tandis que seuls les développeurs sont responsables de l'estimation des tâches et de leur exécution. Méthodes agiles Il est également fortement déconseillé à la direction d'imposer arbitrairement des choix technologiques à l'équipe de développement, et il est préférable de laisser aux développeurs la plus grande latitude possible pour choisir les meilleurs outils pour le système et le projet.
Planification préliminaire de la publication
L'objectif de la planification initiale des versions est d'estimer approximativement les fonctionnalités qui seront livrées avant la date limite (en supposant que celle-ci soit fixe), ou de choisir une date de livraison approximative pour un ensemble de fonctionnalités (si le périmètre est fixe). Ces informations nous permettent de déterminer si le projet générera un retour sur investissement suffisant pour être rentable, et donc de décider de sa poursuite.
Les réunions initiales de planification des versions durent rarement plus d'une journée, voire deux demi-journées si vous ne supportez pas de rester en réunion toute la journée. Le client présente d'abord les fonctionnalités prioritaires à livrer. Idéalement, les développeurs ont déjà établi des estimations approximatives du travail nécessaire à la mise en œuvre de chacune de ces fonctionnalités.
En se basant sur les estimations des développeurs et les priorités fonctionnelles du client, l'équipe établit un plan de déploiement, en attribuant approximativement les fonctionnalités aux premières itérations. Les développeurs peuvent constater que des fonctionnalités de faible priorité présentent des risques de conception ou d'architecture et peuvent donc demander au client d'envisager de les intégrer à des itérations antérieures, afin de gérer ces risques potentiels au plus tôt dans le projet.
Il est extrêmement utile de connaître la vélocité de l'équipe de développement lors d'une version précédente. Dans ce cas, si le périmètre est fixe, il suffit de diviser l'estimation totale des fonctionnalités requises par la vélocité de l'équipe pour obtenir le nombre approximatif d'itérations nécessaires à la livraison des fonctionnalités, et donc la date limite. Si la date limite est fixe (ce qui est généralement le cas), il faut multiplier la vélocité par le nombre d'itérations pour avoir une première idée du nombre de fonctionnalités livrables. Si la vélocité de l'équipe de développement est inconnue, celle-ci doit fournir une estimation, et le plan de livraison sera moins précis pour les premières itérations, jusqu'à l'obtention d'une valeur de vélocité fiable.
Plan de publication préliminaire
Le plan de livraison initial satisfait rarement toutes les parties prenantes : soit les fonctionnalités livrées sont insuffisantes, soit le temps nécessaire pour atteindre les objectifs fixés semble trop long. Dans un environnement agile, l’équipe affronte ces réalités et élabore un plan de développement logiciel en conséquence. Personne ne croit aux solutions miracles qui permettraient de satisfaire tout le monde. Au lieu de nier collectivement la réalité, l’équipe utilise des indicateurs concrets et la négociation pour prendre des décisions difficiles au plus près du début du projet.
Les experts en méthodes agiles s'accordent à dire que, même si c'est le cas possible Pour ajuster la portée, les délais, les ressources et la qualité d'un projet donné, seules les variables relatives aux délais et à la portée se prêtent bien à ces ajustements. De nombreuses études ont démontré que les grandes équipes ont tendance à livrer des systèmes de moindre qualité plus lentement, tandis que les petites équipes ont tendance à livrer des systèmes de meilleure qualité plus rapidement. Il peut certes être nécessaire d'ajouter des programmeurs à une équipe, mais cela risque de la ralentir temporairement, au lieu de l'accélérer. Partant de ce constat, nous acceptons que, lors de la planification des versions, nous devons ajuster soit la portée, soit les délais afin d'obtenir un plan de version acceptable pour les commanditaires, les clients, les développeurs, les gestionnaires et les autres parties prenantes. Le fait que l'équipe prenne ces décisions difficiles en amont réduit le risque global du projet. Cela augmente les chances que l'équipe produise, dans les délais impartis, un ensemble de fonctionnalités qui justifie largement l'investissement des parties prenantes.
Planification continue de la sortie
Le plan de lancement initial est volontairement sommaire. Il doit être suffisamment détaillé pour nous permettre de démarrer, en prévoyant que le projet générera un retour sur investissement suffisant pour largement couvrir ses coûts. (Si le retour sur investissement prévu par le plan de lancement initial est trop faible pour justifier le projet, nous pouvons l'annuler avant d'engager des dépenses importantes.) Dans les projets agiles, la planification est continue et nous ajustons notre stratégie au fur et à mesure. L'un des principaux mécanismes d'ajustement consiste à faire évoluer le plan de lancement en fonction des retours d'information. Il faudra au moins deux itérations pour que la vélocité de l'équipe se stabilise. Les itérations peuvent parfois livrer moins de fonctionnalités que prévu, et parfois plus. Certaines fonctionnalités, certains choix architecturaux, de conception, de framework ou de technologie peuvent s'avérer trop risqués, voire impraticables. L'interface utilisateur peut nécessiter une révision. Des membres du personnel peuvent être recrutés ou quitter l'équipe. Les priorités des fonctionnalités peuvent évoluer. Tous ces facteurs nous aideront à réviser et à affiner le plan de lancement en continu. À chaque nouvelle itération, un plan de lancement révisé, reflétant la nouvelle réalité, doit également être publié.
Démarrage et conclusion
De nombreuses équipes agiles prévoient de ne livrer qu'une petite quantité de fonctionnalités lors de la première itération (souvent appelée « itération 0 »), afin de résoudre les problèmes techniques et logistiques initiaux, et éventuellement de tester l'architecture de bout en bout. Cela peut s'avérer crucial pour les équipes peu ou pas expérimentées en méthodes agiles. Pour une équipe sans indicateur de vélocité pertinent, cela peut signifier que la vélocité ne se stabilise et ne devient fiable qu'à la fin de la deuxième ou de la troisième itération.
Certaines équipes prévoient jusqu'à deux itérations à la fin du projet pour la stabilisation, l'intégration et les tests à l'échelle du système, la correction des bogues et la finalisation de la documentation utilisateur. Dans un projet agile idéal, cela ne serait pas nécessaire, mais en pratique, cela dépend des méthodes agiles spécifiques mises en œuvre par l'équipe, de sa structure organisationnelle, de la complexité globale du système, des livrables non liés au code attendus, de la complexité du déploiement du système et d'autres facteurs similaires.
Questions Fréquentes Posées
Ai-je vraiment besoin d'utiliser des versions et un plan de publication ?
Certaines équipes peuvent s'en sortir sans planification agile au niveau des mises en production. Par exemple, un fournisseur de services applicatifs (ASP) peut simplement déployer le logiciel en production à chaque itération (c'est-à-dire toutes les quelques semaines), chaque itération constituant alors une mise en production et une planification agile simple par itération pouvant suffire. En revanche, si la direction a besoin d'une certaine visibilité au niveau du logiciel, une approche plus rigoureuse est nécessaire. gestion des versions au niveau (c’est-à-dire l’avancement, l’état, le changement par rapport au plan de développement logiciel initial, etc.), la planification et la gestion au niveau de la version peuvent alors s’avérer inestimables.
Quelle est l'ampleur des sorties ?
ReleaseLes délais de sortie varient généralement entre deux et douze mois. Pour les sorties plus longues, il peut être judicieux de les diviser en plusieurs sous-sorties.
Combien d'itérations comporte une version ?
Le nombre d'itérations au sein d'une version dépend généralement du calendrier. Si une version s'étend sur six mois et que les itérations durent deux semaines, alors 13 itérations devraient être planifiées pour cette version.
Qui participe à la planification des versions ?
Pour les petites équipes, il peut être judicieux que l'ensemble de l'équipe pluridisciplinaire participe, à la fois pour apporter sa contribution et pour garantir la responsabilisation. Pour les grandes équipes et les organisations, un sous-ensemble de l'équipe peut être sélectionné ou élu pour la représenter.
Combien de temps durent les réunions de planification des versions ?
Release Les réunions de planification durent généralement entre quatre et huit heures.
Quel est le travail préparatoire nécessaire pour une réunion de planification de version ?
En règle générale, un travail considérable a été effectué en amont d'une réunion de planification de version, notamment en matière d'approbation du projet, de budget, de vision, d'identification de l'équipe, etc. Concernant les fonctionnalités, le client a probablement consacré du temps à collaborer avec l'équipe de développement pour identifier les fonctionnalités initiales, ainsi que pour les décomposer et fournir des estimations initiales de haut niveau.
Le plan de lancement peut-il changer en cours de lancement ?
À mesure que de nouvelles informations sont découvertes, que des fonctionnalités sont déployées, que la compréhension du système s'affine, que les besoins métiers évoluent et que les priorités changent, la composition globale de la version évoluera presque certainement. Bien qu'anticipée, l'évolution de la gestion des versions logicielles devra être communiquée à toutes les parties prenantes concernées.
