User-stroy, Valuable in the INVEST

 

Valuable – 사용자와 고객 혹은 구매자에게 가치 있다

출처 : xp123.com/articles/valuable-stories-in-the-invest-model/

 

스토리는 가치가 있어야 한다. 우리는 누구에게나 가치가 있어야 하는 것이 아니라 고객에게 가치가 있어야 한다. 개발자는(합법적인) 우려 사항이 있을 수 있지만 이러한 우려는 고객이 이를 중요하게 인식하게 만드는 방식으로 구성된다.
이것은 스토리를 분할할 때 특히 문제가 될 수 있다. 전체 스토리를 네트워크 계층, 지속성 계층, 논리 계층 및 프레젠테이션 계층과 같은 다중 계층의 케이크라고 한다. 스토리를 나누면 그 케이크의 일부만 제공한다. 우리는 고객에게 전체 케이크의 본질을 제공하고 싶으며 가장 좋은 방법은 레이어를 수직으로 자르는 것이다. 개발자는 종종 한 번에 하나의 레이어에서만 작업하려는 경향이 있다. 그러나 전체 데이터베이스 계층에서 프레젠테이션 계층이 없는 경우 고객에게 거의 가치가 없습니다.

 

"이 프로젝트의 가치는 무엇입니까?"

• 명확하게 대답할 수 있어야 합니다.
• 다양한 이해관계자가 어떻게 혜택을 받고 있는지 알 수 있어야 한다.
• 이해관계자 : 사용자, 구매자, 관리자, 개발 조직, 스폰서 등

 

개발자에게만 가치 있는 스토리를 피하라!

ex> 데이터 관리

• 개발자 관점 : 모든 데이터베이스 연결은 커넥션 풀을 통해 이루어져야 한다.
• 고객 관점 : 사용자 라이선스 5개로 50명까지 데이터베이스에 연결하여 사용할 수 있어야 한다.

ex> 로그 관리

• 개발자 관점 : 모든 에러 처리 및 로그 생성은 공통 클래스를 통해 이루어져야 한다.
• 고객관점 : 모든 에러는 사용자에게 보여야 하며, 일관된 형태의 로그로 기록되어야 한다.

 

고객이 직접 스토리를 작성하는 것이 가장 좋다.

• 고객 : 이해관계자 모두.
• 인터뷰 또는 VOC 를 통해 요구사항을 수집할 수 있다.

 

What is Value? : 고객에게 필요한 가치를 생각한다.

IRACIS means: - Increase Revenue. (수익 증대) => 새로운 기능을 추가하거나 기능을 개선하여 지금보다 더 많은 비용을 지불하도록 함. - Avoid Costs. (비용 절감) => 사람을 대체 또는 줄일수 있는 프로그램을 도입. (ex> 콜센터 지원 프로그램) - Improve Service. (서비스 개선) => 기능이나 품질을 개선하여 고객의 이탈을 방지한다. (ex> skype 통화 품질 개선) others: - Meet Regulations (규정 준수) => 정부 기관의 규제나 특정 도메인의 법규(상황)에 의해 반드시 필요한 기능 개발 및 고객에게 기능 제안 (ex> 비대면 솔루션) - Build Reputation (평판 구축) => 시장에서 우리의 가치를 높이기 위해 수행되는 작업 (ex> 무료 버전 제공) - Create Options (옵션 생성) => 더 많은 유연성을 제공하기 위해 제공. (ex> 고객사 요청 DBMS 로의 변경) - Generate Information (정보 생성) => 고객이 더 나은 결정을 할 수 있는 정보를 제공 (ex> A-B 테스트 기능) - Build Team (팀의 구성) => 팀의 구성이나 발전을 위해 필요한 기능 때문에 선택될 수도 있음.

Valuing External Impact : 외부에 미치는 영향을 확인한다.

소프트웨어는 현실세계에서 무엇을 달성하기위해 만들어졌다. 시스템 효과에 초점을 맞춘 전통적 방식 스토리 - 시스템이 완벽한 기술로 구현된것 처럼 시스템 동작을 설명한다. - 시스템 외부에서 내부로 이동하거나 내부에서 외부로 나가는 것을 명확히 한다. 작성된 스토리는 제품 소유자와 사용자(고객)가 명확히 이해할 수 있어야 좋은 선택을 할 수 있다. - 우리가 사용하고있는 솔루션(기술)에 대한 "스토리" - 시스템 제작자 또는 사용자가 원하는 것에 대한 "스토리"

Value for Whom? : 누구에게 가치를 제공할 것인가?

우리가 개발한 소프트웨어로부터 얻는 가치는 사람들마다 다양하다. 개발팀의 업무 중 일부는 다양한 이해 관계자의 요구 사항을 균형있게 조정하는 것입니다. - User => 실제로 소프트웨어를 사용하는 사용자의 요구사항. => 소프트웨어를 사용하는 간접 사용자의 요구사항. => 예로, 콜 센터에서 상담원은 직접 사용자이고 고객은 간접 사용자이다. - Purchasers => 구매자의 요구가 사용자의 요구와 완전히 일치하지 않는 경우가 많다. => 예로, 도입한 소프트웨어에 대한 모니터링 도구는 시스템 관리자만 필요하다. - Development Organizations => 표준 준수, 기본 언어 및 아키텍처 사용 등에 반영되는 요구 사항이 있을 수 있다. - Sponsors => 투자 수익을 원한다.

 

 

---

 

• INVEST in User-Story
• (I)ndependent - 독립적이다
• (N)egotiable – 협상 가능하다
• (V)aluable – 사용자 및 고객에게 가치가 있다
• (E)stimable – 추정 가능하다
• (S)mall - 작다
• (T)estable – 테스트 가능하다

참고 사이트

INVEST in Good Stories, and SMART Tasks - XP123

 

---