Comment développer un excellent logiciel avec des méthodes agiles?

Le modèle de satisfaction client Kano définit différentes classes de caractéristiques de produit. Parmi eux se trouvent

1. Qualités indispensables: si elles ne sont pas mises en œuvre, le client n'acceptera pas le produit.

2. Qualités attrayantes (délices): caractéristiques que le client n'attend souvent même pas en premier lieu, mais qui suscitent émotion et plaisir lorsqu'il est découvert.

Les qualités attrayantes ont évidemment beaucoup de valeur ajoutée. Ils obligent les gens à acheter une Ferrari pour 500 000 euros alors qu’une Fiat usagée pour moins de 5 000 répondrait à toutes les exigences indispensables.

Cependant, tous les processus agiles que je connais privilégient fortement les exigences impératives. Ceux-ci ont toujours la plus haute priorité. Il ne semble même pas y avoir de place pour des qualités attrayantes dans l'agile.

Je pense 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 ravissants, et pas seulement le strict minimum qui satisfait à peine aux exigences requises?

Addendum: Comme le soulignent les deux premières réponses, il est logique d'accorder la plus haute priorité aux exigences indispensables. Mais nous (et le client) savons toujours toujours à l’avance quelles sont les exigences indispensables. J'ai fait l'expérience à quelques reprises que les exigences qui avaient été hautement prioritaires au début se sont révélées beaucoup moins importantes, voire inutiles, plus tard. Par conséquent, je crois qu’il ne faut pas se focaliser servilement sur les exigences impératives.

La réponse officielle est que vous comprenez mal agile, agile ne dicte pas les exigences, mais les parties prenantes. Le cœur de l’agile n’est pas de cerner vos exigences dans le marbre, mais de les faire émerger au fur et à mesure, en contact étroit avec votre client, en tirant parti des connaissances progressives.

Mais c'est toute la théorie. Ce que vous avez observé 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 le fait d’écouter le client et de répondre rapidement à ses besoins finit souvent par ne pas faire l’objet d’une réflexion sur le produit ou la conception. Ce qui était auparavant un processus proactif alimenté par une vision et une expertise peut et va souvent dégénérer en un processus passif et entièrement réactif alimenté par les souhaits du client. Cela conduira à ne faire que le strict nécessaire pour "faire le travail".

L’automobile n’aurait jamais été inventée si les fabricants de l’époque avaient été "agiles", car tous les clients demandaient un cheval plus rapide.

Cela ne rend pas agile mal cependant. C'est un peu comme le communisme. Une bonne idée qui ne marche jamais très bien parce que les gens ne sont que des gens qui font des choses. Et la méthode / idéologie / religion les induit dans l’idée qu’ils se débrouillent bien tant qu’ils respectent les règles et / ou suivent les règles.

[modifier]

Slebetman:

Il est ironique que l’agile ait évolué hors de l’industrie automobile (à savoir Toyota).

Rappelez-vous la règle d'or de l'automatisation? "Tout d'abord organiser, puis automatiser". 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 problèmes fondamentaux. Alors ils embauchent ce gourou qui donne 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 cet arriéré. Cela pourrait être une opportunité de faire en sorte que les ventes et le service client comprennent ce que nous faisons, pourquoi il est nécessaire, et nous les aurions hors de nos cheveux pendant que nous brûlions de manière transparente ce que nous avions convenu. " Pas plus "arrêtez ce que vous faites, cela doit être fait maintenant" par un mec que vous ne voulez pas retarder d'apparaître à votre bureau.

D'autre part, les ventes, le service clientèle ou le propriétaire peuvent y voir un moyen de prendre (de nouveau) le contrôle de cette boîte noire d'un département censé faire ce qui est nécessaire. Ils ne voient pas ce qui se passe là-bas, mais ils sont à peu près certains que le cœur du problème est enterré quelque part. Ils présentent donc Scrum, installent un produit propriétaire de leur choix et tout à coup, ils ont tout le contrôle, toutes les chaînes sont dans leur main. Maintenant quoi? ... Ehrr ...

