Agile : 기계 학습 프로젝트의 사용자 사례?

Question

필자는 감독 학습 알고리즘의 프로토 타입 구현을 끝내고 회사 데이터베이스의 모든 항목 (약 5 백만 개 항목)에 카테고리 태그를 자동으로 할당했습니다.

결과가 좋게 보이고 프로덕션 구현 프로젝트를 계획하기 위해 준비되었습니다.

저는 이전에 이런 종류의 작업을 했으므로 소프트웨어의 기능 구성 요소를 알았습니다. 데이터를 가져 오기 위해 웹 크롤러 모음이 필요합니다. 크롤링 된 문서에서 기능을 추출해야합니다. 이러한 문서는 "학습 집합"및 "분류 집합"으로 분리해야하며 각 문서에서 피쳐 벡터를 추출해야합니다. 이러한 특징 벡터는 클러스터로 자체 구성되며 클러스터는 일련의 재조정 작업을 통과합니다. 기타 등등

그래서 30 개의 고유 한 개발/배포 작업이 계획되어 있습니다. 각 작업에는 시간이 예상됩니다. 개발의 첫 번째 단계 - 우리가 장기간에 갖고 싶지만 아직 개발 일정을 수립하기에 우선 순위가 높지 않은 몇 가지 고급 기능을 무시하고 - 약 2 개월 동안 작업 할 예정입니다. . (내가 이미 작동하는 프로토 타입을 가지고 있으므로 프로젝트가 처음부터 시작한 경우보다 최종 구현이 훨씬 간단합니다.)

관리자가 계획을 잘 진행했지만 관리자가 재구성 할 수 있는지 질문했습니다. (1) 프로젝트 관리 소프트웨어는 사용자 스토리를 중심으로 완전히 구성되어 있습니다. (2) 우리의 모든 스케줄링은 개별적으로 작업을 스케줄링하기보다는 전체 사용자 스토리를 스프린트에 맞추는 것에 기반합니다. (3) 웹 개발자와 같은 다른 팀은 민첩한 방법론을 잘 활용했으며, 모든 소프트웨어 기능을 사용자 스토리로 모델링함으로써 많은 이점을 얻었습니다. , 내가 쉽게 대부분의 관련 항목을 찾을 수 있도록 카테고리별로 항목을 검색 할 시스템의 사용자로서

:

그래서 나는이 프로젝트의 최상위 레벨에서 사용자 스토리를 만들어 거대한 복잡한 데이터베이스 내에서.

또는

어쩌면이 기능에 대한 더 나은 최상위 이야기는 다음과 같습니다

이 콘텐츠 편집기로, 나는 그래서 고객이 쉽게 할 수있는, 자동으로 우리의 데이터베이스에있는 항목에 대한 범주 지정을 만들려면 거대하고 복잡한 데이터베이스에서 가치있는 데이터를 찾으십시오.

하지만 실제 문제는 아닙니다.

나를위한 까다로운 부분은 컴퓨터 학습 아키텍처의 나머지 부분에 대한 하위 사용자 스토리를 작성하는 방법을 알아내는 것입니다.

사례를 알고 싶습니다.이 알고리즘에는 (A) 교육과 (B) 분류라는 두 가지 주요 아키텍처 세분화가 필요합니다. 그리고 아키텍처의 트레이닝 부분에 클러스터 공간을 구축해야한다는 것을 알고 있습니다.

내가 읽은 모든 애자일 개발 문헌은 사용자 스토리가 "비즈니스 가치를 제공하는 가능한 최소 구현"이어야 함을 나타냅니다. 최종 사용자 소프트웨어를 디자인 할 때 많은 의미가 있습니다. 작게 시작한 다음 사용자가 추가 기능을 요구할 때 점진적으로 값을 추가하십시오.

그러나 클러스터 공간 자체는 0 비즈니스 가치를 제공합니다.또한 크롤러 또는 피쳐 추출기도 아닙니다. 부분 시스템에는 비즈니스 가치가 없습니다 (최종 사용자 또는 회사 내부의 역할 제외). 훈련 된 클러스터 공간은 크롤러와 피쳐 추출기에서만 가능하며 우리가 함께 분류자를 개발하는 경우에만 관련이 있습니다. 로

관리 대상 학습 클러스터 공간 건설 루틴을, 나는 소비 할 :

