Le d\u00e9veloppement rapide nous a montr\u00e9 comment augmenter la vitesse de d\u00e9veloppement des logiciels et a d\u00e9crit les limites de la vitesse de d\u00e9veloppement afin de nous aider \u00e0 disposer d’une base solide pour distinguer les programmes d’am\u00e9lioration r\u00e9alistes des fantasmes.<\/p>\n\n
LE LIVRE EXPLIQU\u00c9 EN MOINS DE 60 SECONDES<\/strong><\/p>\n\n Le chemin trac\u00e9 dans ce livre est le chemin le moins emprunt\u00e9 dans l’industrie d’aujourd’hui. Ce livre explique comment les \u00e9quipes de d\u00e9veloppement de logiciels peuvent augmenter la vitesse de d\u00e9veloppement des logiciels, ce qui vous permet de livrer des logiciels plus rapidement. Le d\u00e9veloppement rapide met \u00e9galement en \u00e9vidence les pratiques qui rendent les progr\u00e8s visibles, ce qui vous permet de dissiper l’apparence d’un d\u00e9veloppement lent. <\/p>\n\n TROIS CITATIONS PRINCIPALES<\/strong><\/p>\n\n \u00ab\u00a0Choisissez vos batailles. Si le d\u00e9veloppement rapide est une priorit\u00e9 absolue, n’entravez pas vos d\u00e9veloppeurs en insistant sur un trop grand nombre de priorit\u00e9s simultan\u00e9es\u00a0\u00bb.<\/p>\n\n \u00ab\u00a0M\u00eame 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\u00e9\u00a0\u00bb.<\/p>\n\n \u00ab\u00a0Des \u00e9tudes successives ont montr\u00e9 que la motivation a probablement un effet plus important sur la productivit\u00e9 et la qualit\u00e9 que n’importe quel autre facteur.<\/p>\n\n R\u00c9SUM\u00c9S ET POINTS FORTS DES LIVRES<\/strong><\/p>\n\n PARTIE I : UN D\u00c9VELOPPEMENT EFFICACE<\/strong><\/p>\n\n Premier chapitre : Bienvenue dans le d\u00e9veloppement rapide<\/strong><\/p>\n\n Qu’est-ce que le d\u00e9veloppement rapide ?<\/strong><\/p>\n\n Pour certains, le d\u00e9veloppement rapide implique l’application d’un seul outil ou d’une seule m\u00e9thode. Pour les hackers, il s’agit d’\u00e9crire du code pendant 36 heures d’affil\u00e9e. Pour un ing\u00e9nieur informaticien, le RAD associe une participation approfondie de l’utilisateur, des outils CASE et des d\u00e9lais serr\u00e9s. Toutes ces m\u00e9thodes et tous ces outils sont id\u00e9aux et peuvent contribuer pleinement \u00e0 accro\u00eetre la vitesse de d\u00e9veloppement. Selon le livre, le d\u00e9veloppement rapide est une expression descriptive qui signifie d\u00e9velopper des logiciels plus rapidement que les approches habituelles. Un projet de d\u00e9veloppement rapide est un projet qui doit mettre l’accent sur la vitesse de d\u00e9veloppement. \u00c0 l’heure actuelle, de nombreux projets entrent dans cette cat\u00e9gorie. <\/p>\n\n Obtenir un d\u00e9veloppement rapide<\/strong><\/p>\n\n Pour parvenir \u00e0 un d\u00e9veloppement rapide, vous devez tenir compte de ces deux aspects : s\u00e9lectionner des pratiques efficaces plut\u00f4t que des pratiques inefficaces et choisir des techniques orient\u00e9es vers les objectifs. La vitesse de d\u00e9veloppement d\u00e9pend g\u00e9n\u00e9ralement des pratiques de d\u00e9veloppement mises en place. La rapidit\u00e9 avec laquelle vous concevez un produit sp\u00e9cifique est d\u00e9termin\u00e9e par la mesure dans laquelle vous s\u00e9lectionnez des techniques efficaces et orient\u00e9es vers le calendrier. Il existe trois pratiques ax\u00e9es sur le calendrier : Les pratiques ax\u00e9es sur la vitesse, les pratiques ax\u00e9es sur les risques li\u00e9s au calendrier et les pratiques ax\u00e9es sur la visibilit\u00e9. Vos pr\u00e9occupations concernant la vitesse de d\u00e9veloppement d\u00e9terminent le type de pratiques orient\u00e9es vers le calendrier que vous choisissez. Si vous pensez que vous devez augmenter votre vitesse de d\u00e9veloppement, concentrez-vous sur les pratiques ax\u00e9es 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\u00e8me, orientez votre attention vers des pratiques ax\u00e9es sur la visibilit\u00e9. <\/p>\n\n Chapitre deux : Strat\u00e9gie de d\u00e9veloppement rapide<\/strong><\/p>\n\n Strat\u00e9gie g\u00e9n\u00e9rale de d\u00e9veloppement rapide<\/strong><\/p>\n\n Un d\u00e9veloppement rapide peut \u00eatre r\u00e9alis\u00e9 en suivant une strat\u00e9gie en quatre parties. Ces quatre parties sont les suivantes : \u00e9viter les erreurs classiques, mettre en \u0153uvre les principes fondamentaux du d\u00e9veloppement, g\u00e9rer les risques pour \u00e9viter les revers catastrophiques et mettre en \u0153uvre des pratiques ax\u00e9es 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\u00e9terminent dans une large mesure votre capacit\u00e9 \u00e0 obtenir le meilleur calendrier. Les trois premiers piliers fournissent le soutien n\u00e9cessaire au meilleur calendrier possible. Ce n’est peut-\u00eatre pas le soutien id\u00e9al, mais c’est l’essentiel de ce qui est n\u00e9cessaire. Vous pourriez \u00eatre en mesure d’obtenir un emploi du temps optimal sans avoir recours \u00e0 des pratiques ax\u00e9es sur l’emploi du temps. <\/p>\n\n Quatre dimensions de la vitesse de d\u00e9veloppement<\/strong><\/p>\n\n Que vous travailliez lentement pour \u00e9viter les erreurs ou que vous alliez \u00e0 grande vitesse avec les meilleures pratiques ax\u00e9es sur le calendrier. Votre projet de logiciel fonctionne \u00e0 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\u00e9veloppement, la productivit\u00e9 et la qualit\u00e9 des logiciels. Il est clair que toute entreprise qui souhaite am\u00e9liorer sa productivit\u00e9 doit d’abord se pencher sur les questions li\u00e9es aux personnes. Deuxi\u00e8mement, le processus de d\u00e9veloppement de logiciels comprend \u00e0 la fois des m\u00e9thodologies techniques et des m\u00e9thodologies de gestion. Le fait de se concentrer sur les processus augmente l’assurance qualit\u00e9, aide \u00e0 la gestion des risques et vous permet d’\u00e9viter les remaniements. Produit : il s’agit de la dimension la plus tangible. Se concentrer sur la taille et les caract\u00e9ristiques du produit offre d’\u00e9normes possibilit\u00e9s de r\u00e9duction des d\u00e9lais. Si vous pouvez r\u00e9duire l’ensemble des caract\u00e9ristiques d’un produit, vous pouvez r\u00e9duire son calendrier. Enfin, la technologie : lorsque vous changez d’outils technologiques, il y a de fortes chances que vous am\u00e9lioriez votre vitesse de d\u00e9veloppement. Vous pouvez passer de moyens moins efficaces \u00e0 des outils plus productifs. <\/p>\n\n Chapitre trois : Quelle est la dimension la plus importante ?<\/strong><\/p>\n\n Analysez votre projet pour d\u00e9terminer lesquelles des quatre dimensions sont limit\u00e9es et lesquelles vous pouvez exploiter au maximum. Ensuite, exploitez chaque dimension au maximum. Voil\u00e0, en r\u00e9sum\u00e9, la cl\u00e9 d’un d\u00e9veloppement rapide r\u00e9ussi. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e de la partie : \u00ab\u00a0La premi\u00e8re conclusion est que nous savons maintenant avec certitude que les probl\u00e8mes li\u00e9s aux personnes ont plus d’impact sur la productivit\u00e9 et la qualit\u00e9 des logiciels que n’importe quel autre facteur.<\/em><\/strong><\/p>\n\n PARTIE II : D\u00c9VELOPPEMENT RAPIDE<\/strong><\/p>\n\n Premier chapitre : La taille unique convient-elle \u00e0 tous ?<\/strong><\/p>\n\n Les exigences en mati\u00e8re de d\u00e9veloppement rapide varient d’un projet \u00e0 l’autre, m\u00eame s’ils doivent tous \u00eatre d\u00e9velopp\u00e9s \u00ab\u00a0aussi rapidement que possible\u00a0\u00bb. En g\u00e9n\u00e9ral, les produits qui sont largement distribu\u00e9s doivent \u00eatre con\u00e7us avec plus de soin que les produits qui sont \u00e9troitement distribu\u00e9s. Les produits dont la fiabilit\u00e9 est critique doivent \u00eatre d\u00e9velopp\u00e9s avec plus de soin que les produits dont la fiabilit\u00e9 est secondaire. Cela implique que vous devez personnaliser une solution adapt\u00e9e \u00e0 votre situation. <\/p>\n\n De quel type de d\u00e9veloppement rapide avez-vous besoin ?<\/strong><\/p>\n\n L’essentiel du d\u00e9veloppement rapide consiste \u00e0 d\u00e9terminer le type d’approche de d\u00e9veloppement rapide que vous souhaitez. S’agit-il d’un l\u00e9ger avantage en termes de vitesse, d’une meilleure visibilit\u00e9 de l’avancement, d’un co\u00fbt inf\u00e9rieur ou d’une plus grande pr\u00e9visibilit\u00e9 ? De nombreuses personnes pensent avoir besoin d’un d\u00e9veloppement rapide, mais en r\u00e9alit\u00e9, elles ont besoin de prix plus bas et d’une plus grande pr\u00e9visibilit\u00e9 ou d’une approche permettant d’\u00e9viter un \u00e9chec tragique. Pour d\u00e9terminer le type de d\u00e9veloppement rapide dont vous avez besoin, posez-vous les questions suivantes ; <\/p>\n\n Les produits qui doivent se concentrer sur la vitesse de d\u00e9veloppement plut\u00f4t que sur le co\u00fbt ou la pr\u00e9visibilit\u00e9 ont une valeur temporelle diff\u00e9rente de celle des produits typiques. Au fil du temps, la valeur des produits sp\u00e9cifiques diminue progressivement. Mais pour les produits soumis \u00e0 de fortes contraintes de calendrier, il y a un point o\u00f9 ils diminuent pr\u00e9cipitamment. <\/p>\n\n Avant d’aligner votre projet sur le calendrier le plus court plut\u00f4t que sur le co\u00fbt le plus bas, le risque le plus faible ou la meilleure performance, d\u00e9couvrez ce dont vous avez besoin. Les projets qui ressemblent \u00e0 des projets de d\u00e9veloppement rapide pr\u00e9conisent une vitesse de d\u00e9veloppement \u00e0 toute \u00e9preuve, mais ils demandent autre chose. <\/p>\n\n Chapitre deux : Planification du cycle de vie<\/strong><\/p>\n\n Un mod\u00e8le de cycle de vie est un mod\u00e8le prescriptif de ce qui se passe entre la premi\u00e8re lueur et le dernier souffle. Chaque effort de d\u00e9veloppement de logiciel passe par un cycle de vie comprenant toutes les activit\u00e9s entre le d\u00e9but et la fin. Le mod\u00e8le de cycle de vie le plus connu est le mod\u00e8le de cycle de vie en cascade, qui comporte quelques <\/p>\n\n Il existe d’autres mod\u00e8les de cycle de vie. Il existe d’autres mod\u00e8les de cycle de vie et, dans de nombreux cas, ils constituent de meilleurs choix pour le d\u00e9veloppement rapide que le mod\u00e8le en cascade. <\/p>\n\n Cascade pure<\/strong><\/p>\n\n Le mod\u00e8le en cascade est \u00e0 la base d’autres mod\u00e8les de cycle de vie efficaces, car il est associ\u00e9 \u00e0 de nombreux probl\u00e8mes. Dans le mod\u00e8le en cascade, un projet progresse de mani\u00e8re ordonn\u00e9e, depuis le concept initial du logiciel jusqu’aux tests du syst\u00e8me. \u00c0 la fin de chaque phase, le projet est examin\u00e9 pour d\u00e9terminer s’il est en mesure de passer \u00e0 l’\u00e9tape suivante, de l’analyse des besoins \u00e0 la conception architecturale. Si l’examen montre que le projet n’est pas pr\u00eat \u00e0 passer \u00e0 la phase suivante, il reste \u00e0 l’\u00e9tape actuelle jusqu’\u00e0 ce qu’il soit pr\u00eat. <\/p>\n\n Code et correction<\/strong><\/p>\n\n Le mod\u00e8le \u00ab\u00a0code et correction\u00a0\u00bb est standard mais pourrait \u00eatre plus utile. Si vous n’avez pas choisi un autre mod\u00e8le de cycle de vie, vous devez utiliser le mod\u00e8le code-et-fixe par d\u00e9faut. L’utilisation du mod\u00e8le code-et-fixe signifie que vous commencez par avoir une id\u00e9e g\u00e9n\u00e9rale de ce que vous voulez cr\u00e9er. Vous pouvez disposer d’une sp\u00e9cification formelle ou non. Vous utilisez ensuite toute combinaison de m\u00e9thodologies informelles de conception, de codage, de d\u00e9bogage et de test \u00e0 votre convenance jusqu’\u00e0 ce que vous disposiez d’un produit pr\u00eat \u00e0 \u00eatre publi\u00e9. Ce mod\u00e8le n’a pas de frais g\u00e9n\u00e9raux, ce qui signifie que vous ne consacrez pas de temps \u00e0 la planification, \u00e0 l’assurance qualit\u00e9 ou \u00e0 la documentation autre que le codage. Il n\u00e9cessite \u00e9galement peu d’expertise. Toute personne familiaris\u00e9e avec les programmes informatiques peut utiliser le mod\u00e8le \u00ab\u00a0coder et corriger\u00a0\u00bb. <\/p>\n\n Spirale<\/strong><\/p>\n\n Ce mod\u00e8le d\u00e9compose un projet de logiciel en mini-projets et est fortement ax\u00e9 sur les risques. Chaque mini-projet aborde des risques importants jusqu’\u00e0 ce qu’il n’y ait plus de risques \u00e0 g\u00e9rer. Dans ce contexte, le risque se rapporte \u00e0 des exigences incompatibles, \u00e0 des probl\u00e8mes de performance, \u00e0 une architecture mal comprise et \u00e0 bien d’autres choses encore. D\u00e8s que les enjeux ont \u00e9t\u00e9 trait\u00e9s, le mod\u00e8le en spirale se termine comme le mod\u00e8le en cascade. Dans le mod\u00e8le en spirale, vous commencez \u00e0 petite \u00e9chelle au centre de la colonne vert\u00e9brale, vous identifiez et inspectez tous les risques, vous formulez un plan pour contr\u00f4ler les risques et enfin vous vous engagez sur une approche pour l’it\u00e9ration suivante. Le mod\u00e8le en spirale offre au moins autant de contr\u00f4le de gestion que le mod\u00e8le traditionnel en cascade. Vous disposez de points de contr\u00f4le \u00e0 la fin de chaque it\u00e9ration. Comme le mod\u00e8le est ax\u00e9 sur les risques, il fournit des indications pr\u00e9coces sur les risques insurmontables. <\/p>\n\n Chapitre trois : Estimation<\/strong><\/p>\n\n L’estimation des logiciels est assez complexe. Les cadres sup\u00e9rieurs et inf\u00e9rieurs, les clients et certains d\u00e9veloppeurs ne comprennent pas pourquoi l’estimation est si difficile. Le principe de base de l’estimation des logiciels est que le d\u00e9veloppement 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 \u00e0 essayer de clarifier cette image. Comme l’image du logiciel que vous essayez de d\u00e9velopper est floue, l’estimation du temps et des efforts n\u00e9cessaires \u00e0 sa r\u00e9alisation l’est \u00e9galement. La pr\u00e9vision ne peut se pr\u00e9ciser qu’en m\u00eame temps que le logiciel lui-m\u00eame, ce qui signifie que l’estimation d’un projet de logiciel est \u00e9galement un processus d’affinement progressif. <\/p>\n\n Chapitre quatre : Programmation<\/strong><\/p>\n\n Programmation trop optimiste<\/strong><\/p>\n\n Les calendriers trop optimistes sont une vieille tradition dans le domaine du d\u00e9veloppement de logiciels. Tous les probl\u00e8mes de programmation essentiels sont des urgences, et de nombreux projets logiciels ont besoin de plus de temps. La pression excessive exerc\u00e9e par le calendrier est l’influence la plus destructrice dans le domaine des logiciels. La plupart des projets \u00e9tablissent leurs calendriers avant que les exigences ne soient fix\u00e9es et ne les \u00e9tablissent pas sans avoir du temps \u00e0 perdre. Les causes des calendriers trop optimistes sont profondes et comprennent : les gestionnaires ou les clients qui refusent d’accepter un \u00e9ventail d’estimations et qui font des propositions de projet des projets de grande envergure. <\/p>\n\n Les gestionnaires et les d\u00e9veloppeurs sous-estiment d\u00e9lib\u00e9r\u00e9ment le projet parce qu’ils veulent relever un d\u00e9fi ou parce qu’ils aiment travailler sous pression. Les responsables et les d\u00e9veloppeurs sous-estiment d\u00e9lib\u00e9r\u00e9ment le projet parce qu’ils veulent relever un d\u00e9fi ou qu’ils aiment travailler sous pression. Le projet est d\u00e9lib\u00e9r\u00e9ment sous-estim\u00e9 par la direction ou le service des ventes afin de soumettre une offre gagnante. <\/p>\n\n Surmonter la pression des calendriers<\/strong><\/p>\n\n La pression du calendrier est end\u00e9mique dans le d\u00e9veloppement de logiciels et a g\u00e9n\u00e9r\u00e9 une pens\u00e9e n\u00e9gative \u00e0 court terme. D’une part, elle a encourag\u00e9 la prise de raccourcis sur des projets particuliers, ce qui s’est traduit par des r\u00e9sultats m\u00e9diocres. Deuxi\u00e8mement, elle a suscit\u00e9 une mentalit\u00e9 de pompier \u00e0 propos de la pression du calendrier elle-m\u00eame. Nous ne pouvons pas r\u00e9soudre le probl\u00e8me du d\u00e9veloppement rapide tant que nous n’avons pas r\u00e9solu le probl\u00e8me de la pression des d\u00e9lais. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Chaque effort de d\u00e9veloppement de logiciel passe par un \u00ab\u00a0cycle de vie\u00a0\u00bb, qui comprend toutes les activit\u00e9s entre le moment o\u00f9 la version 1.0 d’un syst\u00e8me commence sa vie comme une lueur dans l’\u0153il de quelqu’un et le moment o\u00f9 la version 6.74b prend enfin son dernier souffle sur la machine du dernier client\u00a0\u00bb.<\/em><\/strong><\/p>\n\n TROISI\u00c8ME PARTIE : LES MEILLEURES PRATIQUES<\/strong><\/p>\n\n Chapitre un : Le comit\u00e9 de pilotage du changement<\/strong><\/p>\n\n Cette approche permet de contr\u00f4ler les modifications apport\u00e9es \u00e0 un projet de logiciel. Un comit\u00e9 de changement int\u00e8gre des repr\u00e9sentants du d\u00e9veloppement, de la documentation utilisateur, de l’assurance qualit\u00e9, de l’assistance \u00e0 la client\u00e8le, de la gestion et du marketing, et leur donne l’autorit\u00e9 supr\u00eame pour accepter ou rejeter les changements sugg\u00e9r\u00e9s. Cette approche contribue \u00e0 un d\u00e9veloppement rapide en minimisant le nombre de modifications incontr\u00f4l\u00e9es du produit et en am\u00e9liorant la visibilit\u00e9 de l’\u00e9volution des fonctionnalit\u00e9s. Les comit\u00e9s de changement peuvent \u00eatre mis en place dans n’importe quel type d’environnement. <\/p>\n\n Chapitre deux : Construction quotidienne et test de fum\u00e9e<\/strong><\/p>\n\n Gr\u00e2ce au processus Daily Build and Smoke Test, un produit logiciel est construit chaque jour et test\u00e9 plusieurs fois pour v\u00e9rifier ses op\u00e9rations primaires. Ce processus peut \u00eatre mis en place d\u00e8s le d\u00e9but du projet. Ce processus minimise les risques de retard, la faible visibilit\u00e9 de l’avancement et l’\u00e9chec de l’int\u00e9gration. Le processus fournit un contr\u00f4le critique pour les projets en mode de r\u00e9cup\u00e9ration. Son succ\u00e8s d\u00e9pend du s\u00e9rieux avec lequel les d\u00e9veloppeurs prennent l’approche et de la qualit\u00e9 de la conception des tests de fum\u00e9e. Le processus de construction et de test quotidien peut \u00eatre utilis\u00e9 efficacement pour des projets de toute taille et de toute complexit\u00e9. L’id\u00e9e 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. <\/p>\n\n Chapitre trois : Concevoir pour le changement<\/strong><\/p>\n\n Concevoir pour le changement est une mise en \u0153uvre compl\u00e8te qui englobe de nombreuses pratiques de conception orient\u00e9es vers le changement. Pour \u00eatre efficaces, ces pratiques doivent \u00eatre mises en \u0153uvre d\u00e8s les premi\u00e8res \u00e9tapes du cycle de vie du logiciel. Le succ\u00e8s de cette approche d\u00e9pend de l’identification des changements appropri\u00e9s, de l’\u00e9laboration d’un plan de changement et de la dissimulation des d\u00e9cisions de conception afin que les changements ne se r\u00e9percutent pas sur l’ensemble du programme. Certaines des pratiques de conception orient\u00e9e vers le changement sont plus complexes qu’on ne le pense. Lorsqu’elles sont correctement mises en \u0153uvre, ces pratiques jettent les bases de programmes durables et d’une flexibilit\u00e9 qui minimise les effets des demandes de changement tardives sur le calendrier. Concevoir pour le changement\u00a0\u00bb ne se r\u00e9f\u00e8re pas \u00e0 une m\u00e9thodologie de conception unique, mais \u00e0 une panoplie de pratiques de conception contribuant \u00e0 la flexibilit\u00e9 des logiciels. <\/p>\n\n Chapitre quatre : Livraison \u00e9volutive<\/strong><\/p>\n\n La livraison \u00e9volutive est un mod\u00e8le de cycle de vie qui \u00e9quilibre le contr\u00f4le de la livraison par \u00e9tapes et la flexibilit\u00e9 du prototypage \u00e9volutif. Elle offre l’avantage d’un d\u00e9veloppement rapide en livrant des parties s\u00e9lectionn\u00e9es du logiciel plus t\u00f4t que possible, mais elle ne permet pas n\u00e9cessairement de livrer le produit final plus rapidement. Elle permet de modifier l’orientation du produit \u00e0 mi-parcours en r\u00e9ponse aux demandes des clients. La livraison \u00e9volutive a \u00e9t\u00e9 utilis\u00e9e avec succ\u00e8s pour des logiciels d’entreprise internes et des logiciels \u00e0 emballage r\u00e9tractable. Utilis\u00e9e de mani\u00e8re r\u00e9fl\u00e9chie, elle peut permettre d’am\u00e9liorer la qualit\u00e9 du produit, de r\u00e9duire la taille du code et de r\u00e9partir plus \u00e9quitablement les ressources de d\u00e9veloppement et de test. Comme pour les autres mod\u00e8les de cycle de vie, la livraison \u00e9volutive est une pratique qui s’applique \u00e0 l’ensemble du projet : si vous souhaitez l’utiliser, vous devez commencer \u00e0 planifier son utilisation d\u00e8s le d\u00e9but du projet. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Trop d’heures suppl\u00e9mentaires et de pression sur le calendrier peuvent nuire au d\u00e9veloppement.<\/em><\/strong><\/p>\n\n Mais un peu d’heures suppl\u00e9mentaires peut augmenter la quantit\u00e9 de travail accomplie chaque semaine et am\u00e9liorer la motivation\u00a0\u00bb.<\/em><\/strong><\/p>\n\n COMMENT CE LIVRE PEUT AIDER LES D\u00c9VELOPPEURS DE LOGICIELS<\/strong><\/p>\n\n \u00ab\u00a0Rapid Development\u00a0\u00bb de Steve McConnell est un guide complet pour les d\u00e9veloppeurs de logiciels qui fournit des conseils pratiques et des techniques pour augmenter la vitesse et l’efficacit\u00e9 du processus de d\u00e9veloppement 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 \u00e9galement les meilleures pratiques et strat\u00e9gies pour g\u00e9rer les risques, r\u00e9duire les erreurs, am\u00e9liorer la communication et la qualit\u00e9 globale des projets de d\u00e9veloppement de logiciels. M. McConnell s’appuie sur sa vaste exp\u00e9rience dans le domaine et fournit de nombreux exemples concrets pour illustrer ses propos. Dans l’ensemble, \u00ab\u00a0Rapid Development\u00a0\u00bb est une ressource pr\u00e9cieuse pour les d\u00e9veloppeurs qui souhaitent am\u00e9liorer leur productivit\u00e9 et la qualit\u00e9 de leur travail. Le livre offre des conseils pratiques et r\u00e9alisables pour aider les d\u00e9veloppeurs de tous niveaux \u00e0 devenir plus efficaces et efficients. <\/p>\n","protected":false},"excerpt":{"rendered":" La lenteur du d\u00e9veloppement affecte toutes les personnes impliqu\u00e9es dans le processus de d\u00e9veloppement de logiciels, y compris les clients, les d\u00e9veloppeurs, les utilisateurs finaux et les gestionnaires. Toutes les \u00e9quipes de d\u00e9veloppement de logiciels souhaitent r\u00e9soudre ce probl\u00e8me majeur : comment augmenter la vitesse de d\u00e9veloppement tout en ma\u00eetrisant les calendriers de d\u00e9veloppement sous […]<\/p>\n","protected":false},"author":1,"featured_media":21596,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[102],"tags":[],"writer":[],"class_list":["post-19985","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-de-lecture"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/comments?post=19985"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19985\/revisions"}],"predecessor-version":[{"id":19987,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19985\/revisions\/19987"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media\/21596"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media?parent=19985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/categories?post=19985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/tags?post=19985"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/writer?post=19985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/james-harrison-UVMPVIRCF5w-unsplash-1024x576.jpg\")
<\/figure>\n\n![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/saffu-E4kKGI4oGaU-unsplash-edited.jpg\")
<\/figure>\n\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/brett-jordan-XAX8vCM5G6o-unsplash-edited-scaled.jpg\")
<\/figure>\n\n