Comment faire une revue de code efficace pendant la fièvre de sortie?

La date limite de sortie est demain, votre collègue a finalement terminé sa tâche cruciale pour cette version, le chef de projet se tient au-dessus de votre épaule et vous presse pour enfin faire une construction et vous remarquez une faille dans le code de votre collègue lors de la révision. Pas critique, mais quelque chose que vous ne lâcheriez pas sans la sortie de demain. Et pour aggraver les choses, vous avez votre propre travail dont vous avez besoin pour terminer le plus tôt possible. Donc que fais-tu? Souhaitez-vous soulever votre objection malgré la pression ou laissez-vous simplement celui-ci glisser?

J'ai trouvé une façon de fusionner temporairement ce commit sur une branche différente et de laisser la révision pour plus tard. Cela fonctionne si le problème n'est que cosmétique et s'il est le seul à attendre la révision du code. Cependant, existe-t-il un moyen plus efficace de gérer cela? Par exemple, recommanderiez-vous d'engager une seule personne à ne réviser et tester que le code?

La réponse ici est de communiquer.

1. Informer le responsable technique / de l'équipe du problème
2. Parlez à QA de l'impact potentiel
3. Dites à la direction du projet (qui est juste derrière vous) qu'il peut y avoir un problème qui retarde la publication, et vous reviendrez avec eux dès que possible (en quelques minutes ou heures)
4. Évaluer si ce problème est un bouchon de show pour la version

Si le problème n'est pas un arrêt de spectacle, poursuivez la publication. Informez QA et vos utilisateurs du problème et engagez-vous à une date de suivi où le problème sera corrigé. Cela devient simplement un autre risque pour la production.

S'il s'agit d' un arrêt de spectacle (ce qui signifie qu'il aura un impact négatif sur le résultat net ou la santé de quelqu'un), communiquez-lui en amont que votre recommandation est de retarder la publication et dites pourquoi. Revenez ensuite avec le développeur et déterminez combien de temps il faudra pour résoudre le problème, et dites à la direction que vous avez besoin de X nombre de minutes / heures / jours.

Il y a de fortes chances que la direction ne soit pas satisfaite d'un arrêt de spectacle si tard dans le jeu, mais ne voudra pas que cela soit mis en production.

Communiquez et laissez la direction passer l'appel.

Ne vous contentez pas de communiquer le problème, documentez-le

Ma grande préoccupation concernant les autres réponses jusqu'à présent: tout ce que vous direz dans ce sens au chef de projet typique confronté à une échéance imminente sera probablement ignoré ou oublié. Ensuite, vous pouvez toujours être accroché pour ne pas communiquer suffisamment le risque, en cas de problème.

Informez le chef de projet du problème que vous avez trouvé et faites-lui savoir que vous le documenterez . Vous devez pouvoir indiquer votre diligence raisonnable.

Où documenter et qui dire dépend de votre environnement de travail, mais indiquez certainement votre patron.

Identifier le risque et l' impact

Vous mentionnez que le problème n'est pas critique, mais ne définissez pas vraiment ce que cela signifie. La réalisation de cela est votre prochaine étape.

Faites une analyse rapide des risques et des impacts en identifiant le problème, sa probabilité de causer un problème (risque) et la gravité des conséquences si le risque se concrétise (impact). Utilisez des termes bien définis (que votre chef de projet devrait connaître) comme ceux qui se trouvent dans le lien ci-dessus, mais fournissez également une description pour étayer votre analyse.

Votre documentation doit également inclure votre plan d'action recommandé. Oui , il est normal de soulever une préoccupation et de recommander de poursuivre la publication. Il est correct d' identifier le risque .

Quelle est votre prochaine version?

Si, après avoir terminé votre analyse de risque / impact, vous ne savez toujours pas quoi recommander, tenez compte de votre calendrier de publication. Un code imparfait peut être libéré si vous pouvez vous attendre à inclure le correctif dans deux semaines.