Le vrai problème est souvent que le magasin n’était pas bien organisé et que cela n’a pas changé. Des responsabilités ont été assignées à des personnes qu’elles ne peuvent pas assumer, ou peut-être qu’elles le peuvent, mais M. Boss intervient constamment en ruinant ce qu’elles ont fait ou, le plus souvent, les responsabilités cruciales n’ont été reconnues ni attribuées à qui que ce soit.

Parfois, au fil du temps, une organisation informelle émergera entre les lignes formelles. Cela peut alors compenser en partie l’absence de structure formelle. Certaines personnes finissent par faire ce qu’elles sont bonnes, qu’elles aient une carte de visite pour le prouver ou non. L'introduction émoussée de Agile / Scrum peut ruiner instantanément. Parce que les gens sont maintenant tenus de respecter les règles. Ils sentent que ce qu’ils faisaient n’est pas apprécié, ils reçoivent des petits papiers jaunes avec de petites histoires, le message sera: "quoi que vous fassiez, personne ne se 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.

Donc, les choses empirent et la conclusion sera que Agile craint.

Agile ne craint pas, il est excellent pour les projets de maintenance et peut même être utile pour les nouveaux développements s’il est appliqué avec prudence, mais si les mauvaises personnes ne le comprennent pas ou ne l’adoptent pas pour les mauvaises raisons, il peut être très destructeur.

Il ne semble même pas y avoir de place pour des qualités attrayantes dans l'agile.

Vous comparez des pommes et des oranges. Dans les cascades traditionnelles, si vous avez besoin de l'essentiel, vous obtenez une Fiat. Si les exigences indiquent qu'il doit être de qualité supérieure, vous obtenez une Ferrari.

La même chose se passe dans Agile. Si vos exigences s’arrêtent à l'essentiel, vous obtenez une Fiat. Si vous avez des histoires d'excellence, vous obtenez une Ferrari. Tout ce AGILE vraiment fait respecter est que vous faites les must have premier . Ne construisez pas de spoiler super cool pendant deux ans, puis ratez l’échéance du moteur.

Si longue histoire courte: vous obtenez ce dont vous avez besoin. Si vous planifiez une voiture de sport, vous en obtenez une. Agile ne change rien à cela. Si votre processus agile impose des exigences pour une Fiat, ne blâmez pas agile, blâmez les personnes qui exigent uniquement une Fiat.

Cependant, tous les processus agiles que je connais privilégient fortement les exigences impératives. Ceux-ci ont toujours la plus haute priorité.

Comme il se doit - regardez à nouveau votre modèle Kano: si les exigences impératives ne sont pas satisfaites, le client n'acceptera pas le produit. Et puis vos ravisseurs ne comptent pas.

Il ne semble même pas y avoir de place pour des qualités attrayantes dans l'agile.

Rien ne pourrait être plus éloigné de la vérité.

Les processus agiles mettent généralement l'accent sur les points suivants:

• Livraison fréquente d'un produit fonctionnel sur lequel vous pouvez obtenir des commentaires.
• Divisez les fonctionnalités en petites parties pouvant être complétées rapidement.
• Implémentez ces parties par ordre de priorité.

Rien ne vous empêche de donner une grande priorité aux fonctionnalités "de plaisir". Cela dépend complètement des personnes qui sont chargées de déterminer les priorités.

Or, il est vrai que beaucoup de ces personnes préfèrent ne pas prendre de risques et peuvent donc ne pas accorder la priorité aux "ravisseurs". Mais dans un projet non-agile, ce serait toujours le cas.

Agile ne dit rien sur ce qu'il faut faire en premier. Seul le code doit être écrit de manière incrémentielle et conservé dans un état pouvant être libéré aussi souvent que possible, au lieu d'être prévu pour être inutilisable pendant des mois jusqu'au prochain état pouvant être libéré.

J'ai travaillé à la fois selon un processus agile et un processus BDUF (Big Design Up Front) et, bien que vous puissiez obtenir des fonctionnalités innovantes et attrayantes à partir 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.

