Les meilleures pratiques pour l'implication des clients dans le développement Agile? [fermé]

Question

Nous devons impliquer nos partenaires au développement de la clientèle dans notre processus de développement. Nous sommes plus ou moins suivant les méthodes Agile. Certains clients partenaires sont éloignés, d'autres plus proches. Nous devons réduire au minimum les frais de déplacement.

Nos clients sont en soins de santé et ont tendance à être occupé, coûteux et difficile à programmer.

Quelles sont les pratiques et les technologies ont travaillé pour soutenir la participation à la clientèle? Nous utilisons des appels téléphoniques, des conférences téléphoniques et email. Nous sommes curieux de savoir tirer parti des techniques de wiki et je serais ravi d'entendre ce qui a fonctionné pour d'autres.

Answer 1

Mon expérience avec les méthodes Agile est la plupart du temps pour des applications de bureau. Quand nos clients sont à distance, nous avons passé beaucoup de temps pour obtenir un ingénieur sur le site du client pour configurer / installer une plate-forme de démonstration. L'ingénieur travaille avec le client lors d'un test et la configuration démo / plan qui fournira un environnement que le client croit reproduit les aspects importants de l'environnement de déploiement mais isole le système de démonstration à partir des infrastructures existantes (afin que nous puissions pousser les mises à jour chaque fois que nous devons ). L'ingénieur met également en place des systèmes de déploiement pour déplacer nos applications en production, afin que nous puissions « déployer » sans être sur place. Nos applications peuvent se mettre à jour (soit pour chaque version ou chaque génération) et nous les instruments soigneusement communiqués de journal tous erreurs et soumettons tous les accidents que des bugs à notre bug tracker. De cette façon, nous savons au moins ce qui a mal tourné, même si nous ne savons pas ce qui se passe à droite.

Pour chaque version / build qui apparaît sur le banc d'essai du client, nous fournissons une (courte) screencast, narré par le chef de projet ou développeur principal, démonstration-ing de nouvelles fonctionnalités. Les notes de version contiennent des problèmes à long terme ou des questions que nous voulons que le client à penser (à savoir les questions qui ne peuvent pas être résolus immédiatement par un appel téléphonique ou e-mail), et l'application affiche ces notes pour l'utilisateur.

Enfin, et peut-être plus important encore, nous obtenons le client et / ou la liaison du client un compte sur notre serveur de calendrier et configurer leur application de calendrier pour utiliser ce compte. Voilà donc les deux sens -. Nous pouvons prévoir du temps (sur place, téléphone, e-mail, etc.) avec le client et ils peuvent faire la même chose avec nos développeurs

Answer 2

il n'a pas d'importance si le client est dans la même armoire ou à mi-chemin autour de la planète, à l'exception des retards de communication -. Le facteur critique est disponibilité

un client qui est trop occupé pour répondre à vos e-mails pendant plusieurs jours va entraîner votre itération d'être en retard ou l'échec

le client a deux engagements essentiels pour agile:

1. pour répondre aux questions en temps opportun
2. ne pas changer leur esprit / priorités lors d'une itération

le client doit engager à un accord de niveau de service raisonnable (SLA) sur la disponibilité, par exemple temps de réponse 1 heure, ou le temps de réponse 24 heures, etc., et vous devrez ajuster toutes les estimations et les horaires par le facteur de retard. Si le client ne commettra pas ou ne se conforme pas, annulez l'itération et re plan, ce qui porte à nouveau l'engagement du client à l'avant-garde. Ne pas juste « deviner » ce que vous pensez que le client pourrait vouloir.

Bottom line:. Sans engagement client, agile ne fonctionnera pas

Answer 3

Une option: Installer un proxy client sur le site « partenaire client » qui peut extraire les informations dont vous avez besoin lorsque les clients sont disponibles. Demandez à ces procurations construire les relations solides qui leur permettent de représenter le point de vue du client. Leur temps est tout à vous. Et quand des questions se posent qu'ils ne peuvent pas répondre, ils ont un accès facile à vos partenaires clients -. Même si dans la ligne de café

