사용자 사례를 채택 할 경우 요구 사항 사양이 필요하지 않다고 팀에 확신 시키려면 어떻게해야합니까?

우리는 무거운 SRS (소프트웨어 요구 사항 사양)가 아닌 가벼운 방식으로 이해 관계자 '의도'를 포착하기 위해 사용자 사례를 채택 할 계획입니다. 그러나 스토리의 가치를 이해하고 있지만 스토리를 모든 속성, 우선 순위, 입력, 출력, 소스, 대상 등을 사용하여 SRS와 유사한 언어로 '변환'하려는 욕구가 여전히있는 것 같습니다.

사용자 사례는 아티팩트와 같은 공식적인 SRS의 필요성을 '제거'하므로 SRS를 갖는 요점은 무엇입니까? 시스템의 기능적 요구 사항을 포착하기 위해 사용자 사례를 채택하면 SRS가 '제거'될 것이라고 팀 (교육 및 실무에 의해 자격을 갖춘 CS 직원)을 어떻게 확신시켜야합니까? (NFR 등도 캡처 할 수 있지만 문제의 의도는 아닙니다.)

여기에 나의 '작업 흐름'논쟁이 있습니다 : 초기 요구 사항을 사용자 스토리로 캡처하고 나중에이를 사용 사례 (예 : UI 프로토 타입 / mockups와의 상호 작용을 설명하고 배달 가능한 게시물)로 작성해야합니다. 전개). 따라서 사용자 사례에서 SRS로 전환하기보다는 사용자 사례에서 유스 케이스로 전환하여 유스 케이스로 전환합니다.

현재 직장에서 사용자 스토리를 어떻게 캡처하고 있습니까?

걸음마. 잠시 동안 SRS를 계속 작성하십시오. 그런 다음 모임에 전화하여 그들이 여전히 목적을 달성하는지 논의하십시오. 아무도 아직도 읽었습니까? 그들에게 보낸 시간은 정당합니까? 더 가벼운 다른 중간 단계가 있습니까?

당신은 모르고, 당신은 당신이 틀렸다는 것을 알 수 있습니다. Agile 선언문을 기억하십시오. "포괄적 인 문서보다 소프트웨어 작업"에서 더 많은 가치를 찾을 수 있지만 후자에는 여전히 가치가 있습니다.

하지만 제 생각에는 사용 사례와 사용자 사례가 얼마나 밀접한 관련이 있는지를 알면서도 무거운 문서를 계속 작성하려는 욕구가 사라진다는 것을 빨리 알게 될 것입니다.

에픽은 자리 표시 자입니다

모든 애자일 방법론에서 Epics의 개념은 요구 사항 사양에 필요한만큼, 자리 표시자는 해당 수준에서 필요한 것입니다. 이러한 항목은 지속적으로 우선 순위가 지정되며 요구 사항이 오랫동안 우선 순위가 낮아 지거나 구현되지 않으면 더 많은 세부 정보가 낭비됩니다. 문서화하고 그 주위의 문서를 관리하는 것은 완전한 시간 낭비입니다. YAGNI는 코딩 활동뿐만 아니라 요구 사항 활동까지 확장합니다.

도구는 당신의 친구입니다!

적절한 도구를 사용하여 사용자 스토리를 수집하고 관리하는 경우 요구 사항 스펙을 생성 할 수 있습니다. 요구 사항 사양은 어쨌든 일시적인 아티팩트 문서이며, 살아있는 문서가 아니며, 요구 사항의 스냅 샷입니다. 그리고 현실과 결코 맞지 않습니다.

유물 자동 생성

적절한 도구에서 내보낼 수있는 사용자 스토리는 언제라도 정적 아티팩트 문서보다 훨씬 중요합니다. 개인적으로 Pivotal Tracker 가 User Stories를 추적 하는 것을 선호합니다 .Python Tracker 는 Python으로 MoinMoin 플러그인 제품군을 작성하여 Wiki에 모든 다양한 Stories와 상태를 게시했습니다 (이야기에 대한 자세한 개발자 노트 등이 포함되어 있음), 라이브 데이터는 항상 정적 데이터보다 낫습니다.

Wiki는 모든 상점 / 요구 사항과 완료 상태 및 우선 순위 및 세부 사항, 의견 및 기타 메타 데이터에 대한 실시간 문서가되었습니다.