Ceci est dû au fait que vous avez six mois (ou autre) jusqu'à la prochaine version, et que les chefs de projet sont stressés par le contenu de cette version, car si leur fonctionnalité n'entre pas, il faudra encore six mois avant la prochaine. . Il y a donc toute une liste de fonctionnalités dans un programme très chargé, et si la modeste base est prise au piège de travailler pendant deux ou trois jours avec quelque chose de sympa, elle pense simplement que le client l'aimera, et ce n'est pas sur la liste, ils risquent tout le calendrier et il y aura l'enfer à payer.

Dans un processus agile, nous nous efforçons de maintenir le logiciel dans un état pouvant être relâché et les chefs de projet sont moins stressés, car si leurs fonctionnalités leur échappent, ils ne pourront l'obtenir que dans deux semaines. Ainsi, si un développeur revient d'une conférence avec une idée géniale et consacre quelques jours à quelque chose, il ne met pas en péril un calendrier de six mois.

En gros, vous récoltez ce que vous semez. Si vous encouragez l'innovation et donnez aux équipes une autonomie suffisante pour réussir, vous l'obtiendrez. Si vous exigez constamment de prendre des raccourcis afin de respecter les délais, vous obtiendrez un logiciel adapté, quelle que soit votre méthodologie.

Un excellent logiciel provient de deux choses:

• Donner au client ce dont il a besoin

• Être un professionnel

Il y a toutes sortes de principes à suivre lors du développement d'un logiciel. SEC, lisible, solide, etc., qui n’a 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 géniale, il n'aurait pas besoin de vous. C'est à vous de déterminer ce qui est important.

Notre travail consiste en partie à respecter des normes que le client ne respecte jamais, à moins que les choses tournent terriblement mal.

Si vous le faites bien, alors l'agile tend vers le fiat uniquement lorsque c'est ce que le client veut vraiment. Pas quand ils pensent qu'ils doivent se contenter de ça.

La cascade est différente parce qu’une fois qu’un malentendu s’est installé à propos des exigences d’une voiture de sport haut de gamme, il a tendance à rester. Agile peut faire face à de nouvelles informations et s’adapter s’il s'avère que ce dont ils ont vraiment besoin, c’est d’un vélo «balle».

La cascade est encore utilisée dans de nombreux magasins à ce jour. Ces magasins ont du succès car leurs besoins changent de 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 n'évoquera jamais à moins que vous ne laissiez les choses aller horriblement mal. Ces choses avaient intérêt à être bien choisies ou vous prendrez beaucoup de merde pour perdre du temps sur elles.

N'importe quel idiot peut construire un pont avec un budget illimité. Un professionnel construit un pont qui ne tombe presque jamais.

Par conséquent, je crois qu’il ne faut pas se focaliser servilement sur les exigences impératives.

Bien sr que tu devrais. Sauf lors de l'estimation de votre temps. Parce que ces impératifs ne sont pas la seule considération.

D'accord,

Dans Agile, le programmeur peut créer le logiciel, mais c'est finalement le propriétaire du produit qui crée le produit. (en utilisant les développeurs de logiciels.)

Donc, à propos des "qualités attrayantes", cela appartient au propriétaire du produit.

Si le propriétaire du produit impose le "design sexy", cela peut devenir une exigence. Le développeur ne devrait pas avoir à s'inquiéter de ces choix.

En outre, les logiciels sont si différents des produits physiques réels que, selon moi, une grande partie du modèle Kano ne s'applique pas. Par exemple, pourquoi je facebook? Seule raison: parce que mes amis le font. Comment mettre cela dans le prochain sprint ........ Et l'une des qualités les plus attrayantes du logiciel, c'est qu'il fait ce qu'il est censé faire. (Et c'est là que l'agile aide beaucoup: P)

Mon expérience est en accord avec les commentaires ci-dessus - rien n’est inhérent à Agile qui n’empêche le développement d’excellents logiciels - mais il existe plusieurs aspects de la façon dont Agile est souvent (mal) pratiqué, ce qui conduit à un logiciel qui est seulement "assez bon". . "

