Sauter pour travailler sur différentes fonctionnalités lorsque vous êtes bloqué, est-ce une source d'échecs de projet?

Sur des projets personnels (ou au travail), si l'on est bloqué sur un problème, ou en attente de trouver une solution au problème, si vous passez à une autre section de votre code, ne pensez-vous pas que ce sera une bonne raison pour votre application sera bogué ou pire mais ne sera jamais terminé?

En supposant que vous n'utilisez pas git et ne codez pas chaque fonctionnalité pour une branche spécifique, les choses peuvent devenir incontrôlables puisque vous avez 3 fonctionnalités différentes sur lesquelles vous travaillez et que vous avez des problèmes non résolus dans chacune.

Donc, lorsque vous avez fini de travailler, vous êtes stressé parce que vous avez des problèmes de blocage et du code à moitié cuit qui traînent.

Quelle est la meilleure façon d'éviter ce problème? (si tu l'as)

Je suppose que l'utilisation de quelque chose comme git et la création d'une branche par fonctionnalité est le moyen le plus sûr d'éviter cette mauvaise habitude.

D'autres suggestions?

Ce n'est pas un problème. S'éloigner temporairement d'un problème embarrassant est l'un des meilleurs moyens d'avoir une percée sur un tel problème (soit plus tard lorsque vous y pensez ou la prochaine fois que vous vous asseyez avec une perspective / un esprit nouveau).

Assurez-vous toujours d'utiliser correctement les branchements de contrôle de source et vous n'aurez pas à vous soucier des demi-solutions dans le code. Certaines personnes ne font jamais de pause, mais ce n'est qu'un choix personnel. Vous ne devriez jamais vraiment pousser les pauses à partager avec les autres.

Comme l'a mentionné smp7d , sauter peut vous donner une bonne pause mentale par rapport au problème actuel . Cependant, il est important de ne pas oublier que le code sur lequel vous travailliez est encore incomplet. Assurez-vous de savoir où vous vous êtes arrêté.

Comme l'a mentionné smp7d, le contrôle de source et la ramification sont un excellent moyen de séparer votre nouveau code de fonctionnalité et de voir en quoi il diffère de la base de code principale.

Une suggestion que j'ai est que si vous travaillez sur une méthode particulière, assurez-vous qu'il existe un test unitaire bien nommé autour de cette méthode. De cette façon, lorsque vous travaillez sur ce code le jour / la semaine / le mois / l'année suivants, vous devriez être en mesure de dire clairement ce que la méthode est censée faire, même si elle ne réussit pas actuellement le test.

C'est un problème? Pas quand cela vous vient à l'esprit pour 10% des fonctionnalités que vous essayez de mettre en œuvre. Parfois, vous obtenez votre esprit plus clair lorsque vous faites quelque chose de différent en premier.

Évidemment, c'est un problème lorsque vous êtes bloqué pour 90% des fonctionnalités que vous essayez de mettre en œuvre - alors vous avez besoin de l'aide des autres ou d'un léger coup de pied de votre patron pour terminer ce que vous avez commencé (bien sûr, ce dernier être contre-productif si vous êtes coincé à cause d'un réel problème technique).

La meilleure option dans ce cas est souvent d'essayer de diviser la fonctionnalité sur laquelle vous travaillez en de plus petites sous-fonctionnalités ou "tranches de fonctionnalités", qui peuvent être implémentées, testées et déboguées une par une. Pour moi, cela aide à écrire ces tranches de fonctionnalités, les problèmes ouverts, les parties à faire sur une liste, à leur donner des priorités (A, B, C suffit) et à travailler d'abord sur les choses avec la plus haute priorité.

D'après mon expérience, «sauter autour», ou plus clairement «sauter au hasard» est le symptôme d'un problème plus urgent, l'un des objectifs mal énoncés.

Si vous avez une idée très claire, par écrit, que ce soit des notes post-it sur le côté de votre moniteur ou des spécifications formelles attachées à votre tracker de problème de choix, alors vous savez presque toujours exactement sur quoi travailler ensuite . Si vous travaillez toujours sur l'une de ces choses suivantes, vous aurez de bonnes chances de réussir le projet.

Si, en revanche, votre idée de ce qui est la prochaine chose la plus importante est floue, il est beaucoup plus difficile de trouver réellement une chose à travailler qui résout réellement le problème que votre projet vise à résoudre, ou plus précisément, c'est beaucoup moins coupé - et-sec pour décider que ce changement particulier est terminé et résout un problème particulier.

Si vous avez un objectif comme "rendre l'interface utilisateur plus facile à utiliser", eh bien, il est presque impossible de dire quel pourrait être le prochain correctif, ou lorsque vous avez terminé de "réparer l'interface utilisateur" et que vous pouvez passer à autre chose. Si, d'autre part, vous avez un objectif comme "combiner ces listes déroulantes dans un champ de recherche avec la saisie semi-automatique" et "'foo' devrait se compléter automatiquement en 'Fooly Brand Baring'", c'est totalement évident quand vous aurez corrigé ce problème.

N'écrivez pas de code tant que vous ne savez pas vraiment quand vous arrêter , et si vous n'avez pas d'idées claires, essayez d'en obtenir une au lieu de démarrer une autre branche pour une fonctionnalité générale.

Si vous avez une telle qualité de travail (même pour des projets personnels), alors "sauter" est tout à fait correct, sûr et utile.

Bien que vous éloigner d'un problème puisse vous aider à le résoudre, gardez à l'esprit qu'il y a un coût à changer de contexte. Vous ne devriez essayer de le faire que lorsque vous êtes vraiment bloqué ou qu'une tâche critique survient (par exemple, un client est en panne).

Si vous basculez constamment entre les tâches, vous pouvez vous retrouver avec plusieurs fonctionnalités à moitié terminées et beaucoup de temps perdu. C'est pourquoi des pratiques telles que kan-ban vous encouragent à définir une limite de travail en cours. De cette façon, vous pouvez vous concentrer sur l'achèvement, au maximum, de quelques tâches à la fois, augmentant ainsi le débit.

Parfois, il peut être utile de limiter le nombre de fonctionnalités implémentées en parallèle. Refusez de commencer à implémenter une fonctionnalité supplémentaire si cette limite est dépassée jusqu'à ce qu'une autre fonctionnalité soit terminée. Cette approche est appelée Kanban