44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
## Éliminer les fonctionnalités non essentielles
|
||
|
||
### Identifiants
|
||
|
||
Bonne pratique originale : [BP_001](https://github.com/cnumr/best-practices/blob/main/chapters/BP_001_fr.md)
|
||
|
||
### Catégories
|
||
|
||
| Cycle de vie | Tiers | Responsable |
|
||
|:---------:|:----:|:----:|
|
||
| 1. Spécification | Utilisateur/Terminal | PO/AMOA |
|
||
|
||
### Indications
|
||
|
||
| Degré de priorité | Mise en oeuvre | Impact écologique |
|
||
|:-------------------:|:-------------------------:|:---------------------:|
|
||
| 5 | 4 | 5 |
|
||
|
||
| Ressources Economisées |
|
||
|:-------------------------------------------------------:|
|
||
| Processeur / Mémoire vive / Stockage / Réseau |
|
||
|
||
### Description
|
||
Plusieurs études (Cast Software et Standish Group, notamment) démontrent que 70 % des fonctionnalités demandées par les utilisateurs ne sont pas essentielles et que 45 % ne sont jamais utilisées. En réduisant la couverture et la profondeur fonctionnelle de l’application, on abaisse son coût de développement initial, sa dette technique et les impacts environnementaux associés.
|
||
|
||
On diminue ainsi mécaniquement l’infrastructure nécessaire à son exécution. Par ailleurs, à niveau ergonomique constant, plus l’application est pauvre fonctionnellement, plus elle sera simple à utiliser. Il faut donc réduire le plus possible la couverture fonctionnelle de l’application, en la centrant sur le besoin essentiel de l’utilisateur.
|
||
|
||
Détecter une fonctionnalité non essentielle est possible au moment de l'analyse de l'expression du besoin. La méthode MoSCoW, des ateliers, des wireframes (maquettes fonctionnelles) ou des prototypes avec tests utilisateurs permettent de vérifier l'utilité d’une fonctionnalité en amont de son développement.
|
||
|
||
|
||
### Exemple
|
||
Les succès récents du Web – Google, Twitter, WhatsApp, Pinterest, Instagram, etc. – fournissent un seul service et misent sur une grande sobriété fonctionnelle.
|
||
|
||
Se poser, au moment de l'analyse de l'expression du besoin, la question : « Que se passe-t-il si on ne l’a pas ? ».
|
||
|
||
Respecter le principe YAGNI (You Ain't Gonna Need It) de l’extreme programming : développez quand vous avez effectivement besoin d’une fonctionnalité, pas lorsque vous imaginez en avoir besoin.
|
||
|
||
### Principe de validation
|
||
|
||
|
||
| Le nombre ... | est inférieur ou égal à |
|
||
|-------------------|:-------------------------:|
|
||
| de fonctionnalités dont l'utilité n'a pas été vérifiée avec un panel d'utilisateurs avant développement | 0 % |
|