YAGNI 원칙을 따르지 않는 스크럼 팀

13

SCRUM 회의에서 제품 팀은 모바일 앱에서 사용할 API의 기능에 대해 토론했습니다. 우리는 화면이 어떻게 생겼는지, 어떤 핵심 요소 ( "레이아웃")를 보여야하는지 모의했습니다.

이것과 제품 소유자와의 토론을 바탕으로 API 응답 (HAL + JSON)을위한 프로토 타입을 만들었습니다. 매우 간단하고 HAL 호환 JSON으로 모형에 있던 것을 표현할뿐이었습니다. 비즈니스 사람들이 자신의 아이디어를 자주 바꾸는 경향이 있기 때문에 미래의 아이디어에 영향을받지 않았으며 최소한의 접근 방식을 선택했습니다. 팀에서 제안을 거부했으며 7 대 1로 외면했습니다.

이 팀은보다 복잡한 비의 미적 추상 JSON 구조를 사용하기로 결정하여 레이아웃을보다 유연하게 배열 할 수있었습니다. 이러한 접근 방식의 단점은 설계 상 null 및 빈 속성을 가질 수있는 균일 한 개체 집합으로 끝났다는 것입니다. 또한 A / B 테스트를 수행하는 것이 좋을 것이라고 생각했지만 그러한 요구 사항이 없었기 때문에 예측을 기반으로했습니다.

대부분의 시간 동안 우리는 스프린트의 일부가 아니거나 목업에 언급되지 않은 것들에 대해 토론했습니다. 설명 된 문제는 "미래에 마케팅을한다면 ...", "비즈니스가 우리를 원한다면 ..."이었습니다.

저와 제품 소유자는 숙련 된 프로그래머이며 과거에는 이런 종류의 문제를 보았습니다. 우리는 YAGNI 와 KISS 원칙 을 따르려고 노력합니다 . 나머지 팀원은 경험이 약간 적으며 이러한 원칙을 알고 있지만 이해하지 못하는 것 같습니다.

우리는 팀 전체가 우리에게 더 중요하고 그다지 중요하지 않은 것을 놓고 싸우고 싶지 않기 때문에 그들의 해결책에 동의했습니다. 그러나 그런 일이 다가오는 더 복잡한 토론의 선례가 될 수 있을까 걱정입니다. 그러한 행동을 다루는 방법? 팀 리더로서 내가 더 잘할 수있는 일이 있습니까?

이 제품은 초기 단계 MVP임을 언급 할 가치가 있습니다.

— 재크 코버스
소스

11

I'm afraid if such thing can become a precedence for upcoming, more complicated debates?-그것은 YAGNI에도 위배됩니다. 미래에 대해 걱정하지 않을 것입니다. 만일 당신이 당신의 입장을 견디려면 이미 그렇게했을 것입니다.

— Robert Harvey

@ gnat : 이것은 시간 제약에 관한 것으로 보이지 않습니다.

— Robert Harvey

HAL 준수가 YAGNI의 대상이 아닙니까?

— Matthew

@Matthew 전체가 일주일 걸렸고 HAL을 제거하기 위해 일반 JSON을 사용하여 또 다른 프로토 타입을 준비했지만 "충분하지 않습니다"라고 거부되었습니다. 팀은 그것을 수정했고 그 수정 된 버전이 마침내 사용되었습니다. HAL은 표준, 일련의 지침으로 우리를 위해 일하며 모든 종점에서 균일 한 구조를 적용하는 것이 더 쉽습니다. 이전 API는 표준을 사용하지 않았으며 제대로 끝나지 않았습니다.

— Jacek Kobus

5

유연성은 복잡성을 추가합니다. 팀이 이해하는 한 앞으로 나아갈 수 있습니다.

— Jon Raynor

10

나는 당신의 고통을 느꼈습니다. IMHO 이러한 종류의 문제는 당신이 8 명으로 구성된 팀이 있기 때문에 발생합니다.이 팀은 이미 당신이 항상 최고의 전략적 결정을 내릴 수 없을 정도로 너무 큽니다.

8 명 이상의 기회를 가진 팀의 경우 평범한 프로그래머의 수는 숙련 된 수보다 많습니다. 그것은 종종 더 나은 결정이 평범한 결정에 의해 반대되는 상황으로 이어질 것입니다. 그것은 특히 경험이 많은 사람 중 하나 일 때 (또는 당신이 생각한다고 생각할 때) 만족스럽지 않은 것처럼 들리지만, 실제로 나쁜 결정에 대해서는 적어도 동일합니다.

사실, 팀이 변하지 않는 한 , 적어도 사물이 민주주의를 유지한다면, 당신이 할 수있는 일은 많지 않습니다.

