우리는 현재 JIRA를 사용하여 개발 작업을 추적합니다. 경영진은 비 소프트웨어 개발 관련 작업을 포함하여 모든 것을 "사용자 사례"로 형식화하고 분류하려고합니다. 예를 들면 다음과 같습니다.

"테스트 관리자는 가능한 한 효율적으로 응용 프로그램을 테스트 할 수 있도록 자동 테스트 만 사용하고 수동 테스트는 사용하지 않고 응용 프로그램 테스트를 수행 할 수 있습니까?

수락 기준 : 1. 기존의 수동 테스트 50 개를 완전 자동화 된 테스트로 변환합니다. 2. 테스트는 1 시간 이내에 실행되어야합니다. "

소프트웨어 개발 프로세스를 지원하고 프로그래머가 수행하지 않으며 직접 코드를 제공하지 않는 작업에 "사용자 사례"를 사용하는 것이 합리적이라면 커뮤니티에서 이해하고 싶습니다. 아니면 다르게 처리 / 분류해야합니까 (예 : JIRA)?

2011 년 6 월 7 일 업데이트- "사용자 스토리"용어에 초점을 맞추는 질문을 수정했습니다.

예

이해 관계자, 시스템을 개선하는 모든 기능

[순수한 다운 보트를 시작하자!]

"내 경영진은 비 소프트웨어 개발 관련 작업을 포함하여 모든 것에 애자일을 사용하려고합니다."

모든 기능에 대한 사용자 스토리를 작성하는 것은 아닙니다 .

모든 기능에 대한 사용자 스토리를 작성하려면 반드시 애자일 필요 는 없습니다 . 모든 기능에 대한 사용자 스토리를 작성하고 있습니다.

사용자 스토리! = 민첩합니다.

사용자 사례는 요구 사항을 수집하고 이해하는 방법입니다. 원하는 경우 완벽하게 폭포 방식으로 사용할 수 있습니다. 어떤 사람들은 이것을합니다.

애자일은 프로젝트를 관리하는 방법입니다. Agile 프로젝트에서 User Stories를 사용하거나 사용하지 않을 수 있습니다.

기술적 부채 및 내부 작업을 관리하는 사용자 스토리는 다시 민첩성과 관련이 없습니다.

많은 사람들은 순전히 내부의 제한된 가치가 부가되고 이해 관계가없는 사용자를 위해 가짜 "사용자 스토리"를 작성하는 데 시간을 낭비하지 않고 "기술적"또는 "지원"기능을 스프린트에 추가하는 것을 매우 기쁘게 생각합니다.

QA가 스토리를 얻지 못하면 실제 비즈니스 손실은 얼마나됩니까?

실제 이해 관계자가 자신의 이야기를 얻지 못하면 비즈니스는 진정으로 고통을받습니다.

이것은 나에게 이해가되지 않습니다. 본질적으로 '사용자 스토리'는 품질 보증 엔지니어 스토리가 아닌 개발자 스토리가 아닌 프로젝트 관리자 스토리가 아닌 사용자 스토리입니다.

이 메모에서 소프트웨어는 다음과 같습니다.

1. 정의 가능
2. 테스트 가능

공정 개선은 일반적으로 주관적입니다.

수락 기준 : 1. 테스트 1 개선 (x / y 기준)

테스트 개선을 어떻게 측정합니까? 이에 대한 정의 가능한 계약이 없습니다.

그리고 관련이없는 쪽지에서 나는 당신의 모범이 위에 주어진 것을 진심으로 바랍니다.

테스트 관리자는 가능한 한 효율적으로 응용 프로그램을 테스트 할 수 있도록 자동 테스트 만 사용하고 수동 테스트는 사용하지 않고 응용 프로그램 테스트를 수행 할 수 있습니까?

... 이것은 단지 예입니다. 왜냐하면 이것에 너무 잘못되어서 설명조차 할 수 없기 때문입니다.

기술 부채 는 사용자 스토리와 비슷한 방식으로 처리 될 수 있지만 때때로 추악해질 수 있습니다. 예를 들어, "개발자로서 작업 단위 테스트를 원하므로 다른 변경 사항으로 인해 문제가 발생하는지 확인하는 테스트에 대한 확신을 가질 수 있습니다." 그러나 스프린트 작업의 일부인 자체 리팩토링의 일부로 팀이 수행하는 것이 좋습니다.

