2010-01-25 2 views
1

Lorsqu'un grand système développé par le processus Agile nécessite un changement brutal à grande échelle qui affecte la plupart des choses, quelle est la meilleure façon d'y parvenir en utilisant Agile? La partie itérative change-t-elle à ce stade? Par exemple, que se passe-t-il si une décision est prise pour faire d'un système centralisé un système distribué? Ou choisissez un autre grand exemple omniprésent.Comment les pratiques de développement Agile sont-elles affectées par un changement généralisé du système?

De grands changements auraient dû être planifiés, mais ce n'est jamais un monde parfait qui est l'une des raisons pour lesquelles Agile existe, alors supposons qu'un changement majeur est soudainement introduit qui ébranle la fondation.

Modifier pour récapituler solutions:

  • Il est incrémentiel toute la façon, peu importe comment grand ou petit le changement peut être.
+0

Il est quasiment impossible de répondre à des hypothèses comme celles-ci. Il y a trop de choses que nous pouvons supposer que vous pouvez ensuite rejeter comme ne faisant pas partie de * vos * hypothèses. "choisissez un autre exemple important" nous permet de définir tout ce que nous voulons comme "large" et "omniprésente" et aucune de nos définitions ne pourrait correspondre à la vôtre. Focus et spécificités aident. –

+0

Malheureusement, je me concentre sur le processus Agile en général et comment il est utilisé, et il y a toujours des réponses générales à avoir même si la réponse doit fournir son propre contexte. Je n'ai pas d'exemple précis en ce moment, mais j'apprécie le point de vue pour quand je le fais. –

+0

C'est la création incrémentielle du logiciel.Mais parfois ce ne sont pas des changements incrémentaux du logiciel original sa création incrémentale d'une nouvelle architecture où vous puis branchez ce que vous pouvez de l'ancien système –

Répondre

3

"La partie itérative change-t-elle à ce stade?"

Jamais.

Peu importe à quel point le changement semble être «omniprésent», vous devez tout de même travailler par incréments, dans les itérations que vous pouvez gérer.

Vous devez toujours prioriser les modifications et les rendre d'une manière qui continuera à passer des tests unitaires et qui puisse être libérée si nécessaire.

Vous pouvez, par exemple, constater que la fixation de 80% du système est suffisante, et vous pouvez libérer. Ou peut être nécessaire de réparer 100% du système avant de le relâcher.

Vous continuez à travailler de manière incrémentielle. Dans les sprints. Indépendamment de quand vous relâchez.

+0

+1 Tous les changements à grande échelle sont simplement une série de changements à petite échelle dans le déguisement. En outre, le changement le plus important n'est-il pas le moment où vous avez créé votre projet à partir d'un fichier texte vide? – slebetman

+0

Le * point * d'Agile est de s'adapter au changement. Si vous jetez Agile dès que vous devez vous adapter au changement, vous faites quelque chose de terriblement mal. (OTOH, n'oublions pas qu'adapter le processus de développement * lui-même * pour changer * est * être Agile.) –

+0

kindda. partir d'une voiture et se transformer en avion va vous donner une tout autre chose à partir de 0 et de morphing à un avion. Lorsque l'architecture est assez différente de l'original, vous devez examiner attentivement comment vous voulez changer. –

1

L'agilité n'a pas de réponses magiques.

Il y a un certain nombre d'approches: -

Tracer une voie de changements raisonnablement supplémentaires pour changer le système d'un archtecture à l'autre. Si vous avez raisonnablement bien factorisé du code, vous devriez abandonner le code qui est rendu redondant par le changement et garder des choses indépendantes du changement.

Une autre approche si les choses sont vraiment différentes, commencer un développement parallèle des composants pour le nouveau système. Ou, commencez de nouvelles et volez autant que possible de l'ancien projet.

Cela dépend de la taille du changement.

Questions connexes