Quels sont les bons critères d'utilisation des balles Tracer?

Je lisais pour la première fois The Pragmatic Programmer pour la première fois et je suis tombé sur le concept de Tracer Bullets. J'ai réalisé que j'avais codé selon ce modèle dans le passé et j'ai simplement classé la façon dont je travaillais dans mon cerveau comme "agile".

Ils ne donnent qu'un exemple de l'endroit où ils l'ont utilisé dans le passé. La façon dont la situation a été identifiée comme un bon candidat pour les balles Tracer a été

Il y avait de nombreuses inconnues et de nombreux environnements différents, et personne n'était trop sûr de la façon dont l'interface graphique devait se comporter.

Cela ressemble à la façon dont un grand nombre de projets commencent, en particulier lorsque vous travaillez avec des personnes non techniques sur une application métier typique pour un fonds de couverture (à titre d'exemple).

Je l'ai utilisé parce qu'il me semblait tout simplement correct, sans vraiment savoir comment il s'appelait ni me l'expliquer. Je savais que si j'essayais de mettre tout le monde dans une pièce et de leur faire tout spécifier (ou du moins certaines choses) à l'avance, ce serait un désastre complet, mais encore une fois, c'est une sorte de sensation ...

Quelqu'un peut-il proposer des critères plus concrets pour déterminer quand ce modèle pourrait être la voie à suivre?

Vous devez avoir un projet où vous pouvez avoir une idée si vous êtes sur la bonne voie avec seulement un petit sous-ensemble de fonctionnalités. En général, cela est possible pour des choses comme la conception de l'interface graphique de base, mais cela est difficile avec des choses dont les résultats sont inconnus - par exemple, si vous concevez une application d'exploration de données et la forme de l'outil dépendra du type de modèles qui se produisent dans vos données.

Vous devez également être dans une situation où vous pouvez vous permettre de répéter plusieurs fois. Cela coûte du temps et du développement (et bien sûr peut être bénéfique si vous vous abonnez à des processus de développement agiles), mais le plus difficile est le coût en termes d'exposition aux utilisateurs. Les utilisateurs seront rapidement épuisés si vous leur montrez trop de designs et la qualité de vos commentaires diminuera considérablement. Vous avez donc besoin soit d'un grand pool d'utilisateurs, soit de choisir soigneusement vos (micro) versions.

Je dirais qu'il n'y a vraiment qu'un seul facteur de base qui détermine l'utilité d'une approche Tracer Bullet: le nombre et la portée des incertitudes dans l'architecture et la conception de l'application.

Parce que l'objectif principal (sinon seulement) de la technique est de dissiper ces incertitudes, vous n'en tirerez pas grand avantage si vous n'en avez pas ou si elles ne concernent pas l'architecture ou la conception. Un projet entièrement nouveau sans contraintes architecturales est un exemple typique lorsque le démarrage avec une balle Tracer est presque la seule chose sensée à faire, alors que pour un projet mature avec de nouvelles fonctionnalités à mettre en œuvre, ce serait probablement une perte de temps (même si il peut y avoir des incertitudes concernant les exigences, les clarifier étant davantage du domaine du développement agile ou itératif général).

Je suis tombé sur le concept de développement de Tracer Bullet dans le livre Ship It! , édité par les programmeurs pragmatiques .

Je suppose que dans votre question, vous faites référence au livre The Pragmatic Programmer: From Journeyman to Master . Je ne l'ai pas lu et je ne sais pas comment TBD y est présenté. Dans Ship It! , il y a un chapitre (20 pages), consacré à TBD. Ils parlent notamment de leur expérience avec un exemple concret: une application de datamining pour une entreprise de biotechnologie. Fondamentalement, ils expliquent qu'avoir de belles couches d'abstraction (conçues à l'aide de TBD) les a aidés à éliminer les goulots d'étranglement des performances un par un, en parellisant chaque couche.

À mon avis, TBD est deux choses:

• Créez une architecture logicielle en isolant les objets système et laissez les développeurs collaborer pour définir les interfaces entre ces objets système
• Utilisez des objets fictifs pour vous assurer que l'architecture est durable (testez l'architecture tôt)

Je pense que le premier point est un très bon moyen d'architecturer un logiciel, quoi qu'il arrive. Le deuxième point est intéressant: il peut potentiellement empêcher une réécriture complète d'un projet en raison d'une architecture initiale qui ne fonctionne pas en pratique.