Comment le prototypage rapide s'intègre-t-il dans une méthodologie agile?

Je travaille pour une grande entreprise, qui dicte l'utilisation de processus agiles. Par exemple, pour nos projets, nous utilisons des services basés sur le cloud qui sont spécifiquement destinés à gérer le développement agile.

Le groupe d'ingénierie spécifique pour lequel je travaille n'a pas traditionnellement développé de logiciel (au lieu de cela, nous aidons à conduire les projets d'un point de vue beaucoup plus aérien), mais cela change. Nous avons un large éventail de projets logiciels à venir / planifiés qui sont principalement axés sur les données - par exemple, nous ferons de la surveillance, de la collecte, de l'agrégation des données et de certains rapports. D'autres tâches impliquent l'automatisation avec du matériel spécialisé et divers types d'architectures client / serveur (à plusieurs niveaux). Je dois aider au processus d'embauche de plusieurs personnes et formuler bon nombre de nos plans pour aller de l'avant.

Ma question est de savoir si le prototypage rapide (code jetable) s'inscrit ou non dans une philosophie agile. Par exemple, j'adore Python et sa large gamme de packages. Je vois la possibilité de mettre en œuvre plusieurs de nos idées très rapidement avec un workflow basé sur Python. Cependant, je pense qu'il y aura beaucoup de perceptions que Python n'est pas "de qualité entreprise", et une grande partie de ce travail devrait être réécrite en Java ou peut-être en C ++.

Cependant, la création des prototypes Python nous donnerait beaucoup pour notre argent en nous permettant de fournir rapidement des résultats réels.

Avez-vous été en mesure d'intégrer un prototypage rapide - espérons-le en Python - dans un flux de travail agile solide dans un environnement d'entreprise?

Le concept de "prototypage", comme prévu dans RAD , est un peu étranger au développement agile. Cela ne signifie pas que cela ne peut pas être fait, mais c'est inhabituel.

Différents cas doivent être explorés:

1. Le prototype est-il une "coquille vide", une maquette ou une démo, conçue pour donner une idée de l'apparence d'un produit? Vous pouvez certainement le faire avec une ou plusieurs histoires - mais vous construisez quelque chose à partir de votre propre imagination, pas à partir d'un vrai feedback. Les gens n'évaluent pas une démo comme ils évaluent un produit. Par exemple, consultez les commentaires sur notre prototype de barre supérieure par rapport à notre véritable implémentation de barre supérieure .

2. Le prototype doit-il être construit afin de mieux comprendre l'espace problématique? Ensuite, il doit être couvert comme un pic , et seuls ses résultats doivent être conservés (le code source est transitoire).

3. Le prototype est-il une version 0.x? Un produit minimum viable ? Utilisez ensuite le processus agile de votre choix. Si vous avez besoin de le reconstruire dans une autre langue, vous serez probablement mieux si vous traitez cela avec un produit différent. Notez que cela est parfois traité comme un moyen de raccourcir l'écriture d'une spécification ("cela devrait faire la même chose que le prototype!"). C'est une très mauvaise façon de documenter un produit, mais cela est probablement mieux expliqué en tant que question et réponse distinctes :-)

Le prototypage rapide (ie développement itératif et incrémentiel) n'est-il pas en quelque sorte tout l'intérêt d'Agile?

Il semble que vous ayez des problèmes avec «la perception est la réalité» dans votre organisation. Vous voudrez peut-être rappeler à tout le monde qu'Agile ne signifie pas «jeter tous les plans», pas plus que le développement piloté par les tests ne signifie «jeter toute l'architecture».

Et Python n'est pas (s'il l'a jamais été) un langage jouet. La NASA et ses sous-traitants utilisent Python , et si c'est assez bon pour eux, c'est assez bon pour moi.

Il y a une pratique assez stable dans Extreme Programing appelée Spike . Cela signifie que c'est du code jetable. Il n'y a rien de spécial là-dedans. C'est juste un Sprint dans lequel le résultat attendu est la connaissance du code jetable.

Le lien ci-dessus contient suffisamment d'informations sur les bonnes pratiques, les pièges des pics.

Votre cas d'utilisation spécifique semble un bon exemple: il peut être utile de concevoir l'interface, de valider l'utilitaire et de le montrer à certains utilisateurs.

Vous allez jeter le code et ne pas le mettre en production (le rendre parfaitement clair pour TOUS), donc être agile ou non n'a pas vraiment d'importance. Toutes les pratiques agiles sont purement facultatives pour les prototypes: sprints, burn-down, tests, programmation par paires ou tout ce que vous prévoyez d'utiliser.

Si vous allez principalement construire des modèles fonctionnels en Python pour aider les propriétaires de produits et autres décideurs à conceptualiser le projet, vous n'avez pas besoin d'être prêt pour l'entreprise. Cependant, si vous créez une preuve de concept ou essayez de voir si vous pouvez gérer certains niveaux de performance, vous devriez probablement vous en tenir au langage de production. Cela ne signifie pas que vous ne pouvez pas l'essayer en Python.

Quoi qu'il en soit, vous allez jeter le code, mais avez la connaissance de pouvoir faire ce travail avec une meilleure idée de ce que veulent les propriétaires. Vous pouvez maintenant utiliser la méthode que vous souhaitez.

J'ajouterais que les prototypes sont cruciaux pour l'apprentissage, et aussi dans l'esprit Agile. Si le prototype vous permet d'apprendre, en particulier dans des cycles de rétroaction plus rapides, alors allez-y. Il s'agit de maximiser l'apprentissage et de partager les apprentissages avec l'équipe.

En termes d'apprentissage, j'ajouterais que le prototypage vous permet d'apprendre plus rapidement. De cette façon, vous pouvez valider si les gens se soucient même du problème que vous essayez de résoudre - et si la solution que vous avez en tête est celle qu'ils recherchent - sans perdre beaucoup de temps à créer une solution complète qui peut , en fin de compte, ne pas résoudre un problème suffisamment douloureux ou ne pas le résoudre de la bonne façon.

Le véritable esprit d'Agile réside dans l'interaction et la communication. Je dirais que si le prototype fonctionne bien comme outil d'aide à la communication, il n'y a rien de mal à l'utiliser dans le monde Agile. Dans notre équipe (nous pratiquons l'Agile depuis plus de 5 ans) nous l'avons utilisé de temps en temps. Et je peux voir certains avantages

