Paarprogrammierung und ISO 27001

16

Ich arbeite seit über 7 Jahren in einem eXtreme-Programmierteam und programmiere Paare in einer Windows-Umgebung. Als wir damit begannen, meldete sich jemand mit seinen Windows-Anmeldeinformationen an, und daher war der gesamte Zugriff auf Domänenressourcen und insbesondere die Versionskontrolle für diesen Windows-Benutzer verantwortlich. Schließlich haben wir Windows-Pairing-Konten für bestimmte Pairing-Stationen (z. B. PairA, PairB, PairC usw.) eingerichtet. Alle Entwickler kennen die Passwörter für diese Konten. Die Verantwortung für Commits (Einchecken) wird erreicht, indem die Initialen des Programmierers während des Commits in den Kommentar eingefügt werden.

Bisher hat dies für uns gut funktioniert, aber mein Unternehmen durchläuft derzeit ein ISO 27001-Audit, das vom Prüfer als Risiko eingestuft wurde. Ich habe eine Reihe möglicher Lösungen, z. B. das Erstellen eines Pairing-Kontos für jede Pairing-Kombination, aber ich möchte wirklich wissen, ob jemand anderes auf dieses Problem gestoßen ist und wie er es gelöst hat.

Welche Lösung wurde von den Abschlussprüfern akzeptiert?

pair-programming iso

— Martin Hughes
quelle

11

Ich gehe davon aus, dass die meisten Leute, die Pair-Programming-Praktiken anwenden, der Meinung sind, dass ISO nur das Datumsformat und die Zeichencodierungen verwendet.

— Lars Viklund

6

Warum müssen Sie Konten koppeln? Würde es nicht funktionieren, einzelne Konten zu führen, bei denen Sie sich auf einem beliebigen Computer anmelden können?

— Garrett Hall

Sie können keine einzelnen Konten verwenden, da was passiert, wenn jemand früher zur Arbeit kommt / auf die Toilette geht usw. und der Computer als der andere Benutzer angemeldet ist?

— John Sibly

@JohnSibly Meinst du, wenn du in diesem Zusammenhang weiterarbeiten möchtest? Andernfalls sollten Sie in der Lage sein, eine andere Sitzung auf dem Computer als Ihren eigenen Benutzer zu öffnen.

— Sinjo

2

@ JohnSibly, dann meldet sich der Treiber ab und lässt den Peer anmelden. Wenn sie in den Waschraum gehen, sperren Sie den Computer, wenn Sie Ihren Kollegen nicht vertrauen. Kein Vertrauen ist jedoch ein größeres Problem, das behoben werden sollte.

— CaffGeek

13

Ich würde annehmen, dass die Prüfer es vorziehen würden, dass sich Entwickler als sie selbst anmelden und nicht als ein "Paar", das ein gemeinsames Passwort hat. Das Risiko sollte offensichtlich sein - ein Entwickler fügt einen bösartigen Code als "PairA" hinzu und fügt die Initialen eines anderen in den Kommentar ein (oder kommentiert ihn überhaupt nicht). Wie gehen Sie auf den böswilligen Entwickler zurück?

Ich würde empfehlen, dass sich jeder, der als Erster fährt (in einer Sitzung), mit seiner eigenen ID anmeldet und das Paar weiterhin beide Initialen in die Kommentare einfügt. Auf diese Weise bleibt der Code für einen tatsächlichen Entwickler nachvollziehbar.

— Matthew Flynn
quelle

+1, das ist was in meiner Firma gemacht wird. Wir haben die Wahl zwischen Peer Code Review oder Pair Programming. Der Pair-Programming-Fall ist nur ein Sonderfall der Peer-Überprüfung, bei der der Peer kontinuierlich überprüft wurde, während der Code geschrieben wurde.

— Daniel Pryden

