J'ai un problème avec un directeur senior qui ne comprend pas le développement itératif (encore moins Agile). Il insiste pour que nos spécifications de conception logicielle (SDS) soient complètes avant d'écrire une ligne de code. Complet, pour lui, signifie que tous les détails fonctionnels sont là. De plus, étant un ancien programmeur Cobol, il veut voir les "modules" et les organigrammes. Ceci est une application Web Java pour crier à haute voix!

Quoi qu'il en soit, j'essaie de trouver un endroit simple pour le pointer doucement pour montrer que la FDS n'a pas besoin d'être complète à 100% avant de commencer le codage (elle ne peut pas non plus être complète). Aucune suggestion?

Merci!

En tant que consultant, je comprends une règle simple de consultation:

• Vous ne pouvez pas aider les gens qui ne veulent pas être aidés.

Vous ne pouvez pas faire faire à quiconque ce qu'il ne veut pas, sauf par la force de l'autorité, ce que vous n'avez pas.

En tant que coach, je présente Agile avec trois règles:

1. Il est impossible de rassembler toutes les exigences au début du projet.

2. Quelles que soient les exigences que vous ne recueillez sont garantis au changement.

3. Il y aura toujours plus à faire que le temps et l'argent le permettront.

et un objectif:

• Livrez quelque chose de valeur chaque semaine.

C'est tout ce dont vous avez besoin pour commencer.

Convaincre votre manager, c'est autre chose.

Vous ne pouvez pas «faire» comprendre à un gestionnaire l'agilité différemment de ce que vous pouvez faire comprendre à un développeur. Vous devez lui présenter les arguments (les livres de Kent Beck sont un bon début) et le laisser se décider.

Alternativement, vous pouvez lui demander de vous laisser exécuter une expérience. Prenez un petit projet et exécutez-le avec un développement itératif et gardez un œil sur le temps, le budget, les problèmes de qualité et la satisfaction de l'équipe. Comparez-le avec les projets (ou versions) précédents et voyez s'il était meilleur, pire ou neutre.

Vous ne

Tout d'abord, pourquoi un directeur principal est-il même impliqué dans le choix de la méthodologie de développement logiciel? Cette décision est bien en deçà de son salaire, sent la micro-gestion et en dit long sur la méfiance.

Deuxièmement, pourquoi a-t-il besoin de tout comprendre? Si les spécifications du logiciel sont figées, il y aura précisément une itération. Si ce n'est pas le cas, il y aura plusieurs itérations. Ce n'est pas sa décision .

S'il pense que c'est sa décision, il sape l'autorité du responsable informatique, du chef de projet, de l'architecte informatique, des chefs d'équipe et de l'équipe de développement. Il devrait donc écrire lui-même le logiciel @ # $% ing, ou STFU, et laisser les professionnels faire leur travail sans être encombrés par des cerveaux de dinosaures.

Je ne plaisante pas. S'il ne peut pas vous faire confiance pour faire votre travail, il devrait le faire lui-même et vous devriez vous enfuir en hurlant .

"Faire un logiciel, c'est comme faire un film, vous devez planifier à l'avance mais pendant le tournage, vous devez refaire des prises de vue, revoir de vieilles scènes et éditer le produit final afin de garantir un bon résultat"

Là encore, il est manager, donc selon ses mots:

"Nous devons tirer parti de notre flexibilité synergique pour générer une solution de service complet juste à temps"

Le vieil adage s'applique: vous pouvez amener le cheval à l'eau, mais vous ne pouvez pas le faire boire.

Comme d'autres l'ont souligné, ce qui devrait vraiment être important pour ce directeur principal, c'est la valeur commerciale. Vous pouvez essayer de fournir une estimation rapide du temps que vous allez passer à rédiger ses organigrammes et diagrammes de modules et à rédiger une FDS "complète" (concept ridicule, mais donnez-lui ce qu'il veut). Si je sais quelque chose sur ces choses (et quand j'ai commencé à écrire des logiciels, c'était ainsi), votre estimation sera facilement de plusieurs semaines-homme, sinon plus pour un projet de taille. Exprimez ce chiffre en argent.

Montrez-lui ensuite combien de fonctionnalités vous pourriez offrir en même temps. Discutez avec quelques personnes de l'entreprise du temps que cela leur permettrait d'économiser pour avoir une application Web de base faisant les choses que vous pourriez offrir en même temps. Multipliez ensuite cette économie par la fréquence à laquelle ils utilisent cette fonction pendant, disons, 3 ans. Exprimez cela en argent.

Il existe probablement d'autres avantages commerciaux qui peuvent être exprimés en argent. Mon préféré est toujours la prévention du "goofball". Si votre logiciel peut aider à minimiser les catastrophes ou à les éviter complètement, recherchez une catastrophe récente et exprimez-la en termes d'argent. Ensuite, dites à votre patron: si nous avions cela maintenant, nous aurions économisé cet argent.

Et si le truc de l'argent ne fonctionne pas, alors peut-être que vous devriez vous approcher de lui et lui dire d'arrêter la microgestion de son équipe. Bien que, selon mon expérience, cela soit plus susceptible de vous faire virer qu'autre chose.

L'endroit simple pourrait être le Manifeste pour le développement de logiciels Agile .

Les informations que vous trouverez sur ce site concernent les principaux principes du développement logiciel agile définis par un groupe de professionnels bien connus.

C'est

• Individus et interactions sur les processus et les outils
• Logiciel de travail sur une documentation complète
• Collaboration client sur négociation de contrat
• Répondre au changement suite à un plan

Mais s'il vous plaît, regardez la page en détail pour obtenir l'intention complète.

Je suggérerais d'essayer de lui montrer qu'en faisant du "prototypage rapide" (c'est-à-dire en commençant à coder les premières itérations), vous pouvez étoffer votre SDS plus rapidement et avec plus de précision (ce qui signifie moins de retouches plus tard) et commencer à fournir de la valeur commerciale plus tôt. Vraiment, la valeur commerciale la plus probable est tout ce qui compte pour ce directeur et il a décidé que la meilleure façon de l'atteindre est de suivre ce processus séquentiel. Vous devez lui montrer en ses termes pourquoi votre approche est meilleure.

Cela pourrait être utile - http://www.youtube.com/watch?v=4u5N00ApR_k

Dans ce film "Je veux diriger un projet agile", nous suivons les expériences d'un de ces courageux chef de projet, Luke, car il a de nombreuses rencontres différentes dans l'entreprise, travaillant à établir et à livrer son projet Agile.