Bonne combinaison de planification et de programmation sur un nouveau projet

10

Je suis sur le point de démarrer un nouveau projet (un jeu, mais c'est sans importance). L'idée de base est dans ma tête mais pas tous les détails.

Je ne veux pas commencer à programmer sans planifier, mais je combat sérieusement mon envie de le faire. Je veux un peu de planification avant d'empêcher la refactorisation de l'application entière juste parce qu'une nouvelle fonctionnalité à laquelle je pourrais penser l'exige. D'un autre côté, je ne veux pas planifier plusieurs mois (temps libre) et commencer ça parce que j'ai peur de perdre ma motivation pendant ce temps.

Ce que je recherche, c'est un moyen de combiner les deux sans que l'un ne domine l'autre. Dois-je réaliser le projet à la manière de la mêlée? Dois-je créer des user stories puis les réaliser? Dois-je travailler avec des fonctionnalités? (J'ai une certaine expérience de la mêlée et de la méthode classique de "spécification à coder".)

Mise à jour : que diriez-vous de commencer avec un "mannequin de clic" et d'implémenter la fonctionnalité plus tard?

project-management agile

— WarrenFaith
source

5

Vous êtes sur la bonne voie. Il n'est pas nécessaire de passer des mois à planifier, mais vous devriez certainement avoir une sorte de plan.

La planification vous aidera à organiser vos pensées, à identifier les technologies dont vous pourriez avoir besoin, à clarifier les points chauds et à vous donner une feuille de route à partir de laquelle vous pourrez vous décomposer en objectifs mesurables.

De plus, vous pouvez faire quelques jours de planification pour découvrir que c'est une perte de temps. Peut-être que lors de la planification, vous vous rendez compte que vous êtes loin de votre ligue ou que ce que vous essayez de faire ne peut pas être commercialisé. Il vaut mieux le découvrir maintenant afin que vous puissiez réinvestir votre temps dans d'autres idées que vous avez, plutôt que de suivre cette voie pour vous perdre dans les bois, entouré de vignes codées et de sentiers de logique faillible qui tord votre cerveau en nœuds.

— jmort253
source

La plateforme de ciblage est mon travail quotidien, je connais donc la plupart des technologies que je souhaite utiliser. Je suppose que j'utiliserai une mêlée simple et un plan de base. Je peux donc commencer par quelques backlogs et faire le planing à chaque itération.

— WarrenFaith

Vous continuez à mal orthographier la "planification". Je pensais juste le souligner car je ne peux pas modifier votre commentaire :) Mais oui, je pense que la mêlée est une excellente approche car elle maintient la flexibilité et vous donne la possibilité de décider si cela vaut la peine de poursuivre le projet.

— jmort253

Oo En allemand, c'est l'inverse: planifier avec un n et programmer avec deux m ...: D Merci!

— WarrenFaith

@WarrenFaith - Désolé! C'est mon ethnocentrisme qui sort! Merci d'avoir signalé mon erreur;)

— jmort253

11

Planifiez le produit viable minimum et mettez -le en œuvre. Écoutez ensuite vos utilisateurs, planifiez la prochaine amélioration logique et implémentez-la. Répéter.

— Steven A. Lowe
source

3

.... et chaque fois que vous avez une idée de quelque chose que vous pensez être cool, écrivez simplement l'idée dans le carnet de commandes, mais ne l'implémentez pas tant que le produit minimum viable n'est pas fait.

— k3b

la principale question est toujours de savoir à quel point je dois le planifier. Si vous pouviez aussi me donner ce conseil, vous avez accepté la réponse.

— WarrenFaith

1

@WarrenFaith: fonctionnalités - >> histoires - >> cas de test.

— Steven A. Lowe

4

Peu importe le temps que vous passez à planifier et à concevoir votre programme, vous finissez toujours par en réécrire certaines parties. C'est comme la gravité, pas intelligent de nier son existence.