그것으로 사는 법을 배운다
1-2 년 동안 팀과 협력하고 자신의 전문 지식을 공유하고 시간이 지남에 따라 YAGNI와 KISS의 가치를 배우기를 바랍니다.
"판매"디자인 또는 전략적 결정에 대한 기술
자신의 전문 지식 수준이 전체 팀의 평균에 가까운 다른 (아마도 더 작은) 팀으로 전환하십시오.

최소한의 접근 방식과 YAGNI의 실제 가치를 배우고 이해하는 유일한 방법은 직접 경험을 쌓는 것입니다. 예를 들어, 잘못된 "what if"예측이 많은 레거시 시스템의 유지 관리, "경우에 따라"인수에 의해 동기가 부여 된 잘못된 디자인 결정 또는 실제로는 전혀 필요하지 않은 많은 오버 제너레이션 된 프레임 워크 코드가 포함됩니다. 하지만 이틀 만에 팀원들에게 가르 칠 수있는 것은 아니며 사람들이 스스로 경험해야하는 일부 경험입니다.

— 닥 브라운
소스

5

대부분의 사람들은 난로를 만져서 뜨겁다는 것을 알고 만지지 않아야합니다. 소프트웨어는 거의 동일합니다. ++

— RubberDuck

2

이런 일에는 프로젝트 로그 / 일지를 유지하는 것이 중요합니다. 여러 가지 토론을 기록한 후에는 몇 달 또는 몇 년 후에 사람들이 대화를 회상하는 것보다 훨씬 더 구체적입니다. 연습에 대한 좋은 질문이 있습니다 .

— Robbie Dee

@RobbieDee : 팀이 YAGNI와 KISS에 대해 배우는 데 도움이된다면 확실합니다.

— Doc Brown

3

세 번째 글 머리 기호 (디자인을 "판매"하는 데있어 자신의 기술을 연구하는 것)는 충분히주의를 기울이지 않습니다. 이것이 개발자들이 여전히 훌륭한 의사 소통 기술을 보유해야하는 이유입니다.

— 랜달 스튜어트

@RandallStewart : 절대적으로. 그러나 최고의 의사 소통 기술을 사용하더라도 스스로 경험을하지 않은 사람들에게 YAGNI를 판매하기가 어렵거나 "빠르고 더러워"와 혼동을 느끼거나 "추상이 (항상) 좋다"고 교육받은 사람들에게 단순화를 위해 추상화를 위해 사물을 추상화하는 것. 의사 소통에는 두 가지 측면이 필요합니다. 하나는 잘 설명 할 수 있고 다른 하나는 듣고 이해하려고합니다.

— Doc Brown

8

순방향 호환성은 합법적 인 문제입니다

귀하를 대변 한 7 명의 개발자 중 하나가 설계자 인 경우, 필요에 따라 NFR 을 도입하는 것이 그의 권리 이며, 이러한 NFR 중 하나는 특히보다 드문 드문 원격 시스템 구성 요소를 지원할 때 "앞으로 호환성"이 될 수 있습니다. 출시 일정. 미리 생각하지 않았기 때문에 사용자가 새로운 버전의 앱을 설치하지 않아도됩니다.

다른 요구 사항과 마찬가지로 수락 기준이 필요합니다

즉, 모든 NFR은 요구 사항으로 문서화되어야하며 정의 된 수용 기준을 가지고 있어야 합니다 . 또한 테스트 방법을 마련해야 합니다 . 그렇기 때문에 YAGNI가 중요합니다. 테스트 할 수없는 코드를 작성하고 싶지 않으며, 코드의 유일한 목적이 아무도 사용하지 않는 기능을 지원하는 것이라면 테스트하기가 어렵습니다.

판결이되어서는 안됩니다

나는 당신이 명백히 놓친 무언의 요구 사항에 팀이 동의하고 서면으로 작성하도록 제안합니다. 테스트 수단을 정의한 후에는 구현에서 하나 이상의 테스트에 실패해야하므로 투표 문제가되지 않습니다.

— 존 우
소스

1

문제의 어느 부분에서 OP의 팀이 호환성 요구 사항 때문에 YAGNI의 길을 떠났다는 것을 읽었습니까?

— Doc Brown

순방향 호환성은 Content-Type헤더의 용도

— Jack

2

나는 당신이 원한다면 아마도 다른 것, 아마도 확장 성이라고 부를 것입니다. 요점은 같습니다. 여전히 NFR입니다.

— John Wu

1

시스템을 확장 가능하게 만드는 두 가지 방법이 있습니다. 한 가지 잠재적 인 요구 사항 변경을 예측하고 "경우에 따라"크게 구성 할 수있게 만드는 방법입니다. 이런 종류의 확장성에 대해 많은 수용 테스트를 만들 수 있다고 확신합니다. 또는 가능한 한 단순하게 유지하여 코드베이스를 작고 파악하기 쉬우 며 나중에 필요할 때 확장 점 또는 추상화를 추가 할 수 있습니다. 후자는 테스트를 작성할 수있는 (또는 필요한) 것이 아닙니다. 따라서 나는 "무언의 NFR을 적어 놓음"으로써 이것을 쉽게 해결할 수 있다고 생각하지 않습니다.

