Ne faites jamais rien tant que vous n'êtes pas prêt à l'utiliser, même dans le logiciel? [Principe Toyota] [fermé]

Question

J'écoutais un podcast . Où ils ont parlé des principes que Toyota utilisait:

  

Ne faites jamais rien avant d'être prêt à l'utiliser.

Je pense que cela nous dit de regarder ailleurs, pour apprendre quelles autres pratiques sont connues depuis des années.

Answer 1

Cela peut s’appliquer à la construction de logiciels, mais je ne suis pas sûr que cela soit appliqué

.

Si nous considérons les cinq éléments d'un " toyota-façon de prendre des décisions ", basée sur le principe que" comment vous arrivez à la décision est tout aussi important que la qualité de la décision ":

[mode humour activé]

• Découvrir ce qui se passe réellement, y compris le genchi gembutsu.

    

  Sauf que parfois, on comprend enfin ce qui se passe lorsque le client nous explique à la fin du projet;)   

• Comprendre les causes sous-jacentes qui expliquent les apparences de surface en demandant «Pourquoi?» cinq fois.

    

  Bien sûr, mais le client n'est pas assez disponible pendant le projet;)

• Envisagez globalement des solutions de rechange et développez une justification détaillée de la solution privilégiée.

    

  Trop tard, les programmeurs codent déjà comme des fous:)

• Établir un consensus au sein de l’équipe, y compris des employés de Toyota et des partenaires extérieurs.

    

  Oops que le programmeur est déjà en train de réécrire le système d'authentification même si l'ancien fonctionnait bien

• En utilisant des moyens de communication très efficaces, effectuez un à quatre, de préférence un côté d'une feuille de papier.

    

  Avez-vous entendu "la mort par powerpoint"? ? Ce n'est pas toujours notre point fort;)   

[mode humour OFF]

Sérieusement, comme indiqué dans les réponses précédentes, la philosophie Agile s’adresse aux principaux tenants de ce principe Toyota.

Et il est peut-être un peu plus riche que juste "vous n'en aurez pas besoin", comme décrit dans le livre La méthode Toyota "

Answer 2

En quelque sorte, oui. Il s’agit d’un élément essentiel de la philosophie agile .

Fondamentalement, privilégiez la flexibilité et la rapidité de réponse par rapport aux grandes conceptions initiales et aux spécifications lourdes. L’une des meilleures façons de le faire est de ne construire que suffisamment pour répondre à vos besoins actuels, car vous ne savez jamais quand ils vont changer.

Answer 3

C’est un peu la vieille nouvelle. On l'appelle souvent "vous n'en aurez pas besoin". ("Vous n'allez pas en avoir besoin" en anglais non idomatique), et abrégé en YAGNI .

Problèmes liés à la mise en œuvre d'une fonctionnalité lorsque vous n'en avez pas besoin:

• la mise en œuvre prend du temps à développer les fonctionnalités nécessaires
• la fonctionnalité est difficile à documenter et à tester, car si vous n'en avez pas besoin, qui sait ce qu'elle est censée faire exactement?
• le maintien de la fonctionnalité prendra du temps supplémentaire
• la fonctionnalité ajoute du code supplémentaire, ce qui complique la base de code
• la fonctionnalité peut avoir un effet boule de neige, suggérant d’autres fonctionnalités que vous voudrez peut-être ensuite ajouter, même si elles ne sont pas nécessaires

Answer 4

Penser juste comme ça est une bonne pratique agile. Il existe également quelque chose appelé Test-Driven-Development, qui vous aide à obtenir un logiciel sans bugs (presque), mais qui a également cet effet secondaire que RIEN n'est mis en oeuvre que vous n'utilisez pas.

Par exemple, vous êtes une propre classe de collection. Si vous n’avez besoin que d’une méthode Add et d’une méthode ToArray, pourquoi utiliser le temps nécessaire pour implémenter les méthodes Remove et Count?

Alors oui. Suivez ce principe:)