Release les délais sont souvent fixes, imposés de l'extérieur par des éléments tels que des salons professionnels, des pressions comptables ou des obligations contractuelles. Mais puisque l'objectif est de mettre le logiciel fonctionnel entre les mains des utilisateurs le plus rapidement possible afin de faire des «corrections de cap» dès que possible, tous les efforts sont faits pour garder release des cycles de développement logiciel aussi courts que possible. Agile release les cycles doivent certainement être inférieurs à un an et sont souvent aussi courts que six mois ou trois mois. UN release est, à son tour, composé d'itérations. Pour un projet donné, la durée d'itération sera généralement fixée entre une semaine et un mois. Si la release est dans six mois et les itérations vont durer deux semaines chacune, le release comportera 13 itérations.
Dans certains environnements, les logiciels peuvent être livrés aux utilisateurs, ou au moins à un sous-ensemble d'utilisateurs, de manière incrémentielle à la fin de chaque itération ou toutes les deux itérations. Une fois qu'une liste initiale de fonctionnalités a été identifiée, hiérarchisée et éventuellement estimée, l'équipe tient une release réunion de planification pour établir l'ensemble release planifier et déterminer les fonctionnalités susceptibles d'être livrées. L'ensemble release plan en termes de fonctionnalités prioritaires est ensuite utilisé pour alimenter directement les plans d'itération individuels.
Certaines méthodes agiles mettent l'accent sur une séparation claire des responsabilités entre les programmeurs et les clients. Lors de la planification, seul le client est responsable des décisions commerciales et de la priorisation et seuls les programmeurs sont responsables de l'estimation des tâches et de l'exécution du développement. Méthodes agiles découragent également fortement la direction d'imposer de manière capricieuse des choix technologiques au groupe de développement, donnant plutôt aux développeurs autant de latitude que possible pour choisir les meilleurs outils pour le système et le projet.
Préliminaire release et la planification de votre patrimoine
L'objectif initial release la planification consiste à estimer approximativement les fonctionnalités qui seront fournies par le release date limite (en supposant que la date limite est fixée), ou pour choisir une date de livraison approximative pour un ensemble de fonctionnalités donné (si la portée est fixe). Nous utilisons ces informations pour décider si le projet produira ou non suffisamment de retour sur investissement pour au moins s'autofinancer, et donc si nous devons ou non continuer.
Initiales release les réunions de planification durent rarement plus d'une journée – ou deux demi-journées si vous ne supportez pas de rester en réunion une journée entière. Dans un premier temps, le client présente les fonctionnalités prioritaires à livrer. Idéalement, les développeurs ont déjà élaboré des estimations approximatives de la quantité de travail nécessaire pour implémenter chacune de ces fonctionnalités.
En utilisant les estimations des développeurs et les priorités des fonctionnalités du client, l'équipe établit un release plan, mappant les fonctionnalités très grossièrement aux premières itérations. Les développeurs peuvent trouver que des fonctionnalités assez peu prioritaires présentent des risques de conception ou d'architecture, et peuvent donc demander aux clients d'envisager de les affecter à des itérations antérieures de toute façon, afin de traiter ces risques potentiels le plus tôt possible dans le projet.
Il est extrêmement utile que la vélocité de l'équipe de développement sur un précédent release est déjà connu. Dans ce cas, si la portée est fixe, vous divisez l'estimation totale pour toutes les fonctionnalités requises par la vitesse de l'équipe pour fournir le nombre approximatif d'itérations nécessaires pour fournir la fonctionnalité, et donc le délai. Si le délai est fixe (comme c'est généralement le cas), vous multipliez la vélocité par le nombre d'itérations pour avoir une première idée du nombre de fonctionnalités pouvant être livrées. Si la vélocité de l'équipe de développement n'est pas connue, elle doit en fournir une estimation, et le release Le plan doit être compris comme étant moins précis pour les premières itérations, jusqu'à ce qu'un nombre de vitesse fiable puisse être dérivé.
Préliminaire release plan
La première release Le plan satisfait rarement toutes les parties – soit il n'y a pas assez de fonctionnalités fournies, soit il semble qu'il faille trop de temps pour fournir les fonctionnalités souhaitées. Mais dans le monde agile, l'équipe regarde ces dures vérités en face et développe un plan de développement logiciel autour d'elles. Personne ne croit aux miracles de portée qui satisferont tout le monde. Au lieu de pratiquer le déni collectif, l'équipe utilise des mesures réelles et la négociation pour faire des choix difficiles aussi près que possible du début du projet.
Les leaders d'opinion agiles s'accordent à dire que même s'il est possible Pour ajuster la portée, le délai, les ressources et la qualité d'un projet donné, les seules variables qui répondent bien à l'ajustement sont le délai et la portée. Des recherches approfondies ont montré que les grandes équipes ont tendance à fournir des systèmes de qualité inférieure plus lentement, tandis que les petites équipes ont tendance à fournir des systèmes de qualité supérieure plus rapidement. Il peut en effet être nécessaire d'ajouter des programmeurs à une équipe, mais cela risque de ralentir l'équipe pendant au moins un certain temps, pas de l'accélérer. Une fois que nous acceptons ces conclusions, nous acceptons que dans notre release planification, il faut ajuster soit le périmètre, soit le délai pour produire un release plan qui est accepté comme réalisable par les sponsors, les clients, les développeurs, les managers et les autres parties prenantes. Le fait que l'équipe fasse ces choix difficiles dès le départ réduit le risque global pour le projet. Cela augmente les chances que l'équipe produise un ensemble de fonctionnalités qui rapporte plus qu'adéquatement l'investissement des parties prenantes avant la date limite.
Planifier le release continuellement
La première release le plan est considéré comme approximatif. Il doit être suffisamment détaillé uniquement pour nous permettre de démarrer, en prédisant que le projet générera un retour sur investissement suffisant pour plus que le payer. (Si la première release plan prédit un retour sur investissement trop faible pour justifier le projet, alors nous pouvons annuler le projet avant de gaspiller beaucoup d'argent.) Dans les projets agiles, nous planifions en continu et nous corrigeons notre trajectoire au fur et à mesure. L'un des principaux mécanismes de correction de cap est de permettre au release prévoir d'évoluer en réponse à toutes sortes de commentaires. Il faudra au moins quelques itérations pour que la vitesse de l'équipe se stabilise. Les itérations offriront parfois moins de fonctionnalités que prévu, et parfois plus. Les fonctionnalités, les choix architecturaux, les choix de conception ou les choix de cadre ou de technologie peuvent s'avérer trop risqués ou tout simplement irréalisables. L'interface utilisateur peut nécessiter une révision. Le personnel peut être perdu ou ajouté. Les priorités des fonctionnalités peuvent changer. Tous ces facteurs nous aideront à réviser et à affiner le release planifier en permanence. Lors de la publication de chaque nouveau plan d'itération, une version révisée release plan qui reflète la nouvelle réalité.
Démarrage et conclusion
De nombreuses équipes agiles prévoient de ne fournir qu'une petite quantité de fonctionnalités dans la première itération (souvent appelée "itération 0"), afin de permettre explicitement de résoudre les problèmes techniques et logistiques initiaux, et peut-être aussi de stresser l'architecture de bout en bout. Cela peut être critique pour les équipes qui ont peu ou pas d'expérience agile. Pour une équipe sans bonne métrique de vitesse, cela peut signifier que ce n'est qu'à la fin de la deuxième ou de la troisième itération que la vitesse est devenue stable et fiable.
Certaines équipes planifient également jusqu'à deux itérations à la clôture du projet pour la stabilisation, l'intégration et les tests à l'échelle du système, la correction des bogues et l'achèvement de la documentation utilisateur. Dans un projet agile idéal, cela ne serait pas nécessaire, mais dans le monde réel, cela dépend des pratiques agiles spécifiques suivies par l'équipe, de la structure organisationnelle, de la complexité globale du système, des livrables non codés attendus de l'équipe, de la complexité du système deployment, et des facteurs similaires.
FAQ
Ai-je vraiment besoin d'utiliser releases et a release plan?
Certaines équipes peuvent s'en sortir sans planification agile au release niveau. Par exemple, un ASP peut simplement livrer un logiciel en production à chaque itération (c'est-à-dire toutes les quelques semaines), ainsi chaque itération est effectivement un release et une simple planification agile par itération peut suffire. Si, d'autre part, un certain niveau de visibilité est requis par la direction au niveau du logiciel release gestion niveau (c'est-à-dire progrès, statut, changement par rapport au plan de développement logiciel initial, etc.), puis releasela planification et la gestion au niveau de l'entreprise peuvent être inestimables.
Quelle est la taille releases?
Releases varient généralement entre deux et 12 mois. Pour longtemps releases, il peut être judicieux de le décomposer en plusieurs sous-releases.
Combien y a-t-il d'itérations dans un release?
Le nombre d'itérations dans un release est généralement déterminé par le calendrier. Si un release est de six mois, et les itérations sont de deux semaines, alors 13 itérations doivent être programmées pour le release.
Qui participe à release planification?
Pour les petites équipes, il peut être judicieux que toute l'équipe interfonctionnelle participe à la fois à des fins de contribution et de responsabilité. Pour les grandes équipes et organisations, un sous-ensemble de l'équipe peut être sélectionné ou élu pour représenter l'équipe.
Combien de temps release les réunions de planification durent-elles ?
Release les réunions de planification durent généralement entre quatre et huit heures.
Combien de travail est effectué en préparation d'un release Réunion de planification?
Généralement, beaucoup de travail a été fait avant une release réunion de planification en termes d'approbation de projet, de budgétisation, de vision, d'identification d'équipe, etc. En ce qui concerne la fonctionnalité, le client a probablement passé du temps à travailler avec le développement pour identifier les fonctionnalités initiales, ainsi que potentiellement pour les décomposer et fournir des estimations de niveau.
Est-ce que release changement de plan pendant la release?
Au fur et à mesure que davantage d'informations sont découvertes, que des fonctionnalités sont fournies, que l'on comprend mieux le système, que les besoins de l'entreprise évoluent et que les priorités changent, la composition globale du release va presque certainement changer. Bien qu'anticipée, l'évolution des logiciels release la gestion au fil du temps devra être communiquée à toutes les parties prenantes appropriées.