— Doc Brown

... 이것은 아마도 창의적인 개발자들로 구성된 팀을 NFR에 대한 가정을 세우고 일부를 발명하는 방법에 관한 것입니다.

— Doc Brown

3

개발팀이 빠른 평가판을 수행 할 수있는 프레임 워크를 만들어 제품 팀을 지원하려는 것 같습니다. 이는 제품 팀이 실제로 원하는 것입니다. 당신의 접근 방식은 "문학적으로 그들에게 요구하고 생각하지 않는 것을 제공하는 것"과 비슷합니다.

내가 제품 소유자라면 개발 팀이 후자보다 첫 번째 접근 방식을 취하는 것이 훨씬 행복 할 것입니다.

— 마틴 마트
소스

3

+1 변화를 예상하고 계획하는 것은 완전한 아키텍처 우주 비행사를 타고 내부 플랫폼을 만드는 것과는 다릅니다 . 현재 약간의 토대는 미래에 많은 작업을 막을 수 있습니다. OP의 팀은 아마도 가설의 방향에 너무 많이 기울고 있지만 근본주의 YAGNI 접근법은 확실히 차선책입니다.

— amon

4

OP를 행복하게 표출 하고 팀의 다른 팀보다 "미래에 마케팅을한다면 어떻게 될까? "라는 계획을 세우는 실수를 저지르는 것처럼 들립니다 . 작업이 응용 프로그램 소프트웨어를 구축 할 때 응용 프로그램 소프트웨어 대신 프레임 워크를 구축하기 시작하면 거의 항상 잘못하고 있습니다.

— Doc Brown

@DocBrown 기술적으로 동의합니다. 그러나이 경우는 개인의 존중을 요구하는 것보다 기꺼이하는 것 같습니다. 한편으로는 "올바른"반면 다른 한편으로는 유용하거나 도움이되는 것. 내가 선들 사이에서 읽은 것은 더 이상 편안하지 않은 환경에 기여하는 대신 OP가 온라인 관객에게 자신의 경험을 강조함으로써 자신의 자아를 끌어 올리 겠다는 것입니다. 이 역학은 스크럼의 도입에 일반적입니다.

— Martin Maat

@MartinMaat 나는 그들이 나와 동의하지 않는다는 사실에 약간 실망했습니다. 왜 그런 일이 일어 났는지 이해하지 못했습니다. 일상적인 작업 중에는 코드 검토 등을 도와줍니다. 우리는 종종 논쟁하지만 최종 결과가 더 좋기 때문에 좋아합니다. 나는 그들이 내 의견을 존중한다는 것을 알고 있습니다. 나는 항상 내 이론을 뒷받침하는 유효한 논증을 사용하려고합니다. 결국 그들은 최고의 옵션을 선택하고 책임을집니다. 팀은해야 할 일을했는데 문제를 해결했습니다. 문제가 너무 광범위하고 처음부터 잘 설명되지 않은 것은 저와 제품 소유자의 실수였습니다.

— Jacek Kobus

2

글쎄, 내 의견은 민주주의가 제대로 작동하지 않는다는 것입니다. 정치 시스템이나 대부분의 프로그래머가 후배이거나 평범한 팀에서는 아닙니다.

팀 리더로서, 그리고 팀에서 가장 경험이 많은 사람들 중 한 사람은 다른 팀보다 더 큰 영향을 미칩니다. YAGNI가 당신에게 중요하다면, 그것에 대해 프리젠 테이션을해야합니다. 그것에 대해 토론하고 왜 좋은지 보여주십시오.

결국, 당신의 책임은 다른 사람들보다 높습니다. 코드를 작성하는 것뿐만 아니라 사람들을 안내하는 것입니다.

— Јовић
소스

3

민주주의는 아마도 문제의 원인 일 수도 있지만 민주주의가 아니라면 문제에 대해 설명 된 것보다 더 큰 문제를 쉽게 도입 할 수 있기 때문에 IMHO는 해결책이 없습니다. 실제로 팀을 망치게 할 수 있습니다.

— Doc Brown

@DocBrown 당신은 같은 문장에서 자신을 모순했습니다. IMO 일부 결정은 사람들이 결정하지 않습니다. OP가 설명 한 것은 그중 하나입니다. YAGNI를 사용하지 않는 사람들을위한 암스트롱 인용 : 바나나를 원했지만 바나나와 정글 전체를 잡고있는 고릴라였습니다.

— BЈовић

2