나는 이야기의 사용자와 시스템 행위의 ​​하위 구성 요소가 어디에 사용자 스토리를 만들 수있을 것이라고 생각 기능 추출기에서 가져온 데이터이므로 내가 존재할 수 있습니다.

하지만 정말 이상하게 보입니다. 개발자 (또는 사용자 또는 다른 이해 관계자)가 내 사용자 스토리를 모델링 할 때 어떤 이점을 제공합니까?

주요 스토리는 아키텍처 구성 요소 경계 (크롤러, 트레이너, 분류기 등)를 따라 쉽게 구분할 수 있지만 사용자의 관점에서 보면 유용한 분해는 생각할 수 없습니다.

너희들은 어떻게 생각하니? 정교하고 분할 할 수없고 사용자 중심이 아닌 구성 요소에 대한 민첩한 사용자 스토리를 어떻게 계획합니까?

Answer 1

모든 스토리에는 역할, 액션 및 목표가 있습니다. 그러므로 목표를 달성하기 위해 뭔가를하는 역할 (a/k/a Actor)을 명명하는 이야기를 작성하는 것에 대해 생각해보십시오.

당신이 내려 놓은 것은 분명한 테스트, 즉 성공과 실패를 정의하는 효과적인 의사 결정 절차를 가져야합니다.

여기서 문제가 발생하면 제 생각에 "비즈니스 가치"에 매료되고 있습니다. 작업을 성공적으로 완료했을 때 알 수있는 전반적인 방법을 정의하여 시작하십시오. 그런 다음, "achives business value"가 목표를 향한 진전을 이루고 있습니다.

Agile에서 비즈니스 프로세스를 지향하는 경우가 많기 때문에 약간의 창의적인 창의성을 갖추어야합니다.

업데이트 :

여기 여러 가지가 있습니다.

1. 당신이 시스템 외부에서 구성 요소의 효과를 관찰 할 수없는 경우, 그 구성 요소는 관찰 등가의 의미에서 효과없이 제거 할 수있는 이론이다.

2. 사용자 스토리보다 작은 프로그래머 할당 인 태스크이라는 것이 정의되어 있습니다. 당신이 이야기로 큰 것처럼 보이는 것을 가지고 있다면, 그것을 일로 나누십시오. 그러나 외부 행동을 잘 정의한 방식으로 행동하거나 행동을 관찰 할 수있는 상황에서 행동하십시오.

   1. 큰 이야기 설정하고 이야기를 분해 하위 단계 비정상적으로 많은 수의

   2. 로 휴식 :

   그래서 나 자신을 추천 가능한 방법의 몇 가지가 있습니다 데이터 세트를 분할함으로써 가능합니다.예를 들어, "User request tags updated"를 분해하려면 테스트 데이터를 분해하여 α 태그를 수신 할 데이터 만 가지고 "사용자 요청 태그를 α으로 업데이트했습니다." 모든 것이 α 일 것이므로 항상 알파를 할당하는 가장 간단한 코드를 작성하고 선택한 코드에 대해 걱정하십시오.

Answer 2

'수직 슬라이스'개념을 이용하는 것이 도움이 될 수 있습니다. 단순한 3 계층 응용 프로그램 (예 : UI/Logic/DB)을 상상해보십시오. 하나의 레이어를 만들고 다른 레이어를 만드는 대신 세 개의 레이어를 모두 세로로 슬라이스합니다. 초기 이야기는 "사용자로서 시스템에 로그인하여 액세스 할 수 있기를 원합니다"라고 할 수 있습니다. 완료되면이 이야기는 완전한 기능을 제공 할 수 있다는 점에서 잠재적으로 배송 가능하지만 실제로 배송 할 가치가있는 충분한 가치를 고객에게 제공 할 가능성은 거의 없습니다. 수직 슬라이스의 한 가지 이점은 모든 레이어에 대한 지식, 미래의 반복에서 사용할 수있는 지식을 배웠다는 것입니다. 당신이 익숙하지 않은 경우

는 투자 모델은 사용자 스토리에 대한 매우 유용합니다

I - 독립

N -

협상 V - 가치

E - 견적 가능

S - 적절하게 치수화 됨

T - 테스트 가능

Answer 3

부분 시스템에 대해서도 정확하거나 잘못된 결과를 측정 할 수 있다고 생각합니다. 다른 시스템 구성 요소를 스텁 아웃해야합니다. 확실히 가능합니다. 또한, 제 의견으로는 시스템의 한 부분이 다른 모듈에 대한 액터라는 것이 맞습니다.