Programmation par paire et ISO 27001

16

Je travaille dans une équipe de programmation eXtreme et je fais de la programmation par paires depuis plus de 7 ans dans un environnement Windows. Lorsque nous avons commencé à le faire, quelqu'un se connectait avec ses informations d'identification Windows et, par conséquent, tous les accès aux ressources du domaine, et plus précisément le contrôle de version, seraient responsables devant cet utilisateur Windows. Finalement, nous avons évolué pour avoir des comptes d'appairage Windows pour des stations d'appairage spécifiques (par exemple pairA, pairB, PairC etc…). Tous les développeurs connaissent les mots de passe de ces comptes. La responsabilité des validations (check-ins) est obtenue en plaçant les initiales des programmeurs dans le commentaire pendant la validation.

Jusqu'à présent, cela a bien fonctionné pour nous, mais mon entreprise passe actuellement par un audit ISO 27001 et cela a été signalé par l'auditeur comme un risque. J'ai un certain nombre de solutions possibles telles que la création d'un compte d'appariement pour chaque combinaison de paires, mais je voudrais vraiment savoir si quelqu'un d'autre a rencontré ce problème et comment il l'a résolu.

Quelle solution était acceptable par les auditeurs?

pair-programming iso

— Martin Hughes
source

11

Je dirais que la plupart des gens qui utilisent des pratiques de programmation par paire pensent que tout ce que fait ISO, c'est le format de date et les encodages de caractères.

— Lars Viklund

6

Pourquoi avez-vous besoin d'avoir des comptes de pairage? Cela ne fonctionnerait-il pas de conserver des comptes individuels auxquels vous pouvez vous connecter sur n'importe quelle machine?

— Garrett Hall

Vous ne pouvez pas utiliser des comptes individuels, car que se passe-t-il si quelqu'un entre tôt dans le travail / va aux toilettes, etc. et que la machine est connectée en tant qu'autre utilisateur?

— John Sibly

@JohnSably Voulez-vous dire dans le cas de vouloir poursuivre les travaux en cours sur ce compte? Sinon, vous devriez pouvoir ouvrir une autre session sur l'ordinateur en tant que votre propre utilisateur.

— Sinjo

2

@JohnSably, le pilote se déconnecte et laisse le pair se connecter. S'ils vont aux toilettes, verrouillez la machine si vous ne faites pas confiance à vos pairs. Cependant, aucune confiance n'est un problème plus important qui devrait être corrigé.

— CaffGeek

13

Je suppose que les auditeurs préféreraient que les développeurs se connectent en tant qu'eux-mêmes et non en tant que "paire" qui a un mot de passe partagé. Le risque devrait être évident - un développeur ajoute du code malveillant comme "PairA" et met les initiales de quelqu'un d'autre dans le commentaire (ou ne le commente pas du tout). Comment remontez-vous au développeur malveillant?

Je recommanderais à celui qui conduit en premier (dans une session) de se connecter avec son propre identifiant, et la paire continue de mettre ses deux initiales dans les commentaires - de cette façon, le code reste traçable jusqu'à un développeur réel.

— Matthew Flynn
source

+1, c'est ce qui se fait dans mon entreprise. Nous avons le choix entre la révision de code par les pairs ou la programmation par paires. Le cas de programmation par paire n'est qu'un cas spécial de révision par les pairs, où le pair a passé en revue en continu pendant l'écriture du code.

— Daniel Pryden

@ Daniel merci d'avoir partagé votre expérience. Lorsque nous avons commencé l'appairage, c'était le pilote qui se connectait. Cependant, nos sessions d'appariement sont maintenant plus promiscueuses et, bien souvent, une paire s'échangera avant qu'une tâche ne soit complètement terminée. Bien que ce ne soit pas idéal, il est parfois nécessaire d'orchestrer nos échanges car tout le monde doit s'apparier sur le code de production. Cela signifie que le «conducteur» d'origine doit s'éloigner et donc se déconnecter. Nous pouvons faire enregistrer ce code sans eux, mais la perturbation de la paire, qui est potentiellement en train de déboguer l'application, n'est pas trop à prendre à la légère.

— Martin Hughes

7

Je garderais les comptes tels qu'ils sont, généralement une seule personne conduit, et même si l'autre personne utilise la machine (officieusement), la personne connectée devrait toujours être au courant de ce qui se passe sur sa machine.

Les enregistrements auraient néanmoins besoin de commentaires pour montrer qui était la paire.

— CaffGeek
source

Voulez-vous dire conserver les comptes de paire ("conserver les comptes tels qu'ils sont"), ou utiliser des comptes individuels ("la personne connectée")?

— Caleb

@Caleb, individu en tant que personne connectée qui conduit

— CaffGeek

6

Au lieu de créer des comptes séparés afin que le travail ne soit pas verrouillé sur un utilisateur éventuellement absent, utilisez votre système de contrôle de version. Lorsqu'une paire commence à fonctionner, créez une branche de tâche. Validez le code dans la branche des tâches chaque fois que les tests réussissent. Une fois la tâche terminée, fusionnez à nouveau et fermez la branche de tâche.

— Kevin Cline
source

5

Jusqu'à présent, cela a bien fonctionné pour nous, mais mon entreprise passe actuellement par un audit ISO 27001

ISO 27001 ou non, votre système actuel ne fonctionne que parce que vous êtes une petite entreprise où il y a un haut niveau de communication et de confiance mutuelle. Ce genre de chose ne se transforme pas très bien, vous devrez donc probablement envisager d'autres options à un moment donné dans le futur.

La création d'un compte séparé pour chaque paire possible semble encore moins pratique: vous auriez besoin de 90 comptes pour un groupe de 10 développeurs, et chacun de ces 10 développeurs devrait connaître 9 combinaisons de connexion / mot de passe différentes.

La seule solution pratique consiste à utiliser des comptes individuels, comme d'autres l'ont suggéré, et à suivre l'identité de la deuxième personne de la paire d'une autre manière (commentaire dans votre validation de contrôle de version, champ dans le système de suivi des problèmes, etc.).

— Caleb
source

2

Dans l'intéret de Pete, laissez le membre le plus motivé de la paire prendre le crédit / la responsabilité du push / commit. La prochaine fois, l'autre membre conduira. Le "pilote" ne fera rien avec lequel il n'est pas d'accord avec le copilote.

La programmation est un effort collaboratif. Aucun acte de programmation n'est 100% individuel. Il n'est pas nécessaire d'être exigeant pour réfléchir à ce qu'un push / commit donné a été fait par Tom et Harry et pas seulement Tom. Les avantages de la programmation par paires méritent d'être ignorés.

L'auditeur a raison, il faut éviter les comptes "pool".

— Tulains Córdova
source