수직적 사용자 스토리의 단점

민첩한 접근 방식 으로 작업을 구조화하는 수직 사용자 스토리를 과에서 응용 프로그램의 초점을하지만 완전히 기능 조각을 제공하는 엔드 - 투 - 엔드를 . 이것이 소프트웨어 구축에 대한 새로운 접근 방식이기 때문에 이것이 수평 스토리보다 나은 이유에 대한 많은 문헌을 읽었지만이 접근 방식의 단점에 대해서는 많이 찾지 않습니다.

나는 이미 민첩한 쿨 에이드를 마셨고 케이크를 세로로 자르는 것은 가로로 자르는 것보다 많은 이점이 있다는 데 동의합니다. 여기에 내가 할 수있는 단점의 짧은 목록이 있습니다.

• 스토리를 개발하는 데 필요한 모든 기술 (UI + 서비스 계층 + 데이터 액세스 + 네트워킹 등)을 이해해야하기 때문에 개발자는 처음에 기능 구현 속도가 느려질 수 있습니다.
• 전체 아키텍처 설계 (애플리케이션의 백본 작성)는이 지침에 실제로 맞지 않습니다 (그러나 일부는 전체 아키텍처를 개발 / 변경하는 사용자 스토리의 일부라고 주장 할 수 있음)

수직 분할 사용자 스토리의 단점은 무엇입니까?

참고 : 지금이 질문을하는 이유는 팀에게 이야기를 '수직적 인 방법'으로 시작하도록 설득하려고하고 가능한 트레이드 오프를 미리 가져올 수 있기를 원하기 때문입니다. 접근 방식이 단점에 직면했을 때 실패를 고려하지 마십시오.

나는 장기적인 단점을 모른다. 단기적으로, 그리고 이런 종류의 개발에 익숙하지 않은 팀의 경우 주요 단점은 학습에 익숙해지는 데 약간의 시간이 걸린다는 것입니다.

수직으로 작업하는 가장 효율적인 방법은 풀 스택 개발자를 보유하는 것입니다. 이런 방식으로 스토리는 일반적으로 한 사람 (또는 둘 이상의 파이프 라인 작업없이 )에 의해 실행될 수 있습니다 . 분명히 이것은 개발자가 스택을 가로 질러 (웹 애플리케이션의 경우 html에서 데이터베이스까지) 수직으로 작업해야합니다.

팀이 수직 스토리를 다루는 데 익숙하지 않은 경우 반대 방향으로 진행될 가능성이 높습니다. 각 사람은 애플리케이션의 한 계층 / 계층에 대한 지식 만 갖습니다. 수직 스토리를 소개 할 때 팀이 스토리를 계층에 해당하는 태스크로 분할 한 다음 태스크를 다른 사람에게 분배하도록 기대할 수 있습니다. 이것은 매우 비효율적입니다.

이것에 관해 내가 줄 수있는 가장 좋은 방법은이 파이프 라인을 처음에 견딜 수 있고 장기 목표가 완전히 다르다는 것을 분명히하는 것입니다. 여러 계층의 팀 구성원이 프로그램을 쌍을 이루어 신뢰를 쌓고 결국 사람들이 완전히 독립 할 수 있도록하십시오.

이 접근법이 기술 부채를 가져온다는 다른 대답에는 동의하지 않습니다. 가능하지만 다른 접근 방식도 가능합니다.

나는이 정확한 질문에 대해 많이 생각했습니다.

개인적 책임에 의한 슬라이싱과 팀 책임에 의한 슬라이싱을 구별하는 것이 중요하다고 생각합니다. 이 답변은 주로 슬라이싱 팀에 중점을 둘 것입니다.

일부 배경 : 풀 스택 개발자, 단일 계층 개발자, 수직 (풀 스택) 팀, 수평 (단일 계층) 팀 및 대각 팀과 함께 프로젝트를 수행했습니다. 대각선 팀이란 이야기에 필요한 모든 계층을 포함하지만 시스템의 모든 계층을 반드시 포함 할 필요는 없으며 동일한 계층에 중점을 둔 여러 개발자를 포함 할 수도 있습니다. 다시 말해서, 정신적으로 수직이지만 외관상 또는 구 현상 세부적으로 다소 수평적일 수있다.