아니요, 이것은 모순이 아닙니다 (아마도 내 요점을 잘 표현하지 못했을 수도 있습니다). 항상 "흑백"인 것은 아닙니다. 일부 상황에서는 민주주의가 제대로 작동하지 않기 때문에 민주주의가 아니라고해서 상황을 개선하고 상황을 개선 할 수있는 것은 아닙니다. 종종 그렇게 간단하지 않습니다.

— Doc Brown

1

민주주의를 통해 당신은 대부분의 사람들이 동의하는 "옳은"것을 얻지 않아도됩니다. 그리고 이것은 결함이있을 수 있습니다. 그리고 종종 "올바른"것은 사회적 수용에 문제가 있습니다. YAGNI는 필요한 경우 "고릴라"또는 "전체 정글"을 쉽게 추가 할 수있는 적절한 추상화를 방해하는 수갑이되어서는 안됩니다.

— oopexpert

문제는 @oopexpert : 당신이 수 를해야합니다. YAGNI는 오버 엔지니어링에 대해 이야기합니다. 적절한 추상화는 한 가지이며, 필요하지 않은 것을 추가하는 것은 다른 문제입니다.

— BЈовић

2

야 그니에 대해 약간의 혼란이 있다고 생각합니다.

개발자들은 종종 시스템을 "수정을 위해 폐쇄하고 확장을 위해 개방"하는 추상화를 생략 할 때 YAGNI를 따르고 있다고 생각합니다.

"명백하게"요청되지 않은 기능으로 시스템을 "확장"하지 않으면 YAGNI를 다루지 않습니다. 확장이 발생할 수있는 추상화를 소개하는 것은 이미 언급 된 "순방향 호환성"입니다.

내 개인적인 견해는 도메인에 대한 깊은 지식 만 추상화와 결정의 위치를 결정하는 데 도움이 될 것입니다.

— oopexpert
소스

2

YAGNI와 KISS의 문제점은 완전히 주관적이고 모호하다는 것입니다.

json ?? 야 그니! 그냥 CSV 문자열을 보내십시오!

사물?? 키스 !! 그냥 gotos를 사용하십시오!

'팀장'역할은 잘 정의되어 있지 않지만 팀의 기술적 선택에 대한 주관적인 의견을 표현할 수 없습니다. 그들이 틀렸다고 느끼더라도. 잘 정의 된 요구 사항의 짧은 목록을 고수하십시오.

코드 단위 테스트
API에 대한 통합 테스트
최종 제품에 대한 자동화 된 UI 테스트
성능 및 확장 요구 사항

팀이 모든 비즈니스 요구 사항 및 기본 기술 요구 사항의 기본 성능에 대한 통과 테스트를 달성 할 수 있다면 작동하는 제품이있는 것입니다.

그 후에는 동일하지만 더 빨리 수행하려고합니다.

— 이완
소스

1

팀의 모든 사람들 은 done 의 정의에 동의 해야 합니다 . 이 기능이 없으면 대량의 스코프 크리프, 관점 및 핵심 요구 사항의 난폭 한 경향이 있습니다.

이 이상으로 전달되는 것은 백 로그에 있어야하며 자체적으로 자체 정의가 있습니다.

우선 순위에 관해서는, MoSCoW 방법은 항상 우리에게 잘 도움이되었습니다-YMMV.

— 로비 디
소스

1

이것에 대한 나의 첫번째 생각은 ... 팀이 왜 변화에 관심을 가지는가? 제품 소유자에 대한 역사적인 이해를 가지고있어 향후 개선을 쉽게하기 위해 조금 더 구성 가능한 첫 번째 솔루션을 구축해야한다고 생각합니까? 솔루션에 2 일이 걸리고 5 일이 걸리면 두 배가 넘습니다. 그러나 계획 변경에 매 2 일이 걸리지 만 개선에 1 일이 걸리면 장기적으로 계획이 더 효율적으로 보입니다. 나는이 질문에 옳고 그른 결정이 없다고 생각합니다. 그것은 다른 요인, IMHO에 달려 있습니다. 그러나 다른 솔루션에서 직접 지시하지 않고 LOE를 두 배로 늘리면이 사고 방식에 적합합니다 (확장 성, 견고성 등에 추가 복잡성이 필요하다는 일부 증거). 제품 소유자가 우선 순위를 정하는 데 도움이 필요하기 때문에 이러한 대화에 제품 소유자를 참여시키는 것이 좋습니다. 솔루션이 5 점이고 현재 요구를 충족하지만 원하는 점이 50 점 2 스프린트 이상이면 PO는 "잠시만 기다려야합니다.이 MVP의 우선 순위가 가장 높은 릴리스입니다. 로드맵에없는 기능을 구축하는 데 2 주를 소비 할 수 없습니다. "

— 커티스 리드
소스