S'il y a une chance que la résolution de votre problème soit «priorisée» (c'est-à-dire négligée en faveur de la prochaine amélioration brillante), c'est une raison de plus pour documenter le problème dès que possible après l'avoir découvert: si effectivement «commence» l’horloge ”sur la question.

Dans ce cas, informez tout le monde et laissez-les décider. Ce n'est probablement pas le premier bug que vous avez publié.

La date limite est demain, mais vous vous retrouvez dans cette situation:

le chef de projet se tient au-dessus de votre épaule et vous presse pour enfin faire une construction

Cela peut être l'exception, alors n'apportez pas de modifications drastiques à votre processus simplement parce qu'un bogue est passé. Ce que vous devez faire est de mettre en place des mesures afin de ne pas créer de builds à la dernière minute. Avec un peu de chance, vous créez des builds à une fréquence suffisamment régulière pour vous donner l'assurance que cela réussira. Ce n'est toujours pas une raison suffisante pour les exécuter à la dernière minute. Avoir des choses bien testées est un autre élément pour accroître la confiance.

Présentez ce scénario à celui qui dirige ce truc.

• Déterminez quels types de problèmes doivent être présentés.
• Identifiez les options.
• Qui prend la décision
• Quand tout cela devrait-il être décidé? Ça va probablement être relatif à la date de sortie.

Bien que cela ne réponde pas à ce qu'il faut faire avec ce problème de dernière minute, il offre un moyen de vous assurer que vous pourrez y faire face à l'avenir. Surtout quand il y a une pression pour se libérer, vous voulez avoir un moyen de gérer les choses d'une manière réfléchie et non motivée par les émotions.

S'il y a une date limite et que votre manager est juste derrière vous en regardant par-dessus votre épaule, vous lui dites de partir. Il s'en va ou tu t'en vas. Expliquez-lui qu'étant obligé de réviser sous pression, vous pourriez tout aussi bien ne pas revoir le code.

Dans une situation comme celle-ci, vous pouvez être certain qu'un bogue critique passera.

Vous pourriez être dans une situation chanceuse, comme soumettre à l'App Store d'Apple, où vous avez quelques jours pour retirer une nouvelle version. Mais si votre code est expédié aux clients, c'est une recette pour un désastre. La prochaine fois j'espère que votre manager planifie mieux.

D'autres réponses se concentrent sur le problème de votre manager essayant de plier votre processus qualité.

Cependant, ce que je pense que vous demandez, c'est comment gérer le fait que la révision du code nécessite au moins 2 personnes et entraîne donc des retards importants. Par exemple, si une tâche prend 2h à mettre en œuvre et 2h à réviser, il y a souvent une longue pause entre les deux activités. En temps réel, la tâche peut prendre 2 à 3 jours.

Il s'agit d'un problème classique de débit vs latence. Dans les machines produisant des logiciels (êtres humains), les changements de contexte sont chers, donc empêcher le travail de quelqu'un de faire immédiatement une revue ne devrait pas être une pratique courante.

Voici quelques conseils pour atténuer le problème:

• Pendant que vous travaillez sur une tâche, envoyez le code en petites parties, afin que le réviseur n'ait pas à réserver de longs morceaux de temps continus.
• Promouvoir une culture de haute priorité pour les revues de code. N'arrêtez pas votre unité de travail actuelle lorsque vous recevez une demande, mais lorsque vous vous demandez quoi faire ensuite, choisissez toujours un avis dans votre file d'attente.
• Profitez de la différence de fuseau horaire dans vos équipes, le cas échéant.
• N'engagez pas une seule personne à réviser uniquement le code. C'est contre-productif. Il ne pourra pas gérer la charge s'il veut être sérieux dans sa tâche. Votre manager n'acceptera pas l'idée que quelqu'un soit inactif, juste pour potentiellement économiser un jour.