기능 소유권이 좋은 습관입니까?

최근 우리 회사에서는 한 명의 개발자가 한 기능에 집중해야한다고 제안했습니다. 이는 개발자를 일반적인 팀 루틴에서 제외하고 다른 책임 (회의 등)을 해제하는 것과 같은 의미이며,이 사람은 기술적 인 측면에서 기능에 대한 "유일한"책임자가 될 것입니다.

기록을 위해 SAFe 내에서 SCRUM을 사용하며 팀당 정규 개발자를 위해 두 팀 (Android 및 iOS)간에 QA 및 제품 소유자를 공유합니다.

나는 이것이 단기적으로 생산성을 증가시킬 것이라는 데 동의하지만, 나는 이것이 여러 가지 이유로 나쁜 습관이라는 느낌을 가지고 있습니다.

코드 검토가 가치를 잃습니다.
최소한의 지식 공유.
위험 증가.
팀 유연성 상실.

내가 맞습니까 아니면 전혀 나쁜 습관이 아닙니까?

agile team code-ownership

— 음델 로모
소스

내 즉각적인 반응은 적당히 수행하면 효과가있을 수 있지만 문제가 너무 많이 발생하면 문제에 대한 것이 옳다는 것입니다. 반면에 제 경험은 모든 기능에 이미 사실상의 소유자가 있다는 것입니다. 많은 시간을 투자 한 사람입니다.

— Ixrec

" 한 개발자가 집중해야합니다 (한 명만) "-SPOF를 원한다면 그렇게하는 것이 좋습니다. 나는 최근에 특정 상황에서 가장 필요한 사람 ( " wtf?!? 왜 그렇게 작성 했는가? ")이 실제로 절대적으로 도달 할 수없는 영향에 대한 경험적 이론을 공식화 했습니다 .

— JensG

@JensG : meh, 나는 가장 자주 필요한 사람 ( "wtf? 왜 그런 식으로 글을 썼는가?")이 나라는 경험적 이론을 가지고있다. ""는 0입니다. 기존 코드를 처음부터 다시 검토하는 대신 다른 사람에 의해 막혔을 때 더 주목할 만합니다. ;-)

— Steve Jessop

@SteveJessop : 물론 많은 KLOC 코드를 검토하여 다른 사람들의 사고 방식을 리엔지니어링하려고 시도하는 동안 고객은 현재 ( 또는 다른! ) 솔루션이 필요하다는 소리를 지르지 만 일부 사람들에게는 멋진 아이디어 일 수 있습니다. 대신에 더 생산적으로 보낼 수있는 시간을 낭비하면서 재미있는 것을 볼만큼 충분히 살아남지 않았습니다.

— JensG

@JensG : 다행스럽게도 내 고객은 귀하보다 더 사회화되어 있습니다. 그러므로 나는 나에게 중요한 것이 진정으로 사람들에게 접근하기 어렵다는 결론을 초래하는 일종의 마 법적 사고에 관여 할만큼 압박을받지 않는다. 따라서, 나는 당신이 말한 것에 농담의 요소가 있다고 생각했습니다. 그래서 나는 그것이 어떻게 작동하는지 기억 하는 사람들을 주변에 여러 사람으로 유지함으로써 이해할 수없는 코드를 보상하는 상황을 재밌게 찾을 수있을 정도로 nerdy 입니다. 특히 그러한 wtfs는 종종 내 자신의 멍청한 잘못이며 동료의 잘못이 아닙니다.

— Steve Jessop

답변:

20 년 동안 경험을 쌓아온 결과, 코드 소유권이 디자이너간에 책임을 맡거나 최소한 한 쌍의 소유자가있는 것이 좋습니다. 단일 기능 소유권에는 다음과 같은 문제가 있습니다.

