Devenir Agile

Question

Quelqu'un a-t-il de bonnes techniques ou des exemples sur la façon de promouvoir les avantages des pratiques de développement Agile dans un environnement d'entreprise axé sur la chute des eaux ?

Nous sommes récemment passés au développement basé sur les fonctionnalités, en utilisant la gestion du code des troncs et des branches. Nous avons un projet qui fonctionne bien avec Scrum, mais il est difficile de faire adopter cette approche par le grand public.

Je me demandais juste si quelqu'un d'autre se battait contre la machine des entreprises ?

Answer 1

Bonjour,

Vous aimerez peut-être écouter la conférence de Ken Schwaber sur Scrum sur IT Conversations.

Bien qu'il soit axé sur une "mise en œuvre" particulière d'Agile, il couvre un grand nombre des raisons fondamentales du succès d'Agile.

Vous pouvez consulter le site articles sur l'introduction de la méthode agile à l'Alliance Agile également.

HTH.

Santé,

Rob

Answer 2

Je pense que le meilleur moyen est de commencer à petite échelle et de prouver que l'approche fonctionne réellement.

Comme nous l'avons vu précédemment, Scrum et d'autres techniques agiles peuvent être introduites étape par étape. .

Answer 3

Si vous avez déjà un projet scrum qui fonctionne bien dans votre organisation, 90% de la bataille est faite.

Je vous suggère de prendre le temps de rédiger une étude de cas et de la publier sur votre intranet ou sur un site similaire. Découvrez qui dirige les autres projets que vous considérez comme de bons candidats, et discutez avec eux. Ne vous montrez pas moralisateur - dites simplement "hé, nous avions le problème que vous avez décrit, si vous voulez voir comment nous gérons les projets maintenant, jetez un coup d'œil à ". http://xyz/

L'autre option consiste à demander à un haut responsable de votre organisation de s'en faire le champion. La transition sera beaucoup plus rapide, mais vous devrez trouver un champion approprié et le convaincre des avantages qu'il présente.

Answer 4

Meilleur retour sur investissement en général.

Un processus en cascade devient redondant au moment où vous l'avez terminé, en raison du temps qu'il faut pour le réaliser. Lorsque vous avez terminé, le client a changé sa façon de travailler.

C'est pourquoi le développement itératif et les versions itératives fonctionnent tellement mieux que la cascade. Vous passerez moins de temps à développer des paquets redondants et vous rendrez le client plus heureux en étant mieux à même de répondre à l'évolution de ses besoins.

Le paradigme en général est meilleur. Vous ne faites pas de plans et ne créez pas la perfection. Vous supposez dès le départ qu'il ne sera pas parfait et vous faites "grandir" le logiciel en le rendant flexible et facile à modifier.

Answer 5

Si l'organisation ne reconnaît pas qu'il y a un problème (et beaucoup ne veulent pas le savoir), vous avez une bataille difficile à mener.

Vous pourriez suggérer de réduire la portée des projets (et donc la taille de l'intervalle entre les livraisons) sans changer autrement la méthodologie.

Les phases de la cascade, qui peuvent comprendre l'analyse, la conception, le codage, les tests, la mise en œuvre et la révision, ne sont pas en soi un problème. Mettez-les en correspondance avec un projet dont le champ d'application est limité à une seule fonctionnalité : l'analyse devient la compréhension de l'histoire de l'utilisateur, la conception et le code deviennent une boucle TDD, le test est l'acceptation par l'utilisateur, puis nous mettons le projet en production. Nous n'avons fait qu'une petite unité de travail en quelques jours au lieu du système entier en quelques années.

Ça pourrait marcher.