Sharepoint에서 지속적으로 전자 메일을 보내고 업데이트되지 않는 거대한 Word 문서보다 낫습니다. 모든 사람이 다른 버전을 가지고 있고 다른 사람과 동기화되지 않도록 보장합니다!

사용 사례보다 풍부한 사용자 사례

사용 사례는 WHY 라고 말하는 사용 사례보다 훨씬 가치가 있습니다.

사용자 스토리 형식 : As a [ROLE] I [ACTIVITY] so that [WHY]은 유사한 사용 사례보다 훨씬 표현 적입니다 The System [shall/shall not/may/must] perform [action](여기서 조치는 플로우 차트).

사용자 스토리를 통해 WHO 는 무언가를하고 싶고, 무엇 을하고 싶은지 (복잡한 작업에 대한 자세한 다이어그램 / 문서를 가리킬 수 있음), 이 활동을 수행하려는 이유 가 가장 중요 합니다.

첫 번째가 있다면 두 번째는 완전히 중복되며 최상의 소음입니다. 워터 폴 방법론의 전통적인 공식 요구 사항 사양은 애자일 환경에 적합하지 않습니다.

결국

경영진이 변화를 약속하지 않으면 새로운 방법론으로 성공하지 못할 것입니다. 저는 매년 천억 달러가 넘는 회사에서 일했습니다. 그들은 애자일 / 스크럼으로 이사하기 위해 아기 발걸음 을 내딛지 않았습니다 . 그들은 방금 전 회사가 이것으로 이사하고 있습니다. 여기에 새로운 방식이 있습니다. 새로운 방식에 대한 교육이 시작될 때 여기에 사용할 새로운 도구가 있습니다. 여기에 이런 방식으로 일을 시작하는 날짜가 있습니다. 그것은 1 년 안에 그들을 위해 일했습니다. 나는 같은 성공을 가진 소규모 회사에서 이것을 구현하기 위해 노력했습니다.

헌신

변경 사항에 관계없이 베이비 스텝 구현은 실패의 레시피입니다. 그들이 조용히 동의하지 않고 수동적으로 실패에 대해 적극적으로 설정하는 것은 관리를위한 코드입니다. 그들은 내가 그것에 헌신하기에 충분히 이것을 믿지 않는다고 말하고 있으므로, 나는 당신이 실패 / 성공하지 못하도록 충분히 노력할 것입니다. 그들은 그들이 시도하고 작동하지 않았다고 말할 수 있습니다. 그냥 괜찮아 부분적인 헌신은 결국 실패로 이어집니다.

귀하의 경우, 그들은 조용히 User Stories를 믿지 않을 것이며, 두 가지를 모두 한 후에 그들은 SRS가 아닌 쓸모없고 User Stories라고 주장하기 시작하고 User Stories 작성을 중단 할 것입니다. , 앞으로 이동하지 않고 뒤로 이동시킵니다.

나는 유머를 시도하고 사용합니다.

http://www.halfarsedagilemanifesto.org/로 시작 하십시오

이것에 대해 잠시 동안 이야기 하고 ( 전환 )
그 충돌이 실제로 의미하는 바에 대해 이야기하고 ( 공개 토론 ),
잠시 후 조직으로 돌아 서서 ( 피벗 )
SRS를 검토하고 새로운 프로젝트 설정에 적합한 지 여부를 조사하십시오 .

그런 다음 접근법 re : SRS의 변경에 대한 토론으로 결론을 내리거나 다른 회의에서 결론을 내리고 더 많은 합의가 있는지 확인하십시오.

하루가 끝나면 예산에 제약을 받아 비즈니스 사람들에게 서비스를 제공하기 때문에 사용하는 것에 조금 더 견고 할 수 있지만 실제로는 산업, 회사 규모, 조직적 요인 및 많은 요인에 달려 있습니다. 다른 요인들.

SMT에서 멀어지고 사용자 스토리를 사용하기 시작하는 설득력있는 mgmt는 기본적으로 민첩성을 채택하도록 설득하는 것과 동일합니다. 애자일의 생산성 이점에 대한 강력한 통계가 있습니다. 한 가지 예는 VersionOne이 2013 컨퍼런스에서 발표 한 것입니다. 이 산업 데이터에 mgmt를 표시하고 청취 유형 인 경우 기회가 있습니다.