mobile-best-practice/chapters/MBP_001_fr.md

44 lines
2.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

## É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 / Requêtes |
### 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 lapplication, on abaisse son coût de développement initial, sa dette technique et les impacts environnementaux associés.
On diminue ainsi mécaniquement linfrastructure nécessaire à son exécution. Par ailleurs, à niveau ergonomique constant, plus lapplication est pauvre fonctionnellement, plus elle sera simple à utiliser. Il faut donc réduire le plus possible la couverture fonctionnelle de lapplication, en la centrant sur le besoin essentiel de lutilisateur.
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é dune 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 la pas ? ».
Respecter le principe YAGNI (You Ain't Gonna Need It) de lextreme programming : développez quand vous avez effectivement besoin dune 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 % |