Comment évitez-vous d'attendre les exigences lors de l'utilisation de méthodes de développement agiles itératives comme SCRUM?


7

Nous essayons de faire du développement agile dans mon travail actuel et nous réussissons pour la plupart. Le principal problème semble être que les développeurs sur le projet attendent toujours les exigences au début du sprint et se précipitent pour obtenir des choses à la fin. Les analystes d'affaires qui répondent aux exigences travaillent toujours sans arrêt pour satisfaire aux exigences.

EDIT: Informations supplémentaires: Nous sommes en train de personnaliser une application commerciale pour notre usage interne. Nos «user stories» se composent de la partie de l'application que nous allons personnaliser dans le sprint spécifique et des systèmes que nous intégrerons en interne. L'intégration avec différents systèmes fonctionne normalement très bien parce que nous pouvons commencer à travailler dessus tout de suite. L'écran 'Personnaliser x' est le principal problème car les développeurs ne peuvent rien y faire. Nous devons attendre d'avoir les exigences des BA avant de pouvoir vraiment faire quoi que ce soit.

EDIT: un aperçu plus concret/confusion peut-être: Je me demande si une partie du problème est que l'écran qui sont personnalisés sont déjà là car cela est un produit COTS qui est fortement personnalisée. Les gens suggèrent que les histoires des utilisateurs devraient être comme «faire un écran qui fait X». C'est déjà fait. Peut-être qu'il n'y a pas un bon moyen de faire des histoires d'utilisateur pour ces exigences ... peut-être que cela doit être une toute nouvelle question.

9

N'attendez pas. Construire un prototype basé sur les exigences minimales que vous avez et obtenir des commentaires dès que possible du propriétaire du produit. Plus souvent qu'autrement, ils ne savent pas ce qu'ils veulent de toute façon - si vous pouvez leur montrer quelque chose de tangible comme point de départ, vous êtes plus susceptible d'obtenir des commentaires utiles. De plus, une fois que vous aurez une meilleure idée des besoins réels, vous aurez probablement déjà acquis beaucoup d'informations sur le développement de votre prototype.


3

À un poste précédent, nous avons géré cela en demandant à nos clients d'être en avance d'une semaine. Bien sûr, cela rompt avec certaines des interprétations strictes de l'agile, mais cela rend les choses tellement plus faciles. Nous ferions des essais et travaillerions une semaine ou deux à partir du développement, alors quand les développeurs travaillaient sur l'itération, les tests 2 travaillaient sur ce qui sortait de IT1 et l'affaire sur IT3. La priorité a toujours été donnée au développement actif, si bien que parfois, il tombait en panne si une histoire était particulièrement flexible (c'est-à-dire que l'entreprise devait passer beaucoup de temps à réviser les choses à mi-parcours).

Mise à jour pour répondre aux questioneers Mettre à jour

Il me semble que ces ne se distingue pas vraiment sur leurs propres histoires alors et peut-être l'équipe de BA a besoin de réévaluer la façon dont ils écrivent des histoires. Je veux dire que vous ne pouvez pas "raconter une histoire" avec personnaliser l'écran X. En théorie, une histoire devrait ressembler à quelque chose comme "Quand l'utilisateur passe à l'écran X, il devrait pouvoir modifier (et enregistrer) le floozit"

  0

Hmmm ... le problème est que l'écran est déjà là ... donc les changements sont dans le sens de 'déplacer ce champ ici' ou 'ce champ doit être calculé comme XXXXXXX au lieu de comment il est maintenant' . Nos documents de besoins que nous obtenons sont essentiellement une grande liste de ceux-ci à changer pour l'écran. 23 sept.. 082008-09-23 20:30:43

  0

Intéressant. Ma première pensée serait alors pourquoi ne pas faire de chacun de ces articles des histoires de très faible complexité. Si ce n'est pas faisable ou simplement une perte de temps, j'irais avec ce que les autres ont dit et je demanderais aux BA de rassembler ces listes plus tôt dans le processus. 23 sept.. 082008-09-23 20:32:34

  0

C'est le problème. Il y a un grand retard dans la négociation des documents d'exigence. Il est abordé à chaque session de révision de sprint. Nous demandons qu'ils soient faits plus tôt, mais ils travaillent sans arrêt. 23 sept.. 082008-09-23 20:41:07

  0

Sur une note de côté ... votre nom semblait familier pour une raison quelconque. Je pense que j'ai déterminé que vous êtes amis avec Ben Lee, avec qui j'ai travaillé pendant un certain temps en 2007. 23 sept.. 082008-09-23 20:47:39

  0

Vous avez 100% raison il est un ancien colocataire de la mienne. 24 sept.. 082008-09-24 01:06:55

  0

haha ​​small world 24 sept.. 082008-09-24 13:37:35


2

Il semblerait que les BAs ne vous transmettent pas vos user stories pour le sprint. manière opportune.