홀 디자이너를 피하고 성장 기회를 제한하는 경향이 있습니다.
모든 계란을 한 바구니에 담아 버스에 치거나 종료하면 지식에 구멍이 생길 수 있습니다
한 사람이 코드에서 문제를 보지 못하고 동료 소유자가 없으면 코드 검토가 훨씬 덜 효과적입니다.
모든 사람이 자신의 스타일을 사용하여 코드를 작업하는 경우 코드 일관성과 가독성을 유지하기가 어렵습니다. 이는 스타일 가이드 라인으로 해결할 수 있지만 사람들이 기본 동작에 의존하는 구성에 대한 규칙을 사용할 때 미묘한 영향을 줄 수 있습니다.
개발자는 코드를 소유 한 경우 코드를 보호하고 방어적인 경향이있어 코드의 진화를 방해 할 수 있습니다.

— 제이슨 케이
소스

전혀. 1 인 전용 소유권의 가장 명백한 단일 문제로 버스 요소 를 언급하는 것이 중요합니다 .

— JensG

그러나 버스 팩터는 비용과 YAGNI와 교환해야하며 버스가 실제로 조직을 손상 시키거나 많은 번거 로움을 유발하는지 여부와 관계가 있습니다. 만약 일주일에 3 시간 씩 잃는 것 중에서 선택 한다면 , 두 사람이 단 하나의 코드가 아닌 특정 비트에 대해 교육 받거나 60 시간을 잃어 버릴 수 있습니다. 개발자 중 한 명을 공격 한 경우 속도를 높이려면 대부분의 경우 일회성 비용을 선택해야합니다. 그러나 언급 된 이유로 인해 지식 사일로는 다른 단점이 더 중요합니다 (명확하지는 않지만).

— Steve Jessop

피처 소유권은 불가피하며, 잘 수행하는 것이 좋습니다. 이 기술은 숙달을 돕고 일반적으로 인정되는 참여의 기둥 중 하나 인 자율성을 허용 합니다. 그것은 누가 그 코드에 대한 책임을 가지고 있는지 명확하게하고, 위임, 의사 소통 및 다른 방식으로 작업을 수행하는 데 도움을줍니다.

그러나 당신은 그것에 대해 이야기하고 있지 않습니다. 당신은 새로운 팀을 만드는 것에 대해 이야기하고 있습니다-이 코드를 나머지 코드에서 잘라냅니다. 대단하지 않습니다. 그것은 그들의 경력을 제한합니다. 프로젝트 / 회사에 위험을 추가합니다. 동지에 해를 끼칩니다.

따라서 나쁜 생각에서 벗어나기 위해 약간의 조정이 필요할 수 있습니다.

— 텔라 스틴
소스

한 사람의 코드 소유권은 불가피하지만 소수의 사람들이 소유 할 것이라는 데 동의하지 않습니다. 나는 코드를 공유하는 데 나쁜 일을했지만 그와 동일한 조직을 보았습니다. 내가 본 가장 효과적인 설정은 2 ~ 3 명이 코드 조각을 알고 공동 작업했을 때였습니다. 이것은 코더들 사이에서 스트레스와 격리를 줄였습니다. 왜냐하면 그들은 실패했을 때 스스로 갈고리에 걸리지 않았기 때문에 조직의 다른 사람들의 빠른 훈련 램프없이 마감 시간을 맞추기 위해 지연 된 기능에 더 많은주의를 기울일 수 있습니다.

— Jason K.

@jason-물론, 팀에는 편안하고 코드를 작성할 수있는 소수의 사람들이 있어야합니다. 그러나 한 사람이 주제 전문가를 가장 많이 사용하는 것만으로 끝날 것입니다.

— Telastyn

종종 발생하고, 가장 가능성이 높은 시나리오이며, 주제 전문 지식이 좋은 일이라는 데 동의합니다. 단지 여러 사람이 지역의 중소기업이 겹치는 부분을 통해 더 나은 성공을 거두었 기 때문에 불가피 할뿐입니다.

— Jason K .