에지 케이스에 대한 수락 기준

저는 민첩한 팀의 제품 소유자입니다. PO 수락 테스트를 수행 할 때 일반적으로 몇 가지 중요한 사례를 시도하는 것이 좋습니다. 내가 무언가를 발견 한 다음 개발자에게 다시 전달하는 것은 드문 일이 아닙니다. 그의 이야기를 거부하면 개발자 중 한 사람으로부터 밀려 나고 있습니다. 그는 내가 이야기에서 설명하는 것만 코딩하는 경향이 있기 때문에, 내가 우연한 경우와 수용 기준에서 프로그램이 어떻게 반응해야하는지 명시하지 않았기 때문에 불공평하다고 말했다. 코딩하는 동안 엣지 케이스에 부딪 칠 때마다 물어 보라고 권유했지만 엣지 케이스와 광산을 통해 생각하는 것이 그의 일이 아니라고 생각하고 다음 스프린트에 대한 새로운 이야기를 만들어야합니다.

내 방어에서는 스토리를 구현 한 후에야 스토리 디자인을 알지 못하므로 모든 가능성을 반복하기가 어렵습니다 (DB 또는 속성 파일에 구성되어 있습니까?). 간단히하기 위해 계산기 앱에 나누기를 추가하는 이야기가 있다고 가정 해 봅시다. 이상적인 스크럼 세계에서 승인 기준에 "제로 시나리오 처리"시나리오를 추가해야합니까, 아니면 앱이 5/0에 영향을 미치지 않도록 개발중인 사례를 처리해야합니까? 분명히,이 경우 앱이 5/0에서 열심히 충돌하면 수락하지 않지만 로그, DIV0 또는 오류를 처리하는 다른 방법을 전달하면 통과합니다. 충돌하지 않습니다.

답은 둘 다 자신의 고유 사례에 대해 생각해야한다고 생각합니다. 개발자는 주어진 사용자 입력으로 인해 앱이 충돌하는 것과 같이 데이터에 특정한 에지 사례를 처리해야하므로 5 / 0은 분명히 스펙트럼 의이 부분에 해당합니다. 개발자는 사용자의 상호 작용의 일부로 제공된 입력이 잘못된 것으로 이어질 때 적절한 오류 메시지가 무엇인지 생각해야합니다.

스펙트럼의 일부는 비즈니스 측면입니다. 사용자 계정에서 나누기 단추를 사용할 수없는 경우 계산기는 어떻게 작동해야합니까? 계정이 Mod 작업을 사용할 수 있지만 나누기 기능에 액세스 할 수없는 경우 어떻게 작동해야합니까?

전달해야하고 모든 팀원의 승인을 받아야한다는 중요한 메시지는 모두 같은 팀에 속한다는 것입니다. 제품이 완료되지 않은 경우 제품이 완료 되지 않아 팀원이 책임을 져야합니다.

팀은 "내 책임이 아닌 내 직업이 아닌"유형의 태도 / 만트라가 아닌, 함께 일해야합니다.

합격 기준은 다음과 같은 형태로 나타납니다.

• 사업 수락
• 품질 보증 수락

일반적으로 비즈니스 승인은 일반적으로 다음과 같은 질문에 대답합니다.

• 구현 된 기능이 원하는 기능을 수행합니까?

이 버튼을 누르면이 작업이 발생할 것으로 예상되는 것처럼 비즈니스 중심의 요구 사항이 여러 가지 있습니다. 예상되는 비즈니스 시나리오와 예상되는 동작을 나열하지만 가능한 모든 경우를 다루지는 않습니다 .

품질 보증이 비업무 적 요구 사항에 대한 기술을 개발할 수 있도록 반복하기 전에 비즈니스 요구 사항을 정의해야합니다. 품질 보증은 필요에 따라 우연한 사례뿐만 아니라 파괴적인 사례를 개발해야합니다.

스토리 작업을 시작하기 전에 두 가지 요구 사항을 모두 검토하여 작업 단위에 대한 공식적인 평가와 헌신이 이루어질 수 있도록해야합니다. 이 작업이 완료되면 기능 / 스토리를 작업 할 수 있습니다. 이 시점에서 모든 사람은 비즈니스 관점과 기술 관점에서 무엇을 제공해야하는지 명확하게 알 수 있습니다.

