10-07-2015, 07:49 PM
Perso, je fais maintenant extrèmement gaffe aux "cette feature anticipe une autre feature de plus tard", car la probabilité que l'autre feature ne soit pas développée est importante (pas développée du tout, ou pas comme prévue). Ce genre d'approche m'a fait me retrouver avec des hooks partout, des points d'ancrages dans tous les sens pour des features qui n'existent pas et dont 9 fois sur 10 l'idée est revenu et modifiée avant d'être développée. En plus, cela fini par créer des features avec des frontières floues, qui se mélangent peu à peu les unes aux autres et débouchent en spaghettis code.
Donc, je te conseillerai de bien arrêter chaque feature, et de jouer "l'autiste": tu t'en fous des features d'après, ce qui compte, c'est de faire une belle feature bien définie et délimitée maintenant.
Attention aussi aux cahiers des charges avec une vision trop long-termiste. Finalement, un petit cahier des charges c'est mieux. Cela permet de faire un jeu plus vite, avec les features essentielles, de prendre bien son temps pour avoir une belle archi, et sur le long terme c'est rentable (je reprends mon exemple perso: eclerd, c'était un énorme pavé de bien 50 pages, et finalement, c'est tout à jeter car y'a rien qui tient debout et rien n'est récupérable ni évolutif).
Donc, je te conseillerai de bien arrêter chaque feature, et de jouer "l'autiste": tu t'en fous des features d'après, ce qui compte, c'est de faire une belle feature bien définie et délimitée maintenant.
Attention aussi aux cahiers des charges avec une vision trop long-termiste. Finalement, un petit cahier des charges c'est mieux. Cela permet de faire un jeu plus vite, avec les features essentielles, de prendre bien son temps pour avoir une belle archi, et sur le long terme c'est rentable (je reprends mon exemple perso: eclerd, c'était un énorme pavé de bien 50 pages, et finalement, c'est tout à jeter car y'a rien qui tient debout et rien n'est récupérable ni évolutif).