이미 소장하고 있다면 판매해 보세요.
|
1부. 전략
1장. 애자일 제품 관리 __퀴즈 __제품 마인드 vs 프로젝트 마인드 __제품 관리란 무엇인가? __제품 관리 공백과 세 가지 V ____비전 ____가치 ____검증 __제품 관리와 스크럼 __제품 책임자 __제품 정의 __퀴즈 리뷰 2장. 비전 __퀴즈 __비즈니스 모델링 ____비즈니스 모델 캔버스 __제품 비전 ____집중 ____제품 상자 ____엘리베이터 피치 ____실용 대 감성 ____보편성 ____스크럼으로 비전 수립하기 __기술 전략 __퀴즈 리뷰 3장. 가치 __퀴즈 __가치의 정의 __가치 전달 __가치 지표 __증거 기반 관리 ____현재 가치 ____직원당 수익 ____제품 원가 비율(Product Cost Ratio) ____직원 만족도(Employee Satisfaction) ____고객 만족 ____출시 시기 ____릴리스 빈도 ____릴리스 안정화 ____주기 ____제품 작업 시간 지수(On-Product Index) ____혁신 능력 ____설치된 버전 지수 ____사용성 지수 ____혁신 비율 ____결함 __트래킹 지표 __돈이 흘러가는 곳 __부정적 가치 ____가시적 ____비가시적 __가치 중립성 ____지표의 왜곡 __퀴즈 리뷰 4장. 검증 __퀴즈 __이해관계자의 피드백 __시장의 피드백 ____최소 기능 제품 MVP ____기술 ____시장 ____카노를 통한 최소 기능 제품 ____프로모션 MVP ____마이닝 MVP ____랜딩 페이지 MVP ____오즈의 마법사 MVP ____단일 피처 MVP __방향 전환인가, 유지인가 __퀴즈 리뷰 2부 스크럼 5장. 경험주의 __퀴즈 __복잡한 문제 __확실성 퀴즈 __복잡성 시각화하기 __커네빈 ____명확(간단) ____난해 ____복잡 ____혼돈 ____모두 사용 ____질서 ____무질서 __복잡성 유형 __리스크 관리 __퀴즈 리뷰 6장. 스크럼 __퀴즈 __왜 프레임워크인가? __스크럼의 기둥 ____투명성 ____점검 ____조정 __스크럼 역할 ____제품 책임자 ____도메인 전문가와 이해관계자의 관계 ____개발팀 ____제품 책임자 및 개발팀 ____개발팀 = 제품 ____스크럼 마스터 ____제품 책임자 및 스크럼 마스터 ____기타 ____스크럼팀 ____이해관계자 __스크럼 산출물 ____제품 백로그 ____제품 책임자 및 제품 백로그 ____스프린트 백로그 ____제품 책임자와 스프린트 백로그 ____증분 ____제품 책임자와 증분 ____기타 ____‘완료(Done)’ ____제품 책임자와 ‘완료’ ____번다운·번업 차트 ____릴리스 번다운 __스크럼 이벤트 ____스프린트 ____제품 책임자와 스프린트 ____스프린트 계획 수립 ____제품 책임자와 스프린트 계획 수립 ____스프린트 목표 ____일일 스크럼 ____제품 책임자와 일일 스크럼 ____스프린트 리뷰 ____제품 책임자 및 스프린트 리뷰 ____스프린트 회고 ____제품 책임자와 스프린트 회고 ____기타 ____제품 백로그 개선 __반복과 증분 __소프트웨어 개발을 위한 애자일 선언문 __퀴즈 리뷰 3부. 전술 7장. 제품 백로그 관리 __퀴즈 __요구 사항이란? ____제품 백로그 ____사용자 스토리 ____비기능 요구 사항 ____에픽 ____인수 기준 ____~을 테스트한다(Test That…) ____~을 시연한다(Demonstrate That…) ____Given, When, Then(걸킨 구문) ____스파이크 __제품 백로그 순서 정하기 ____가치, 리스크 및 크기 측정 ____가치 ____리스크 ____규모 __‘완료’ ____‘완료’의 정의 ____‘완료’ 정의 예 ____완료가 제품 책임자에게 중요한 이유는? __‘준비’는 마음가짐이다 ____준비하기 ____린 요구 사항 관리 __스토리 매핑 ____스토리 맵 작성 단계 ____스토리 맵 탐색 ____스토리 맵 및 제품 백로그 ____과거와 미래 __임팩트 매핑 __성공 기준 __예시 기반 구체화 __퀴즈 리뷰 8장. 릴리스 관리 __퀴즈 __릴리스 이유 __릴리스 전략 ____대규모 릴리스 ____소규모 릴리스 ____기능적 릴리스 __추정 및 벨로시티 ____여러 팀 관리 __제품 확장 ____하나의 제품, 하나의 팀 ____확장 전에 팀 역량 필요 ____여러 제품, 하나의 개발팀 ____여러 개의 제품, 여러 개의 개발팀 ____하나의 제품, 여러 개의 개발팀 ____확장된 스크럼도 여전히 스크럼이다 ____넥서스 프레임워크 __보고 ____예측의 기본 ____예측 ____여러 제품에 대한 예측 ____완료율 ____몬테카를로 시뮬레이션 ____당신의 벨로시티는 무슨 색인가? __예산 책정 __거버넌스 및 컴플라이언스 __킥오프 __품질 ____정의 ____품질 유형 ____제품 품질 ____기술 품질 ____품질 유지 ____1사분면 ____2사분면 ____사전 제품 ____3사분면 ____4사분면 ____사후 제품 __퀴즈 리뷰 9장. 프로페셔널 제품 책임자 __제품 책임자 성공에 대한 이해 ____수용형 제품 책임자 ____제시형 제품 책임자 ____여러분 __스킬 및 특성 __성공 측정 |
Don McGreal
Ralph Jocham
박현철의 다른 상품
김낙일의 다른 상품
류미경의 다른 상품
|
[이 책에서 다루는 내용]
◆ 개발을 가이드하기 위한 외부 관점의 측정 방식을 활용해 외부에서 내부로의 성공 정의 ◆ 제품 책임자의 역할에 권한 및 기업가 정신 부여 ◆ 비즈니스 모델 공유를 기반으로 조직과 구성원들 간의 일체감 형성 ◆ 스크럼 제품 책임자 역할, 이벤트, 결과물을 효과적으로 적용 ◆ 제품 백로그 정의 및 관리, 적시에 협업 기반의 구체화로 활용성 상승 ◆ 투명성과 기술 부채 감소, 대규모 제품 개발 확장 ◆ 스크럼을 사용해 제품 팀의 작업에 자율성, 목적성, 숙달 고취 [이 책의 구성] 크게 세 개의 부로 나눴으며, 각 부분은 비교적 독립적인 주제의 장으로 구성했다. 1부, ‘전략’은 스크럼과는 거의 관련이 없으며 적절한 애자일 제품 관리와 제품의 ROI 극대화에 중점을 뒀다. 이를 달성하는 방법으로 세 가지 V, 즉 비전(vision), 가치(value), 검증(validation)을 소개한다. 2부, ‘스크럼’은 경험적 프로세스 제어를 정의하고 스크럼이 어떻게 복잡성 관리와 가치를 지속적으로 전달하는 도구로 작용하는지 밝히면서 시작한다. 스크럼 가이드의 도움으로 제품 책임자 역할에 특히 주의하며 각 역할과 산출물 및 이벤트를 정의한다. 3부, ‘전술’에서는 제품 백로그 및 릴리스 계획을 관리하기 위한 구체적인 프랙티스와 도구를 소개하고, 프로페셔널 제품 책임자가 된다는 것이 무엇을 의미하는지 살펴본다. [지은이의 말] 이 책은 사람이 만드는 제품 중 소프트웨어 제품을 효과적으로 관리하는 방법을 설명한다. 하지만 전력망, 원자력 발전소, 사과 과수원, 나노 로봇, 심지어 빗물 배수 시스템과 같은 다른 인공 제품에도 쉽게 적용할 수 있다. 사람이 구상하고 만들고 유지하고 결국에는 수명이 다 돼 제거하거나 대체하는 모든 것이 이 책에 담겨 있다. 특히 알려진 것보다 알려지지 않은 것이 더 많은 복잡한 제품들을 다룬다. 제품 창작자인 제품 책임자는 아이디어 공간을 인지하고, 다른 사람들이 가치 있고 유용하다고 여길 수 있는 것을 고안한다. 우리가 가르치고 유지하는 Scrum.org의 프로페셔널 스크럼 제품 책임자(Professional Scrum Product Owner) 과정에 많은 생각과 프랙티스를 담았다. 여기에 그 과정에 있는 것과 똑같은 정보를 포함해 다양한 정보를 담았기에 과정과 완벽한 동반자라고 생각한다. 우리가 가르치고 논의하면서 이 주제에 관해 글을 쓰는 것을 즐기는 만큼 여러분도 이 글을 읽는 것을 즐기기를 진심으로 바란다. - 돈과 랄프 [옮긴이의 말] ‘구슬이 서말이라도 꿰어야 보배’이듯, 아무리 좋은 방법이라도 실제 프로젝트나 제품 개발에 효과적으로 활용할 수 있어야 의미가 있다. 그래서 더 많은 사람이 애자일 방식에서 더 많은 가치와 가능성을 찾아 애자일을 실제로 적용하며 프로젝트나 제품 개발에서 성공할 수 있으면 좋겠다는 생각을 했고, 이런 생각이 이 책을 번역한 계기가 됐다. 하지만 전통적인 방법은 나쁘고 애자일 방법은 좋다는 오해는 하지 않길 바란다. 전통적인 방법론 체계도 프로젝트 성공을 위해 POC(Proof of Concepts), 파일럿, 프로토타이핑, 단계적 접근, 변화 관리 등 다양한 상황에 적용할 수 있는 많은 지식과 경험을 함께 적용해왔으며, 애자일이라 해도 충분한 준비 없이 적용한다면 오히려 지속해서 실패할 수도 있기 때문이다. SOA(Service-Oriented Architecture)나 PMBOK(Project Management Body of Knowledge)와 같은 전통적 개발 및 관리 방식 안에는 사람과 조직, 업무, 아키텍처, 관리, 프로세스 등 다양한 가치에 대한 통찰과 지식체계가 있다. 중요한 것은 부족한 예산과 기간, 충분하지 않은 자원, 신기술 및 비즈니스간 융복합 적용 전략, 코로나19와 비대면의 중요성 등 끊임없이 변화하는 현실 속에서 복잡하고 불확실한 상황이 점점 심화됨에 따라, 경쟁력 있는 제품 및 서비스 개발에 애자일 접근이 보다 바람직한 국면을 맞이하고 있다는 사실이다. 다만 애자일이 변화하는 현실과 모든 제약 상황을 극복하고 항상 프로젝트나 제품 개발을 성공적으로 이끌어주지는 못한다. 이 책은 인간의 내면에 존재하는 욕망과 더욱 치열해지는 조직의 생존과 번영을 위한 각고의 노력을 효과적으로 실체화하는 저자들의 좋은 사례와 통찰을 제시하고 있다. 미처 생각하지 못했던 중요한 가치와 수단들을 이 책에서 발견하고 활용할 수 있다면, 더 많은 프로젝트 및 제품 개발을 성공할 수 있을 것이라고 기대해본다. |
|
이뤄졌으면 하는 일이 있을 수 있다. 비전을 실현하거나(두 곳을 여행하는 새로운 방식), 제품을 생산하거나(호수에 있는 워터 슬라이드 또는 양자 컴퓨터), 어떤 제품을 개선하기를(더 빠르고, 더 효과적이고, 더 우호적인 고객 서비스) 바랄 수도 있다. 그게 무엇이든 원하는 것을 이루는 데 필요한 권위와 자원이 있는 사람이라도 그 일을 이루는 것은 매우 어렵다. 단지 무엇을 원하는지와 필요한 자금, 물품을 다른 사람에게 적절하게 말하기만 하면 훌륭하거나 적어도 만족할 만한 결과를 얻게 될 것으로 생각한다. 하지만 생각대로 되지 않는다. 다른 사람들과 소통할 때는 상대가 우리의 뜻을 이해할 것이라 여긴다. 그러나 꼭 그렇지만은 않다. 우리의 말이 유창하지 않거나 이해하기 어려울 수도 있다. 가끔은 대화 상대가 멍청할 수도 있다. 대화가 시기상조일 수도 있지만 기다려주는 사람은 없다!
이 책은 우리의 욕망을 조심스럽고 일관되고 가능한 한 소란스럽지 않고 성가시지 않게 전달하는 방법을 알려준다. 그렇게 하지 않으면 우리를 지지하는 사람들이 떠나고, 돈을 낭비하며 돌이킬 수 없는 피해를 볼 수 있다. 스크럼의 가장 큰 장점은 전달하는 내용이 명확한지 그리고 다른 사람들이 그 내용을 얼마나 잘 받아들이는지를 자주 확인하는 여러분의 능력에 달려 있다. 전달하는 내용의 명확성과 결과를 자주 점검하는 것이 중요하다. 결과가 어떻게 될지 소통하는 법을 이제 막 배우기 시작한 시점에는 특히 그렇다. 소통을 잘할수록 내용은 더욱 정확해진다. 노력을 많이 하지 않고도 명확하지 않은 것을 명확한 것으로 바꾸며 결정하는 방법을 배우면 원하는 결과를 얻을 수 있다. 원하는 것이 있고 스크럼을 사용해 의사소통과 결과물을 개선할 때 필요한 역할이 제품 책임자(Product Owner)다. 돈 맥그리얼(Don McGreal)과 랄프 조참(Ralph Jocham)은 사람들이 스크럼을 사용해 제품 책임자 역할을 할 수 있도록 이 책을 저술했으며, 두 저자가 여태까지 해온 일을 잘 전달하고 있다. - 켄 슈와버 (Ken Schwaber) |