Comment développer un excellent logiciel avec des méthodes agiles?
Le modèle Kano de satisfaction client définit différentes classes de caractéristiques du produit. Parmi eux,
Qualités indispensables: si elles ne sont pas mises en œuvre, le client n'acceptera pas le produit.
Qualités attrayantes (ravisseurs): caractéristiques que le client n'attend souvent même pas en premier lieu, mais provoquent l'excitation et le plaisir lorsqu'il est découvert.
Les qualités attrayantes ont évidemment beaucoup de valeur commerciale. Ils obligent les gens à acheter une Ferrari pour 500 000 alors qu'une Fiat d'occasion pour moins de 5 000 répondrait à toutes les exigences.
Cependant, tous les processus agiles que je connais privilégient fortement les exigences incontournables. Ceux-ci obtiennent toujours la priorité la plus élevée. Il ne semble même pas y avoir de place pour des qualités attrayantes en agile.
Je crois que les processus agiles sont très utiles dans le développement de logiciels. Mais comment peuvent-ils être appliqués pour créer des produits logiciels de haute qualité et pas seulement le strict minimum qui satisfait à peine les exigences incontournables?
Addendum: Comme les deux premières réponses l'ont souligné, il est logique de donner la priorité absolue aux exigences incontournables. Mais savons-nous (et le client) vraiment à l'avance quelles sont les exigences incontournables. J'ai fait plusieurs fois l'expérience que des exigences qui étaient prioritaires au début se sont avérées beaucoup moins importantes, sinon inutiles, par la suite. Par conséquent, je crois que l'on ne devrait pas se concentrer servilement sur les exigences incontournables.
La réponse formelle est que vous avez mal compris l'agilité, l'agilité ne dicte pas les exigences, les parties prenantes le font. Le cœur de l'agile n'est pas de graver vos exigences dans la pierre mais plutôt de les faire émerger au fur et à mesure, en contact étroit avec votre client, en bénéficiant d'une vision progressive.
Mais c'est toute la théorie. Ce dont vous avez été témoin est en effet un trait commun à de nombreuses chaînes de production de logiciels qui ont adopté une méthode de travail agile.
Le problème, c'est que l'écoute du client et la réponse rapide à ses besoins finissent souvent par ne plus penser au produit ou faire du design. Ce qui était autrefois un processus proactif alimenté par la vision et l'expertise peut se dégrader et devient souvent un processus passif, entièrement réactif, alimenté par les souhaits du client. Cela conduira à faire juste le strict nécessaire qui "fera le travail".
L'automobile n'aurait jamais été inventée si les constructeurs de l'époque avaient été "agiles" car tout ce que les clients demandaient était un cheval plus rapide.
Cela ne rend cependant pas l'agile mauvais. C'est un peu comme le communisme. Une excellente idée qui ne fonctionne presque jamais bien parce que les gens ne sont que des gens qui font des choses. Et la méthode/l'idéologie/la religion les endort dans l'idée qu'ils se portent bien tant qu'ils passent par les mouvements et/ou suivent les règles.
[Éditer]
Slebetman:
Il est donc ironique que l'agilité soit issue de l'industrie automobile (à savoir Toyota).
Rappelez-vous la règle d'or de l'automatisation? "Organisez d'abord, puis automatisez". Si vous automatisez un processus interrompu, le mieux qui puisse arriver est d'accélérer tout ce qui ne va pas. Les gens de Toyota n'étaient pas des idiots.
La raison typique pour adopter une nouvelle méthodologie est que les choses ne vont pas bien. La direction le reconnaît, mais elle peut ne pas comprendre les principaux problèmes. Ils embauchent donc ce gourou qui prononce un discours résilient sur Agile et Scrum. Et tout le monde aime ça. Pour leurs propres raisons.
Les développeurs peuvent penser "Hé, cela pourrait fonctionner. Nous serions plus impliqués dans les problèmes commerciaux et nous pourrions fournir des informations pour combler ce retard. Cela pourrait être l'occasion de faire comprendre aux ventes et au service client ce que nous faisons, pourquoi c'est nécessaire, et nous les aurions hors de nos cheveux pendant que nous brûlerons de manière transparente ce que nous avons convenu. " Pas plus "arrêtez ce que vous faites, cela doit être fait maintenant" par un mec que vous ne voulez pas retarder l'apparition de votre bureau.
Les ventes, le service client ou le propriétaire, d'autre part, peuvent le voir comme un moyen de reprendre (à nouveau) le contrôle de cette boîte noire d'un département qui fait probablement les choses nécessaires. Ils ne voient pas ce qui se passe là-bas mais ils sont à peu près sûrs que le cœur du problème est enfoui quelque part là-dedans. Ils présentent donc Scrum, installent un product owner de leur choix et tout d'un coup ils ont tout le contrôle, toutes les cordes sont entre leurs mains. Et maintenant? ... Ehrr ...
Le vrai problème est souvent que la boutique n'était pas bien organisée au départ et cela n'a pas changé. Les gens se sont vu attribuer des responsabilités qu'ils ne peuvent pas gérer, ou peut-être qu'ils le peuvent, mais M. Boss interfère constamment et ruine ce qu'ils ont fait, ou (le plus souvent selon mon expérience), des responsabilités cruciales n'ont été reconnues ou assignées à personne.
Parfois, avec le temps, une organisation informelle émerge entre les lignes formelles. Cela pourrait alors compenser en partie l'absence d'une structure formelle. Certaines personnes finissent par faire ce qu'elles savent faire, qu'elles aient une carte de visite pour le prouver ou non. L'introduction brutale d'Agile/Scrum peut ruiner cela instantanément. Parce que les gens doivent désormais respecter les règles. Ils sentent que ce qu'ils faisaient n'est pas apprécié, ils reçoivent à la place de petits papiers jaunes avec de petites histoires, le message sera: "quoi que vous fassiez, personne ne s'en souciait". Inutile de dire que cela ne sera pas particulièrement motivant pour ces personnes. Au mieux, ils commenceront à attendre les commandes et ne prendront plus aucune initiative.
Les choses empirent donc et la conclusion sera que l'Agile craint.
Agile ne craint pas, il est idéal pour les projets de maintenance et peut même être bon pour les nouveaux développements s'il est appliqué avec soin, mais si les mauvaises personnes ne le comprennent pas ou l'adoptent pour les mauvaises raisons, il peut être le plus destructeur.
Il ne semble même pas y avoir de place pour des qualités attrayantes en agile.
Vous comparez des pommes et des oranges. En cascade traditionnelle, si vos besoins vous obligent à avoir les indispensables, vous obtenez une Fiat. Si les exigences disent que ce doit être de premier ordre, vous obtenez une Ferrari.
La même chose se produit dans Agile. Si vos exigences s'arrêtent aux incontournables, vous obtenez une Fiat. Si vous avez des histoires d'excellence, vous obtenez une Ferrari. Tout ce qui est agile vraiment est que vous faites les choses indispensables d'abord. Pas construire un spoiler super cool pendant deux ans et ensuite manquer la date limite pour le moteur.
Pour faire court: vous obtenez ce dont vous avez besoin. Si vous prévoyez une voiture de sport, vous obtenez une voiture de sport. Agile ne change rien à cela. Si votre processus agile présente des exigences pour une Fiat, ne blâmez pas l'agile, blâmez les gars qui ont besoin d'une Fiat uniquement.
Cependant, tous les processus agiles que je connais privilégient fortement les exigences incontournables. Ceux-ci obtiennent toujours la priorité la plus élevée.
Comme il se doit - regardez à nouveau votre modèle Kano: si les exigences indispensables ne sont pas satisfaites, le client n'acceptera pas le produit. Et puis vos ravisseurs n'ont pas d'importance.
Il ne semble même pas y avoir de place pour des qualités attrayantes en agile.
Rien ne pouvait être plus loin de la vérité.
Les processus agiles mettent généralement l'accent sur ces points:
- Livraison fréquente d'un produit fonctionnel sur lequel vous pouvez obtenir des commentaires.
- Divisez les fonctions en petites parties qui peuvent être achevées en peu de temps.
- Mettez en œuvre ces parties par ordre de priorité.
Rien ne vous empêche d'accorder une priorité élevée aux fonctionnalités "délectables". Cela dépend complètement des personnes chargées de déterminer les priorités.
Maintenant, il est vrai que beaucoup de ces personnes préfèrent ne pas prendre de risques et ne donnent donc pas la priorité aux "ravisseurs". Mais dans un projet non agile, ce serait toujours le cas.
Un excellent logiciel vient de deux choses:
Donner au client ce dont il a besoin
Etre un professionnel
Il y a toutes sortes de principes à suivre lors du développement de logiciels. SEC, lisible, SOLIDE, etc. qui n'ont rien à voir avec les exigences du client. Le client a demandé une voiture de sport. Si le client comprenait ce qu'il fallait pour rendre une voiture de sport impressionnante, il n'aurait pas besoin de vous. À vous de découvrir ce qui est important.
Une partie de notre travail consiste à maintenir des normes que le client ne connaît jamais à moins que les choses tournent mal.
Si vous le faites correctement, l'agilité ne tend vers le fiat que lorsque c'est ce que le client veut vraiment. Pas quand c'est ce qu'ils pensent qu'ils doivent se contenter.
La cascade est différente car une fois qu'un malentendu sur une exigence de voiture de sport haut de gamme s'est installé, elle a tendance à persister. Agile peut faire face à de nouvelles informations et s'adapter s'il s'avère que ce dont ils ont vraiment besoin est un vélo à balle.
La cascade est toujours utilisée dans de nombreux magasins à ce jour. Ces magasins réussissent car leurs besoins évoluent moins de 2% en un an.
Votre travail ne consiste pas simplement à donner au client ce qu'il veut. C'est aussi pour s'occuper de choses pour lesquelles vous savez que vous n'obtiendrez aucun crédit. Les choses que le client ne soulèvera jamais à moins que vous ne laissiez les choses tourner horriblement mal. Ces choses feraient mieux d'être bien choisies ou vous prendrez beaucoup de merde pour y perdre du temps.
Tout idiot peut construire un pont avec un budget illimité. Un professionnel construit un pont qui ne tombe presque jamais.
Par conséquent, je pense qu'il ne faut pas se concentrer servilement sur les exigences incontournables.
Bien sûr que tu devrais. Sauf lors de l'estimation de votre temps. Parce que ces exigences incontournables ne sont pas la seule considération.
Agile ne dit rien sur quoi doit être fait en premier, seul ce code doit être écrit de manière incrémentielle et maintenu dans un état libérable aussi souvent que possible, au lieu d'être planifié comme inutilisable pendant des mois jusqu'au prochain état libérable.
J'ai travaillé à la fois dans un processus Agile et un processus BDUF (Big Design Up Front), et bien que vous puissiez certainement obtenir des fonctionnalités innovantes et attrayantes des deux processus, dans BDUF, sans surprise, vous devez les planifier à l'avance. Cela signifie que les innovations doivent généralement être proposées ou au moins parrainées par des personnes influentes dans le processus de conception.
C'est parce que vous avez six mois (ou peu importe) jusqu'à la prochaine version, et les chefs de projet sont stressés par ce qui se passe dans cette version, car si leur fonctionnalité n'entre pas, il faudra encore six mois avant la prochaine . Il y a donc une liste de fonctionnalités bondées dans un calendrier surchargé, et si le bas rang se retrouve pris à travailler pendant deux ou trois jours sur quelque chose de cool, il pense simplement que le client aimera, et ce n'est pas sur le liste, ils risquent tout le calendrier et il y aura un enfer à payer.
Dans un processus Agile, nous nous efforçons de garder le logiciel dans un état libérable, et les chefs de projet sont moins stressés parce que si leur fonctionnalité glisse, ils ne peuvent l'obtenir qu'en deux semaines. Donc, si un développeur revient d'une conférence avec une idée géniale et passe quelques jours sur quelque chose, il ne met pas en danger un calendrier écrit de six mois.
En gros, vous récoltez ce que vous semez. Si vous encouragez l'innovation et donnez aux équipes suffisamment d'autonomie pour livrer, vous l'obtiendrez. Si vous exigez constamment des raccourcis afin de respecter les délais, vous obtiendrez un logiciel adapté, quelle que soit votre méthodologie.
D'accord,
Dans Agile, le programmeur peut créer le logiciel, mais en fin de compte, c'est le propriétaire du produit qui crée le produit. (en utilisant les développeurs de logiciels.)
Donc, au sujet des "qualités attrayantes", c'est au propriétaire du produit.
Si le propriétaire du produit exige un "design sexy", cela peut être rendu obligatoire. Le développeur ne devrait pas avoir à se soucier de ces choix.
De plus, le logiciel est tellement différent des produits physiques réels que je pense qu'une grande partie du modèle Kano ne s'applique pas. Par exemple, pourquoi dois-je Facebook? Seule raison: parce que mes amis le font. Comment mettre cela dans le prochain sprint ........ Et aussi, l'une des qualités les plus attrayantes du logiciel, c'est qu'il fait réellement ce qu'il est censé faire. (Et c'est là que l'agilité aide beaucoup: P)
Mon expérience est d'accord avec les commentaires ci-dessus - il n'y a rien inhérent à Agile qui empêche le développement d'un excellent logiciel - cependant il y a plusieurs aspects de la façon dont Agile est souvent (mal) pratiqué ce qui conduit à un logiciel qui n'est que "assez bon".
- Agile met l'accent sur l'obtention de quelque chose fonctionnant le plus tôt possible; cependant, cela signifie faire des hypothèses simplificatrices et couper les coins, en particulier dans l'infrastructure non visible par l'utilisateur. Il n'y a rien de fondamentalement mauvais à ce sujet, si le coût de la correction des hypothèses simplificatrices est faible; cependant, trop souvent, cette "dette technique" n'est pas supprimée avant la mise en production d'un produit;
- Agile prêche qu'à la fin d'un sprint, vous devriez toujours avoir quelque chose d'aussi près que possible à expédier, afin que les parties prenantes et les chefs de projet puissent décider que "ce qu'ils ont" est assez bon pour pousser production. Encore une fois, rien de fondamentalement mauvais avec cela, si vous avez effacé toutes vos "dettes techniques" (ou avez fait votre paix avec combien vous avez et où c'est le cas.) Cependant, selon mon expérience, beaucoup trop de dettes techniques entrent en production avec la promesse d'un directeur que "nous allons nettoyer une fois que la pression pour expédier sera coupée", qui se transforme rapidement en "c'est en production, nous devons faire très attention à ce que nous changeons maintenant ", qui finit par devenir" Vous ne m'avez jamais dit que nous avions cette exposition! Nous devons faire un meilleur travail la prochaine fois! " La leçon de Ben Frankin sur "L'amertume de la mauvaise qualité demeure longtemps après que la douceur du prix bas est oubliée" ne semble jamais être apprise;
- Cependant, même avec des gestionnaires de confiance et des développeurs bien disciplinés, il y a le problème courant que trop peu d'analyses, de conception et revue de conception se produisent avant avant le début du sprint dans lequel la mise en œuvre devrait être lancée et terminée. L'incapacité à considérer les métaphores et les conceptions de l'interface utilisateur comme alternatives est importante - il est généralement trop coûteux de réviser cela de manière significative après le démarrage d'un projet; l'incapacité des équipes juniors à étudier attentivement les produits de leurs concurrents ou à prioriser la définition et la mise en œuvre de technologies d'infrastructure telles que I18N, les cadres de notification, la journalisation, la sécurité et les stratégies de version d'API (par exemple) signifie qu'elles auront finalement des bogues plus élevés, une productivité plus faible et une dette technique accrue, que s'ils venaient de passer les 2 à 5 premiers sprints à l'avance à effectuer la formation, l'analyse, la conception et le prototypage requis. En bref, les équipes Agile doivent résister à la licence de pirater;
- J'ai eu un gestionnaire de deuxième niveau (de plus de 100 développeurs) qui a découragé ses développeurs de prendre le temps d'écrire leurs conceptions prévues, même au niveau le plus élémentaire. Son raisonnement - "Je veux que les gens se parlent" - qui était ironique parce qu'ils étaient dans 5 fuseaux horaires différents et 3 pays. Inutile de dire qu'il y avait beaucoup de doigtés sur l'équipe qui allait devoir travailler beaucoup de nuits et de week-ends tard dans le projet une fois qu'ils avaient compris que tout le monde pensait l'autre guy était responsable de l'implémentation de certaines fonctionnalités (ou de la réimplémentation parce que les conceptions du fournisseur et du consommateur ne correspondaient tout simplement pas.)
Tout se résume vraiment à savoir si le chef de projet et les parties prenantes veulent pour fournir un produit de haute qualité. S'ils s'y sont engagés, Agile le permettra. OTOH, parce qu'Agile place la prise de décision sur le calendrier uniquement entre les mains de la partie prenante et du chef de projet, Agile rend difficile pour une équipe de développement de livrer un excellent projet sans ce soutien. En bref: la responsabilité de la qualité des produits incombe presque exclusivement aux chefs de projet.
Must-be qualitiessont souvent difficiles à déterminer. Les gens les ont en subconscience. Les itérations agiles et la participation des clients aident à trouver la plupart des incontournables. C'est le pouvoir de l'agile et il est insensé de le négliger .One-dimensional qualitiescela signifie que les promesses qui doivent être tenues, sont soutenues par la cascade OK, jusqu'à ce qu'elles ne changent pas. Ici, être agile ne fait qu'aider, mais pas avec autant de puissance.Attractive qualitiessont de belles fonctionnalités. Ils pourraient devenir des incontournables de la prochaine génération. Mais dans la génération actuelle, ils ne sont même pas dans l'accord - sinon ils seraient des qualités unidimensionnelles. Ces méthodes agiles qui supposent une participation représentative des clients soutiennent très bien ces qualités. Car nous pouvons changer légèrement la portée pendant le travail. Nous pouvons négocier l'amélioration d'un endroit pour une compensation dans un autre. En cascade, c'est pratiquement impossible. Sans un grand retard organisationnel, nous ne pouvions ajouter que des fonctionnalités gratuitement. C'est possible, si du temps supplémentaire est préalablement prévu dans le budget.
Ainsi, les processus agiles peuvent prendre en charge le modèle Kano, certains le font considérablement et certainement beaucoup mieux que les meilleurs projets en cascade.
Pour le faire beaucoup dans votre compréhension, vous devez définir des processus agiles avec un participant représentant du client responsable.
Je suis plutôt en retard à cette soirée, mais j'aimerais partager un autre angle sur ce sujet:
Mais comment peuvent-ils être appliqués pour créer des produits logiciels de haute qualité et pas seulement le strict minimum qui satisfait à peine les exigences incontournables?
Il y a un aspect temporel dans le développement de logiciel agile qui résulte de approche itérative et de considérer feedback client, qui sont deux éléments importants de la méthodologie agile . Exemple: les fonctionnalités identifiées comme qualité attrayante dans l'itération t peuvent devenir une qualité incontournable dans l'itération suivante t + 1.
L'application de méthodes agiles peut modifier dynamiquement la catégorie de qualité d'une fonction. Si vous comparez les fonctionnalités prévues de l'itération t avec les fonctionnalités finies de certaines itérations ultérieures t + n, vous constaterez exactement ce que vous avez mentionné:
J'ai fait plusieurs fois l'expérience que des exigences qui étaient prioritaires au début se sont avérées beaucoup moins importantes, sinon inutiles, par la suite.
Compte tenu de cet aspect temporel, il est plausible que les méthodes agiles puissent produire des produits logiciels de haute qualité ravissants tandis que se concentrant sur le strict minimum . Le approche itérative associé à feedback client change les règles du jeu au fil du temps.
Conclusion
Comment développer un excellent logiciel avec des méthodes agiles?
Appliquez une approche itérative et écoutez feedback client. Abandonnez l'un de ces éléments et vous obtiendrez une forme moins réussie de développement logiciel agile.
> How to develop excellent software with agile methods?
- Lors de la production d'un client spécifique logiciel individuel:
- trouver un client dont le coût n'a pas d'importance car la fonctionnalité "délicieuse" coûte de l'argent supplémentaire et le client doit décider s'il veut payer pour cela.
- Lors de la production produits logiciels:
- les fonctionnalités "délicieuses" sont bonnes pour attirer de nouveaux clients et le coût de mise en œuvre d'une fonctionnalité "délicieuse" n'est pas si important si le le produit est vendu plus de 1000 fois.
- Dans un environnement où "assez bon (le moins cher) est le meilleur", vous n'aurez pas l'argent pour implémenter des fonctionnalités "délicieuses"
Dans une équipe Scrum, le Product Owner est responsable de choisir les fonctionnalités à implémenter. C'est donc à lui (et à son budget) de définir un "bon logiciel" ou "excellent"
Vous soulevez de bons points. Mais je ne pense pas que ces problèmes soient limités aux processus/méthodologies agiles.
Il existe des opinions différentes sur ce qui est essentiel par rapport aux fonctionnalités non essentielles. Pour utiliser votre exemple, quelqu'un qui achète une voiture pourrait considérer que l'attention est une caractéristique essentielle et donc considérer une Fiat comme ne répondant pas à cette exigence indispensable.
Plus réaliste, un produit logiciel pourrait avoir besoin de certaines fonctionnalités pour répondre aux besoins de ses utilisateurs finaux réels ... mais il pourrait également avoir besoin de certaines autres fonctionnalités pour être vendu. Parce que la personne qui autorise l'achat n'est souvent pas un utilisateur final.
Par conséquent, une fonctionnalité qui n'est pas "essentielle" pour le ou les utilisateurs finaux pourrait être essentielle à la vente du produit ... et donc également essentielle à l'entreprise qui crée le produit.
Tout cela se résume au fait qu'il est essentiel d'avoir une bonne équipe de développement de produits pour définir les exigences et les priorités de manière appropriée. Mais ce n'est pas seulement vrai pour les magasins agiles.
Il est également important d'avoir des propriétaires de produits/parties prenantes autorisés à prendre des décisions. Si les décisions de votre propriétaire de produit sont constamment annulées par quelqu'un d'autre, je serais le premier à convenir que c'est un problème, mais encore une fois, ce n'est pas un problème avec l'agilité.
Il y a d'autres choses que vous voulez chez vos propriétaires de produits ... une description que j'ai entendue est "C.R.A.C.K." (collaboratif, représentatif, autorisé, engagé et compétent). Un propriétaire de produit manquant dans l'un de ces domaines peut créer des problèmes pour un projet. Mais j'ai d'abord entendu cet acronyme dans un environnement en cascade, donc clairement la douleur des mauvais clients/propriétaires de produits ne se limite pas aux magasins agiles.
Ce que l'agile peut (aider) à faire, c'est de faire ressortir certains de ces problèmes.
Par exemple, la littérature XP est IIRC assez explicite sur le fait que le "client" soit bien informé, accessible à l'équipe et autorisé à prendre des décisions. Le terme "propriétaire du produit" implique un certain niveau de connaissance , engagement et autorité.
Si vous vous trouvez dans une situation où la plupart des fonctionnalités livrées se composent de ravisseurs au lieu de fonctionnalités indispensables, il est beaucoup plus facile de soulever ce problème (et beaucoup plus facile de déterminer la cause) lorsque vous fournissez des logiciels fonctionnels ou quasi-fonctionnels tous les 2-3 semaines que lorsque les livraisons sont espacées de plusieurs mois ou années.
Si vous travaillez en petites itérations - et que vous revoyez fréquemment l'arriéré (y compris en revoyant la hiérarchisation) - cela donne à l'équipe l'occasion d'apprendre des erreurs précédentes. "Cela semble être vraiment important maintenant, mais vous vous souvenez de la navigation dynamique dont nous étions sûrs que nous n'avions pas besoin?" Comme d'autres l'ont souligné, ces discussions sont beaucoup moins probables si tout a été planifié à l'avance.
En revanche, la méthodologie de conception initiale suppose (par défaut) que la compréhension du produit et des fonctionnalités est statique. Ce n'est pas mon expérience: avoir quelque chose de tangible avec lequel travailler change presque toujours la compréhension du problème par les gens d'affaires. D'où l'accent mis sur la rétroaction rapide. (La compréhension des développeurs change également, mais cela n'affectera pas les priorités.)
Le report d'une partie de la planification vous permet également de répondre aux changements des besoins de l'entreprise. "Vous connaissez le site Web que vous êtes en train de créer? Nous en avons vraiment besoin pour être une application mobile, capable d'un fonctionnement déconnecté." Ce n'est pas quelque chose qui a été demandé spécifiquement ... mais ne voudriez-vous pas que votre processus soit capable de répondre aux changements du paysage des affaires (au moins en théorie)?
Agile ne dit pas "ne construisez pas de fonctionnalités non essentielles". Il dit "permettre à l'entreprise de décider quelles fonctionnalités (pas) construire".
... et (tout aussi important) "permettez aux techniciens de vous dire combien de temps une fonctionnalité que vous voulez mettre à construire".
TL; DR
En fait, le développement agile vous aide à augmenter la qualité du logiciel, à garder le client satisfait et à fournir un produit de grande valeur.
Le développement agile a été introduit par quelques gars intelligents pour résoudre les problèmes auxquels de nombreux projets logiciels sont confrontés dans les processus traditionnels.
Les valeurs clés du développement agile telles que définies par le manifeste agile (1) sont,
- Individus et interactions sur les processus et les outils
- Logiciel de travail sur une documentation complète
- Collaboration client sur négociation de contrat
- Répondre au changement au sujet d'un plan
Par conséquent, le développement agile ne vous empêche pas de créer des logiciels de haute qualité. Le développement agile vous aide à fournir des logiciels de haute qualité.
Mais savons-nous (et le client) vraiment à l'avance quelles sont les exigences incontournables.
Exactement. En se concentrant sur les individus, le client, le logiciel de travail et les modifications des exigences, le développement agile vous aide à comprendre ce que les clients veulent avant la livraison du produit final.
C'est une raison pour laquelle les frameworks agiles comme Scrum ont des cycles d'itération courts dont les résultats sont des produits qui fonctionnent. Vous pouvez déjà valider votre travail à un stade précoce par rapport aux attentes du client et ajuster les objectifs/exigences à la demande. Un développement agile vous aide à vous assurer de réaliser la qualité indispensable d'un produit.
À l'époque - c'est toujours vrai pour aujourd'hui - de nombreux projets logiciels développés dans des approches traditionnelles ont échoué, n'ont pas réussi ou ont causé des mécontentements chez les clients car la qualité incontournable n'a pas été atteint.
En outre, le développement agile vous aide également à atteindre une qualité attrayante . La réflexion du produit après chaque itération éclaire de nouvelles exigences qui n'étaient pas concernées par le client au démarrage du projet (qualités attractives). Cela maintient le client satisfait.
Je voudrais également mentionner les qualité inverse - attributs qui conduisent à l'insatisfaction - du modèle Kano.
Dans chaque projet, il y a des exigences qui semblent être de bonnes idées au début du projet. Après un certain temps, ils changent à l'opposé et provoquent des déceptions.
Dans un processus de développement logiciel traditionnel, vous reconnaîtrez ces exigences dans le produit final après une longue exécution du projet. Trop tard pour éviter les déceptions des clients et les changer, un projet de suivi est nécessaire.
Le développement agile vous aide à identifier précocement les exigences non fonctionnelles ou insatisfaisantes et à les modifier au cours du projet.
Comme je l'ai dit, le développement agile vous aide à augmenter la qualité du logiciel, à garder le client satisfait et à fournir un produit de grande valeur.