• Agile met l’accent sur l’obtention rapide de quelque chose qui fonctionne; Cependant, cela implique de simplifier les hypothèses et de réduire les coûts, en particulier dans l'infrastructure non visible par l'utilisateur. Il n’ya rien de mal à cela, si le coût de la correction des hypothèses simplificatrices est peu coûteux; cependant, trop souvent, cette "dette technique" n’est pas éliminé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’excellent à livrer, afin que les parties prenantes et les responsables de projet puissent décider que «ce qu’ils ont» est suffisamment bon pour être intégré. production. Encore une fois, rien de fondamentalement faux avec cela, sivous avez effacé toute votre "dette technique" (ou avez fait la paix avec ce que vous avez et où elle se trouve.) Cependant, selon mon expérience, une dette technique bien trop importante entre en production avec la promesse d'un responsable " «Je vais le nettoyer une fois que la pression pour expédier est éteinte», ce qui se transforme rapidement en «il est en production, nous devons faire très attention à ce que nous changeons maintenant», ce 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 le thème "L'amertume de la mauvaise qualité reste longtemps après que la douceur du bas prix a été oubliée" ne semble jamais avoir été apprise;
• Cependant, même avec des gestionnaires confiants et des développeurs disciplinés, il existe un problème commun, à savoir que trop peu d'analyses, de conceptions et de vérifications de la conception appropriées ont lieu avant le début du sprint dans lequel l'implémentation devrait être lancée et achevée. L'absence de réflexion sur une alternativeLes métaphores et les conceptions de l'interface utilisateur sont volumineuses - il est généralement trop coûteux de le réviser de manière significative après le début d'un projet. l'incapacité des équipes juniors d'étudier attentivement les produits de leurs concurrents ou de donner la priorité à 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 bugs plus importants, une productivité plus faible et une dette technique plus élevée que si ils venaient de passer les deux à cinq premiers sprints à l’avance à effectuer la formation, l’analyse, la conception et le prototypage nécessaires. En bref, les équipes agiles doivent résister à la licence de piratage.
• J'ai un responsable de second niveau (plus de 100 développeurs) qui a découragé ses développeurs de prendre le temps d'écrire leurs conceptions planifiées, même au niveau le plus élémentaire. Son raisonnement - "Je veux que les gens se parlent" - ce qui était ironique parce qu'ils se trouvaient dans 5 fuseaux horaires différents et dans 3 pays. Inutile de dire que de nombreuses personnes ont été désignées pour savoir quelle équipe allait devoir travailler plusieurs nuits et week-ends tard dans le projet, une fois qu’elles ont compris que tout le monde pensait que l’ autre type était responsable de la mise en œuvre de certaines fonctionnalités (ou réimplémentation car les conceptions du fournisseur et du consommateur ne sont pas simplement maillées.)

Tout se résume vraiment à savoir si le chef de projet et les parties prenantes souhaitent proposer un produit de haute qualité. S'ils sont déterminés à le faire, Agile le permettra. OTOH, parce qu'Agile confie la prise de décision concernant le planning aux seules personnes responsables de la partie prenante et du projet, Agile empêche une équipe de développement de réaliser un excellent projet sans ce soutien. En bref: la responsabilité de la qualité du produit incombe presque uniquement au (x) responsable (s) du projet.

TL; DR

En fait, le développement agile vous aide à augmenter la qualité du logiciel, à satisfaire le client et à fournir un produit de grande valeur.

Le développement agile a été introduit par quelques types malins 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 la 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 un logiciel de haute qualité. Le développement agile vous aide à fournir des logiciels de haute qualité.

Mais nous (et le client) savons toujours toujours à l’avance quelles sont les exigences indispensables.

Exactement. En vous concentrant sur les individus, le client, les logiciels en fonctionnement et les modifications des exigences, un développement agile vous aide à comprendre ce que le client souhaite avant la livraison du produit final.

C'est la raison pour laquelle les frameworks agiles comme Scrum ayant des cycles d'itération courts dont les résultats sont des produits opérationnels. 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 la qualité essentielle d'un produit.

