04-02-2014, 11:39 PM
pour la méthodo, attention, agilité et extrem programming n'ont de sens que s'il y a équipe et rôles différenciés (à minima le client/product owner/testeur et le développeur, et les développeurs dans XP puisque l'un des principes est de bosser en binome)
après ça ne change rien au fait d'utiliser ou pas les quelques principes que tu as cité mais ce n'est pas parce qu'on applique quelques éléments d'une méthodo qu'on utilise une méthodo
une fois dit cela je pense que ce sont de bons principes, je rajouterais la notion de backlog général (autant pour toi pour tenir sur la durée, que pour piloter les efforts d'une éventuelle future équipe).
attention aux TDD, c'est intéressant d'automatiser mais pas tout :
si une fonctionnalité est simple ou ne risque pas d'évoluer / régresser (donc si pas trop de dépendance avec d'autres modules/fonctionnalité) il est inutile de passer du temps à faire du test automatisé.
grosso modo si tu penses qu'une fonctionnalité ne devra être testée que durant 3 ou 4 itérations, tu prévois des tests manuels, si tu penses que tu vas plus souvent revenir ou être impacté par d'autres alors éventuellement développe les tests.
le développement de ces tests peut être coûteux, en tant comme en motivation, et pas forcément utile, c'est pourquoi il faut juger de leur pertinence.
Après ca ne remet pas en cause le TDD juste attention à "le mieux est l'ennemi du bien"
pour le reste je ne me prononce pas, pas assez d'expérience
après ça ne change rien au fait d'utiliser ou pas les quelques principes que tu as cité mais ce n'est pas parce qu'on applique quelques éléments d'une méthodo qu'on utilise une méthodo
une fois dit cela je pense que ce sont de bons principes, je rajouterais la notion de backlog général (autant pour toi pour tenir sur la durée, que pour piloter les efforts d'une éventuelle future équipe).
attention aux TDD, c'est intéressant d'automatiser mais pas tout :
si une fonctionnalité est simple ou ne risque pas d'évoluer / régresser (donc si pas trop de dépendance avec d'autres modules/fonctionnalité) il est inutile de passer du temps à faire du test automatisé.
grosso modo si tu penses qu'une fonctionnalité ne devra être testée que durant 3 ou 4 itérations, tu prévois des tests manuels, si tu penses que tu vas plus souvent revenir ou être impacté par d'autres alors éventuellement développe les tests.
le développement de ces tests peut être coûteux, en tant comme en motivation, et pas forcément utile, c'est pourquoi il faut juger de leur pertinence.
Après ca ne remet pas en cause le TDD juste attention à "le mieux est l'ennemi du bien"
pour le reste je ne me prononce pas, pas assez d'expérience