Créez-en un à jeter vs effet du deuxième système


15

D'une part, il y a un conseil qui dit "Construisez-en un à jeter". Ce n'est qu'après avoir terminé un système logiciel et vu le produit final que nous réalisons ce qui s'est mal passé dans la phase de conception et comprenons comment nous aurions vraiment dû le faire.

D'un autre côté, il y a l '"effet du second système" qui dit que le deuxième système du même type qui est conçu est généralement pire que le premier; il existe de nombreuses fonctionnalités qui ne correspondaient pas au premier projet et ont été poussées dans la deuxième version, ce qui conduit généralement à trop complexe et trop d'ingénierie.

N'est-ce pas là une contradiction entre ces principes? Quelle est la vision correcte des problèmes et où est la frontière entre ces deux?

Je crois que ces «bonnes pratiques» ont d'abord été promues dans le livre fondateur The Mythical Man-Month de Fred Brooks.

Je sais que certains de ces problèmes sont résolus par les méthodologies Agiles, mais au fond, le problème est toujours que les principes sont toujours en vigueur; par exemple, nous ne ferions pas de changements de conception importants 3 sprints avant de passer en direct.


3
Personnellement, je pense que vous en avez besoin de trois - un pour comprendre les bases du problème, deux pour comprendre les choses avancées et un troisième pour bien faire les choses.
Wyatt Barnett

5
@Wyatt: I mon cas, le nombre correct pour "bien faire les choses" est n + 1, n étant l'itération actuelle
mattnz

Réponses:


23

Construire un pour jeter vient de "ne pas savoir ce que vous ne savez pas" au début, donc vous apprenez au fur et à mesure ce que vous auriez dû faire au début.

Le deuxième effet du système vient de "savoir maintenant ce que vous ne saviez pas, mais ne pas savoir ce que vous ne savez toujours pas", c'est-à-dire que le deuxième effet du système vient d'essayer de construire un système plus grand, plus brillant et plus complexe que le premier, à l'insu nécessaire au début - ressemble beaucoup à ce qui se passe avec le premier système.

L'effet du second système n'est donc pas contradictoire. Construire un deuxième système avec les mêmes fonctionnalités que le premier n'est (à ma connaissance) jamais fait. Le deuxième système doit toujours être "meilleur", donc plus complexe, donc des problèmes sensiblement similaires au premier système sont attendus - qui devraient être jetés.

Donc, construisez-en un à jeter, jetez-le de manière et reconstruisez-le sans élargissement de la portée, et vous n'aurez pas de deuxième problème de système. (Cela a tendance à être fait plus souvent sur des planètes avec un ciel violet, une mer rose et des cochons volants.)


Le "premier système qui sera jeté" n'est-il pas un prototype? Si cela est vrai, autant que je sache, le prototype n'a généralement pas toutes les fonctionnalités du produit tendance; ou du moins dans le cadre d'un prototype jetable.
m3th0dman

C'est pourquoi vous devriez refactoriser fortement dans les sprints ultérieurs, abandonnant vos tentatives initiales de résoudre le problème à mesure que de nouvelles exigences sont découvertes dans votre carnet de produits.
Joeri Sebrechts

@Joeri Sebrechts Refactoring ne signifie pas jeter le premier système; vous ne pouvez pas non plus refactoriser de mauvaises exigences ou une mauvaise architecture ...
m3th0dman

La seule chose que je dois ajouter à cette réponse, pour plus de clarté, est que le deuxième système fait référence à un deuxième système de production.
Thomas Owens

0

Le problème auquel vous faites référence signifie que plusieurs choses ont été ignorées, d'où le système résultant a mal tourné. Permettez-moi de décrire certaines des étapes manquantes:

Gestion de la qualité - Faites-le bien dès la première fois! N'utilisez jamais de hacks temporaires ou de compromis temporaires. Il ne doit pas être retravaillé. Toutes les ressources sont utilisées efficacement et tout ce que vous faites est une contribution appropriée au projet.

Analyse de faisabilité - Découvrez les besoins de l'entreprise. Créez une analyse de rentabilisation pour le projet.

Plan de projet - Définissez clairement votre portée initiale, planifiez la façon dont la solution sera livrée, créez une base de référence, respectez le plan. Ne passez pas de temps sur tout ce qui n'est pas sur le chemin critique.

Ingénierie des exigences - Obtenir les exigences commerciales (c.-à-d. Capturer les processus commerciaux et déterminer quelles opérations commerciales devraient être prises en charge par le système informatisé, traduire les opérations commerciales 1: 1 en cas d'utilisation du système). Validez et vérifiez! (construisons-nous la bonne chose? Construisons-nous la bonne chose?) Toutes les exigences doivent être liées au besoin commercial initial.

Conception de logiciels - Traduisez les cas d'utilisation et le modèle de domaine en conception de composants et architecture de solution. Tous les composants doivent être liés aux exigences de RE.

Implémentation - Codez le logiciel comme dans la conception. Tout le code doit être lié aux composants de SD.

Validation - Tests unitaires, tests d'intégration, performances, ... (tous les cas d'utilisation de RE devront maintenant être testés)

Ce sont là quelques aspects clés d'un processus logiciel. Les activités mentionnées font partie du génie logiciel. C'est ainsi que vous construisez la bonne solution logicielle pour les besoins réels de l'entreprise et que vous la construisez dans les délais, le budget et les spécifications.

Recherchez ces termes pour créer un meilleur logiciel et le faire correctement la première fois:

  • Analyse de faisabilité (en particulier comment construire une analyse de rentabilisation)
  • Gestion de projet (en particulier plan de projet et registre des risques avec atténuation des risques)
  • Ingénierie des exigences (élicitation, analyse, spécification, validation)
  • Conception de logiciels (UML et génie logiciel basé sur les composants)
  • Construction de logiciels (modèles de conception, cadres, programmation défensive)
  • Validation des logiciels (tests unitaires, UAT, etc.)

1
Il sera toujours nécessaire de retravailler à mesure que les exigences changent. Mais dans des systèmes bien conçus, ces retouches peuvent être effectuées de manière incrémentielle et propre sans affecter les pièces indépendantes.
JesperE

Rêver. Vous attendez du client qu'il sache à l'avance ce qu'il veut / ce dont il a besoin. Cela ne se produit pas; c'est pourquoi nous avons des méthodes agiles.
Rétablir Monica - M. Schröder

En d'autres termes, il ne doit y avoir de changement de sw que lorsque le processus opérationnel de l'entreprise change et cela ne se produit pas si souvent.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.