이것은 내가 계획했던 것보다 길었던 것으로 판명되었지만 (설명으로 시작 했음) 추가 된 길이 / 세부 사항이 도움이 되었기를 바랍니다.
애자일은 CRUD 앱에만 국한되지 않습니다
민첩성에 관한 대부분의 문헌은 사용자가 무대 뒤에서 무슨 일이 일어나고 있는지 거의 알고있는 CRUD 유형 비즈니스 응용 프로그램에 편향되어있는 것 같습니다. (작성되는 대부분의 코드가 아마도이 클래스에 속하기 때문에 좋습니다.)
방법론이 그러한 종류의 시스템을 목표로하기 때문이 아니라,이 유형의 따르기 쉬운 예제를 만들기가 더 쉽기 때문이라고 생각합니다. 따르기 쉽지 않은 예제를 만들면 요점이 독자에게 민첩한 개념에 대해 가르치려고했을 때 예제를 이해하려고 시도 할 수 있습니다.
사용자 사례! = 요구 사항
이러한 유형의 응용 프로그램의 경우 사용자 사례 (요구 사항)와 개발 작업 간의 관계는 대부분 간단합니다. 사용자 사례를 몇 가지 작업으로 나누기 만하면됩니다.
사용자 스토리는 없는 요구 사항과 동일. 사실, 요구 사항이 얼마나 '높은 수준'인지에 따라 겹치는 부분이있을 수 있지만 일반적으로 동일하지는 않습니다. SVN 사용자가 Git으로 전환하려고 할 때와 비슷한 "요구 사항"의 동의어로 사용자 스토리를 생각하면 SVN의 관점에서 생각. (그런 다음 나쁜 시작 가정으로 인해 문제가 발생합니다.)
요구 사항과 사용자 스토리의 주요 차이점 인 IMHO는 요구 사항이 특정 시스템 구성 요소의 동작 방식을 자세하게 지정한다는 것입니다. 입력, 출력, 가정 / 사전 조건, 발생 가능한 예외 등을 포함 하는 사양 입니다 . 시스템의 기능 에 중점을 둡니다 .
OTOH의 사용자 사례는 시스템 구성 요소에 대한 자세한 동작 사양을 만들지 않고 최종 사용자의 예상 결과에 중점을 둡니다. 그들은 예상되는 사용자 경험 에 중점을 둡니다 .
내가했던 일은 팀에서 채택한 연습으로 사용자 스토리를 작업으로 나누는 것이 었습니다. 당신의 임무는 당신이 원하는 / 필요한만큼 구체적이거나 모호 할 수 있지만, 이야기를 완료된 상태로 만들기위한 실제 작업에 대한 진행 지표가 될 수 있습니다.
예
몇 년 전 사용자가 테스트 사례를 자체 할당해야했기 때문에 팀의 모든 직원이 중복 된 노력을 피하기 위해 작업중인 TC를 알 수있었습니다. UI는 내부 웹 애플리케이션이었습니다. 사용자는 버튼 만 보았지만 이야기는 기술적 구현 세부 사항 등을 포함하는 여러 작업으로 나뉩니다.
사용자 가시성
그러나 대부분의 코드가 사용자가 직접 볼 수없는 복잡한 처리를 처리해야하는 다른 유형의 응용 프로그램이 있습니다.
어떤 식 으로든 사용자에게 공개 할 수 있습니까?
GPS를 고려하십시오. 자신의 차례를 놓치면 실제 경로 재 계산 프로세스는 보이지 않지만 사용자는 유용한 피드백 (예 : "재 계산 ...")을받습니다.
컴파일러는 경고 나 오류를 표시하거나 GUI에 새로운 설정 / 옵션을 포함시켜 사용자가 새로운 것이 추가되었음을 알 수 있습니다. 컴파일러 사용자는 프로그래머라고 생각합니다. 새로운 표준에 대한 지원이 추가되지 않습니까?
새로운 표준을 지원하는 것은 기능 수준에있을 수 있으며 사용자 스토리로 세분화 해야 하지만, 경우에 따라 기능을 대신 사용해야 할 때 스토리를 사용하려고하지 않는지 확인 해야합니다. ?
자동차의 이미지 분석은 자동차 사고로 끝날 가능성이 줄어들 었다는 것을 사용자에게 알려주는 방식으로 표현 될 수 있습니다. 예를 들면 다음과 같습니다.
자율 주행 차의 승객으로서, 나는 더 안전하게 여행 할 수 있도록 인식 할 수없는 물체에 충돌 할 때 차량이 가능한 한 0에 가까워 질 가능성이 필요합니다.
미국은 보안, 안전 등 기능적 및 비 기능적 요구 사항의 조합을 사용하여 일반적으로 지정해야 할 사항을 높은 수준에서 포착합니다.
그러나 시스템에 대한 요구 사항이 더 많을 수 있습니다. 예 :
abc
구성 요소의 기능 A
은 이미지 비교 알고리즘에서 공차 임계 값을 줄여서 천천히 움직이는 물체를 더 잘 감지해야합니다.
나에게이 쉽게 될 일 제가 위에서 언급 한 사용자 스토리에 따라, 제목과 같은 : 기능의 감소 허용A.abc
한 다음 거기에 기타 관련 세부 사항을 포함한다.
유체 시뮬레이션 시스템의 경우 시스템이 수행하는 백그라운드 작업에 대한 피드백을 제공하는 진행률 표시 줄이있을 수도 있습니다. 스팸성이있는 것을 피하고 싶을 수도 있지만 항상 사용자에게 무언가를 알려주는 방법이 있습니다.
나는 당신이 언급 한 특정 도메인에 대해 더 잘 알고 더 현실적인 사례를 제시하는 것에 대해 충분히 알지 못하지만 여기서 테이크 아웃하는 경우 다른 방법을 사용하여 덜 눈에 띄는 것에 대한 사용자 피드백을 제공 할 수 있습니다 시스템이 수행 중일 수 있습니다. 즉, 보이지 않는 것을 조금 더 눈에 띄게 만드는 방법이있을 수 있습니다. (여러분의 노력 등으로 인해 시스템 성능이 얼마나 빨라지는지에 대한 릴리스 노트 세트를 작성하는 경우에도 마찬가지입니다.)
이야기와 과제의 관계
여기서 작업과 사용자 스토리를 연관시키는 것이 실제로 어려울 수 있습니다.
우리의 접근 방식은 사용자의 이야기에 초점을 유지하는 것이었다 것을 요청했다 이유 가했고, 될 어떤 것을 필요했던 사실 "완료"미국을 고려. 방법은 항상 미국의 탈락 및 개발자 (들)에 남아 있었다.
개발자는 미국에서 설명 된 문제를 그들이 수행 할 일련의 작업으로 분류 할 수 있습니다.
나는 이것을 백엔드 서버 측 프로그래밍을 한 사람이라고 말하고 있는데, 이는 최종 사용자에게 얻을 수있는 "보이지 않는"것일 것이다.
내가해야 할 일에 따라, 때때로 AJAX를 사용하여 간단한 "로드 중 ..."애니메이션 / gif를 표시하여 사용자가 잘못된 인상을받지 않고 다른 무언가가 완료 될 때까지 조금 기다려야한다는 것을 알았습니다. 때로는 이렇게 간단했습니다. 이에 대한 작업이 적절할 것입니다.
다른 패러다임, 실습 및 경험
이 문제를 극복 할 수있는 기술이 있습니까? 아니면 우리가 받아들이고 최대한 활용해야하는 것입니까?
패러다임의 변화를 받아들이고 실천하고 경험을 쌓는 것 외에는 말할 것도 없습니다. 나는 종종 사람들이 그 과정을 통해 지름길을 취하는 것을 보았습니다. 나는 특히 당신이 시작한다면 그것에 대해 충고 합니다. 더 많은 경험을 얻으면 약간의 유연성을 허용 할 수 있지만 자신을 약화시키지 마십시오.
당신이 이전에 한 말을하더라도, 당신은 여전히 이야기가 마치 "이름이 바뀌었다"고 생각합니다. 그것은 잘못된 가정이라고 생각합니다. 이것이 민첩한 접근 방식과 민첩하지 않은 접근 방식의 근본적인 차이점에 관한 더 깊은 문제 의 증상 이라고 생각합니다 .
둘째, 민첩성이 폭포에 비해 패러다임 전환 이라는 점을 받아 들여야한다고 생각합니다. 즉, 프로세스의 목표는 비슷하지만 매우 다른 방식으로 진행됩니다. 도움이된다면 SVN과 Git을 생각하십시오.
요구 사항과 사용자 스토리의 개념적 차이에 대한 현재의 이해를 향상시키고 동일한 것이 아니라는 점을 인정하십시오.
스프린트에서 배우기-회고
내가 충분히 강조 할 수없는 것은 각 스프린트가 끝날 때마다 스크럼 마스터와 개발자 간의 회고 입니다. 그곳은 그들이 정직하고 투명한 방식으로 "잘됐다"거나 "잘 못 갔다"는 것들을 논의하는 곳이며 , 다음 스프린트가 "잘 못 갔다"는 점을 다루기 위해 어떤 가능한 변화가 시행 될 것인가 .
이를 통해 우리는 서로의 경험을 적응시키고 심지어 배울 수있게되었으며,이를 알기 전에 팀 속도의 일반적인 일관성으로 측정 한 결과 크게 향상되었습니다.