개발자가 사용자 스토리에 대해 얼마나 자세하게 설명 할 수 있습니까?

내가 경험 한 민첩한 개발의 가장 큰 단점은 개발에 관여하지 않는 사람들이 사용자 스토리 (3-10 이상적인 사람의 날)에 다음과 같은 1-3 문장을 포함해서는 안된다는 만트라에 중점을 둡니다.

고객은 자유 텍스트 검색을 사용하여 원하는 제품을 찾을 수 있습니다.

이 문장을 주면서 프로젝트 관리자는 개발자로서 저에게 견적을 제시하고 스토리를 개발할 것을 기대합니다. 그들은 민첩한 개발이 이와 같은 문장이 개발자에게 제공해야하는 전부임을 의미한다고 가정합니다.

민첩한 개발에 대한 잘 알려진 문헌이 이것이 실제로 효과가있을 것이라는 인상을주기 때문에 나는 그들을 비난하지 않을 것입니다. "Planning XP"에서 스토리 당 2 페이지 정도의 자연어를 읽었지만 그게 전부입니다. "포괄적 인 문서"보다 "작동 소프트웨어"가 선호되므로이 주제는 일반적으로 피해야합니다.

물론 개발자가 그렇게 할 기회가 주어지면 고객과의 인터뷰에서 고객이 이야기에 대한 요구 사항을 나열합니다.

• AND 및 OR과 같은 부울 연산자가 필요합니다.
• 모든 용어에 대한 퍼지 검색이 필요합니다.
• 우리는 문구뿐만 아니라 한 단어로도 검색해야합니다.
• X, Y 및 Z 기준을 충족하는 제품을 찾고 싶지 않습니다.
• 결과를 정렬하고 싶습니다. 아, 그리고 사용자는 옵션 a, b 및 c가있는 콤보 상자에서 정렬 기준을 선택할 수 있습니다.

따라서 기술적 세부 사항이나 소프트웨어 디자인 또는 구현 세부 사항에 대해 이야기하고 있지 않습니다. 순수한 요구 사항입니다. 더 오래 이야기할수록 고객은 실제로 원하는 것에 대해 말할 것이 많다는 것을 깨닫게됩니다.

그러나 종종 나는 그러한 정보가 제공되지 않거나 매우 조잡한 방식으로 자신을 발견합니다. 면접을 할 가능성도없고 면접을 맡을 사람이 저에게 그 결과를 제공하지도 않습니다.

때때로 관리자는 "우리는 Lucene 검색을 원합니다"와 같은 기술적 인 세부 정보를 제공하지만 제품 이름 또는 제품 설명 만 찾고 싶을 때는 생각하고 싶지 않습니다. 때때로 나는 그들이 단지 게으른 생각합니다;)

나에게 이것은 내가 일하는 프로젝트 (e-business 웹 응용 프로그램, 프로젝트 당 500-2000 일)의 가장 큰 문제입니다. 나는이 문제를 자주 해결했으며 관리자는 대부분의 개발자가 상황에 문제가 있음을 알고 있습니다. 그러나 그들은 개발자가 너무 많은 "완벽 주의자"라고 믿는다. 그들은 개발자들이 "항상 모든 것을 명시하기를 원한다"고 성가신 것으로 보인다.

일반적으로 인정되는 숫자가 없기 때문에 논쟁하기가 어렵습니다. 모든 사람들은 반복이 얼마나 오래 걸리는지 알고 있습니다. 그러나 스토리를 추정하고 개발하는 데 얼마나 많은 요구 사항이 필요한지 알 수 없습니다.

당신은 몇 가지 참조가 있습니까?

민첩성의 요점이 조금 빠져 있습니다. 당신이 전화 무엇 한 마른 검색하고 총알 포인트 각각에 대해 하나 사용자 스토리를, 나는 적어도 6으로 참조하십시오. 꼭 나가기에는 비용이 많이 드는 코너에 자신을 그리는 것을 피하기 위해 충분한 계획을 세우십시오. 그러나 모든 아이디어는 가치를 제공하는 데 필요한 최소값을 제공하고 빠른 피드백을 얻을 수 있도록 충분히 빨리하는 것입니다.

스토리를 이와 같이 나눌 경우 추정하기가 쉬워 질뿐 아니라 제품 소유자가보다 세분화 된 방식으로 우선 순위를 지정할 수 있습니다. 확실히 그들은 검색 결과를 정렬하는 기능을 좋아하지만 백 로그의 다른 항목만큼 검색과 전혀 관련이없는 것은 중요하지 않을 수 있습니다.

