En fait mon expérience perso est que ce qui bouffe pas mal du temps dans la conception d'un projet c'est que le développeur n'est pas seulement un codeur (un traducteur en code machine) mais extrêmement souvent le gardien de la logique et de la cohérence de l'application. Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc. (et c'est long et difficile, ce qui explique que parfois il n'a plus trop envie de communiquer avec le client et cherche à répondre lui même au questions comme noté dans la technique n°1). Perso je pense que le plus gros gain de temps (et de confort) c'est quand on a un client qui a un esprit logique et ne rebute pas à affronter les problèmes. (On pourrait imaginer un test de logique fait au client avant de lui fournir un devis :-P), et en tout cas un dialogue fluide (réactivité aux questions / réponses, points régulier) est plus qu'indispensable.
Ceci dit la technique n°3 (commencer/prototyper les interfaces) est sûrement intéressante (mais peut conduire à des promesses ensuite difficile à tenir, quand on a occulté une difficulté technique).
[^] # Re: Hypothèse fondamentale discutable
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
En fait mon expérience perso est que ce qui bouffe pas mal du temps dans la conception d'un projet c'est que le développeur n'est pas seulement un codeur (un traducteur en code machine) mais extrêmement souvent le gardien de la logique et de la cohérence de l'application. Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc. (et c'est long et difficile, ce qui explique que parfois il n'a plus trop envie de communiquer avec le client et cherche à répondre lui même au questions comme noté dans la technique n°1). Perso je pense que le plus gros gain de temps (et de confort) c'est quand on a un client qui a un esprit logique et ne rebute pas à affronter les problèmes. (On pourrait imaginer un test de logique fait au client avant de lui fournir un devis :-P), et en tout cas un dialogue fluide (réactivité aux questions / réponses, points régulier) est plus qu'indispensable.
Ceci dit la technique n°3 (commencer/prototyper les interfaces) est sûrement intéressante (mais peut conduire à des promesses ensuite difficile à tenir, quand on a occulté une difficulté technique).