La lenteur du développement affecte toutes les personnes impliquées dans le processus de développement de logiciels, y compris les clients, les développeurs, les utilisateurs finaux et les gestionnaires. Toutes les équipes de développement de logiciels souhaitent résoudre ce problème majeur : comment augmenter la vitesse de développement tout en maîtrisant les calendriers de développement sous haute pression. Dans Rapid Development, écrit par Steve McConnell, l’auteur met l’accent sur des idées de développement efficaces en examinant les stratégies de développement rapide et en étudiant les erreurs classiques dans le cadre des principes fondamentaux du développement logiciel et de la gestion des risques. Il aborde les questions essentielles du développement rapide, de la planification du cycle de vie, de l’estimation et de l’ordonnancement.
COMMENT CE LIVRE NOUS A-T-IL AIDÉS ?
Le développement rapide nous a montré comment augmenter la vitesse de développement des logiciels et a décrit les limites de la vitesse de développement afin de nous aider à disposer d’une base solide pour distinguer les programmes d’amélioration réalistes des fantasmes.
LE LIVRE EXPLIQUÉ EN MOINS DE 60 SECONDES
Le chemin tracé dans ce livre est le chemin le moins emprunté dans l’industrie d’aujourd’hui. Ce livre explique comment les équipes de développement de logiciels peuvent augmenter la vitesse de développement des logiciels, ce qui vous permet de livrer des logiciels plus rapidement. Le développement rapide met également en évidence les pratiques qui rendent les progrès visibles, ce qui vous permet de dissiper l’apparence d’un développement lent.
TROIS CITATIONS PRINCIPALES
« Choisissez vos batailles. Si le développement rapide est une priorité absolue, n’entravez pas vos développeurs en insistant sur un trop grand nombre de priorités simultanées ».
« Même si vous faites quelques bonnes choses, par exemple en utilisant largement les pratiques de programmation modernes, vous pouvez toujours commettre une erreur qui annule vos gains de productivité ».
« Des études successives ont montré que la motivation a probablement un effet plus important sur la productivité et la qualité que n’importe quel autre facteur.
RÉSUMÉS ET POINTS FORTS DES LIVRES
PARTIE I : UN DÉVELOPPEMENT EFFICACE
Premier chapitre : Bienvenue dans le développement rapide
Qu’est-ce que le développement rapide ?
Pour certains, le développement rapide implique l’application d’un seul outil ou d’une seule méthode. Pour les hackers, il s’agit d’écrire du code pendant 36 heures d’affilée. Pour un ingénieur informaticien, le RAD associe une participation approfondie de l’utilisateur, des outils CASE et des délais serrés. Toutes ces méthodes et tous ces outils sont idéaux et peuvent contribuer pleinement à accroître la vitesse de développement. Selon le livre, le développement rapide est une expression descriptive qui signifie développer des logiciels plus rapidement que les approches habituelles. Un projet de développement rapide est un projet qui doit mettre l’accent sur la vitesse de développement. À l’heure actuelle, de nombreux projets entrent dans cette catégorie.
Obtenir un développement rapide
Pour parvenir à un développement rapide, vous devez tenir compte de ces deux aspects : sélectionner des pratiques efficaces plutôt que des pratiques inefficaces et choisir des techniques orientées vers les objectifs. La vitesse de développement dépend généralement des pratiques de développement mises en place. La rapidité avec laquelle vous concevez un produit spécifique est déterminée par la mesure dans laquelle vous sélectionnez des techniques efficaces et orientées vers le calendrier. Il existe trois pratiques axées sur le calendrier : Les pratiques axées sur la vitesse, les pratiques axées sur les risques liés au calendrier et les pratiques axées sur la visibilité. Vos préoccupations concernant la vitesse de développement déterminent le type de pratiques orientées vers le calendrier que vous choisissez. Si vous pensez que vous devez augmenter votre vitesse de développement, concentrez-vous sur les pratiques axées sur la vitesse. Si vous pensez que votre vitesse est correcte, mais que c’est la perception qu’en a votre client qui pose problème, orientez votre attention vers des pratiques axées sur la visibilité.
Chapitre deux : Stratégie de développement rapide
Stratégie générale de développement rapide
Un développement rapide peut être réalisé en suivant une stratégie en quatre parties. Ces quatre parties sont les suivantes : éviter les erreurs classiques, mettre en œuvre les principes fondamentaux du développement, gérer les risques pour éviter les revers catastrophiques et mettre en œuvre des pratiques axées sur le calendrier. Mettez tous les piliers en place et faites en sorte qu’ils soient aussi solides que possible. Les trois premiers piliers déterminent dans une large mesure votre capacité à obtenir le meilleur calendrier. Les trois premiers piliers fournissent le soutien nécessaire au meilleur calendrier possible. Ce n’est peut-être pas le soutien idéal, mais c’est l’essentiel de ce qui est nécessaire. Vous pourriez être en mesure d’obtenir un emploi du temps optimal sans avoir recours à des pratiques axées sur l’emploi du temps.
Quatre dimensions de la vitesse de développement
Que vous travailliez lentement pour éviter les erreurs ou que vous alliez à grande vitesse avec les meilleures pratiques axées sur le calendrier. Votre projet de logiciel fonctionne à l’aide de quatre dimensions essentielles : le processus, les personnes, le produit et la technologie. Tout d’abord, ce sont les personnes qui, plus que tout autre facteur, ont un impact sur le développement, la productivité et la qualité des logiciels. Il est clair que toute entreprise qui souhaite améliorer sa productivité doit d’abord se pencher sur les questions liées aux personnes. Deuxièmement, le processus de développement de logiciels comprend à la fois des méthodologies techniques et des méthodologies de gestion. Le fait de se concentrer sur les processus augmente l’assurance qualité, aide à la gestion des risques et vous permet d’éviter les remaniements. Produit : il s’agit de la dimension la plus tangible. Se concentrer sur la taille et les caractéristiques du produit offre d’énormes possibilités de réduction des délais. Si vous pouvez réduire l’ensemble des caractéristiques d’un produit, vous pouvez réduire son calendrier. Enfin, la technologie : lorsque vous changez d’outils technologiques, il y a de fortes chances que vous amélioriez votre vitesse de développement. Vous pouvez passer de moyens moins efficaces à des outils plus productifs.
Chapitre trois : Quelle est la dimension la plus importante ?
Analysez votre projet pour déterminer lesquelles des quatre dimensions sont limitées et lesquelles vous pouvez exploiter au maximum. Ensuite, exploitez chaque dimension au maximum. Voilà, en résumé, la clé d’un développement rapide réussi.
Citation préférée de la partie : « La première conclusion est que nous savons maintenant avec certitude que les problèmes liés aux personnes ont plus d’impact sur la productivité et la qualité des logiciels que n’importe quel autre facteur.
PARTIE II : DÉVELOPPEMENT RAPIDE
Premier chapitre : La taille unique convient-elle à tous ?
Les exigences en matière de développement rapide varient d’un projet à l’autre, même s’ils doivent tous être développés « aussi rapidement que possible ». En général, les produits qui sont largement distribués doivent être conçus avec plus de soin que les produits qui sont étroitement distribués. Les produits dont la fiabilité est critique doivent être développés avec plus de soin que les produits dont la fiabilité est secondaire. Cela implique que vous devez personnaliser une solution adaptée à votre situation.
De quel type de développement rapide avez-vous besoin ?
L’essentiel du développement rapide consiste à déterminer le type d’approche de développement rapide que vous souhaitez. S’agit-il d’un léger avantage en termes de vitesse, d’une meilleure visibilité de l’avancement, d’un coût inférieur ou d’une plus grande prévisibilité ? De nombreuses personnes pensent avoir besoin d’un développement rapide, mais en réalité, elles ont besoin de prix plus bas et d’une plus grande prévisibilité ou d’une approche permettant d’éviter un échec tragique. Pour déterminer le type de développement rapide dont vous avez besoin, posez-vous les questions suivantes ;
- Quelle est la force de la contrainte de calendrier du produit ?
- L’importance accordée au calendrier du projet s’explique-t-elle par le fait qu’il s’agit d’un projet similaire au développement rapide ?
- Le projet présente-t-il des faiblesses qui empêchent un développement rapide ?
Les produits qui doivent se concentrer sur la vitesse de développement plutôt que sur le coût ou la prévisibilité ont une valeur temporelle différente de celle des produits typiques. Au fil du temps, la valeur des produits spécifiques diminue progressivement. Mais pour les produits soumis à de fortes contraintes de calendrier, il y a un point où ils diminuent précipitamment.
Avant d’aligner votre projet sur le calendrier le plus court plutôt que sur le coût le plus bas, le risque le plus faible ou la meilleure performance, découvrez ce dont vous avez besoin. Les projets qui ressemblent à des projets de développement rapide préconisent une vitesse de développement à toute épreuve, mais ils demandent autre chose.
Chapitre deux : Planification du cycle de vie
Un modèle de cycle de vie est un modèle prescriptif de ce qui se passe entre la première lueur et le dernier souffle. Chaque effort de développement de logiciel passe par un cycle de vie comprenant toutes les activités entre le début et la fin. Le modèle de cycle de vie le plus connu est le modèle de cycle de vie en cascade, qui comporte quelques
Il existe d’autres modèles de cycle de vie. Il existe d’autres modèles de cycle de vie et, dans de nombreux cas, ils constituent de meilleurs choix pour le développement rapide que le modèle en cascade.
Cascade pure
Le modèle en cascade est à la base d’autres modèles de cycle de vie efficaces, car il est associé à de nombreux problèmes. Dans le modèle en cascade, un projet progresse de manière ordonnée, depuis le concept initial du logiciel jusqu’aux tests du système. À la fin de chaque phase, le projet est examiné pour déterminer s’il est en mesure de passer à l’étape suivante, de l’analyse des besoins à la conception architecturale. Si l’examen montre que le projet n’est pas prêt à passer à la phase suivante, il reste à l’étape actuelle jusqu’à ce qu’il soit prêt.
Code et correction
Le modèle « code et correction » est standard mais pourrait être plus utile. Si vous n’avez pas choisi un autre modèle de cycle de vie, vous devez utiliser le modèle code-et-fixe par défaut. L’utilisation du modèle code-et-fixe signifie que vous commencez par avoir une idée générale de ce que vous voulez créer. Vous pouvez disposer d’une spécification formelle ou non. Vous utilisez ensuite toute combinaison de méthodologies informelles de conception, de codage, de débogage et de test à votre convenance jusqu’à ce que vous disposiez d’un produit prêt à être publié. Ce modèle n’a pas de frais généraux, ce qui signifie que vous ne consacrez pas de temps à la planification, à l’assurance qualité ou à la documentation autre que le codage. Il nécessite également peu d’expertise. Toute personne familiarisée avec les programmes informatiques peut utiliser le modèle « coder et corriger ».
Spirale
Ce modèle décompose un projet de logiciel en mini-projets et est fortement axé sur les risques. Chaque mini-projet aborde des risques importants jusqu’à ce qu’il n’y ait plus de risques à gérer. Dans ce contexte, le risque se rapporte à des exigences incompatibles, à des problèmes de performance, à une architecture mal comprise et à bien d’autres choses encore. Dès que les enjeux ont été traités, le modèle en spirale se termine comme le modèle en cascade. Dans le modèle en spirale, vous commencez à petite échelle au centre de la colonne vertébrale, vous identifiez et inspectez tous les risques, vous formulez un plan pour contrôler les risques et enfin vous vous engagez sur une approche pour l’itération suivante. Le modèle en spirale offre au moins autant de contrôle de gestion que le modèle traditionnel en cascade. Vous disposez de points de contrôle à la fin de chaque itération. Comme le modèle est axé sur les risques, il fournit des indications précoces sur les risques insurmontables.
Chapitre trois : Estimation
L’estimation des logiciels est assez complexe. Les cadres supérieurs et inférieurs, les clients et certains développeurs ne comprennent pas pourquoi l’estimation est si difficile. Le principe de base de l’estimation des logiciels est que le développement de logiciels est un processus d’affinement progressif. Vous commencez avec une image floue de ce que vous voulez construire et vous passez le reste du projet à essayer de clarifier cette image. Comme l’image du logiciel que vous essayez de développer est floue, l’estimation du temps et des efforts nécessaires à sa réalisation l’est également. La prévision ne peut se préciser qu’en même temps que le logiciel lui-même, ce qui signifie que l’estimation d’un projet de logiciel est également un processus d’affinement progressif.
Chapitre quatre : Programmation
Programmation trop optimiste
Les calendriers trop optimistes sont une vieille tradition dans le domaine du développement de logiciels. Tous les problèmes de programmation essentiels sont des urgences, et de nombreux projets logiciels ont besoin de plus de temps. La pression excessive exercée par le calendrier est l’influence la plus destructrice dans le domaine des logiciels. La plupart des projets établissent leurs calendriers avant que les exigences ne soient fixées et ne les établissent pas sans avoir du temps à perdre. Les causes des calendriers trop optimistes sont profondes et comprennent : les gestionnaires ou les clients qui refusent d’accepter un éventail d’estimations et qui font des propositions de projet des projets de grande envergure.
Les gestionnaires et les développeurs sous-estiment délibérément le projet parce qu’ils veulent relever un défi ou parce qu’ils aiment travailler sous pression. Les responsables et les développeurs sous-estiment délibérément le projet parce qu’ils veulent relever un défi ou qu’ils aiment travailler sous pression. Le projet est délibérément sous-estimé par la direction ou le service des ventes afin de soumettre une offre gagnante.
Surmonter la pression des calendriers
La pression du calendrier est endémique dans le développement de logiciels et a généré une pensée négative à court terme. D’une part, elle a encouragé la prise de raccourcis sur des projets particuliers, ce qui s’est traduit par des résultats médiocres. Deuxièmement, elle a suscité une mentalité de pompier à propos de la pression du calendrier elle-même. Nous ne pouvons pas résoudre le problème du développement rapide tant que nous n’avons pas résolu le problème de la pression des délais.
Citation préférée du chapitre : « Chaque effort de développement de logiciel passe par un « cycle de vie », qui comprend toutes les activités entre le moment où la version 1.0 d’un système commence sa vie comme une lueur dans l’œil de quelqu’un et le moment où la version 6.74b prend enfin son dernier souffle sur la machine du dernier client ».
TROISIÈME PARTIE : LES MEILLEURES PRATIQUES
Chapitre un : Le comité de pilotage du changement
Cette approche permet de contrôler les modifications apportées à un projet de logiciel. Un comité de changement intègre des représentants du développement, de la documentation utilisateur, de l’assurance qualité, de l’assistance à la clientèle, de la gestion et du marketing, et leur donne l’autorité suprême pour accepter ou rejeter les changements suggérés. Cette approche contribue à un développement rapide en minimisant le nombre de modifications incontrôlées du produit et en améliorant la visibilité de l’évolution des fonctionnalités. Les comités de changement peuvent être mis en place dans n’importe quel type d’environnement.
Chapitre deux : Construction quotidienne et test de fumée
Grâce au processus Daily Build and Smoke Test, un produit logiciel est construit chaque jour et testé plusieurs fois pour vérifier ses opérations primaires. Ce processus peut être mis en place dès le début du projet. Ce processus minimise les risques de retard, la faible visibilité de l’avancement et l’échec de l’intégration. Le processus fournit un contrôle critique pour les projets en mode de récupération. Son succès dépend du sérieux avec lequel les développeurs prennent l’approche et de la qualité de la conception des tests de fumée. Le processus de construction et de test quotidien peut être utilisé efficacement pour des projets de toute taille et de toute complexité. L’idée qui sous-tend le processus de construction et de test quotidien est simple : il s’agit de construire le produit et de le tester quotidiennement.
Chapitre trois : Concevoir pour le changement
Concevoir pour le changement est une mise en œuvre complète qui englobe de nombreuses pratiques de conception orientées vers le changement. Pour être efficaces, ces pratiques doivent être mises en œuvre dès les premières étapes du cycle de vie du logiciel. Le succès de cette approche dépend de l’identification des changements appropriés, de l’élaboration d’un plan de changement et de la dissimulation des décisions de conception afin que les changements ne se répercutent pas sur l’ensemble du programme. Certaines des pratiques de conception orientée vers le changement sont plus complexes qu’on ne le pense. Lorsqu’elles sont correctement mises en œuvre, ces pratiques jettent les bases de programmes durables et d’une flexibilité qui minimise les effets des demandes de changement tardives sur le calendrier. Concevoir pour le changement » ne se réfère pas à une méthodologie de conception unique, mais à une panoplie de pratiques de conception contribuant à la flexibilité des logiciels.
Chapitre quatre : Livraison évolutive
La livraison évolutive est un modèle de cycle de vie qui équilibre le contrôle de la livraison par étapes et la flexibilité du prototypage évolutif. Elle offre l’avantage d’un développement rapide en livrant des parties sélectionnées du logiciel plus tôt que possible, mais elle ne permet pas nécessairement de livrer le produit final plus rapidement. Elle permet de modifier l’orientation du produit à mi-parcours en réponse aux demandes des clients. La livraison évolutive a été utilisée avec succès pour des logiciels d’entreprise internes et des logiciels à emballage rétractable. Utilisée de manière réfléchie, elle peut permettre d’améliorer la qualité du produit, de réduire la taille du code et de répartir plus équitablement les ressources de développement et de test. Comme pour les autres modèles de cycle de vie, la livraison évolutive est une pratique qui s’applique à l’ensemble du projet : si vous souhaitez l’utiliser, vous devez commencer à planifier son utilisation dès le début du projet.
Citation préférée du chapitre : « Trop d’heures supplémentaires et de pression sur le calendrier peuvent nuire au développement.
Mais un peu d’heures supplémentaires peut augmenter la quantité de travail accomplie chaque semaine et améliorer la motivation ».
COMMENT CE LIVRE PEUT AIDER LES DÉVELOPPEURS DE LOGICIELS
« Rapid Development » de Steve McConnell est un guide complet pour les développeurs de logiciels qui fournit des conseils pratiques et des techniques pour augmenter la vitesse et l’efficacité du processus de développement de logiciels. L’ouvrage aborde divers sujets tels que la planification du projet, la collecte des besoins, la conception, le codage, les tests et la gestion de projet. Il aborde également les meilleures pratiques et stratégies pour gérer les risques, réduire les erreurs, améliorer la communication et la qualité globale des projets de développement de logiciels. M. McConnell s’appuie sur sa vaste expérience dans le domaine et fournit de nombreux exemples concrets pour illustrer ses propos. Dans l’ensemble, « Rapid Development » est une ressource précieuse pour les développeurs qui souhaitent améliorer leur productivité et la qualité de leur travail. Le livre offre des conseils pratiques et réalisables pour aider les développeurs de tous niveaux à devenir plus efficaces et efficients.
