스크럼에서 "기술 사용자 스토리"가 허용됩니까?

Scrum에서 기술 사용자 스토리가 허용됩니까? 그렇다면 Scrum에서 기술 사용자 스토리를 작성하기위한 표준 템플릿은 무엇입니까? 같은가요 As a <user> I want to do <task> so that I can <goal>??

필자는 일부 블로그에서 개발자로서 사용자 가 아님을 읽었지만 Scrum이이를 강제하지 않는다는 것도 읽었습니다. 그들이 공유 한 몇 블로그가 있습니다 사용자로 시스템에 사용자 스토리를 그 등 as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. 그렇다면 어느 것이 표준입니까?

예를 들어 다음과 같은 사용자 사례가 있습니다.

리뷰어로서 다른 사용자가보고 좋아할 수 있도록 모든 호텔 / 음식의 사진을 업로드하고 싶습니다

사용자로서 내 의견을 더 잘 설명 할 수 있도록 사진 설명을 추가하고 싶습니다

이제이 두 가지 사용자 스토리에는 큰 기술 항목이 있습니다. 이미지 저장 및 검색

다음 설명과 함께 "이미지 저장 및 검색 메커니즘"이라는 기술 스토리를 추가 할 수 있습니까?

개발자로서 이미지를 저장하고 검색하는 메커니즘을 개발하여 사용자가 필요한 곳에서 이미지를 추가 /보기

기술적 인 이야기는 허용되지만 가능한 한 많이 피하는 것이 좋습니다.

예를 들어 이미지 저장 및 검색에 대한 이야기는 두 가지 일반 사용자 스토리로 쉽게 작성할 수 있습니다.

1. 검토 자로서 업로드 한 사진을 지속적으로 저장하여 다른 사용자가 언제든지 볼 수 있도록하고 싶습니다.
   (이는 원본 업로드 스토리에서 이미지가 업로드 후에 영구적으로 저장되지 않는다고 가정합니다. 이상하게 보일 수 있지만 스토리를 분리하여 관리하기 쉽게 만드는 방법입니다.)
2. 사용자로서 편리한 업로드 이미지를 한 번에보고 싶습니다.
   이것은 저장된 이미지를 나중에 검색 할 수 있음을 의미합니다.

기술 스토리는 조직에 중요하지만 사용자에게 기능으로 직접 표시되지 않는 작업을 위해 예약해야합니다. 예를 들어, 더 많은 수 또는 요청을 처리하기 위해로드 밸런싱 추가.

특정 예를 들어, 질문은 개발자가 이미지를 저장하거나 검색하는 메커니즘을 개발하여 사용자가 이미지를 추가하거나 보지 않으려는 경우 필요에 따라 이미지를 추가하거나 볼 수있는 메커니즘을 개발하려는 이유는 무엇입니까?

즉, 귀하의 질문은 좋은 것이지만 그 예는 그렇지 않습니다. 이것은 사용자 기능이며 사용자 스토리가 있어야합니다. 그리고 사용자가 실제로 해당 기능이 필요하지 않은 경우 개발자는 원하지 않아도됩니다.

기술적 인 이야기는 "개발자로서 데이터 보관 모듈의 중복을 줄이고 6 개 장소에서 모든 변경을 수행 할 필요가 없습니다."

스프린트에 포함시켜야하는지에 대한 질문은 어려운 것이며, 그것은 당신이 당신의 고객이라고 생각하는 사람에 따라 다릅니다. 최종 사용자입니까, 아니면 귀하를 고용 한 회사입니까, 아니면 귀하를 고용 한 회사입니까?

컨설팅 회사에서 일하는 사람들이 많은 업계 의견 안내를합니다. 그런 관점에서 개발자의 이야기가 나쁘다는 주장을 볼 수 있습니다. 그들은 당신이하는 일의 일부일 뿐이며, 그것을 지불하는 회사에게는 보이지 않습니다. 이 회사들은 청구서를 너무 높이 올리면 작업이 건조 될 수 있으므로 모든 개발자가 개발 시간을 향상 시키거나 버그가없는 소프트웨어를 출시하는 능력을 향상시키는 기술 개발 만하는 원칙에 따라 작업합니다.

내 경험은 사내 팀에서 일하면서 임금을 지불하는 회사에 직접 소프트웨어를 제공하는 것입니다. 많은 회사에서 비즈니스와 비즈니스의 기술 측면 사이에 신뢰 장벽이 있습니다. 이 모든 것에는 비용을 줄이는 것이 수입을 늘리는 것과는 다른 사고 방식이 있습니다.

이러한 환경에서는 중요한 개발자 스토리를 정의하는 것이 좋습니다. 가시성을 높이고 신뢰를 유발하며 개발자와 경영진이 비즈니스에 대한 이러한 작업의 가치에 대해 생각하고 그에 따라 우선 순위를 정하도록 권장합니다.