또한 지정된 모든 것을 필요로하는 프로그래머의 생각에 따라 고객의 관점에서 살펴보십시오. 많은 경우, 자동차를 사러가는 것처럼, 세일즈맨은 앞 유리 와이퍼 노브에 대해 원하는 색상을 요구합니다. 우리가 중요하다고 생각하는 많은 세부 사항은 고객의 관점과는 전혀 관련이 없습니다. 요구 사항이 과도하게 지정된 곳에서 일한 적이 있으며 믿기 만해도 재미가 없습니다. 당신이 불평하는 위도의 종류, 많은 프로그래머들이 갖고 싶어합니다.

첫 번째 문제는 사용자 평가에 시간 추정치를 적용하지 않아야한다는 것입니다. 1에서 INFINITY까지의 복잡성을 일반적으로 추정하는 스토리를 작성하고 "스토리 포인트"를 적용해야합니다. 스토리 포인트는 종종 1,2,3,5,8,13,20 ... (모든 조직마다 고유 한 규칙이 있습니다.)과 같은 방식으로 실행됩니다.

1-당신은 당신의 수면에서 할 수 있으며 구현할 가치가 거의 없습니다. 2-당신은 이것을 이해하고 오버런 위험이 거의없이 신속하게 처리 할 수 ​​있습니다. 3-당신은 이것을 이해하지만 놀랍게도 1-2가있을 수 있습니다. 5-이것은 약간의 연구가 진행될 것이며 약간의 위험이 있습니다. 8-이것은 큰 작업이며 많은 연구가 필요하며 스프린트에 적합하지 않을 수 있습니다. 13-이것은 거대하며 스프린트에는 적합하지 않습니다. 큰 위험이 있습니다. 기타

일반적으로 8 이상의 사용자 스토리는 더 작은 스토리로 나누어야합니다.

이 작업을 수행 할 정보가없는 경우 프로젝트 관리자에게 정보를 다시 제공하고 추가 정보가 필요하다고 말해야합니다.

스프린트로 스토리를 수락 한 후에 만 ​​시간을 추정해야하지만, 그럼에도 불구하고 이에 대한 강조는 줄어 듭니다. 아이디어는 팀이 포인팅 프로세스에 익숙해지면 스토리 포인트에서 스프린트 당 대략적인 출력을 측정하고 계획을 세울 수 있다는 것입니다. 스프린트보다 짧은 시간 단위로 계획하고 싶지 않습니다. 여기서 아이디어는 여러 스토리가 스프린트에 적합하고 1-5 스토리 포인트 범위에 있도록 작업을 올바르게 분류하는 경우 충분히 정의되었음을 의미합니다.

또한 회사의 PM이 "스토리"가 무엇인지 이해하지 못하는 것 같습니다. "사용자 스토리"의 중요한 부분은 종료 기준입니다. 종료 기준은이 저장이 완료되었음을 표시 할 수있는 방법을 명확하게 설명하는 짧은 문장 또는 두 문장입니다. 이상적으로는 품질 관리 담당자가 "예, 테스트 할 수 있습니다"라고 말한 것이어야합니다. 중요한 점은 PM이 소프트웨어가 "종료 기준"을 충족하면 사용자 스토리가 완료되었음을 이해해야한다는 것입니다. "그러나 우리는 그것을 원하지 않았다"고 잘라 내지 않았다. 그들이 전달 된 것을 원하지 않았지만 출구 기준과 일치한다면 새로운 이야기를 입력해야합니다.

여기에는 "PM 교육"이라는 요소가 있습니다. 애매 모호한 이야기가 큰 이야기 포인트를 초래한다는 사실을 알아야하며, 원하는 것을 얻기 위해 이야기를 모호하게 정의했다면 다시해야한다는 것을 배워야합니다.

이해 관계자가 충분한 정보를 수집하지 않으면 분명히해야하고,해야 할 경우 훨씬 더 많은 일이 아닌가? 민첩한 시절이되기 훨씬 전에, 나는 추정치가 매우 크고 정보 부족으로 인한 위험을 허용하기에 추정치가 너무 크다고 명시 적으로 말함으로써 성공했습니다. 모든 질문에 대해 최악의 경우를 가정 하고이 최악의 경우를 기준으로 추정했습니다. 관리자가 더 많은 정보를 제공 할 때 더 많은 정보를 제공 할 의사가 있다는 것을 알게되었습니다.

이것은 시스템을 게임하는 것이 아닙니다 ... 이것은 완벽하게 유효합니다. 그것이 "A"인지 "B"인지 모를 경우, 엉덩이를 포괄 할 수있는 가장 큰 추정치를 기준으로 추정합니다.