Answer 4

Le point entier du client agile est d'avoir un discours ouvert et libre avec les développeurs (IE de rétroaction immédiate). Si vos clients réels ne peuvent pas fournir ce, alors vous avez besoin d'un intermédiaire / proxy qui peut remplir ce rôle. Vous ne faites pas besoin réelle les clients, vous avez juste besoin de quelqu'un qui peut représenter des intérêts assez bien pour répondre à vos clients des besoins clients.

Answer 5

Juste quelques idées:

Si vous choisissez d'utiliser un wiki, assurez-vous qu'il prend en charge une liste « changements récents » tout-wiki à l'échelle, et de préférence un qui est spécifique aux utilisateurs. Le moins éloigné des gens de développement sont, plus susceptibles d'avoir le courrier électronique comme métaphore de leur utilisation de l'ordinateur. S'ils ne peuvent pas dire immédiatement quand il y a quelque chose de nouveau pour eux de voir, ils ne pourront jamais explorer. Vous avez également besoin de préférence des moyens de signaler leur que vous avez besoin de leur attention sur les questions, ou ils traiteront des changements comme les pays candidats.

Je suis un grand croyant dans la création de captures d'écran vidéo d'interactions (narré) et de les distribuer aux utilisateurs. Contrairement à une véritable démonstration, les clients ne se sentent pas comme ils ont besoin d'interrompre, et ils peuvent revenir en arrière et re-regarder la même interaction plus et plus, en accordant une attention aux petits détails.

Enfin, si vous faites distribuer des prototypes, assurez-vous d'envoyer quelqu'un (ou au moins une session de partage d'écran) pour voir comment les prototypes sont utilisés. la conception contextuelle est efficace. Vous pouvez compter sur les personnes qui utilisent votre prototype différemment de la façon dont vous vous attendez, et vous devez comprendre comment ils l'utilisent pour vraiment comprendre où sont les problèmes, même si elles ne les déclarent pas.

Answer 6

Avez-vous envisagé quelque chose comme LogMeIn .

Cela permettrait aux clients soit connecter à un PC sur votre réseau déjà en cours d'exécution de votre application, ou bien vous permettre d'installer / mettre à jour l'application sur un de leurs ordinateurs.

Cela résoudrait la question du client à distance et soutiendrait également l'exigence de la rétroaction des clients continue en cours dans le processus agile.

Je l'ai utilisé une ancienne société de soutien technique, mais il n'y a aucune raison (sauf peut-être le coût) que cela ne fonctionnerait pas pour votre situation.

Il est aussi un excellent moyen de voir réellement comment les utilisateurs utilisent votre application et donc trouver ce qui fonctionne et ce qui ne fonctionne pas.

Answer 7

Tout d'abord, assurez-vous que vous avez un gestionnaire de produit ou d'un propriétaire du produit fermer les développeurs. Cette personne va gérer la relation avec le client.

Ensuite, le chef de produit peut démontrer le produit au client à la fin de chaque itération et également poser des questions aux clients lorsque le développeur a besoin des commentaires pour mettre en œuvre une histoire d'utilisateur.

Il est étonnant les commentaires positifs que vous pouvez obtenir des clients lorsque vous les impliquez.

Nous n'avons pas utilisé un wiki et la plupart de la communication se fait via e-mail, téléphone, et une application de partage d'écran (nous utilisons GoToMeeting, mais il y a des tonnes de solution là-bas).

Answer 8

Vous devriez probablement faire un coup d'envoi une fois avec tout le monde à un endroit. Face-à-face temps est précieux. Cela inclut tous les développeurs. Préparez quelques questions magnétiqes, mais aussi assez de temps pour que se mêlent.

Answer 9

Je pense que la plupart des définitions des processus agiles qui ont une forte dépendance sur l'implication des clients que vous avez déjà manqué les « meilleures pratiques », ce qui serait un sur place, et de préférence « en équipe » présente à la clientèle en tout temps. Donc, je suppose que nous sommes à la recherche d'une « nouvelle meilleure pratique ». :)