최근에 저는 수평 팀에서 대각선 (거의 수직) 팀으로 전환 한 그룹에서 일했습니다. 같은 그룹의 사람들이 두 가지 다른 방식으로 정렬되는 것을 보는 것은 특히 교훈적입니다. 그것은 몇 가지 장점과 단점을 분명하게 만듭니다.

다음 요약 비교로 지금까지 의견을 정리하겠습니다.

수평 팀

장점 :

• 관심사 분리 및 느슨하게 결합 된 계층 육성
• 훨씬 쉬운 워크로드 분배 관리
• 전문 기술 담당자가 관리하기 쉬움
• 인트라 계층 협업, 모범 사례, 자부심 및 우수 문화 조성
• 자연스럽고 긴급한 통신 패턴과 일치

단점 :

• 계층을 분리하여 계층 간 통신을 방해 할 수 있음
• 완화되지 않은 경우 계층 "버블"문화 활성화
• 일반 리더십을 활용하기 어려움
• 일반인 방해

수직 / 대각 팀

장점 :

• 한 팀에서 사용자 스토리의 모든 부분 ( "원 스톱 상점")
• 단일 스프린트로 n- 계층 스토리를 전달하는 데 특히 도움이됩니다 (실제로 필요합니까?)
• 계층 간 협업 및 일반 기술의 성장 촉진
• 일반인 지원

단점 :

• 훨씬 더 어려운 워크로드 분배 관리
• 열악한 관심사 분리 및 긴밀하게 결합 된 계층 가능
• 계층 내 통신을 줄임으로써 전문화를 방해합니다. 수평 적 / 전문가 적 행동을 완화시키지 않으면 서이 구조에서 어떻게 우수 문화가 생길 수 있는지 알기가 어렵다

팀 멤버십이 모든 솔루션에 적합한 것은 아니라고 생각합니다. 그러나 수직 팀은 일반화가 필요한 조직에 더 적합합니다. 엔지니어가 일반 전문가이고 풀 스택 작업을 좋아하는 경우 수직 팀을 고려해야하는 아주 좋은 이유입니다. 수평 팀은 전문가가 필요한 조직에 더 적합합니다. 엔지니어가 전문가라면 수평 팀을 고려해야하는 아주 좋은 이유입니다.

다른 사람들이 언급했듯이, 다른 방향을 얇게하는 2 차 구조 / 동작은 시스템의 단점을 완화하는 데 도움이 될 수 있습니다. 흥미로운 완화 요소 중 하나는 스프린트 지속 시간입니다. 짧은 스프린트는 수평 팀의 단점 중 일부를 더 견딜 수있게합니다. 이번 주에 백엔드와 다음 주에 프론트 엔드를 구축 할 수 있다면 충분히 빠를까요?