궁극적으로 시도해 볼 것을 제안합니다. 그리고 그것이 가치를 제공하지 않는다면, 그만하십시오.

그러나 내 본능에 따르면이 개발의 가치를 비즈니스에 고려하고 있다면 개발자 이야기로 만들려고조차하지 않았을 것입니다. 최종 사용자에게 좋거나 그렇지 않습니다. 그렇지 않은 경우 비즈니스에 가치가 없습니다.

좋은 질문입니다. 나는 공식적인 대답이 없지만 내가 일하는 곳에서 기술 사용자 이야기를 추가하고 기술 부채라고 부릅니다. 만약 그들이 허락되지 않았다면, 나는 단지 내 작업을 기록하고 비즈니스에 알리는 목적으로 추가 할 수있는 다른 방법을 찾을 것입니다. 마찬가지로,이 문서를 가지고 있으면 향후 프로젝트에 필요한 것이 무엇인지 생각 나게됩니다.

예를 들어, 기술 애플리케이션을 추가 할 수없는 경우 새 애플리케이션의 연결 끊기는 데이터베이스 모델을 작성하고 데이터 모델러가 승인하기를 기다리는 스프린트가 시작된 후 일주일 동안 윙윙 거릴 것입니다. 그것들은 모델러와 함께 반복되며 완료되면 스크립트를 dba로 보내고 db 객체를 생성하기를 기다립니다. 그 동안 새 코드 프로젝트, 일부 기본 ORM 기능 및 소스 제어 레이아웃을 작성하고 모든 사항을 말하고 완료하면 하나의 빈 방문 페이지를 작성하고 배치 할 시간이 있습니다.

이 일이 진행되는 동안 매일 정보를 기록하지 않으면 실제로 우리 팀이 프로젝트를 진행하지 않고 있다는 사실이 비즈니스에 어렴풋이됩니다. 이야기에 이러한 항목을 포함한다는 것은 업무를 점검하고 업무를 문서화했으며 진행중인 비즈니스에 알리는 것을 의미합니다.

이 작업을 수행하는 가장 좋은 방법이 있다면 나는 모두 귀입니다.

내 개인적인 느낌은 팀이 스크럼이 허용하는 것에 너무 매달리지 않아야하고 팀에 무엇이 효과적인지 더 걱정해야한다는 것입니다. 스크럼이 약간 나쁜 평판을 얻은 이유 중 하나는 실무자들이 민첩한 프로젝트 관리의 아이디어에 반하는 프로세스 중심 이 될 수 있기 때문 입니다.

나는 지금 내 soapbox에서 벗어날 것입니다. 그러나 아래가 실제로 '스크럼'인지 궁금한 경우 위의 내용을 다시 읽으십시오.

사용자 스토리에서 정의한 '기능'과 해당 기능을 지원하기 위해 기술 팀이 제공해야하는 '제공 물'을 분리하는 것이 중요합니다. 이 경우 사진을 저장하고 검색해야하는 것은 기술 팀으로서 구현해야하는 기술 결과물입니다. 거의 모든 이야기에는 기술적 인 결과물이 필요합니다.

이것이 중요한 이유는 기술적 인 결과물 자체가 사용자 관점에서 가치를 창출하는 것이 아니기 때문입니다. 기술 결과물을 사용자 스토리로 추적하기 시작하면 기술 결과물을 비즈니스 가치 생성으로 취급하는 함정에 쉽게 빠질 수 있습니다. 이런 식으로 물을 진흙탕으로 던지면 사업 목표 (예 : 돈이 드는 것)를 지원하는 일과 실제 사업 목표 (예 : 돈을 버는 것)가 혼동됩니다.

위의 모든 답변은 Scrum 프레임 워크에 대한 신뢰할 수있는 소스 문서 : Scrum Guide 를 참조하지 않습니다 .

제품 백 로그에는 향후 릴리스에서 제품의 변경 사항을 구성하는 모든 기능, 기능, 요구 사항, 개선 사항 및 수정 사항이 나열됩니다.

가치 창출에 중점을 두어야합니다. 때로는 그 가치가 인프라 업그레이드와 같은 기술 작업에서 비롯됩니다. 해당 항목을 제외하지 마십시오!

사용자 스토리 라는 용어 는 Scrum Guide에 나타나지 않습니다.

다양한 프로세스와 기술을 사용할 수있는 프레임 워크입니다.

사용자 스토리를 사용하는 것은 PBI를 기록 할 수있는 기술 중 하나 일뿐입니다. "As a, I want, So that"형식을 보는 것이 일반적이지만, 원래 의도에 맞지 않을 수 있습니다 . 이 번거로운 형식은 Agile 2017 .

수직 슬라이싱을 이해하고 활용 하면 PBI (제품 백 로그 항목)의 크기를 줄이는 데 도움이됩니다. 그 하나의 슬라이스 고려 저장 및 검색 에 항목을 저장 하고 검색 할 항목 들 .