페어 프로그래밍 및 ISO 27001

16

저는 eXtreme 프로그래밍 팀에서 일했으며 Windows 환경에서 7 년 이상 페어 프로그래밍을 수행했습니다. 처음 시작했을 때 누군가는 Windows 자격 증명으로 로그인하므로 도메인 리소스에 대한 모든 액세스, 특히 버전 제어는 해당 Windows 사용자에게 책임이 있습니다. 결국 우리는 특정 페어링 스테이션 (예 : pairA, pairB, PairC 등)을위한 Windows 페어링 계정을 갖도록 진화했습니다. 모든 개발자는이 계정의 비밀번호를 알고 있습니다. 커밋에 대한 책임 (체크인)은 커밋 중에 프로그래머 이니셜을 주석에 넣음으로써 달성됩니다.

지금까지 이것은 우리를 위해 잘 작동했지만 회사는 현재 ISO 27001 감사를 진행하고 있으며 이는 감사가 위험 요소로 표시했습니다. 모든 페어 조합에 대해 페어링 계정을 만드는 등의 여러 가지 가능한 솔루션이 있지만 다른 사람이이 문제를 겪었는지 여부와 해결 방법을 알고 싶습니다.

감사관은 어떤 솔루션을 수용 할 수 있었습니까?

pair-programming iso

— 마틴 휴즈
소스

11

페어 프로그래밍 방식을 사용하는 대부분의 사람들은 ISO가하는 모든 것이 날짜 형식과 문자 인코딩이라고 생각한다고 생각합니다.

— Lars Viklund

6

페어링 계정이 필요한 이유는 무엇입니까? 컴퓨터에 로그인 할 수있는 개별 계정을 유지하는 것이 효과가 없습니까?

— 개렛 홀

누군가가 일을 일찍 시작하거나 화장실 등에 갔을 때 기계가 다른 사용자로 로그인하면 어떻게됩니까? 개인 계정을 사용할 수 없습니까?

— 존시 블리

@JohnSibly 해당 계정에서 진행중인 작업을 계속하고 싶습니까? 그렇지 않으면 컴퓨터에서 자신의 사용자로 다른 세션을 열 수 있어야합니다.

— Sinjo

2

@JohnSibly, 드라이버가 로그 오프하고 피어가 로그온하도록합니다. 그들이 화장실에 가면 동료를 믿지 않으면 기계를 잠그십시오. 그러나 수정해야 할 더 큰 문제는 신뢰가 아닙니다.

— CaffGeek

13

감사인이 개발자가 공유 암호를 가진 "페어"가 아닌 자체적으로 로그인하는 것을 선호한다고 가정합니다. 위험은 명백해야합니다. 개발자는 일부 악성 코드를 "PairA"로 추가하고 다른 사람의 이니셜을 주석에 넣거나 전혀 주석을 달지 않습니다. 악의적 인 개발자를 어떻게 추적합니까?

누구든지 (세션에서) 처음으로 자신의 ID로 로그인하는 것이 좋으며, 쌍은 이니셜을 계속 주석에 넣습니다. 그러면 코드는 실제 개발자에게 다시 추적 할 수 있습니다.

— 매튜 플린
소스

+1, 이것은 우리 회사에서 수행 한 것입니다. 우리는 피어 코드 검토 또는 페어 프로그래밍을 선택할 수 있습니다. 페어 프로그래밍 사례는 피어 검토의 특별한 경우이며 코드가 작성되는 동안 피어가 지속적으로 검토하고 있습니다.

— Daniel Pryden

@Daniel 경험을 공유해 주셔서 감사합니다. 우리가 처음 페어링을 시작했을 때, 로그인하는 것이 드라이버였습니다. 그러나 우리의 페어링 세션은 이제 더 무차별 적이며 작업이 완전히 완료되기 전에 종종 쌍이 교환됩니다. 이것이 이상적이지는 않지만 모든 사람이 프로덕션 코드를 페어링해야하므로 스왑을 조정해야하는 경우가 있습니다. 이것은 원래의 '드라이버'가 걸어서 로그 아웃해야한다는 것을 의미합니다. 코드 없이도 코드를 체크인 할 수는 있지만 앱 디버깅 도중에 발생할 수있는 페어에 대한 방해가 너무 가벼워지지는 않습니다.

— Martin Hughes

7

계정을있는 그대로 유지합니다. 일반적으로 한 사람 만 운전하고 있으며 다른 사람이 (비공식적으로) 컴퓨터를 사용하더라도 로그인 한 사람은 여전히 자신의 컴퓨터에서 발생하는 상황을 알고 있어야합니다.

그러나 체크인은 여전히 쌍이 누구인지 보여주기 위해 주석이 필요합니다.

— CaffGeek
소스

페어 계정 ( "계정을 그대로 유지")을 유지하거나 개별 계정 ( "로그인 한 사람")을 사용 하시겠습니까?

— Caleb

@Caleb, 로그인 한 사람이 운전중인 사람

— CaffGeek

6

작업이 부재중인 사용자에게 잠기지 않도록 별도의 계정을 만드는 대신 버전 관리 시스템을 사용하십시오. 쌍이 작동하기 시작하면 작업 분기를 만듭니다. 테스트가 통과 될 때마다 작업 분기에 코드를 커밋하십시오. 작업이 완료되면 작업 분기를 다시 병합하고 닫습니다.

— 케빈 클라인
소스

5

지금까지 이것은 우리를 위해 잘 작동했지만 회사는 현재 ISO 27001 감사를 진행하고 있습니다

ISO 27001의 유무에 관계없이 현재 시스템은 커뮤니케이션 및 상호 신뢰 수준이 높은 소규모 회사이기 때문에 작동합니다. 그런 종류의 것은 잘 확장되지 않으므로 나중에 다른 시점에서 다른 옵션을 고려해야 할 것입니다.

가능한 모든 쌍에 대해 별도의 계정을 만드는 것은 훨씬 실용적이지 않습니다. 10 명의 개발자 그룹에 대해 90 개의 계정이 필요하며, 10 명의 개발자 각각은 9 개의 서로 다른 로그인 / 암호 조합을 알아야합니다.

유일한 실질적인 해결책은 다른 사람들이 제안한 것처럼 개별 계정을 사용하고 다른 방법으로 두 번째 사람의 신원을 다른 방식으로 추적하는 것입니다 (버전 관리 커밋의 주석, 문제 추적 시스템의 필드 등).

— 케일럽
소스

2

Pete를 위해, 한 쌍의 운전원이 푸시 / 커밋에 대한 신용 / 책임을 갖도록하십시오. 다음에 다른 멤버가 운전합니다. "운전자"는 부조종사에게 동의하지 않는 어떠한 행동도하지 않을 것입니다.

프로그래밍은 공동 작업입니다. 100 % 개별적인 프로그래밍 행위는 없습니다. 주어진 푸시 / 커밋이 Tom뿐만 아니라 Tom과 Harry가 수행했음을 반영하기를 까다로울 필요는 없습니다. 페어 프로그래밍의 이점은 이러한 뉘앙스를 간과 할 가치가 있습니다.

감사는 옳습니다. "풀"계정은 피해야합니다.

— 툴 린즈 코르도바
소스