이러한 제안 된 원칙 중 일부를 실제 문제에 적용하기 위해 ... 수평 슬라이스는 내가 작업 한 매우 실제적인 SaaS 개발 팀에서 매우 효과적이며 모든 계층에서 매우 어려운 기술적 문제를 해결하고 있다고 말합니다 ( 전문화가 엄청나게 중요하다고 생각되는 곳에서, 배달 빈도 (및 높은 세분성 / 빈도에서의 신뢰성)는 비즈니스 성공에 중요했습니다. 이 결론은 수평 슬라이싱의 우수성에 대한 일반적인 진술이 아니라 매우 특정한 실제 팀을위한 것입니다.

한 가지주의 사항 : 나는 아마도 몇몇 희귀 한 예외적 인 일반인을 알고 있었음에도 불구하고 현대 소프트웨어 개발 세계의 개인에 의한 일반주의 능력에 대한 믿음의 주장에 대해 상당한 증거없이 편향되어있을 수 있습니다. 나는 일반적으로 각 계층이 복잡해지고 대안 언어 / 플랫폼 / 프레임 워크 / 배치의 확산에 따라 각기 다른 요구를 충족함에 따라 일반성이 엄청나게 큰 순서라고 생각합니다. 요즘에는 모든 거래의 잭이 아무도 쉽게 마스터 할 수 없습니다. 또한, 일화 적으로, 나는 대부분의 개인이 약간의 예외를 제외하고는 꽤 전문화하기를 원한다는 것을 알았습니다.

내가 찾은 가장 큰 단점은 팀이 통합 된 아키텍처 접근 방식에 따라 응용 프로그램을 빌드하기가 어렵다는 것입니다.

프로젝트의 초기 단계에서 모든 사람들이 자신의 레이어를 따로 작성합니다. 스토리 (및 관련 레이어)는 작동하지만 스프린트 엔드에서 제공되는 제품을 되돌아 보면 각 개발자의 아키텍처 아이디어간에 약간의 차이가 있음을 쉽게 알 수 있습니다.

이런 종류의 것은 불가피하지만 차단제는 아닙니다. 나는 두 가지 방법으로 이것을 싸우려고 노력했다.

1. 각 스토리를 구현하기 전에 팀과 긴 디자인 토론
   • 이것은 빨리 피곤해집니다. 누군가가 정보에 입각 한 결정을 내리기에는 너무 이르다가 결국에는 반드시 바뀌어야 할 것들에 대해 논쟁하게됩니다.
2. 계속해서 기술적으로 부채를지고 있음을 명심하고 상대적으로 고립 된 상태로 개발하십시오 .
   • 여기서 핵심은 기술 (건축) 부채를 문제로 기록하는 것입니다. 이것은 상환되어야 할 것입니다.
   • 몇 번의 스프린트 후 일관성 있고 통일 된 아키텍처를 결정하는 것이 더 쉬울 것입니다. 이것은 기술 부채의 일부를 상환하기 위해 강화 스프린트를 요청해야 할 때입니다 (기존 코드 리팩터링). 또는 프로젝트의 다음 반복에 대해 단편적으로 상환 할 수 있습니다.

내가 생각할 수있는 유일한 다른 문제는 일반적으로 프로젝트 초기에 추가 할 상용구 코드가 많이 있다는 것입니다. 수직 슬라이스 스토리를 작성한다는 것은이 전제 조건 보일러 플레이트로 인해 처음 몇 개의 스토리에서 팀의 속도가 인위적으로 낮다는 것을 의미합니다.

나는 어떤 단점도 모르지만 세로 이야기는 잘못 구현 될 수 있습니다.

내가 처음 커리어를 시작했을 때 나는 XP를하고 싶어하는 팀에 합류했지만 경험이 없었습니다. 수직 사용자 스토리를 사용할 때 많은 실수를했습니다.

수평 작업을 할 때 우리가 겪었던 문제 중 하나는 기능이 여러 계층에 잘 통합되지 않았다는 것입니다. API는 종종 사양, 누락 된 기능 및 기타 여러 문제와 일치하지 않습니다. 종종 개발자가 다른 것으로 이동했기 때문에 기다릴 수도 있고 직접해야 할 수도 있습니다.

Vertical Stories로 전환하면 이러한 문제를 해결하고 재 작업 낭비를 줄이거 나 없앨 수있었습니다.

이러한 작업 방식을 지원하는 여러 가지 XP 관행이 있습니다. 누구나 어떤 영역에서든 작업 할 수 있어야하며 모든 사람이 찾은 버그를 수정해야합니다 ( 집합 적 코드 소유권 ).

세로 이야기를 변경할 때는 익숙하지 않은 영역에서 작업하기가 까다로울 수 있습니다. 자신과 짝을 이루는 팀원을 확신하지 못하면 페어 프로그래밍 이 도움이 될 수 있습니다. 페어 프로그래밍이 새로운 코드 기반으로 가장 빠른 속도를 얻는 방법이라는 것을 알았습니다.

우리가 발견 한 레이어에 대한 강력한 소유자가 없으면 중복이 발생했습니다. 이것이 큰 문제는 아니지만, 우리는 무자비 하게 리팩터링 (적절한 테스트를 통해 지원)을 수행해야했습니다.

여러 가지 문제를 언급했지만 Vertical User Stories가 원인이라고 생각하지 않습니다. 사실, 문제가 더 분명해졌습니다. 전환 한 후에는 팀이나 응용 프로그램 계층에서 문제가 더 이상 난독 화되지 않았습니다.