Comment traiter avec des clients et des itérations dans l'équipe Agile? [fermé]

Question

Ce fil est un suivi de mon précédent . Il est en fait 2 questions, donc j'espère que personne ne l'esprit, car ils sont dépendants les uns des autres.

Nous commençons un nouveau projet au travail et nous le considérons comme une excellente occasion d'essayer des techniques Agile en action. Nous avons eu une séance de réflexion sur les idées que nous lisons dans plusieurs livres et articles, et est venu avec le concept qui nous convient le mieux: 2 semaines itération, suivi d'appel avec les clients qui choisiraient ce trucs qu'ils veulent avoir dans la prochaine itération. J'ai juste quelques questions, que nous ne pouvions pas comprendre nous-mêmes.

Que faire dans la première itération?

Que, en général, faire dans les premières itérations si nous commençons à partir de zéro? Il suffit de lui donner un mois de développement à base de code de l'application ou commencer par de simples fils-cadres avec des fonctionnalités pré-codées limitée? Qu'est-ce que les clients veulent généralement voir? Brillant choses qui ne fonctionne pas ou des choses laides qui fonctionne?

Comment communiquer avec les clients?

Notre première pensée pour définir le processus à quelque chose comme ceci:

texte alt http://img690.imageshack.us/img690/2553/communication .png

Est-ce une bonne idée d'avoir un point focal côté client ou est-il préférable de communiquer directement avec tous les clients pour éviter une mauvaise communication?

---

Toutes les pensées sont les bienvenus! Merci à l'avance.

Answer 1

À mon avis, un facteur clé de succès pour le développement agile est de se concentrer sur la fourniture de valeur pour le client à chaque itération. Je serais certainement choisir « choses laides qui fonctionne » sur « des choses brillantes qui ne fonctionne pas ». Faire UIs brillant et essayer d'obtenir le client pour comprendre la logique métier de chapeau prend beaucoup de temps pour mettre en œuvre est toujours risqué qui Joel Spolsky a écrit un bon article sur.

Si le client veut des améliorations à l'interface utilisateur, ils peuvent toujours mettre cela comme une exigence pour la prochaine itération.

En ce qui concerne la communication avec les clients, je pense que votre scetch devrait être légèrement ajustée. Parler en termes Scrum votre « point focal » est appelé « propriétaire du produit ». Avoir une personne en coordination avec les clients est bon, car il peut prendre beaucoup de temps pour les différentes parties prenantes sont d'accord sur les besoins. Toutefois, le propriétaire du produit (ou point focal) doivent être en contact direct avec le promoteur, sans passer par le chef de projet. En fait, le propriétaire du produit et le chef de projet a des rôles bien distincts qui gagnent beaucoup en étant divisé sur deux personnes.

Le propriétaire du produit est la voix des parties prenantes à l'équipe de développement. Le chef de projet d'autre part est responsable du bien-être de l'équipe du projet et garde souvent suivi du budget, etc. Ces rôles parfois opposés a l'ordre du jour, et les ayant divisés sur deux personnes donne une occasion en bonne santé pour la négociation entre des intérêts contradictoires. Si une personne a deux rôles, cette personne ont souvent tendance à favoriser l'un d'eux, ce qui réduit automatiquement l'autre. Vous ne voulez pas travailler dans une équipe où le chef de projet met toujours le client avant les besoins de l'équipe. D'autre part, aucun client veut un propriétaire du produit qui met toujours aux besoins de l'équipe première, neglegting le client. Fractionnement les responsabilités de deux personnes aide à remédier à cette situation.

Answer 2

Je suis d'accord avec la réponse Anders. Mon une observation supplémentaire est que de nombreux clients trouvent qu'il est impossible de ignoire le truand. Ils se font du souci au sujet de la présentation plutôt que la fonction. Par conséquent, vous devrez peut-être mordre la balle et à faire au moins un écran « Nice » pour montrer que vous prêter attention aux détails de la présentation.

Answer 3

  

Que, en général, faire dans les premières itérations si nous commençons à partir de zéro?

De nombreuses équipes utilisent un Iteration Zéro :

• Configuration de l'infrastructure de développement (contrôle de code source, les machines de développement, la construction automatique, un processus d'intégration continue, un environnement de test, etc.),
• instruit le client et d'accord avec lui sur la méthodologie,
• créer une première liste de fonctionnalités, d'identifier les plus importants et faire une estimation initiale,
• définir le temps des réunions (réunion de planification, de démonstration, rétrospective), choisissez la longueur d'itération.