Il y a la possibilité d'introduire un « client proxy » sur place. Je dois admettre que d'être très sceptiques quant à la valeur d'un client proxy. Je suis préoccupé par le risque d'introduire une sorte de second ordre et autre fonction inutile d'analyste d'affaires au mélange, avec le rapport signal accru bruit et le potentiel de messages tronqués. Il comporte aussi le risque de permettre à des clients réels occupés à réduire leur implication dans le processus, ce qui est susceptible de conduire à l'insatisfaction. Je me demande s'il pourrait y avoir quelqu'un avec une bonne connaissance du domaine qui a récemment pris sa retraite et pourrait être disponible pour agir à ce titre en tant que consultant?

bande passante de communication avec les clients à distance est étonnamment faible que face à face, quelque chose que je jusqu'à ce que je ne l'avais pas pleinement réalisé commencé à traiter avec les utilisateurs dans un autre pays. Même avec la vidéo la perte est importante.

Combien de temps vos itérations? Comment est itérations la planification? Serait-il plus facile d'aller pour des itérations plus et obtenir plus de planification fait moins fréquemment, ou réduire l'itération longueur et aller plus petits, mais des séances de planification plus fréquentes? Sont plus d'un involv client

Avez-vous une version utilisable et disponible à la fin de chaque itération? Y at-il de temps pour les utilisateurs concernés d'avoir le temps sur les mains avant-la prochaine session de planification? utilisateurs engagés par l'expédition de maintien seraient souvent à la surface semblent être une bonne idée, qui légifère peut-être pour les petites itérations fréquentes (une semaine? deux semaines?)

L'idée wiki pourrait fonctionner: avez-vous regardé le cadre FIT ? Il est une sorte de test d'acceptation intégré / wiki, ce qui pourrait aider à obtenir des tests d'acceptation des clients distants. Je pense que je regarderais aussi de fournir une sorte de (séparé ou intégré) « tableau de bord du projet », peut-être poussé régulièrement à des clients clés, ainsi que sur demande. l'utiliser comme un substitut pour des choses comme des post-its sur les tableaux blancs, les graphiques visibles Big et similaires. Il y a un certain nombre d'open-source ou options à faible coût qui peuvent servir -. Écrire votre propre alternative simple ne doit pas être trop de temps ou onéreux, soit

Rappelez-vous surtout que « Agile » est une sorte de-étiquette fourre-tout pour les développements qui se déroulent en mettant l'accent sur les valeurs et principes énoncés dans la section manifeste Agile . Ce qui est considéré « meilleur » dans une situation ne peut pas être dans un autre. Si vous comprenez les principes et revoir régulièrement vos méthodes avec un œil critique, alors vous allez probablement être assez proche de l'application des meilleures pratiques à votre situation.

Je ne l'ai pas regardé pendant un certain temps, mais avec Beck et Fowler sur la liste des auteurs, il devrait y avoir quelque chose d'utile dans planification extrême programmation .

Answer 10

Dans ma position précédente @ drchrono.com I agrégées demandes de données / rétroaction / itération de 20.000 cliniciens à travers le pays. La meilleure façon de le faire est de évangéliser un site comme uservoice.com. Je tenais « démonstrations web en direct tous les jours » avec parfois 50 à 100 médecins (médecins inscrits à partir de notre site Web). Dans ces démos, je démontrerait notre voix produit actuel et l'utilisateur de conduire évangéliser leurs commentaires dans un outil utile pour notre équipe de développement. Tout cela a été fait à distance et a conduit à une augmentation globale de 1 400% de la croissance des revenus récurrents.