Dans un monde idéal, il est préférable de respecter le délai avec moins de bugs. Mais d'après votre expérience qui est plus préférable / acceptable:

1. Respecter la date limite mais a un certain nombre de bugs parce que le développeur se précipite dans les choses
2. Moins de bugs mais pas tout à fait respecter le délai car le développeur est très rigoureux dans l'écriture du code

La réponse à cette question dépend fortement des objectifs commerciaux, ainsi que du client.

Entreprise :

Si vous faites affaire avec un client de niveau entreprise bien établi sur le marché, il est moins flexible et ne peut pas s'adapter aux changements aussi rapidement. Par conséquent, la stabilité est une exigence absolue dans la plupart des cas. Il existe des exceptions pour la recherche et le développement et l'entrée dans de nouveaux secteurs verticaux. Des finitions plus rapides en premier dans certains cas.

Ces types de clients comprennent généralement qu'un bon logiciel prend du temps à développer et travailleront avec vous pour essayer d'atteindre les objectifs.

Startups :

Pour un nouveau démarrage, les règles sont radicalement différentes. En tant que startup, vous devez savoir immédiatement si le produit que vous construisez répondra effectivement à un besoin, comme le prédit votre recherche marketing. Pour une startup, mettre un prototype sur le marché le plus rapidement possible peut recueillir de nombreux commentaires précieux sur la direction que devrait prendre le produit.

Il peut également vous établir en tant que leader du marché, vous aidant à gagner de précieuses parts de marché dans une nouvelle verticale avant qu'elle ne soit saturée de concurrence.

Étant donné que les startups sont petites, flexibles et peuvent s'adapter rapidement au changement, ce modèle fonctionne le mieux pour elles.

En résumé, il y a d'autres facteurs à considérer, mais l'idée principale est que chaque projet est différent et aura des objectifs de qualité et de délai de commercialisation différents. Il appartient au leadership exécutif de déterminer une stratégie commerciale efficace qui inclut une analyse approfondie des coûts d'opportunité du choix d'une méthode plutôt qu'une autre.

ou ... 3. Coupez les fonctionnalités non essentielles

Parfois, en raison des bonbons techniques ou des fonctionnalités de bonbons demandés par le client, les délais sont difficiles à respecter et, par nature, une plus grande quantité de bogues survient. Ce sont les principes KISS et YAGNI qui sont appliqués.

Citant ce livre , "Rework", l'essentiel / noyau / épicentre de votre logiciel est ce dont l'entreprise a besoin pour fonctionner, tout comme un stand de hot-dog peut être un stand de hot-dog sans garniture, ce que vous ne pouvez pas découper sont les hot-dogs.

Renégocier

L'une des choses les plus difficiles à apprendre est de garder les clients satisfaits, et d'après mon expérience, cela peut être plus facilement accompli avec des itérations de produits plus petites.

Parfois, les délais exigent que le logiciel fonctionne à un niveau de production élevé depuis le premier jour. Les gestionnaires / clients ne savent pas toujours (ce qui est la plupart du temps) ce dont ils ont réellement besoin pour le logiciel. Essayez donc de réduire les fonctionnalités non essentielles et de conserver la qualité. En fin de compte, cela dépend de la façon dont l'environnement de production sera critique, mais essayez de supprimer des fonctionnalités supplémentaires et d'offrir une qualité. Citant à nouveau de "Rework":

Faire plus tard, c'est aussi faire mieux

... et aussi respecter les délais avec moins de bugs

Eh bien, vous pouvez l'encadrer de cette façon: voulez-vous payer la qualité maintenant ou plus tard? Soit prendre le temps de bien le faire en premier lieu, soit passer du temps plus tard à régler tous les problèmes. Je dirais que cette phase de correction de bugs post-développement de fonctionnalités peut être plus coûteuse car elle peut également être plus risquée et plus sujette à des solutions hacky puisque le code existant est déjà en place et probablement de qualité insuffisante.

Respectez la date limite et présentez une liste des problèmes connus .

Les gens détestent trouver des bugs, mais s'ils ont été informés à l'avance, ils ont tendance à être beaucoup plus indulgents.

Cela dépend entièrement de la situation ...

Il y a plusieurs facteurs à considérer:

1. Est-il facile de déployer des correctifs?
2. Est-il possible de publier une version de base simplifiée, puis de corriger de nouvelles fonctionnalités (cas de bord) au fil du temps?
3. Quelle est la culture générale de l'industrie cliente pour un tel produit? S'attendent-ils à des versions parfaites ponctuelles ou sont-ils habitués à l'idée d'un système évolutif qui pourrait être bogué lors de sa première sortie?
4. Quel risque pour l'entreprise une version initiale de buggy pose-t-elle, au lieu de faire exploser la date limite?