비즈니스 및 품질 보증 팀원이 스토리에 서명하면 스토리가 최종 승인됩니다. 이는 비즈니스 승인 및 품질 보증 수락 모두 반복 중에 발생해야합니다. 추가 스토리 작업을 시작할 수 있음을 나타내는 완료 (DoD)의 정의입니다.

새로운 결과는 결함 또는 추가 스토리 스파이크로 기록 될 수 있습니다. 완벽한 세상에서는 이런 일이 발생하지 않지만 실제로는 기능 / 스토리 작업시 발생하는 "발견"이 있습니다. 이것은 자연 스럽습니다.

팀이 함께 작동합니다 요구 사항의 성운 발견 유형에서 해시 (비즈니스, QA, 개발자). 이것이 민첩한 경우, 의사 소통과 발생할 수있는 질문에 대한 빠른 해결을 위해 모두 같은 테이블에 앉아 있어야합니다. 다음과 같이 가야합니다.

품질 관리 :

"개발자, 우리는이 특정 시나리오를 처리해야합니다.이 데이터를 입력하면 오류가 발생합니다."

장치 :

"어떤 요구 사항도 다루지 않았지만이를 다루기 위해 몇 가지 추가 기능을 추가 할 수 있습니다. 비즈니스 담당자,이 경우에 응용 프로그램이 어떻게 작동하겠습니까?"

사업:

"표준 오류 메시지를 표시하고 사용자가이 시나리오를 다시 시도하도록하겠습니다. 그러면 얼마나 많은 추가 노력이 필요합니까?"

장치 :

"쉬운 시간입니다. 한두 시간 만 더 쉬울 것입니다.이 반복에 전념 할 수 있습니다. QA이 시나리오에 대한 승인 기준을 업데이트하십시오. 이에 대한 추가 이야기가 필요하지 않습니다. 감사합니다!"

또는 작품이 많은 경우 백 로그에 새로운 스토리가 추가됩니다. 팀은 원래의 모든 요구 사항을 충족하면서 원래의 스토리를 수락 한 다음 다음 반복에서 스파이크 스토리를 선택할 수 있습니다.

입력이 부정확하거나 모호한 경우에도 견실 한 방식으로 동작하는 소프트웨어를 작성하는 것은 소프트웨어 개발자의 일에서 필수적인 부분입니다.

개발자가 그렇게 생각하지 않으면 요구 사항 사양에 명시 적으로 작동하지 않는 추가 요구 사항을이 요구 사항을 명시하고 개발자에게 최종 테스트를 제출하기 전에 해당 프로세스를 직접 적용 할 수 있도록 테스트 프로세스의 예를 제공하십시오 검토 코드.

어쨌든 합격 시험은 모든 요구 사항 문서의 중요한 부분이어야합니다. 요구 사항에 수용 기준도 명시되어 있지 않으면 실제로 요구 사항이 아닙니다. 소원입니다.

여기서 일어난 일은 value을 발견 했다는 것 입니다. 입력 값은 스토리 (및 승인 기준) 작성 시점 또는 코드 작성 시점을 고려하지 않았습니다. 그것이 수용 기준의 일부가 아닌 경우, 당신은 실제로 그 이야기를 거부 할 근거가 없습니다.

우리 팀에서 할 일은 :

1. 예상되는 실제 동작을 자세히 설명하는 버그를 만듭니다.
2. 새로 찾은 요구 사항이 문서화되도록 승인 기준을 업데이트하십시오.
3. 다음 반복에서 다른 모든 스토리 및 버그와 함께 버그의 우선 순위를 지정하십시오.

여기서 이점은이 버그를 수정하는 것이 다음으로해야 할 가장 중요한 일인지 여부를 고려해야한다는 것입니다. 수정하기에 충분히 중요하거나 중요하지 않을 수 있지만 그 가치를 고려하는 것이 중요합니다.