@ Daniel danke für das Teilen Ihrer Erfahrung. Als wir mit dem Pairing begannen, war es der Fahrer, der sich anmelden würde. Unsere Pairing-Sessions sind jetzt jedoch promiskuitiver und oft wird ein Pairing getauscht, bevor eine Aufgabe vollständig erledigt ist. Auch wenn dies nicht ideal ist, ist es manchmal erforderlich, unsere Swaps zu orchestrieren, da jeder den Produktionscode koppeln muss. Dies bedeutet, dass der ursprüngliche 'Fahrer' weggehen und sich ausloggen muss. Wir können diesen Code ohne sie einchecken lassen, aber die Störung für das Paar, das möglicherweise gerade die App debuggt, ist nicht allzu leichtfertig.

— Martin Hughes

7

Ich würde die Konten so lassen, wie sie sind, normalerweise fährt nur eine Person, und selbst wenn die andere Person die Maschine (inoffiziell) benutzt, sollte die angemeldete Person immer noch wissen, was auf ihrer Maschine passiert.

Checkins würden dennoch Kommentare benötigen, um zu zeigen, wer das Paar ist.

— CaffGeek
quelle

Meinen Sie, Sie behalten die beiden Konten bei ("Behalten Sie die Konten bei, wie sie sind"), oder Sie verwenden einzelne Konten ("die Person, die angemeldet ist")?

— Caleb

@Caleb, Person als die Person angemeldet, die das Fahren macht

— CaffGeek

6

Verwenden Sie Ihr Versionskontrollsystem, anstatt separate Konten zu erstellen, damit die Arbeit nicht an einen möglicherweise abwesenden Benutzer gebunden ist. Wenn ein Paar zu arbeiten beginnt, erstellen Sie einen Task-Zweig. Übergeben Sie den Code nach jedem Bestehen der Tests an den Taskzweig. Wenn die Aufgabe abgeschlossen ist, führen Sie sie zurück und schließen Sie den Aufgabenzweig.

— Kevin Cline
quelle

5

Bisher hat dies für uns gut funktioniert, aber mein Unternehmen durchläuft derzeit ein ISO 27001-Audit

ISO 27001 oder nicht, Ihr derzeitiges System funktioniert nur, weil Sie ein kleines Unternehmen sind, in dem ein hohes Maß an Kommunikation und gegenseitigem Vertrauen herrscht. Solche Dinge lassen sich nicht sehr gut skalieren, sodass Sie wahrscheinlich ohnehin irgendwann in der Zukunft über andere Optionen nachdenken müssen.

Das Erstellen eines separaten Kontos für jedes mögliche Paar ist noch weniger praktisch: Sie benötigen 90 Konten für eine Gruppe von 10 Entwicklern, und jeder dieser 10 Entwickler müsste 9 verschiedene Anmelde- / Kennwortkombinationen kennen.

Die einzige praktikable Lösung besteht darin, einzelne Konten zu verwenden, wie andere vorgeschlagen haben, und die Identität der zweiten Person in dem Paar auf andere Weise zu verfolgen (Kommentar in Ihrem Versionskontroll-Commit, Feld im Fehlerverfolgungssystem usw.).

— Caleb
quelle

2

Lassen Sie das treibende Mitglied des Paares für den Push / Commit Kredit / Verantwortung übernehmen. Nächstes Mal fährt das andere Mitglied. Der "Fahrer" wird nichts tun, worüber er sich mit dem Copiloten nicht einig ist.

Das Programmieren ist eine gemeinsame Anstrengung. Keine Programmierurkunde ist 100% individuell. Es besteht kein Grund, umständlich darüber nachzudenken, dass ein bestimmter Push / Commit von Tom und Harry und nicht nur von Tom ausgeführt wurde. Die Vorteile der Paarprogrammierung sind es wert, diese Nuance zu übersehen.

Der Prüfer hat Recht, "Pool" -Konten sollten vermieden werden.

— Tulains Córdova
quelle