Il faut comprendre que le refactoring est une partie normale du développement et c'est juste une question de décider quand vous le faites. Attendez trop longtemps et vous vous retrouvez avec d'énormes quantités de spaghettis, suppliant pour une réécriture complète. Pas drôle.

Ma suggestion est de planifier un peu mais de commencer à coder dès que possible et de refactor, refactor, refactor pour garder le code en forme. Le principe DRY (ne vous répétez pas) en est un excellent indicateur.

— Martin Wickman
source

Merci pour votre réponse. Je sais que le refactoring n'est pas inhabituel mais je ne veux pas empêcher le refactoring causé par un rabotage manqué.

— WarrenFaith

@Warren - le fait de ne pas planifier n'empêche pas la refactorisation. Vous pouvez soit coder la solution sur l'ordinateur, soit tenter de la coder dans votre tête ou sur papier. Je pense que les deux sont inefficaces. Commencez à coder, sachant que vous le modifierez plus tard.

— kevin cline

@kevin cline: Ok, permet de faire la différence entre refactoriser le code existant pour une nouvelle fonctionnalité ou des améliorations et réécrire presque toute l'application pour une nouvelle fonctionnalité. Je peux vivre avec le premier, pas vraiment avec le second ..

— WarrenFaith

@WarrenFaith: Tant que le code est serré et en forme, vous devriez pouvoir éviter les réécritures. La seule fois où j'ai vu des réécritures, c'est quand le système est devenu une grosse boule de boue (pas de refactoring), ou un changement technique fondamental (changement de plateforme).

— Martin Wickman

3

Quand je suis dans cette position, j'utilise parfois TDD (développement piloté par les tests) et commence à planifier certains tests pour la partie la plus complexe du système que je développe. Alternativement, je peux rassembler un pseudo-code de haut niveau, là encore pour les zones les plus complexes. Je trouve que ce processus me donne un plan d'action lâche et m'aide à identifier les domaines susceptibles de prendre le plus de temps.

Pour moi, cette approche fonctionne parce qu'elle se situe quelque part entre le codage et la planification. Une fois que vous avez vos idées de test et / ou votre pseudo-code, vous pouvez parcourir chaque section logique et implémenter le code. J'aborde souvent d'abord la partie la plus difficile d'une solution proposée, car généralement la partie la plus difficile est la caractéristique principale de l'application et vous pouvez toujours retarder les cloches et les sifflets.

Puisque vous commentez que la plupart du code est dans votre tête et que vous êtes prêt à plonger et à programmer, l'utilisation de cette approche peut vous aider à vous concentrer sur chaque section sans que votre esprit ne soit assombri par le système dans son ensemble.

Pour résumer plus succinctement, on pourrait dire "aborder d'abord la partie la plus difficile, diviser pour mieux régner, avec un pseudo code et / ou des plans TDD"!

— BradB
source

Je ne suis pas fan de TDD mais merci quand même!

— WarrenFaith

Je ne dis pas nécessairement utiliser TDD, mon point de vue était que c'est quelque chose que j'utilise comme structure pour "planifier" mon code. De cette façon, je ne saute pas directement dans l'écriture de mon code et je ne passe pas longtemps à rédiger des documents de masse / plans de projet qui sont un peu trop éloignés du codage réel. Il s'agit de trouver le juste milieu. Vous pouvez réaliser la même chose en principe avec un stylo et du papier. Je dois également souligner que je n'écris pas un test pour TOUT - juste les domaines les plus complexes.

— BradB

3

Essayez simplement de rendre le code modulaire. Tout ce que vous prévoyez est susceptible d'être rejeté lors de la prochaine itération.

— davidk01
source

2

Je recommanderais au moins d'écrire vos idées. Selon la taille du projet, une grande partie de la planification formelle peut ne pas être nécessaire. Si toutefois il est très important, vous voudrez peut-être vous éviter des maux de tête et passer quelques jours à faire une planification plus approfondie.

— Kenneth
source