À l’époque - c’est encore le cas aujourd’hui - de nombreux projets logiciels développés dans le cadre d’approches traditionnelles ont échoué, n’ont pas abouti ou ont provoqué le mécontentement des clients, car la qualité indispensable n’a pas été atteinte.

En outre, le développement agile vous aide également à atteindre une qualité attrayante . Refléter le produit après chaque itération met en lumière de nouvelles exigences qui n'étaient pas concernées par le client au début du projet (qualités attrayantes). Cela garde le client satisfait.

Je voudrais également mentionner la 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. Au bout d'un moment, ils changent au contraire et provoquent des déceptions.

Dans un processus de développement logiciel traditionnel, vous reconnaîtrez de telles exigences dans le produit final après un long projet. Trop tard pour éviter les déceptions des clients et les modifier, un projet de suivi est nécessaire.

Le développement agile vous aide à identifier rapidement les exigences non travaillées 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, à satisfaire le client et à fournir un produit de grande valeur.

Je suis assez tard pour 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 ravissants, et pas seulement le strict minimum qui satisfait à peine aux exigences requises?

Le développement logiciel agile présente un aspect temporel qui découle de l' approche itérative et de la prise en compte des commentaires des clients , deux éléments importants de la méthodologie agile. Exemple: Les caractéristiques identifiées comme étant de qualité attrayante dans l'itération t pourraient devenir une qualité incontournable à l'itération suivante t + 1.

L'application de méthodes agiles peut modifier de manière dynamique la catégorie de qualité d'une fonctionnalité. Si vous comparez les fonctionnalités planifiées de l'itération t avec les fonctionnalités finies d'une itération ultérieure t + n, vous ferez l'expérience de ce que vous avez mentionné:

J'ai fait l'expérience à quelques reprises que les exigences qui avaient été hautement prioritaires au début se sont révélées beaucoup moins importantes, voire inutiles, plus tard.

En gardant à l'esprit cet aspect temporel, il est plausible que les méthodes agiles puissent produire des produits logiciels de grande qualité, tout en se concentrant sur le strict minimum . L' approche itérative associée aux commentaires des clients modifie 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 les commentaires des clients . Éliminez l'un de ces éléments et vous obtiendrez une forme moins efficace de développement logiciel agile.

   > How to develop excellent software with agile methods?

• Lors de la production d'un logiciel individuel spécifique au client :
  • trouvez un client où le coût n'a pas d'importance, car l'option "ravissante" coûte de l'argent supplémentaire et le client doit décider s'il veut payer pour cela.
• Lors de la production de produits logiciels :
  • Les fonctionnalités "ravissantes" sont utiles pour attirer de nouveaux clients et le coût de mise en œuvre d'une fonctionnalité "ravissantes" n'est pas si important si le produit est vendu plus de 1000 fois.
• Dans un environnement où "assez bon (moins cher) est le mieux", vous ne recevrez pas l'argent nécessaire pour mettre en oeuvre des fonctionnalités "délicieuses"

Dans une équipe Scrum, le propriétaire du produit est responsable de choisir les fonctionnalités à implémenter. C’est donc à lui (et à son budget) de définir un logiciel "satisfaisant" ou "excellent"

Vous soulevez de bons points. Mais je ne crois pas que ces problèmes se limitent aux processus / méthodologies agiles.

Les opinions divergent quant aux caractéristiques essentielles par opposition aux caractéristiques non essentielles. Pour prendre votre exemple, une personne qui achète une voiture pourrait considérer l’attention comme une caractéristique essentielle et par conséquent, considérer une Fiat comme ne répondant pas à cette exigence impérative.
De manière plus réaliste, un logiciel peut avoir besoin de certaines fonctionnalités pour répondre aux besoins de ses utilisateurs finaux réels… mais il peut également avoir besoin de certaines autres fonctionnalités pour être vendu. Parce que la personne autorisant l'achat n'est souvent pas un utilisateur final.
Ainsi, une fonctionnalité qui est "non essentielle" pour le ou les utilisateurs finaux peut être essentielle pour vendre le produit ... et donc également pour l'entreprise qui crée le produit.

