Comment éduquer un responsable du développement sur les difficultés de la conception de logiciels?

Question

J'ai eu quelques gestionnaires de développement qui ne semblent pas comprendre ou apprécier les difficultés de conception et d'implémentation de logiciels. Ces gestionnaires croient que les processus et les méthodologies résolvent complètement le problème et j'ai du mal à leur expliquer que ce n'est pas le cas et que vous ne pouvez pas lire un livre sur la dernière mode et espérer obtenir des résultats en les appliquant comme est.

La dernière frustration que j'ai est de convaincre mon manager à (a) Donnez-moi des exigences pas à la pièce mais un plus grand ensemble autant que possible. (b) Donner à mon équipe le temps de réfléchir à la façon de concevoir, de débusquer quelques alternatives, de mettre au point une esquisse d'implémentation, de planifier les tâches, etc

Les frustrations sont aggravées par la méthodologie Agile et l'interprétation de cela qui dit de ne pas faire la conception initiale (par rapport à BIG design à l'avant dans Waterfall), le propriétaire du produit peut changer les exigences à tout moment et ainsi de fils.

Jusqu'à présent, je n'ai pas eu beaucoup de succès et je dois supporter les frustrations qui en résultent. Pouvez-vous me donner des arguments qui peuvent convaincre ces gestionnaires?

EDIT-1: Rétrospectives sont faites, mais pas toujours à la fin de chaque sprint, et les problèmes sont élevés. Mais comme je l'ai mentionné, mon directeur n'apprécie pas le besoin de délais de conception et les frustrations liées aux exigences de repas à la pièce.

EDIT-2 Je n'ai aucun problème avec l'évolution des besoins. Je comprends que ce sera le cas, mais imaginez ceci: vous voulez une petite fonctionnalité pour commencer et ensuite vous continuez à en ajouter plus autour. Après quelques itérations, le design ne peut plus le gérer et une refonte (pas de refactoring) est nécessaire. En premier lieu, cela aurait pu être mieux résolu avec une conception initiale si les caractéristiques connexes avaient été étudiées ensemble. Ce n'est pas le BDUF, c'est la façon naturelle de le faire (ce que j'appelle le sens commun du génie logiciel). Mon manager ne comprend pas pourquoi je demande du temps pour le remodeler (quelques fois je l'appelle simplement refactoring pour qu'il corresponde à la manière agile de le faire, mais c'est vraiment une refonte) et ne développe pas et ne présente pas de nouvelles fonctionnalités .

Answer 1

Agile Simple Design ne signifie pas ne faire AUCUN design/architecture à l'avant. Cela signifie faire la conception minimale à l'avant, de sorte que vous ne paierez pas un prix horrible pour les demandes de changement raisonnables.

parle Scott Ambler au sujet du changement Affaires - http://www.agilemodeling.com/artifacts/changeCase.htm parle James Coplien sur Agile Architecture - http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/

La dans tout l'art/métier c'est dans la façon de couper l'architecture d'une manière qui permet:

• convergence relativement rapide sur l'architecture globale/infrastructure - de l'ordre de jours par mois de temps de développement estimé. Développer «juste assez» d'architecture/infrastructure pour chaque caractéristique/exigence
• faire le bon équilibre des préparations pour l'avenir par rapport à se concentrer sur les fonctionnalités d'aujourd'hui.

Il est important que votre Product Owner soit conscient de tout cet équilibrage et que vous travailliez en collaboration. Il devrait comprendre que si vous négligez toute pensée pour l'avenir, chaque changement sera très coûteux. Il y a un prix à payer pour la flexibilité.

Son btw est très similaire à l'investissement dans l'assurance qualité et l'automatisation des tests. Vous payez quelque chose maintenant, qui ne payera qu'après X fois que vous testez le code. Si le code ne change jamais, c'était une perte d'effort. Tout le monde sait que la plupart des changements de code ...

Answer 2

Chaque temps requis sont modifiés (ou augmenté) devraient donc

• l'estimation à remplir et,
• l'évaluation du risque

Commencer à donner des estimations mises à jour (même si vous devez devinez) et des listes de risques chaque fois que vous obtenez une mise à jour ou une nouvelle exigence. Cela aidera votre gestionnaire à établir la connexion. Essayez de le faire dans un esprit de serviabilité - «à des fins de planification» - de sorte que vous ne soyez pas perçu comme obstructif ou dépourvu d '«attitude volontaire». Rappelez-vous que les estimations peuvent (en théorie) baisser, et les risques peuvent être réduits.

Answer 3

Achetez votre manager this book. C'est ce que j'ai fait, et cela a bien fonctionné :)

Answer 4

Les exigences de l'entreprise vont changer, peu importe où vous travaillez. Ce n'est pas ta faute, ce n'est pas la faute de ton patron, ce n'est la faute de personne.Le point entier de prendre les exigences sur fragmentaire est de vous encourager à réfléchir sur le problème en question, pas un autre problème que vous pourriez ou ne pas avoir besoin de résoudre. C'est assez libérateur une fois que vous entrez dans le rythme. Pensez à la conception initiale comme une optimisation prématurée. Vous n'en aurez peut-être pas besoin, et même si vous savez que vous en avez besoin, vous en saurez plus sur votre conception dans deux semaines que vous ne le savez aujourd'hui. Cela vous aidera à résoudre votre problème d'ingénierie avec les meilleures connaissances possibles sur l'état de votre code.

Cela étant dit, edg a absolument raison. Lorsque vous ajoutez d'autres exigences, l'estimation change. Ce n'est pas la faute des développeurs ou de quelqu'un d'autre; plus de travail signifie plus de travail, peu importe comment vous le placez. Si votre patron ne réalise pas que l'ajout d'exigences entraînera une estimation plus importante du projet, vous devez lui expliquer que Agile n'est pas une formule magique qui vous permet d'ajouter plus de fonctionnalités sans rien payer pour eux.

Answer 5

Tout d'abord ce problème semble assez sensible, donc tout ce que j'ai écrit ci-dessous est juste mon opinion personnelle, et pas nécessairement une chose sage à faire. A mon avis, vous ne pouvez pas faire de logiciel si vous ne savez pas quel problème il devrait résoudre. Si les exigences viennent en petites parties qui sont trop petites pour superviser le problème, alors je voudrais juste poser des questions sur les parties qui semblent manquer. Comme: "ok donc le logiciel devrait faire X, mais cela signifie-t-il aussi Y ou sinon Z peut-être parce que si c'est Y alors ... mais si c'est Z alors ..." Bien sûr si le manager est au milieu d'extraire les exigences, il ne peut pas répondre, mais au moins, il sait qu'il existe encore des questions ouvertes qui influent sur le développement. Pas de délai pour la conception: la conception et le développement sont un processus itératif qui pourrait aller de pair. C'est juste comment vous nommez la chose. Si le responsable veut voir du code à la fin de la journée, alors j'utiliserais simplement la première moitié de la journée pour concevoir et la deuxième moitié de la journée pour faire du code basé sur ce design.Si le gestionnaire ne veut pas voir le design, d'accord avec moi, je vais juste montrer le code.