Financement de projets agiles

L'entreprise dans laquelle je travaille s'oriente provisoirement vers une stratégie de gestion de projet Agile - ayant connu les «joies» de la cascade de temps en temps. La clé de tout cela est un changement dans l'accent mis sur la fourniture de fonctionnalités plutôt que sur le respect de délais stricts.

Bien que le processus de développement et la relation client se soient certainement améliorés grâce aux versions itératives encouragées par Agile, il s'avère un peu plus difficile d'appliquer la même logique aux stratégies de financement du projet. Les clients sont souvent peu habitués à des concepts comme Agile, et expriment une grande inquiétude à propos de ce qu'ils perçoivent comme un cas de "ça sera prêt quand c'est prêt".

J'aimerais entendre les réflexions et les expériences des gens sur le financement de projets Agile

edit: Je tiens à souligner que je ne demande pas aux gens de m'expliquer les avantages et les inconvénients de la méthode Agile , ni que je pense qu'Agile équivaut à "elle sera prête quand elle sera prête", c'est une crainte exprimée par le clients / entreprises avec lesquels j'ai travaillé lors de la promotion des pratiques de développement Agile.

Ce qui m'intéresse, ce sont les expériences que les gens ont eues en résolvant les conflits entre les méthodes de budgétisation en cascade "traditionnelles" ancrées dans les relations avec les clients commerciaux et les méthodes de développement plus progressives - et les stratégies budgétaires qu'ils ont adoptées pour soutenir cette évolution.

Si vous avez pu donner un devis sur un projet avec une date finale exacte sur toutes les fonctionnalités, pourquoi êtes-vous passé à une approche agile? Vous et tout le monde avez du mal avec cela et une approche agile est en face de ce fait. Utilisez-le comme propagande contre la concurrence. Southwest Airline ne vous promet pas de siège dans une île comme tout le monde et le donne à quelqu'un d'autre.

Bien sûr, le client veut une date de fin exacte. Ils veulent un logiciel peu coûteux et sans bogue livré à l'avance indépendamment de toute modification de la demande d'origine. Dites à votre équipe de vente d'apprendre à vendre un projet en utilisant des principes agiles. Plus vous passerez d'interactions, plus vous vous rapprocherez de la date de fin du projet. Le client apprend également à prendre en compte les effets des demandes de changement.

Les projets agiles ne fonctionnent pas dans le sens de "ce sera prêt quand il sera prêt". C'est une ligne classique de l'ingénierie en cascade.

Les projets agiles sont terminés lorsque le client décide qu'il ne veut plus dépenser d'argent pour des fonctionnalités supplémentaires. Cela pourrait être converti en un argument de vente clé par vos vendeurs. Au lieu de s'engager sur un ensemble fixe de fonctionnalités (dont le besoin peut ou non être connu à l'avance) pour un montant fixe, le client peut commencer avec un montant initial pour un ensemble de fonctionnalités initial, puis le prendre par étapes. Cela garantira deux ou trois choses:

• Tant que la liste des fonctionnalités est correctement hiérarchisée, le client obtient toujours les prochaines fonctionnalités les plus importantes, maximisant ainsi son avantage de ses dépenses (il obtient "le meilleur rapport qualité / prix").
• Si le client manque d'argent, il a maximisé son investissement ET vous avez été payé pour ce que vous avez livré. Personne n'est blessé, tout le monde en profite.
• Le client peut changer d'avis sur les priorités et les fonctionnalités à chaque tour de roue (à chaque extrémité d'une interaction). Un avantage distinct sur les contrats à prix fixe normaux.

Il y a probablement plus, mais ce qui précède devrait être suffisant pour amener vos vendeurs dans la bonne direction.

Eh bien, je ne vois pas cela comme un cas de "Il sera prêt quand il sera prêt". La méthodologie agile favorise l'offre de livrables sur une base régulière, comme toutes les deux semaines. C'est pourquoi le client est une partie importante et très active du projet tout au long de sa vie car il fournit des conseils sur la façon dont les caractéristiques de votre produit prendront forme. Si quoi que ce soit, un client commencera à voir des résultats plus tôt, plutôt que vers la fin d'un projet, comme dans l'approche en cascade.

Tant que vous réitérez le fait que le client sera une partie active du projet et qu'il verra le projet commencer à prendre forme tôt, cela pourrait lui assurer qu'il ne s'agit pas d'attendre qu'il soit terminé.

Bien que l'endroit où je travaille fasse une horrible bastardisation d'Agile, je pense que les clients sont plus susceptibles de préférer le développement de logiciels dans les itérations que les versions complètes.

Les itérations se prêtent aux demandes individuelles des clients, en ce sens qu'elles demandent quelque chose et l'obtiennent lorsque la fonctionnalité est implémentée, pas une fois qu'elle est terminée et que toutes les autres choses qui ont été regroupées avec elle pour une version sont également effectuées.

Je n'ai jamais vu un client dire: "Nous voulons cette fonctionnalité, et nous voulons attendre 8 mois pour qu'elle soit livrée avec un tas d'autres fonctionnalités qui ne nous intéressent pas."

Que diriez-vous d'établir un cycle de paiement en phase avec les itérations? L'idée de l'agilité est que vous ne pouvez vraiment planifier et estimer que sur de courtes périodes, et la poussée et l'engagement sont toujours forts pour ces cycles courts. Alors pourquoi ne pas cibler le financement de la même manière - demandez aux clients de contribuer à l'emploi avec $$ en même temps qu'ils contribuent avec des conseils. Après tout, s'ils n'obtiennent pas ce qu'ils veulent, ils ne devraient pas payer pour cela.

Et ensuite, déterminez ce qui se passe à la fin d'un projet - par exemple, le client possède-t-il le code ou simplement l'exécutable? Mais cela serait conforme aux précédents projets de type cascade.

L'idée d'Agile est que vous itérez rapidement et établissez exactement ce que vous allez livrer à la fin de chaque sprint, donc lorsque les 2/3/4 semaines de votre sprint sont terminées, vous avez des fonctionnalités tangibles dans votre application / projet que vous pouvez présenter à votre client et obtenir des commentaires.

ETA: vous pouvez regrouper les «sprints» en «jalons», avec des livrables établis, et recevoir un paiement par jalon.

Je ne suis pas moi-même convaincu que vous devez vendre un projet fixe et gérer Agile de votre côté, mais plutôt vendre des itérations à votre client.

Les itérations sont claires à comprendre et vous ne mélangez pas les deux concepts.

Les deux documents suivants vous fourniront quelques informations sur les interactions Agile Management & Sales Process:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf