개발자간에 사용자 스토리를 공유해야합니까? [닫은]

나는 일반적으로 백엔드 및 프론트 엔드 개발이있는 이야기를 봅니다. 예를 들어, 몇 개의 테이블과 일부 동적 컨트롤이있는 큰 대화 상자를 고려하십시오. 우리는 몇 가지 이야기를 만들 것입니다 (각 테이블마다 다이나믹 제어 시스템에 대해 하나씩).

그런 다음 개발자 팀은 백엔드에서 한 사람과 프런트 엔드에서 다른 사람으로 나눕니다. 이를 통해 백엔드 사용자는 SQL 계층의 구조에 대해 쉽게 걱정할 수 있고 프론트 엔드 사용자는 레이아웃과 같은 것에 집중할 수 있습니다. 백엔드와 프론트 엔드 사이의 초기 인터페이스가 합의 된 후 두 개발자는 스프린트가 끝날 때까지 자신의 역할에 집중할 수 있습니다.

그런 다음 혼란이 온다. 누가 어떤 이야기를 "소유"합니까? "진행 중"은 무엇을 의미합니까? 백엔드와 프론트 엔드에 대해 두 개의 스토리를 만들어야합니까? 그렇다면 기능을 기반으로 한 사용자 스토리의 아이디어를 깨뜨리지 않습니까? 우리 시스템에는 "하위 작업 (sub-task)"이라는 개념이있어 이러한 문제 중 일부를 완화시킵니다. 그러나 하위 작업은 추가 복잡성을 추가합니다. 더 좋은 방법이 있습니까? 이것이 스크럼을 사용하는 "나쁜"방법입니까?

지난 몇 년 동안 몇 곳에서 어떤 형태의 애자일을 사용해 왔습니다. 아직 공식적인 교육이 없기 때문에 잘못된 용어 나 이념을 용서하십시오. 프로세스 개선을위한 실용적인 방법을 배우려고합니다.

"스토리"는 고객의 관점에서 완전한 이야기를 나타 내기 때문에 그렇게 명명되었습니다 . 프론트 엔드 또는 백엔드가 없으면 고객이 실행할 유스 케이스 경로가 없습니다.

귀하의 경우에는 프론트 엔드와 백 엔드가 모두 하나의 이야기라고 생각합니다. 작업으로 나눕니다. 개발자는 서로 다른 작업을 소유합니다. 이러한 작업은 진행 중, 코딩 완료, 모듈 테스트 완료 등의 단계를 통해 개별적으로 추적 할 수 있습니다.

동일한 스토리에 QA 할당 작업을 포함시켜야합니다. 유효성 검사없이 스토리는 쓸모가 없습니다. QA는 고객이 보게 될 엔드 투 엔드 통합 스토리를 테스트합니다. 그래야 전체 스토리가 완료로 표시되어야합니다. 이상적인 민첩한 환경에서 실제 고객 또는 고객 프록시는 실행중인 응용 프로그램에서 스토리를 시도하고 동의 한 요구 사항을 충족하면 Accepted 스토리를 표시합니다.

더 빠른 피드백 루프를 원한다면 유스 케이스를 더 작은 엔드 투 엔드 기능으로 나누십시오. 예를 들어, "고객은 장바구니를 사용하여 물건을 구입할 수 있습니다"와 같은 유스 케이스 대신 "고객은 장바구니에 제품을 추가 할 수 있습니다"등으로 나눕니다. 그런 다음 각 작은 유스 케이스를 완료하십시오. 위에서 설명한대로 끝에서 끝까지.

편집 : 일부 소스로 위의 포인트를 백업하고 싶었습니다. 좋은 사용자 스토리의 특징은 " INVEST " 라는 약어로 간결하게 표현 됩니다. 빌 웨이크 (Bill Wake)가 제작했으며 스크럼 운동으로 대중화되었습니다. 특히 이야기에 관한 항목은 독립적이고 수직적입니다.

여기 와 여기에 더 많은 정보가 있습니다 .

누가 어떤 이야기를 "소유"합니까?

누구든지 그 이야기를 듣습니다. 조직의 관점에서 핵심은 한 사람이 작업을 담당한다는 것입니다. 두 사람이 있으면 벅을 통과하기가 너무 쉽습니다.

백엔드와 프론트 엔드에 대해 두 개의 스토리를 만들어야합니까? 그렇다면 기능을 기반으로 한 사용자 스토리의 아이디어를 깨뜨리지 않습니까?

따라 다릅니다. 나는 두 가지 방식으로 작동하는 것을 보았다. 이야기가 두 명의 개발자가 풀 타임으로 일할 수있을만큼 충분히 크다면 아마도 분리되어야 할 것입니다. 두 개발자가 서로 다른 두 팀의 일부인 경우 분할해야합니다. 두 개발자가 서로 다른 스프린트 동안 작업 할 경우 분할해야합니다.

이것이 스크럼을 사용하는 "나쁜"방법입니까?