작업은 시스템의 최종 사용자에게 보여주지 않지만 유지 관리 및 시간을 단축하는 데 도움이 될 수 있기 때문에 사용자 스토리와 별개의 작업을 갖는 아이디어가 좋습니다. 새로운 기능을 개발하십시오. 몇 개의 작업이 2 분일 수 있고 다른 작업이 2 주일 수 있으므로 전체 포인트 총점으로 몇 개의 작업에 따라, 팀이 스프린트를 취하고 새로운 기능을 넣지 않았지만 작동하는지 결정하는 것일 수 있습니다. 내가 일하는 곳에서 몇 번 본 것들을 정리하는 일에

제 생각에는 프로세스 개선 작업뿐만 아니라 소프트웨어가 아닌 개발 프로젝트에 사용자 스토리를 사용할 수 있습니다. 예를 들어, 3 년 전 저는 친구의 결혼식에서 최고의 남자 였고 결혼 계획을 위해 애자일 방법론과 사용자 스토리를 사용했습니다. 우리가 완료해야 할 모든 작업은 각 사용자 스토리에 대한 페르소나, 의도, 정당성 및 성공 기준을 가진 사용자 스토리로 작성되었습니다. 관련된 모든 당사자는 전날 스크럼에 참여하여 전날에 한 일과 그 날에 할 일에 대해 논의했습니다. 모든 사람들이 지리적으로 분산되어 있었기 때문에 우리는 일일 스크럼 회의, 스프린트 계획, 회고전, 이야기 쓰기 및 평가 세션을위한 전화 회의를 열었습니다. 우리는 총 6 회 (3 개월)의 스프린트를 보냈으며 결혼식은 돌을 돌리지 않은 채 놀라운 성공을 거두었습니다.

내부 "사용자 스토리"를 실제 사용자 스토리와 혼합 할 때 심각한 문제가 있습니다.

찾을 수있는 한 "이해 관계자"에 대한 많은 정의를 다시 읽으십시오.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

닭과 돼지의 차이를 볼 수 있도록 매우주의해서 읽어보십시오.

내부 "사용자 스토리"는 닭에 의해 작성됩니다.

실제 사용자 스토리는 돼지에 의해 작성됩니다.

"치킨 지향"사용자 스토리는 그리 중요하지 않습니다. 실제 가치가있는 실제 사용자 스토리 인 것처럼 관리하려는 경영진의 수에 관계없이 실제 사용자 스토리가 아니며 동일한 방식으로 가치를 창출하지 않습니다.

논쟁의 모호한 부분에는 QA 문제가 있습니다. 품질 관리는 중요하며이 기능이 없으면 아무 효과가 없습니다.

그것은 마술처럼 QA를 갑자기 돼지로 만들지 않습니다. 여전히 이해 관계자가 아닙니다. 이들은 나머지 작업에 대한 지원, 인프라 및 필수 토대를 제공합니다. 그러나 "사용자 스토리"는 실제 사용자의 실제 사용자 스토리와 본질적으로 다릅니다.

QA가 테스트 개선 테스트를 표시하지 않으면 아무도 비즈니스를 중단하지 않습니다. 돈이 손실되지 않습니다.

사용자가 처음에 비즈니스를 수행 할 수없는 경우 비즈니스가 종료 된 것입니다. 돈이 없어졌습니다. 전체 작업은 전체 실패입니다.

내부 ( "치킨") 및 실제 ( "돼지") 이해 관계자를 혼동하지 마십시오.

"닭과 돼지"의 의견은 요점을 놓치고 있습니다. 내부 이해 관계자는 개발중인 제품과 관련하여 닭이지만, 개발 과정에서는 돼지입니다.

당신이 묻는 질문은 "As a , 나는 할 수 있기를 원합니다 _ _ _ 수 있도록 __ "은 (는) 개선에 새 소프트웨어 코드 작성이 필요하지 않은 비즈니스 프로세스를 정의하고 개선하는 데 유용합니다. 동일한 작업을 생각하고 모범 사례를 찾고 있기 때문에이 스레드를 사용했습니다. 나의 강한 직관은 당신의 질문에 대한 대답이 "예"라는 것입니다. 문장 구조의 목적은 실제로 작가가 이미 염두에두고있을 수있는 솔루션을 추상화하고 사용자가 무엇에 초점을 맞추도록하는 것입니다. 프로세스 사용자가 할 수 있기를 원합니다 프로세스에 적용될 때 사용자 스토리가 유용하지 않은 이유는 없습니다.

수용 기준에 관한 요점은 좋은 것이지만 그것에 대해 독단적 일 필요는 없다 (어쨌든 민첩하다). 비즈니스 프로세스를 설계 할 때 "프로세스 변경이 목표를 달성했는지 어떻게 알 수 있습니까?"라는 질문을하는 것이 좋습니다. 해당 질문에 답하기 위해 항상 자동 테스트를 실행할 수는 없지만 사용자 스토리를 도구로 실격시키는 이유는 아닙니다.