Que dois-je faire lorsque mon chef d'équipe rompt mon schéma de base de données avec une version à venir?

Mon chef d'équipe a cette terrible habitude de contourner le schéma de la base de données et d'apporter des modifications qui entraîneraient de graves ruptures sur la base de code (sans vraiment me consulter sur la façon dont les modifications affecteraient la base de code).

Normalement, je voudrais simplement vivre avec, mais nous avons un délai de 2 semaines et cela se produit depuis que j'ai commencé il y a 1 mois et demi. J'ai été amené, pour accélérer le développement du projet.

En raison de la date limite, je consacre déjà plus de 60 heures par semaine et je n'ai pas vraiment d'énergie pour faire face à cela (j'ai déjà essayé à certains égards). Nous ne sommes qu'une équipe de 2 personnes, et en plus de changer la base de données quotidiennement, il n'a pas beaucoup contribué au développement réel (codage).

Actuellement, j'ai l'impression de faire tout le travail, en plus de devoir «réparer» ce qu'il rompt avec ses changements.

Comment gérer cela? J'ai déjà parlé à notre manager de son manque d'effort au sein du service développement. Il est là depuis 6 mois de plus que moi, mais j'ai écrit 95% du code lorsque vous excluez la 5e monstruosité de la base de données de forme normale qu'il a `` contribué ''.

Aucune suggestion?

Autopsie:

Vendredi, nous avons eu une discussion avec le directeur et j'ai fait part de mes inquiétudes. Cela a conduit à un peu de confrontation, mais dans l'ensemble, je sentais que le directeur était du côté de moi. Donc, au moins, nous avons notre gel de données en place maintenant, voyons comment cela se passe à partir d'ici.

"La date limite est dans deux semaines; nous devons geler le schéma si nous voulons l'atteindre."

Parler au gestionnaire ET au développeur lors de la même réunion:

"Les modifications de la base de données et du code doivent apparaître simultanément. Si vous modifiez la base de données, vous devez également modifier et tester la base de code. Sinon, vous soumettez des validations rompues, ce qui est inacceptable si nous devons respecter le délai. Je ne corrigerai plus le code brisé par vos commits, je vais simplement annuler les modifications et vous laisser un e-mail car je ne peux pas enquêter et résoudre les problèmes en dehors du travail qui m'a été assigné et je m'attends toujours à respecter le délai. "

Beaucoup plus difficile si vous n'avez pas de plan de test ...

Vous devrez être plus énergique et vous assurer que bientôt (comme hier, avant-hier ou le mois dernier) vous vous installez sur un schéma et que vous allez de l'avant. Il n'y a aucun moyen raisonnable de continuer à développer une application avec une base de données qui est une cible mobile.

Vous devez le confronter et lui expliquer comment ses modifications affectent la base de code et donc les délais du projet. Convainquez-le qu'il doit tenir compte de l'impact de ses changements avant de les effectuer. Faites-lui également accepter en présence de votre manager le fait qu'il sera responsable des retards qu'il induit par ce comportement

Si le chef d'équipe n'est pas une personne raisonnable (et qu'il / elle ne semble pas raisonnable d'après votre description de son comportement), parlez à votre manager et expliquez-lui que vous ne respecterez pas la date limite avec la façon dont les choses se passent. Demandez-lui de prendre position et assurez-vous que votre chef d'équipe en est conscient en organisant une réunion où le gestionnaire définit les attentes.

Vous devriez également pousser votre cas concernant le manque de contribution de votre chef d'équipe au développement. Les deux problèmes doivent être résolus pour faire du projet un succès.

Vous devrez imposer une certaine retenue à votre équipe, mais cela peut être difficile à jouer à votre place.

Un moyen utile de résoudre ce problème pourrait être d'adopter un contrôle des changements documenté plus rigoureux. Vous pouvez jouer cela en insistant sur le fait que, pour le moment, des changements ad hoc mettent en danger votre capacité à gérer les mises à jour du système d'une manière qui n'a pas de conséquences imprévues et menaçantes pour les délais (ce qui est vrai). Insistez donc pour que toutes les modifications soient accompagnées d'une documentation montrant la modification proposée et ses effets sur tous les autres codes et structures. Vous serez étonné de voir à quel point cela réduira le volume des changements qui se produisent :-)

Avez-vous tenu une rétrospective avec l'équipe? Sinon, tenez-en un. Lorsque vous le faites, identifiez les modifications non planifiées (nettoyage avec) dans la base de données comme un problème. Précisez le coût pour vous et les autres concernant le risque et la qualité de vie au travail. Le travail continu de 60 heures par semaine n'est pas durable. Si vous n'êtes pas en mesure de maintenir votre rythme de développement, vous n'êtes pas agile.

De plus, faites-vous du TDD (développement piloté par les tests) ou un test fonctionnel / de régression automatisé? Si tel est le cas, les modifications apportées à la base de données devraient entraîner des tests interrompus. Cela devrait aider à gérer l'impact et à identifier le code qui doit être mis à jour.

Dans ce cas, votre chef d'équipe n'est pas « trop agile », votre chef d'équipe est un « cowboy agile ». Organisez une rétrospective, identifiez ce qui a mal tourné. Donnez-lui une priorité élevée, puis abordez-la lors de la prochaine itération. Cela devrait corder dans votre cow-boy agile !!!

N'y avait-il pas un même problème avec vous il y a environ un an? « Mon chef d'équipe dit A.Property = A.Property; c'est bien '. On dirait que la qustion a été interdite car je ne la vois pas dans l'historique de mes commentaires. Quoi qu'il en soit, le point est:

Si vous sentez que tous vos chefs d'équipe vous gâchent avec à peine la moitié de votre expérience, vous trouveriez probablement un emploi sans un . Je suggérerais de faire un essai et de devenir chef de file comme autre option, si vous en étiez capable, on vous avait déjà proposé de le faire.