기억해야 할 열쇠는 그 과정이 당신에게 봉사하는 것이지 그 반대가 아니라는 것입니다. 사용자 스토리는 기술 담당자와 비 기술 담당자가 의사 소통을 용이하게하는 방법입니다. 그들은 자신이 원하는 것을 철자하고, 모든 사람들이 협상 한 다음, 진행 상황에 대한 피드백을 제공합니다.

프로세스가 효과가있는 한 그렇게 나쁘지 않습니다.

Scrum 모델을 구현 한 경우 여러 개발자가 단일 사용자 스토리에 참여할 수 있습니다. 데이터 계층, 통합, 프런트 엔드 CSS, 인프라 등을위한 작업이있을 수 있습니다. 팀은 스토리를 완성하기 위해 다양한 하위 작업을 함께 묶을 수 있습니다.

즉, 한 사람 이 이야기를 소유 하고 이야기의 진행 상황을 업데이트하고 모든 사람들이 자신의 작품을 완성하고 함께 일하도록 보장해야합니다. 이야기가 "완료"되었다고보고하는 사람입니다.

다른 사람들이 제안한 것처럼, 우리 팀은 또한 사용자 스토리를 작업으로 나눕니다. 소프트웨어 (JIRA 또는 Rally 등)를 통해 사용자 스토리를 관리하는 경우 일반적으로이 작업을 수행하기가 쉽습니다. 그러면 이야기의 어떤 부분이 움직이고 있는지 쉽게 알 수 있습니다.

그러나 작업의 대안은 각 사람이 자신의 역할을 마칠 때 소유권을 다시 할당하는 것입니다. 따라서 이야기 1은 개발자 1이 백엔드 작업으로 시작한 다음 개발자 2에게 전달하여 UI를 수행합니다. 그런 다음 확인을 위해 품질 보증 테스터에게 전달됩니다. 이 방법은 벽에 실제 카드를 사용하거나 소프트웨어가 작업을 추적하지 않는 환경에서 잘 작동합니다.

그러나 어떤 경우에도 팀이 테스트를 포함하여 완료되었다고 동의 할 때까지 이야기를 "완료"라고 부르지 않는 것이 좋습니다. 그렇게하면 모든 사람이 자신의 의견을들을 기회가 있습니다. 이 코드를 집단 코드 소유권 및 코드 검토에 대한 아이디어와 결합하면 팀은 모든 스토리를 실제로 "소유"합니다. 그것은 길을 따라 다른 사람들에게 "지정"될 수 있지만, 누군가가 아프면 (아픈 / 휴가 / 너무 많은 회의? / 다른) 작업은 여전히 ​​끝날 수 있습니다.

우리 팀은 종종 아침 서기 / 스크럼 회의의 일환으로 사용자 이야기를 받아들입니다. 그렇게하면 모든 사람이 실제로 "완료"되었는지 쉽게 확인하거나 이의를 제기 할 수 있습니다. 다른 경우에는 QA 엔지니어가 테스트를 수행하고 작업이 완료되고 모든 작업이 완료된 것으로 만족하면이를 완료한다고합니다.

오늘 저는이 큰 프로젝트를 "서사시"라고 부릅니다. 서사시는 여러 이야기로 구성되며 여러 스프린트 / 반복에 걸쳐있을 수 있습니다. 우리에게 이야기는 항상 단일 개발자에게 제공되며 단일 스프린트에 적합해야합니다. 그런 다음 단일 스토리를 작업으로 세분화합니다. 각 작업은 해당 스토리에서 동일한 개발자가 완료합니다. 작업은 스프린트 / 반복 동안 스토리의 진행 상황에 대한 통찰력을 제공하기위한 것입니다. 각 이야기가 완성되면 각 개발자가 서사시 진행 상황을 보여줍니다.

서사시의 요점은 단일 스프린트 / 반복에 반드시 맞지 않는 더 큰 목표를 갖는 것입니다. 시간이 지남에 따라 모든 이야기가 완성되고 서사시가 완성됩니다. 서사시가 석방됩니다.

그런 다음 혼란이 온다. 누가 어떤 이야기를 "소유"합니까? "진행 중"은 무엇을 의미합니까?

스프린트 / 반복에 대한 이야기를 이해 당사자에게 보여주고 승인해야하는 2 주마다 코드를 시연합니다. 이러한 맥락에서 이야기에 대한 "완료"는 내가하는 일을 보여줄 수 있음을 의미합니다. 개발자는 자신의 이야기를 소유하고 있으며이를 보여줄 책임이 있습니다 (이 부분은 지나치게 단순화되었지만이 답변에는 충분합니다. 우리는 한 사람을 통해 데모를 조정합니다). "완료"는 성공적으로 시연 될 수 있음을 의미합니다. "진행 중"은 작업이 탁월하고 스토리가 완료되지 않았 음을 의미합니다. 서사시의 모든 이야기가 성공적으로 시연되면 서사시가 완성됩니다.

이제 이것은 완벽한 사례 진행입니다. 우리는 실패한 이야기와 데모, 다른 것을 원하는 사용자 등을 가지고 있습니다. 위의 목표는 대부분의 경우 효과가 있습니다.