Tout cela revient simplement au fait qu'il est essentiel de disposer d'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 que les propriétaires du produit / les parties prenantes soient autorisés à prendre des décisions. Si les décisions du propriétaire de votre 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 d'agile.

Il y a d'autres choses que vous voulez dans votre (vos) propriétaire (s) du produit ... une description que j'ai entendue est "CRACK" (collaboratif, représentant, autorisé, engagé et compétent). Un produit propriétaire dépourvu de l'un de ces domaines peut causer des problèmes à un projet. Mais j'ai d'abord entendu cet acronyme dans un environnement de cascade, de sorte que la douleur des mauvais clients / propriétaires de produits ne se limite pas aux magasins agiles.

Ce que Agile peut (aider) faire, c’est faire ressortir certaines de ces questions.

Par exemple, la littérature XP indique clairement à l’IIRC que le «client» doit être informé, accessible à l’équipe et autorisé à prendre des décisions. Le terme "propriétaire du produit" implique un certain niveau de connaissance, d’engagement et d’autorité.

Si vous vous trouvez dans une situation où la plupart des fonctionnalités livrées consistent en des ravisseurs au lieu de fonctions indispensables, il est beaucoup plus facile de soulever ce problème (et beaucoup plus facilement de déterminer la cause) lorsque vous livrez un logiciel en fonctionnement ou presque, tous les jours. 2-3 semaines que lorsque les livraisons se font en mois ou en années.

Si vous travaillez dans de petites itérations - et que vous consultez fréquemment l'arriéré (notamment en révisant la hiérarchisation des priorités) -, l'équipe peut tirer parti des erreurs précédentes. "Cela me semble très important maintenant, mais souvenez-vous de la navigation dynamique dont nous étions sûrs que nous avions besoin et que nous n'avons pas utilisée?" Comme d'autres l'ont souligné, ces discussions sont beaucoup moins probables si tout a été planifié d'avance.

En revanche, la méthodologie de conception initiale suppose (par défaut) que la compréhension du produit et de ses fonctionnalités est statique. Cela n’a pas été mon cas: le fait de pouvoir travailler avec quelque chose de concret change presque toujours la compréhension du problème par les gens d’affaires. D'où l'accent mis sur le retour 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éagir aux changements des besoins de l'entreprise. "Vous connaissez le site Web que vous construisez? Nous avons vraiment besoin que cela soit une application mobile, capable de fonctionner de manière déconnectée." Ce n’est pas une question qui a été posée spécifiquement… mais ne voudriez-vous pas que votre processus soit en mesure de réagir aux changements du paysage commercial (du moins en théorie)?

Agile ne dit pas "ne construisez pas de fonctionnalités non essentielles". Cela dit "permet à l'entreprise de décider quelles fonctionnalités (non) à construire".
... et (tout aussi important) "permet aux techniciens de vous dire combien de temps une fonctionnalité que vous souhaitez créer sera longue à créer".

1. 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 .
2. One-dimensional qualitiescela signifie que les promesses qui doivent être remplies sont appuyées par la cascade OK, jusqu'à ce qu'elles ne changent pas. Ici, être agile n'aide que beaucoup, mais pas avec autant de force.
3. Attractive qualitiessont des fonctionnalités intéressantes. 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. Les méthodes agiles qui supposent la participation du représentant du client supportent très bien ces qualités. En effet, nous pouvons modifier légèrement la portée pendant les travaux. Nous pouvons négocier l'amélioration d'une place pour une compensation sur une autre. En cascade, c'est pratiquement impossible. Sans grand délai d’organisation, nous ne pouvions ajouter que des fonctionnalités gratuitement. C'est possible, si du temps supplémentaire est déjà prévu dans le budget.

Ainsi, les processus agiles peuvent prendre en charge le modèle de Kano, certains le font beaucoup, et nettement mieux que les meilleurs projets de cascade.

Pour bien le comprendre, vous devez définir des processus agiles avec un participant responsable représentant le client.