Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
D'abord, le noyau Linux a été développé selon une méthode même si celle-ci est propre aux développeurs du noyau et surtout propre à l'approche personnelle de Linus. Méthode qui d'ailleurs s'est raffinée au fur et à mesure des développements. C'est exactement l'approche des méthodes agiles ; la méthode utilisée est une méthode agile.
Ensuite, un programme s'écrit, certes, mais selon des techniques dites d'ingénierie, de la même façon que le projet dans lequel l'élaboration du programme se fait. Ainsi, par exemple, Scrum va t'aider en donnant des techniques dans la gestion de ton projet tandis que des approches comme XP ou TDD va te fournir des méthodes d'écriture de code te permettant d'atteindre une certaine qualité tout en maintenant une cohésion et une discipline d'équipe. De plus, afin de maintenir un code de qualité tout en maintenant une vélocité d'élaboration du programme, des outils comme l'intégration continue, les tests unitaires et d'intégration automatiques, des outils de contrôle de versions, le source control, etc. sont plus ou moins nécessaires et font partie ce que l'on appelle l'ingénierie logicielle.
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.
D'abord, le propre des méthodes agiles est l'auto-discipline et l'auto-organisation. Ce qui tranche en général des méthodes comme CMMi par exemple qui est malheureusement utilisée le plus souvent de la façon dont tu dis.
Ensuite, s'il existe une multitude de méthodes dites agiles, et qui émergent en partie du monde du logiciel libre, certaines sont plus connues sous des noms bien précis comme Scrum, Crystal Clear, etc. Or ces dénominations sont importants parce qu'ils permettent de mieux diffuser la connaissance (ce qui ce cache derrière ce nom) et ils permettent aussi de pouvoir les "vendre" à tes manageurs dans une entreprise ... et ça c'est important ; d'où d'ailleurs le buzz autour.
Derrière les méthodes agiles, je dirais que c'est une sorte de retour du contrôle des développeurs dans la façon dont s'écrivent les programmes, face à un raz bol de toujours payer les pots cassés du fait des décideurs ou manageurs qui n'ont de connaissance du développement logiciel que leur prétention d'y connaitre.
[^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Coding Dojo à Grenoble. Évalué à 2.
Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
D'abord, le noyau Linux a été développé selon une méthode même si celle-ci est propre aux développeurs du noyau et surtout propre à l'approche personnelle de Linus. Méthode qui d'ailleurs s'est raffinée au fur et à mesure des développements. C'est exactement l'approche des méthodes agiles ; la méthode utilisée est une méthode agile.
Ensuite, un programme s'écrit, certes, mais selon des techniques dites d'ingénierie, de la même façon que le projet dans lequel l'élaboration du programme se fait. Ainsi, par exemple, Scrum va t'aider en donnant des techniques dans la gestion de ton projet tandis que des approches comme XP ou TDD va te fournir des méthodes d'écriture de code te permettant d'atteindre une certaine qualité tout en maintenant une cohésion et une discipline d'équipe. De plus, afin de maintenir un code de qualité tout en maintenant une vélocité d'élaboration du programme, des outils comme l'intégration continue, les tests unitaires et d'intégration automatiques, des outils de contrôle de versions, le source control, etc. sont plus ou moins nécessaires et font partie ce que l'on appelle l'ingénierie logicielle.
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.
D'abord, le propre des méthodes agiles est l'auto-discipline et l'auto-organisation. Ce qui tranche en général des méthodes comme CMMi par exemple qui est malheureusement utilisée le plus souvent de la façon dont tu dis.
Ensuite, s'il existe une multitude de méthodes dites agiles, et qui émergent en partie du monde du logiciel libre, certaines sont plus connues sous des noms bien précis comme Scrum, Crystal Clear, etc. Or ces dénominations sont importants parce qu'ils permettent de mieux diffuser la connaissance (ce qui ce cache derrière ce nom) et ils permettent aussi de pouvoir les "vendre" à tes manageurs dans une entreprise ... et ça c'est important ; d'où d'ailleurs le buzz autour.
Derrière les méthodes agiles, je dirais que c'est une sorte de retour du contrôle des développeurs dans la façon dont s'écrivent les programmes, face à un raz bol de toujours payer les pots cassés du fait des décideurs ou manageurs qui n'ont de connaissance du développement logiciel que leur prétention d'y connaitre.