Créer un logiciel métier modifie le métier lui-même. Les spécifications de départ deviennent inexactes.
Le client peut demander des choses qui s'avèrent très complexes pour les informaticiens alors que des solutions plus simples et efficaces peuvent exister. Les informaticiens ne peuvent les suggérer que si ils connaissent très bien le métier.
Les méthodes agiles permettent de coller au vrai besoin des utilisateurs et non aux idées de "responsables" hiérarchiques qui sont loin du terrain.
Le cycle en V permet de vérifier qu'un logiciel est conforme aux spécifications, mais comment vérifier que les spécifications sont conformes au besoin ? Mon opinion est que le cycle en V fonctionne bien pour l'informatique embarquée où tout peut et doit être spécifié mais dès que l'on met des humains dans la boucle, il devient très peu performant.
De la même façon, l'architecture d'un système d'information est un choix critique. Si elle est bonne, le système pourra évoluer facilement. Si ce n'est pas le cas, le système vieillira très mal.
Une solution consiste à découper le projet en projets plus petits et définir les interfaces entre eux. Le responsable du projet doit être avant tout le gestionnaire de ces interfaces.
Enfin, le plus important, ce sont les compétences de ceux qui travaillent sur le projet.
[^] # Re: Agile... comment casser le charme!
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 5.
Créer un logiciel métier modifie le métier lui-même. Les spécifications de départ deviennent inexactes.
Le client peut demander des choses qui s'avèrent très complexes pour les informaticiens alors que des solutions plus simples et efficaces peuvent exister. Les informaticiens ne peuvent les suggérer que si ils connaissent très bien le métier.
Les méthodes agiles permettent de coller au vrai besoin des utilisateurs et non aux idées de "responsables" hiérarchiques qui sont loin du terrain.
Le cycle en V permet de vérifier qu'un logiciel est conforme aux spécifications, mais comment vérifier que les spécifications sont conformes au besoin ? Mon opinion est que le cycle en V fonctionne bien pour l'informatique embarquée où tout peut et doit être spécifié mais dès que l'on met des humains dans la boucle, il devient très peu performant.
De la même façon, l'architecture d'un système d'information est un choix critique. Si elle est bonne, le système pourra évoluer facilement. Si ce n'est pas le cas, le système vieillira très mal.
Une solution consiste à découper le projet en projets plus petits et définir les interfaces entre eux. Le responsable du projet doit être avant tout le gestionnaire de ces interfaces.
Enfin, le plus important, ce sont les compétences de ceux qui travaillent sur le projet.