Je suppose qu'il n'y a aucune session de planification de sprint d'après ce que vous dites. Étant donné que l'un des grands principes de Scrum est que l'équipe de développement assume la responsabilité de ce qu'ils vont travailler par sprint, il semble que ce n'est pas trop agile pour moi! (-:

En plus d'avoir des sprints courts c'est-à-dire.

  0

Notre chef d'entreprise et notre scrum master dressent la liste des choses que nous faisons pour le sprint, puis assignent qui les fait. Lors de nos séances de planification, nous fournissons habituellement les estimations, de sorte qu'elles ne sont pas très utiles. Nous avions l'habitude de faire du bénévolat pour les tâches dans la planification du sprint aussi ... plus maintenant que le 23 sept.. 082008-09-23 19:28:45


4

Si je comprends bien votre situation, ce sont les BA qui sont en retard. Il y a deux choses que vous pourriez essayer. Essayez les petits sprints ou les petits morceaux d'exigence. D'une manière ou d'une autre, le travail pour les BA devrait être plus concis et gérable.

  • Prenez une interation pour retravailler ou bug squash. Cela devrait permettre aux BA de prendre de l'avance. Si, cependant, le problème est que les BA doivent voir les exigences précédentes dans le "sauvage" avant de faire plus d'exigences, vous avez des problèmes beaucoup plus importants. :)

  •   0

    Je commence à me demander s'il y a un problème avec nos histoires d'utilisateurs en ce qu'elles sont trop vagues/en avance. 23 sept.. 082008-09-23 19:43:29


    1

    Eh bien, un certain nombre de choses pourraient aider - Dans le processus SCRUM, il y a le concept de Product Owner qui est un rôle de porc, cela représente le client. Vous pouvez donc inviter le PLM ou le contact principal du client à la réunion de votre SCRUM. Cela donnera à votre client une certaine adhésion à votre processus et l'amènera à travailler «avec» vous sur vos objectifs. - Les constructions hebdomadaires au client pourraient aider. Ainsi, l'idée de base des baisses hebdomadaires est de montrer le "progrès" du client. Donc si pendant quelques semaines il n'y a pas de progrès, cela devrait poser la question "pourquoi?" et alors vous devriez être capable d'expliquer que c'est pour le manque de finalisation des exigences.

    Hope this helps


    1

    la "user story" est un espace réservé pour une conversation future, alors soyez devant le client et demandez-leur; si c'est le travail du BA, allumez un feu ;-)


    1

    Vos user stories sont incomplètes. 'Personnaliser l'écran X' est une tâche, il ne décrit aucune exigence ou critère d'achèvement. L'histoire de l'utilisateur devrait ressembler à «Permettre à Nancy de voir les commandes d'achat associées pour un article en inventaire». Puis décomposer cela en tâches pendant votre sprint que vous pouvez travailler. Une fois que les BA ont développé une user story pratique puis ajoutez-la à votre backlog produit, hiérarchisez-la, et planifiez vos sprints pour les articles de backlog supérieurs. Les BA devraient développer des user stories et ajouter à votre backlog indépendamment de vos sprints, et ainsi ne pas vous bloquer. Au cours d'un sprint, les tâches sont terminées et l'historique de l'utilisateur ne change pas. Après la libération du client fournit des commentaires qui va dans le backlog du produit que plus d'histoires d'utilisateurs.


    0

    Je vois quelques façons de gérer cela:

    Option 1, sous SCRUM, vous devriez avoir un propriétaire du produit qui gère votre carnet de produit, qui est censé contenir des demandes de fonctionnalités du logiciel. Si la fonctionnalité consiste en quelque chose de vague comme 'Personnaliser l'écran X' et que vous décidez d'ajouter cela à votre sprint, alors les tâches de sprint doivent être concrètes, décomposées, et je dirais que l'une de ces tâches doit être 'Définir les exigences pour l'écran X'.

    Lors du SCRUM quotidien, lorsque vous posez vos trois questions à chaque membre de l'équipe, le développeur qui a cette tâche de mod d'écran dira "Je suis bloqué en attente des exigences de la BA." fait ce qu'ils peuvent pour que ça avance. À mon avis, l'option 2, à mon avis, est que les articles ne se retrouvent pas dans le carnet de commandes de votre produit tant qu'ils ne sont pas suffisamment bien définis pour effectuer au moins un travail productif. Nous savons tous que les exigences changent, mais le fait est que vous devez en avoir assez pour commencer.


    0

    Facile.

    vous permettre de penser en dehors des règles strictes de Scrum, et revenir à vos racines maigres: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

    Croyez-moi, une fois que vous obtenez que le flux va, vous ne serez jamais regarder en arrière.


    0

    Comme il est dit ci-dessus, habituellement au début de chaque sprint, vous devez prioriser le backlog existant et choisir quelques histoires pour le sprint actuel. S'il n'y a pas assez d'user stories pour les développeurs, vous devez déplacer les développeurs vers un autre projet et laisser le temps au propriétaire du produit de créer un backlog décent (= assez important pour alimenter certaines équipes) pour le projet.