1) Aider à la communication

2) Faites participer les utilisateurs aux entretiens de la solution et obtenez un retour rapide

Caveat:

La communication directe entre UX et les ingénieurs ne doit JAMAIS être remplacée par des artefacts de prototypage. Si possible, le jumelage avec un ingénieur fonctionne bien mieux que la communication via un médiateur (prototype).

D'autres ont déjà mentionné le but d'apprentissage des pointes. Ce qui manque, c'est le principe agile sous-jacent de celui-ci, c'est l' échec rapide .

L'un des piliers du développement agile est de reconnaître les parties dures et de rechercher des concepts, voir si vous pouvez le faire. La façon classique de travailler à travers toutes les tâches dans un ordre "logique" peut s'avérer très coûteuse si vous constatez que vous ne pouvez pas faire quelque chose tard dans le projet. Tout ce qui a été fait jusqu'à présent pourrait être un gaspillage.

Si cela doit finir ainsi, vous voulez le savoir le plus rapidement possible. Ensuite, les parties prenantes peuvent choisir soit d'arrêter de brûler de l'argent alors qu'il n'y en a pas encore beaucoup et d'accepter ce qu'elles veulent n'est pas possible, soit d'essayer une approche radicalement différente du problème qui aura de nouvelles chances de réussir. Si vos prototypes servent cet objectif, ils sont en effet les plus agiles.