Dans la Silicon Valley Bible d'Eric Ries, The Lean Start-Up, l'idée de Minimum Viable Product est apparue pour la première fois. Depuis lors, le MVP est devenu une pratique standard pour les équipes produit de divers secteurs, y compris le SaaS, le commerce électronique et les consommateurs l'électronique, les appareils portables et une variété d'autres.
Image from https://www.dynamicyield.com/glossary/minimum-viable-product/
Si vous voulez faire une voiture, ne faites pas d'abord les roues, puis faites les essieux, puis faites la coque de la voiture ... De cette façon, vous ne pouvez avoir une voiture qu'après que toutes les pièces sont finalement assemblées. vous devez d'abord construire une planche à roulettes, puis vous pouvez l'utiliser pour, par exemple, transporter des boîtes ou d'autres choses, puis transformer la planche à roulettes en scooter avec accoudoirs, puis la transformer en vélo. Puis une moto et enfin une voiture. Dans ce processus, vous pouvez avoir des «roues» à exécuter à chaque étape.
Suivez la méthode traditionnelle en cascade, effectuez toutes les analyses des exigences, puis toute la modélisation de la conception, puis toutes les implémentations de codage et enfin tous les tests. Vous ne l'avez pas fait de cette façon. Au lieu de cela, vous libérez les nouvelles fonctions développées à chaque itération, même tous les jours au cours de l'itération. Chaque petite fonction passera par l'ensemble du processus d'analyse, de conception, de codage et de test dans un cycle de 2/3 jours. Les fonctions libérées à chaque itération sont disponibles en elles-mêmes, et l'ensemble du système sera être disponible lorsque toutes les fonctions seront terminées. Vous publierez donc officiellement le système à la fin des trois itérations. Après tout, comment utiliser un système incomplet?
Le processus de développement est déjà très agile, n'est-ce pas?
Beaucoup de gens ne peuvent pas comprendre cette image, car ils pensent que c'est une métaphore, pas vraiment des scooters aux vélos en passant par les motos et les voitures. Cependant, le tournant fondamental du développement logiciel agile est démontré dans cette image ci-dessus. Le logiciel est doux. Un vélo peut vraiment être converti en une moto avec un moteur, et cela n'affectera pas l'utilisation continue du vélo au moment de son installation. Cela peut même être plus absolu: si votre processus de développement logiciel ne se déroule pas de la même manière que le deuxième moitié de l'image, vous n'avez pas du tout pratiqué Agile.
Pendant tout ce processus, l'ensemble du système métier (pas seulement le système informatique) est disponible à tout moment, la modification du système métier est contrôlable et réversible à tout moment, et les avis d'amélioration sur le système métier peuvent être émis à tout moment. temps et être inclus dans les fonctionnalités suivantes.
Il s'agit d'une livraison itérative: le système logiciel est progressivement déployé dans le système d'entreprise de manière itérative, en changeant progressivement le système d'entreprise (plus numérique, plus pratique, meilleure expérience ...), et en veillant à ce que chaque étape du changement dans l'entreprise le système est sûr et fiable.
Qu'il s'agisse de déployer des systèmes logiciels et de modifier les systèmes d'entreprise de manière itérative, ou de déployer des systèmes logiciels et de modifier les systèmes d'entreprise de manière tout-en-un, c'est le tournant entre agile, non agile ou faux agile. Vous pouvez fermez la porte et engagez-vous dans le développement itératif. C'est amusant, mais au final, le logiciel est publié en grande quantité, et c'est en cascade.
Pour parcourir ce tournant, les user stories doivent être plus granulaires. L'étendue de la diffusion sélectionnée pour chaque itération doit être de bout en bout.
See also
No comments:
Post a Comment