답변:
저는 Scrum 전문가는 아니지만 AFAIK "집합 적 코드 소유권"은 팀 및 제품 별로 구성 되어야합니다 (그리고 귀하의 질문은 Scrum에만 국한된 것이 아니라고 생각합니다. 모든 "공유 코드"개발 프로세스에 적용될 수 있습니다).
두 팀 A, B, 두 제품 A, B 및 공유 구성 요소 C가있는 경우 가능한 시나리오가 다릅니다. 공유 구성 요소는 주로 제품 A에 속할 수 있습니다 (제품 B 팀에서는 재사용했지만 진화하지는 않음). 이 상황에서 팀 A는 건축 비전을 분명히 책임집니다. 또는 그 반대도 마찬가지입니다. 제품 B에 명확하게 속하므로 책임이 있습니다. 팀 A가 책임을지는 경우, 팀 B는 긴급 버그 수정을 허용하기 위해 구성 요소 포크를 사용할 수 있지만 (C의 메인 라인으로 다시 통합하는 방법도 있어야 함) B는 더 큰 구성 요소의 진화를 피해야합니다.
그러나 제품 A와 B에 모두 C에 대한 "구동 요구 사항"이 많은 경우 C는 자체 버전 관리, 릴리스 관리, 변경 관리, 단위 테스트 등을 갖춘 별도의 팀과 함께 별도의 제품으로 C를 관리해야합니다. 해당 구성 요소에 대한 책임. 그 팀은 "가상 팀"일 수 있으며, 팀 A, B 또는 둘 다와 별도의 개발자로 구성됩니다. 이 팀은 C의 "공유 코드 소유권"과 "아키텍처 비전"에 대한 책임이 있습니다. C가 타사 공급 업체에서 제공 한 구성 요소라고 생각하면됩니다.
스크럼이나 애자일에는 "명확한 아키텍처 비전"이라는 개념이 없습니다!
나는 오랫동안 건축가였으며 건축 비전을 가지려면 미래의 요구 사항을 명확하게 볼 필요가 있음이 분명합니다. 대부분의 경우 요구 사항이 명확하지 않기 때문에 고정 된 비전을 갖는 것은 합리적이지 않습니다.
변화하는 요구 사항에 충분히 적응할 수있는 아키텍처가 필요합니다. 다시 말해, 상황이 변하고 아키텍처가 변한다는 것입니다. 저는 재구성 할 수있는 "소프트"아키텍처를 옹호하지 않습니다. 나는 오늘 가지고있는 아키텍처가 곧 폐기되고 변경 될 필요가 있다는 것을 받아들이는 것에 대해 이야기하고있다. 따라서 아무도 "결혼"해서는 안된다.
집합 적 코드 소유권은 이론적으로 모든 사람이 무엇이든 변경할 수 있어야 함을 의미합니다. 이것은 "사일로의 반대쪽"으로 이해되어야합니다. 다시 말해, 모든 사람들이 SQL 쿼리를 미세 조정하고 예제를 제공 할 수있는 숙련 된 DBA는 아니지만 숙련되고 장애가있는 기술 장벽이있을 수 있습니다. 그러나 이로부터 DBA만이 할 수있는 것은 아닙니다. 손 최적화 쿼리. 다른 사람들이 능숙 해 지도록 도와 줄 수있는 "피처 도메인 전문가 (feature domain expert)"가있을 것입니다.
예를 들어, "A"기능의 도메인 전문가 인 경우에도 다른 사람이 "A"기능에 대한 작업을 수행 할 것으로 예상되지만 주요 변경이 필요하거나 사람들이 도움을 필요로 할 때 상담을받을 가능성이 있습니다. 기능 "A"는 확실히 내 기능이 아닙니다 . 내가 잘 아는 기능이 될 것입니다. 더 많은 기능을 알고, 다른 사람들이이 기능을 알고 싶어하는 것이 저의 관심사입니다.
종합적으로 : 요구 사항이 등장하고 변화함에 따라 개발자가 아키텍처를 여러 번 설계하고 재 설계했습니다. 모든 사람은 자신의 기술에 따라 필요한 사항을 변경하고 언제 도움을 요청해야하는지 알아야합니다. 때문에 아키텍처에 더 장기적인 비전이 없다 우리가 사람들을 신뢰 하고 우리는 요구 사항을 신뢰하지 않는다 .
예를 들어 spotify는 "시스템 소유자"라는 역할을 사용하여 문서에서 직접 문제를 해결합니다.
기술적으로는 누구나 시스템을 편집 할 수 있습니다. 분대는 효과적으로 기능 팀이므로, 새로운 기능을 프로덕션에 적용하려면 일반적으로 여러 시스템을 업데이트해야합니다. 이 모델의 위험은 아무도 시스템 전체의 무결성에 중점을 두지 않으면 시스템 아키텍처가 엉망이되는 것입니다.
이러한 위험을 완화하기 위해 "시스템 소유자"라는 역할이 있습니다. 모든 시스템에는 시스템 소유자 또는 시스템 소유자 쌍이 있습니다 (페어링 권장). 운영상 중요한 시스템의 경우 시스템 소유자는 개발자 관점을 가진 한 사람, 즉 개발자 관점을 가진 사람과 운영 관점을 가진 사람입니다.
시스템 소유자는 해당 시스템과 관련된 기술 또는 건축 문제에 대한 "가는"사람입니다. 그는 코디네이터이며 시스템에서 코드를 작성하는 사람들이 서로 걸려 넘어지지 않도록 안내합니다. 그는 품질, 문서화, 기술 부채, 안정성, 확장 성 및 릴리스 프로세스와 같은 것에 중점을 둡니다.
시스템 소유자는 병목 현상이나 상아탑 설계자가 아닙니다. 그는 개인적으로 모든 결정을 내리거나 모든 코드를 작성하거나 모든 릴리스를 수행 할 필요는 없습니다. 그는 일반적으로 시스템 소유권 외에 다른 일상적인 책임을 가진 분대원 또는 챕터 책임자입니다. 그러나 때때로 그는 "시스템 소유자의 날"을 취하여 해당 시스템에서 하우스 키핑 작업을 수행합니다. 일반적으로 우리는이 시스템 소유권을 사람의 10 분의 1 미만으로 유지하려고하지만 시스템마다 많은 차이가 있습니다.
회사 수준 (팀 수준뿐 아니라)에서이 시스템 소유자가 아키텍처 무결성을 보장하려는 이점이나 집단적 코드 소유권을 갖는 것이이 아이디어를 정말 좋아합니다.
완전한 문서에 대한 링크 : https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf 는 민첩한 스케일링에 대한 실제 경험을 바탕으로 짧지 만 매우 흥미로운 문서입니다.
해결하기 어려운 문제이며, 개발 방법론이 아니라 프로젝트 관리 방법론 인 Scrum에 의해 확실히 해결되지는 않았습니다.
내가 찾은 가장 효과적인 솔루션은 훌륭한 패키지 관리 (nuget / gem / etc) 및 버전 관리입니다. 다른 팀이 소비 할 준비가 될 때까지 변경하지 마십시오. 새로운 빌드로 넘어 가면서 이전 빌드를 계속 사용하도록하십시오.
어떤 변경 사항이 적용되고 어떤 변경 사항이 적용되는지 명확하게하는 버전 관리 전략이 있는지 확인하십시오.
또한 변경을 할 때, 각 팀원에게 코드 검토를 푸시하십시오. 그들이 자신의 변화를 맨 위에 구현할 수 있도록 그것을 소비하기 훨씬 전에 그것들이 그들에게 어떤 영향을 미칠지 살펴 보도록하자.
그리고 일이 정말로 지저분해질 때; 한 팀이 변경을해야하고 다른 변경을 쉽게 소비 할 수없는 경우 (이 경우는 매우 드문 경우 임), 코드를 분기하고 완전히 다른 패키지로 만들지 만, 빠른 시간 내에 공통 코드로 돌아가는 것이 우선 순위가되도록하십시오 허용합니다.
항상 분명하지 않은 대답은 팀이 주어진 구성 요소를 공유 할 방법을 결정하게하는 것입니다.
예를 들어, 우리 팀은 최근 비슷한 제품을 오랫동안 개발해온 다른 두 팀과 공통된 많은 코드를 공유하는 새로운 제품군을 개발하기 시작했습니다. 우리 제품은 몇 가지면에서 다르기 때문에 때때로 공통 코드에 사용자 지정 지점을 추가하는 방법을 찾아야합니다.
우리는 그 코드에 대해 약간의 충돌이 있었고, 공통 소유권을 다루는 몇 가지 다른 임시 방법을 시도했습니다. 그런 다음 큰 새로운 기능이 등장하면서 모든 팀을 하나로 묶어 같은 페이지를 가져와야한다고 결정했습니다. 결과적으로 각 팀의 세부 정보를 처리하는 두 명의 구성원으로 구성된 소규모 그룹이 만들어졌습니다.
우리 팀이 제안한 솔루션이 다른 상황에서는 작동하지 않을 수 있습니다. 더 간단한 것이거나 훨씬 더 공식적인 것이 필요할 수 있습니다. 요점은, 당신은 집단 소유권을 가지고 당신에게 무엇이 효과가 있는지 알아내는 것입니다.
나는 가정을 자유롭게 할 것이다.
위의 가정이 맞다면 두 팀이 서로 방해하는 경우가 가끔 있습니다. 다음과 같은 방법으로 해결할 수 있습니다.