Azure Boards Sprints에서 PBI의 Assigned To 및 Task State를 표시하지 않을 수 있음

최근 프로젝트에서 아주어 DevOps를 사용하는 경우가 많아졌다면서 "아주어 DevOps의 보드를 제대로 사용하는 방법을 알려주세요"라고 말했다.이런 질문은 자주 받는다.
애저디브옵스는 간단하게 사용하기 시작해 오히려 제대로 쓸 수 있을지 걱정할 수 있기 때문이다.Azure DevOps 자체는 자신의 프로젝트에 따라 자유롭게 바꿀 수 있다. 예를 들어Scrum.org에서 Azure 프레임워크를 바꾸지 않기 위해'쓰레기'(바꾸면 쓰레기가 아니다)를 표시한다.자신의 취향과 반대로 잘못 사용하면 불안할 수 있다.제대로 사용하고 싶어요.이런 기분 잘 알아요.
그래서 이번에는'어떻게 하면 어저트 데비옵스를 쓰레기로 사용할 수 있을까'라는 관점으로 살펴보려고 한다.Azure DevOps에 Scrum 템플릿이 설정되어 있다고 가정합니다.

PBI의 Assigned To에 누구를 넣어야 하나요?

흔한 질문으로 "Product Backlog Item(PBI)의 Assigned To에 누구를 넣어야 하나요?"이런 문제가 있습니다.

위에서 설명한 대로 Sprints 화면에는 PBI에 Unassinged가 표시됩니다.PBI에 Assigned To가 있는데 그것이 아직 지정되지 않았기 때문에 이렇게 표시된다는 것이다.
한편, Task의 Unassinged는 잘 알고 있습니다.To Do의 임무는 아직 아무도 착수하지 않았기 때문에 Unassinged에서는 임무가 In Progress로 바뀔 때 담당자의 이름이 표시됩니다.
여기서 유추하면 PBI도 마땅한 책임자가 있어야 하는데 그게 도대체 누구지?나는 이것도 당연하다고 생각한다.그러나 이것은 정확하지 않거나 기본값이 적합하지 않다.
폐기물 중

제품 리베이트(Product Backlog)는 제품 소유자(Product Ownner:PO)의 책임 범위

분리 후 기록(Sprint Backlog)은 개발자(Developers)의 책임 범위

제품 백그라운드 종목에서'단거리의 일'을 선택하여 단거리의 백그라운드 종목

을 만든다.
그런 생각일 거예요.따라서 PBI는 들키지 않을 거예요.굳이 말하자면 제품 경영자의 이름을 입력해야 하나.그렇지만

Azure DevOps의 Boards에서 PBI 자체는 제품 백그라운드와 분리 후 로그에 특별한 변화가 없음

Sprints 화면의 PBI에 제품 소유자의 이름이 위화감이 있음

원래 제품 소유자는 쓰레기 그룹에서 한 명이어야 하기 때문에 PBI에서 매번 제품 소유자의 이름을 표시할 필요가 없다

따라서 PBI의 Assigned To(Unassinged를 유지하면 됨)를 특별히 설정할 필요도, 스프린츠에 이름을 표시할 필요도 없다.

이런 느낌으로 안 보이게 설정하는 게 좋아요.

Sprints 화면의 오른쪽 위 모서리에 있는 기어에서 Settings를 켜도록 설정하고 Fields에서 Product Backlog Item을 선택하여 "Show Assiinged Toas:"옵션을 제거하면 변경할 수 있습니다.

그나저나 Task의 State도 간판에 고스란히 표시된 내용일 뿐이니 체크를 취소하고 숨길 수 있다.여기는 같은 Settings의 Fields의 Task입니다. 버튼을 누르면 Additional fields가 최초로 표시한 State를 제거합니다.

미션의 Assinged To도 "결단력 없음"

Azure DevOps의Task는 폐기물 이외에도 사용할 수 있기 때문에 어쩔 수 없지만, 미션의 Assigned To는 폐기물이라면'들켰다'는 것도 아니겠죠.어떤 걸 말하려면, 스스로 임무를 가지러 가는 건가.뭐, 임무를 보면 책임자가 분배되는 것이 옳을지도 모른다
퀘스트 카드에는 기본적으로 Unassinged가 표시되어 있습니다. "아, 퀘스트가 아직 분배되지 않았다"는 느낌으로 읽으면쓰레기통인데도 "임무는 어떤 상사가 자신에게 맡긴다"는 잘못된 인식이 있는 것도 좋지 않다고 생각한다.

누군가가 방해가 되는 Developers에 참가했을 때, 임무는 스스로 가져갔다.스스로 To Do의 임무를 In Progress에 가져가 여러 번 전달하고 싶다.
또한 지도자와 사장의 경험이 있고 경험을 방해하지 않은 사람은 다른 사람의 임무를 분배하는 데 익숙해질 수 있으므로 하지 말라고 말할 필요가 있다.

"코드 교란"을 변경하지 않으면 Azure DevOps를 자유롭게 사용자 정의할 수 있습니다.

프레임'쓰레기'를 조정하는 과정에서 개발하려면 기본 부분(오해를 초래하고 좋지 않은 사용법을 추천)이라는 설정을 바꾸지 않는 것이 좋다. 그렇지 않으면 자유롭게 변경할 수 있다.

• 재생 목록 "Windows 데스크톱 응용 프로그램을 만듭니다!"

이 애니메이션에서는 2화부터 Sprints의 화면을 사용자 정의하여 누구의 이름도 표시하지 않습니다.Azure DevOps를 혼자 쓰면 괜찮겠죠p>