내 경험에 비추어 볼 때, 내가 작업하고있는 많은 변경 사항이나 프로젝트가 바로이 문제를 처리합니다. Custom X는 무언가를 원하고 원하는 것에 대한 아이디어를 가지고 있지만 요구 사항에 대한 작은 전자 메일 만 제공합니다. 클라이언트가 원하는 것을 '정확하게'알지 못하기 때문입니다. 그렇기 때문에 대부분의 고객 서비스 부서 업무는 고객의 요구를 충족시키고 필요한 정보를 필터링하는 동시에 고객이 정말로 원하는 것이 무엇인지 또는 실제로 필요한 것이 무엇인지 예측하는 것입니다.

클라이언트가 (나를 위해) 웹 애플리케이션의 한 섹션에서 모든 전화 번호 목록을 반환하기를 원한다고 가정 해보십시오. 그들은 물리적 인 것, 논리적 인 것, 사람이나 위치에 할당 된 것 등을 의미하지 않습니다. 그들은 단순히 모든 전화 번호를 원합니다. 개발자로서 나는 거기에 앉아서 당신과 마찬가지로 고객에게 물어볼 12 가지 이상의 질문을 생각할 수 있습니다. 그러나 당신이 말한 것처럼 그것은 불가능합니다. 그렇기 때문에 제품과 고객을 잘 아는 우수한 고객 서비스 부서를 운영하는 것이 매우 중요합니다.

그런 종류의 전화가 고객 담당자에게 들어 오면, 고객에게 올바른 질문에 대한 답변을 요청하기 위해 무엇을 요구해야하는지 알면서 고객과 통화를 구체화 할 수 있습니다. 또한 고객이 과거에 요청한 내용을 미리 알고 있으며 고객에게 묻지 않고 무언가에 대해 '예'또는 '아니오'라고 말할 수있는 개발 시스템에 대해 충분히 알고 있습니다.

물론, 클라이언트와 클라이언트 서비스 모두 놓친 다른 것이 여전히 필요한 경우가 많지만 항상 일어날 것입니다. 당신의 목표와 클라이언트 서비스의 목표는 무언가를 개발하고 변경이 필요한 클라이언트로부터 그것을 얻는 것 사이의 지연 시간을 최소화해야합니다. 그리고 이것은 고객 서비스와의 의사 소통과 훈련에 달려 있습니다.

어쩌면 그것은 내가있는 곳만큼 당신에게 실현 가능하지는 않지만 고객 담당자와의 의사 소통과 신뢰가 좋으면 거의 항상 정도에 따라 도움을 줄 것이므로 좌절감을 줄이고 고객 만족도를 높일 수 있습니다. 또한 어깨를 으 rug하고 "프로젝트의 전체 범위를 알지 못하므로 시간이 얼마나 걸리는지 모르겠습니다."라고 말하는 대신 프로젝트에 더 쉽게 기간을 정할 수 있습니다. 우리는 여기서 동일한 문제를 겪고 있으며, 더 나은 의사 소통과 훈련은 합리적인 마감일을 정하고 지속적으로 달성하는 데 도움이됩니다.

고객

제품을 검색하고 싶습니다

제품 관리자 나는 고객의 이야기를 분석하고 다음 요구 사항을 생각해 냈습니다. 각 요구 사항은 별도의 사용자 사례로 기록되었습니다.

• 제품 검색
• 결과 정렬
• 검색 결과 필터링

개발자 제품 관리자로부터 사용자 사례를 받았습니다. 각 사용자 스토리를 분석하고 각 사용자 스토리에 대한 작업 목록을 생각해 냈습니다.

• 제품 검색
  1. 작업 1 : 데이터베이스 변경
  2. 작업 2 : 서버 측 변경
  3. 작업 3 : 프런트 엔드 변경

이 과정에서 고객, 제품 관리자 및 개발자는 모두 이해 관계자입니다. 그들은 모두 작업을 시작하기 전에 분석 프로세스에 기여해야합니다. 이것은 매우 간단한 예입니다.

우리의 사용자 스토리는 다음 순서로 분석되고 구체화됩니다 (일부 변형이 있음).

헬프 데스크-> 제품 소유자-> 제품 관리자-> 부서 책임자 (고급 개발자, QA 리드 등)-> 개발자

모든 관련 이해 관계자가 분석 프로세스에 기여하면 스토리를 제공하는 데 얼마나 오래 걸립니까? 우리가 따르는 추정 프로세스는 개별 개발자의 속도와 전문 지식을 기반으로합니다.

나는 이것이 올바른 일을하는 방법이라고 말하지는 않지만 조직 내에서 실제로 잘 작동합니다.