물론 개발자 (및 사용자)가 이러한 최첨단 사례를 탐색하도록 장려 할 수있는 방법을 찾아야합니다. 개발자 팀이 스토리를 분석하는 데 시간을 소비하지 않는 경우 스토리를 시작하기 전에 자세한 계획 세션을 갖도록 권장하십시오.

일부 관찰 :

... 그의 이야기를 거절 할 때

나는 당신의 직장 문화 나 과정을 모르지만 이야기를 거부하는 것은 심각한 단계입니다. 내가 개발자라면 저와 팀에 나쁜 영향을 미치는 기록 된 행동이기 때문에 다시 밀어 붙일 것입니다.

그는 에지 케이스를 지정하지 않았기 때문에 불공평하다고 말합니다.

그가 당신이 모든 가장 중요한 사건을 알기를 기대하는 것은 불공평합니다. 그러나 동시에, 당신이 그를 기대하는 것은 불공평합니다. 모든 변경에는 위험이 있으며 문제가 발견되면이를 해결하기 위해 팀으로 협력해야합니다.

이야기를 구현하기 전까지는 그의 디자인을 모릅니다

디자인을 몰라도됩니다. 백 로그 관리를 위해 어느 스토리가 더 쉽고 어려운지에 대한 초기 교육 된 추측을하기 위해 디자인을 아는 것이 도움이 될 수 있습니다. 그러나 스토리를 작성할 때 개발자를 디자인에 빠뜨리지 마십시오. 단순히 PO를위한 음성 인식 키보드 일 때 모든 재미를 빨아들입니다.

프로세스 개선 작업을 수행하고 팀을 구성해야하는 것처럼 들립니다. 프로세스에 제안 할 수있는 몇 가지 사항 :

• 개발자는 발견 된 엣지 케이스를 수정하는 데 시간을 이야기에 포함 시키라고 제안하십시오. 각 사용자 스토리의 일부로 만드십시오. 이것은 0 개의 새로운 버그가 도입되었다는 목표를 통해 쉽게 방어 할 수 있습니다. 문제는 개발자가 현재 계획하고 있지 않다는 것입니다. 그리고 그는 당신이 문제를 발견했을 때 시간이 없습니다. 어느 쪽이든 시간이 걸리므로 계획 중에 보이는 이야기에 넣으십시오.
• 테스트 후 (그리고 테스트 해 주셔서 감사합니다!) 개발자에게 검색된 문제 목록을 보냅니다. 이러한 문제의 해결은 만족스러운 "고정 사례"조건과 상충됩니다.
• 문제가 해결되지 않았거나 너무 늦게 발견되면 사용 사례를 충족시킬 수 있는지 여부에 따라 스토리를 푸시해야하는지 여부를 결정하십시오. 알려진 문제와 해결 방법이 발생합니다. 릴리스 노트에 공개하고 수정하기위한 새로운 스토리를 작성하십시오.
• 프로세스에 푸시 백을 생성하는 특정 거친 지점이 있으면 프로세스를 변경하십시오! 결국, 프로세스 개선은 Scrum의 일부입니다. 예를 들어, 스토리를 거부 할 때 개발자가 화를 내면 거부가 수정 사항을 트리거하지 않도록 팀에 프로세스 변경을 제안하십시오. 완료 및 거부 전에 테스트 및 수정을 수행하십시오.
• 팀과 팀원과 협력하여 최대한 활용하십시오. 그들은 완벽한 일을하지 않으며 당신도하지 않습니다. 계획하십시오. 우리 팀은 보통 실력이 뛰어나므로 계획되지 않은 지원 계획에 대한 계획을 세우고 계획되지 않은 계획에 대한 계획을 세웁니다.

요구 사항은 명확하고 간결해야합니다. 그렇지 않은 경우 정확히 당신에게 일어난 일이 발생합니다. 그것은 당신의 잘못이며 요구 사항을 지정할 때 할 수있는 최악의 일은 일을 가정하는 것입니다.

0으로 나누기에 관한 구체적인 예입니다. 오류를 기록하도록 지정하지 않은 경우 개발자가 결과로 100을 인쇄하는지 불평하지 마십시오.

그러나 그런 경우에는 누락 된 간격을 채우고 개발자에게 전달합니다. 결국, 요구 사항의 버그가 발생합니다.