En tant que programmeur, je suis tout à fait en faveur de la méthodologie agile, nous savons tous qu'elle fait la différence, mais comment la vendez-vous à un tiers? Le travail que nous faisons est généralement à prix fixe et il est habituel pour nous d'avoir seulement une vue de haut niveau des exigences quand nous citons car c'est souvent une situation concurrentielle. Nous constatons souvent que lorsque nous gagnons un contrat et que nous examinons les détails, les fonctionnalités prennent de l'ampleur. Bien que nous ayons un mécanisme pour gérer ce fléau, il n'est pas assez robuste et transparent, ce qui nous amène généralement à concéder des jours.comment gérer un projet agile avec un tiers
La méthodologie agile peut dire qu'il n'y a pas de fluage de portée, mais dans le monde réel, nous savons tous qu'il y a. Quand un client vous demande de fournir une solution, à un prix fixe et à l'échelle de temps (ce qui sera toujours le cas), puis changez les poteaux de but à mi-projet, ce qui est un fluage de portée. À la fin de leur budget, il est fort probable qu'ils se retrouveront avec quelque chose de différent de ce qu'ils avaient initialement prévu et qui pourrait ne pas répondre entièrement à leurs besoins initiaux. À ce moment-là, ils vont revenir et prétendre qu'ils n'ont pas ce qu'ils ont payé - la seule protection que nous avons contre cela est une spécification qui énonce exactement ce qu'ils vont mettre en avant que nous pouvons livrer contre, clairement pas la manière agile.
Je sais que les gens vont dire que le client doit être tenu informé à tout moment de ce qu'ils obtiennent et de ce qui est déplacé hors de portée bla bla bla ... mais dans le monde REAL autant que je peux voir vous aurez toujours des clients qui diront ensuite à la fin - ce n'est pas ce que vous avez promis de livrer/nous avons payé. Comment gérons-nous cette situation?