Bref, il n'y a pas de réponse en noir et blanc à cela. Par exemple: pour quelque chose comme un système embarqué qui est difficile et coûteux à déployer sur des appareils sur le terrain, il peut être préférable d'essayer d'attendre (renégocier les délais si possible) et de le rendre aussi exempt de bogues que possible. D'un autre côté, pour quelque chose comme un grand système de portail Web (écrit comme une application Web) qui peut facilement être mis à niveau à tout moment en déployant des correctifs à leur sortie, il peut être plus judicieux de publier une version initialement douteuse, et puis corrigez les problèmes (et la fonctionnalité de cas de bord) au fur et à mesure.

Mais au bout du compte, d'après mon expérience, il s'agit davantage d'une décision commerciale que d'une décision technologique. Si vous êtes dans une situation où le dépassement du délai est très important, tout en ayant une version initiale de buggy ne l'est pas (ou vice versa) - vous voudrez peser ces choses lors de la prise de décision.

REMARQUE: En tant que programmeur, bien sûr, je préfère l'idée de peaufiner un produit autant que possible avant de le déchaîner (diable, je préfère ne pas avoir de délais du tout, jamais;)). Mais en réalité, ce n'est pas possible dans la vraie vie. Souvent, une version initiale dépouillée est une bonne solution intermédiaire.

J'ai vu beaucoup de PM craindre de dire au client que nous ne pouvons pas respecter le calendrier et insister pour que nous expédions avec des bogues connus. Je peux vous dire que chaque fois qu'ils le disent au client, il est généralement beaucoup plus intéressé par moins de bugs et une échéance déplacée. Je vous garantis qu'ils se souviendront plus des bogues que de la date limite manquée, à moins que la date limite ne soit absolument inamovible (comme le début de la saison de déclaration de revenus lorsque vous faites un logiciel de taxe) ou affectera d'autres choses qui seront très coûteuses à déplacer (IMHO 98% de tous les délais ne répondent pas à ces critères).

Je pense que cela dépend du bug. Voulez-vous retarder une version pour corriger un bogue où l'application se bloque à la minute où elle est lancée sur n'importe quel ordinateur? Oui définitivement. Avez-vous besoin de corriger un bogue qui ne se produit que sur Windows ME pendant la pleine lune? Cela peut probablement attendre.

S'il s'agit d'un bug critique, il est préférable de faire le numéro 2 haut la main. La raison en est qu'il coûte exponentiellement plus cher à réparer si vous devez pousser ce correctif dans une mise à jour.

Pour les mises à jour moins critiques, vous pouvez publier une mise à jour groupée qui réduit ce coût dans une certaine mesure.

En cas de doute, je dis que vous optez pour le n ° 2, mais je ne serais pas surpris d'obtenir un recul de la direction avec cette approche. Je soupçonne que les gestionnaires ont tendance à être jugés davantage en fonction de leur capacité à respecter les délais qu’ils ne provoquent pas de mises à jour critiques inutiles.

Ni. Pourquoi ne pas cuire la qualité avec votre code? Être en mesure de respecter les délais avec un code de qualité? Vous pouvez supprimer moins de fonctionnalités, mais si la qualité est intégrée au processus, vous pouvez atteindre les deux.

Ce qui se passe maintenant, c'est que vous aurez besoin d'un chef d'équipe ou d'un gestionnaire de développement habilité qui peut donner un coup de pouce à l'entreprise et avoir la conversation autour de 2 choses:

1. Qualité intégrée au code = 2 fonctionnalités en moins par build
2. Donner la priorité aux fonctionnalités les plus nécessaires de la partie prenante quant à ce dont elles ont VRAIMENT besoin.

Ensuite, vous pouvez vous concentrer sur les fonctionnalités de la plus haute valeur et les repousser avec excellence.

Eh bien, en ce qui concerne les tests, ce n'est jamais fini. c'est fini mais jamais fini.

Optez pour le lancement avec des bugs avec gravité et plus de priorité.

Le respect de l'échéance avec de nombreux bugs vous rend pauvre dans l'industrie et le client ne reviendra plus vers vous. Vous pouvez parler avec le client pour obtenir le retard de deux ou trois jours.

Si vous regardez cela d'un utilisateur final, je serais assez malmené si quelqu'un promettait de faire quelque chose pour lundi et quand j'essayais de l'utiliser, cela ne fonctionnait pas, ou tout était bogué.

Mais si vous regardez le côté "procédural", cela signifie que l'application a besoin de plus de tests et de sa part de la vie naturelle du logiciel.

Ma meilleure approche est d'essayer de faire fonctionner les choses comme elles devraient fonctionner (si c'est un module majeur, ne faites pas attention aux détails, la connexion dans le formulaire doit se connecter mais tout le monde sera payé si vous ne montrez pas de notifications par la suite).

C'est une question à laquelle vous seul pouvez répondre. Cela dépend du type de produit, qui est le client, ce que le client demande, etc. Il n'y a aucun moyen pour nous de donner une réponse simple «a ou b». Sa situation dépend entièrement.

Mais je vous rappelle que le coût de la correction d'un bogue après sa sortie est bien plus élevé que sa résolution avant sa sortie. Il faut donc en tenir compte lorsque vous décidez d'attendre ou non la publication pour corriger un bogue, car vous y consacrerez plus de temps / d'efforts / d'argent.