Iteration Zero est très spécial car il ne fournit aucune fonctionnalité au client, mais se concentrer sur ce qui est nécessaire pour exécuter les prochaines itérations de manière agile. Mais les itérations suivantes devraient commencer à offrir de la valeur au client.

  

Il suffit de lui donner un mois de développement à base de code de l'application ou commencer par de simples fils cadres avec fonctionnalité code pré-limitée?

Non, ne développent pas le cœur de votre application pendant un mois. Au lieu de cela, commencer à livrer une tranche verticale de l'application (de l'interface utilisateur à la base de données) immédiatement, des tranches non horizontales. Cela ne signifie pas qu'un écran doit être complète (par exemple mettre en œuvre un seul champ de recherche dans un écran de recherche), mais il devrait idéalement être représentatif de l'aspect final et la sensation (à moins que vous d'accord avec le client sur une étape intermédiaire). La partie importante est aux choses de construction qui offrent une valeur immédiate au client incrémentale .

  

Qu'est-ce que les clients veulent habituellement voir? Brillant choses qui ne fonctionne pas ou des choses laides qui fonctionne?

Pour mon expérience, ils veulent voir progrès démontrables et que vous voulez obtenir des commentaires le plus rapidement possible.

  

Est-ce une bonne idée d'avoir un point focal côté client ou est-il préférable de communiquer directement avec tous les clients pour éviter une mauvaise communication?

Vous avez besoin un personne pour représenter les clients (qui est appelé Product Owner Scrum):

• il fournit une seule voix faisant autorité
• il a une parfaite connaissance de l'entreprise (à savoir qu'il peut répondre à des questions)
• il sait comment maximiser le retour sur investissement (à savoir comment donner la priorité fonctionnalités)

Answer 4

Agile veut généralement fournir au client quelque chose de précieux, rapidement.

Alors je serais certainement pas passer « mois de développement à base de code de l'application ». Pour moi, que les odeurs de la « grande conception avant up » anti-modèle. Aussi, voir YAGNI .

Obtenir que beaucoup d'informations des clients sur ce dont ils ont besoin plus brefs, et mettre en œuvre que dans votre première itération. « Précieux » est dans l'œil du client. Thet savent s'ils veulent voir l'interface utilisateur slick (peut-être qu'ils veulent donner un diaporama sur le produit à un salon, si la fonctionnalité peut être faux) ou des fonctionnalités de travail simples (peut-être que vous développez quelque chose dont ils ont besoin pour commencer < em> avec le plus tôt possible). Business Value est ce que ils disent les aider à faire leur travail.

Je fait mes itérations aussi court que je peux (vos 2 semaines pourrait travailler, je vous suggère de considérer 1 semaine) Si vous ne pouvez absolument pas votre équipe de développement et vos clients colocalisé, au lieu d'avoir un appel avec les clients, je vous propose une réunion. Demo ce que vous avez fait sur l'itération précédente et les commentaires Solliciter sur ce qui devrait rester, ce qui devrait changer, et ce qui doit être ajouté.

Comme d'autres l'ont dit, vos sons « point focal » comme un produit propriétaire. Ce qui me préoccupe au sujet de votre dessin est si elle est censée impliquer que les devs ne interagissent pas avec le bon de commande ou les clients. Une chose qui rend le travail Agile est quand il y a beaucoup de communication. Ayant communication / de l'équipe de dev toujours filtré par le gestionnaire de projet est presque certainement lié à entraîner un manque de communication, travail inutile, et les détails manqués.

Answer 5

Je suis d'accord avec les deux réponses, mais je voudrais juste ajouter une chose de son expérience personnelle. Vos clients ont acheté pour le changement vers itérations rapides? En plus de fournir des commentaires après chaque itération qui va demander au client d'effectuer des tests d'utilisation de chaque fonction.

Maintenant, je ne sais pas ce que votre relation avec votre groupe est client, mais ce ne est pas rare que les clients de prendre une « demande Put in - se système de travail sur » l'attitude en ce sens qu'ils sont enthousiastes en donnant des exigences, mais pas avec forthoming moment où il vient de tester la fonctionnalité.

Maintenant, cela peut être tout à fait inapproprié à votre situation, mais est toujours utile d'examiner la façon dont votre flux de travail client devra changer ainsi que vos groupes.

Vive