La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
La discipline est nécessaire dans un programme / projet complexe, je ne pense pas que le développement du noyau Linux soit si anarchique que ça. J'en veux pour preuve l'intégration de reiserfs4 (paix à son âme :o(( ) ou de zfs qui ont été refusés car ils ne respectaient pas les 'normes' de codage. Le code est relu avant d'être intégré (tiens une forme de pair-programming même si on est en mode distribué).
Sinon concernant la notion de codification stricte et la vente de gros livres, ça existe sûrement mais c'est contraire à l'Agile où l'idée est de privilégier l'adaptation et le bout de la chaîne (l'équipe). La méthode est plus un certain nombre de règles que l'on pose pour travailler et réaliser un projet (quelque soit sa licence). Mais je suis bien d'accord il y a énormément de buzz autour de l'agilité, si ça fait progresser tout le monde tant mieux, de toute façon c'est inévitable. Il y aura toujours des parasites (ça existe même dans le libre, et là aussi ça me rend triste). Pour moi l'agilité c'est une 'philosphie', une manière de penser son projet, comme le libre.
Le chef n'existe plus en tant que tel dans une équipe Agile puisque l'un des mots d'ordre est 'empowered the team' (donner le pouvoir à l'équipe). Je dirai même au contraire que le chef de projet classique a plutôt tendance à disparaitre dans une équipe agile (ce qui n'est pas sans créer une certaine résistance).
Pour les bugs, désolé moi je me trompe souvent, je remanie mon code très souvent et j'essaye de suivre l'évolution des librairies que j'utilise. Je suis bien content d'avoir une batterie de tests qui m'assure 'automatiquement' que tout fonctionne toujours, plutôt que de devoir rejouer ça à la main où que mes utilisateurs le découvrent en étant bloqué avec mon logiciel en rade :o(. Ce n'est pas parfait mais ça aide et moi je ne veux plus coder sans, j'y gagne en temps et en stress en moins et en plaisir en plus :o).
PS.: juste pour conclure, l'agilité était l'un des arguments qui a convaincu mon boss d'ouvrir notre logiciel en GPLv3 cette année ;o).
[^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode
Posté par Emmanuel Hugonnet . En réponse à la dépêche Coding Dojo à Grenoble. Évalué à 2.
La discipline est nécessaire dans un programme / projet complexe, je ne pense pas que le développement du noyau Linux soit si anarchique que ça. J'en veux pour preuve l'intégration de reiserfs4 (paix à son âme :o(( ) ou de zfs qui ont été refusés car ils ne respectaient pas les 'normes' de codage. Le code est relu avant d'être intégré (tiens une forme de pair-programming même si on est en mode distribué).
Sinon concernant la notion de codification stricte et la vente de gros livres, ça existe sûrement mais c'est contraire à l'Agile où l'idée est de privilégier l'adaptation et le bout de la chaîne (l'équipe). La méthode est plus un certain nombre de règles que l'on pose pour travailler et réaliser un projet (quelque soit sa licence). Mais je suis bien d'accord il y a énormément de buzz autour de l'agilité, si ça fait progresser tout le monde tant mieux, de toute façon c'est inévitable. Il y aura toujours des parasites (ça existe même dans le libre, et là aussi ça me rend triste). Pour moi l'agilité c'est une 'philosphie', une manière de penser son projet, comme le libre.
Le chef n'existe plus en tant que tel dans une équipe Agile puisque l'un des mots d'ordre est 'empowered the team' (donner le pouvoir à l'équipe). Je dirai même au contraire que le chef de projet classique a plutôt tendance à disparaitre dans une équipe agile (ce qui n'est pas sans créer une certaine résistance).
Pour les bugs, désolé moi je me trompe souvent, je remanie mon code très souvent et j'essaye de suivre l'évolution des librairies que j'utilise. Je suis bien content d'avoir une batterie de tests qui m'assure 'automatiquement' que tout fonctionne toujours, plutôt que de devoir rejouer ça à la main où que mes utilisateurs le découvrent en étant bloqué avec mon logiciel en rade :o(. Ce n'est pas parfait mais ça aide et moi je ne veux plus coder sans, j'y gagne en temps et en stress en moins et en plaisir en plus :o).
PS.: juste pour conclure, l'agilité était l'un des arguments qui a convaincu mon boss d'ouvrir notre logiciel en GPLv3 cette année ;o).