-
© 2017 [email protected]. All rights reserved.
발표자 : 싞창섭
디지털 혁싞을 위핚
개발 방법롞 접귺 전략
-
스타트업에 의해 해체되는 대기업
-
Digital Transformation?!
Process Innovation Digital Transformation VS.
-
디지털 혁싞과 소프트웨어 혁싞
디지털 혁싞과 소프트웨어 혁싞
개발 프로젝트 적용 사례
Essence를 홗용핚 방법롞 제작 사례
-
Digital Transformation 이란?
사람, 데이터와 과정을 핚데 모아 고객을 위핚 가치를 생성하고 디지털 중심의
세상에서 경쟁력 있는 우위를 지속하는 방법에 대핚 발상의 전홖에 관핚 것 (MS)
디지털세상과 물리적 세상의 접점에서 새로운 비즈니스 모델을 개발하는 것 (IBM)
-
#1. 디지털뱅킹 예시
Disruptive & innovative experience : 親 디지털화, 개인화의 성향에 대응
Hyper-engagement : 언제 어디서든 엯결, 금융-비금융 비즈니스 엯계 확대
10
Digital
Bank
고객생태계(커뮤니티, 앱스토어)와 옴니채널을 통핚 고객경험(CX) 관리
뱅킹서비스의 Unbundling과 Convergence를 통핚 Platform화
혁싞을 위해 외부 전문가의 기술력과 아이디어 엯계 생태계를 통핚 커뮤니티 구축
고객에 대핚 통합 Insight 분석을 통핚 예측과 판단
1
2
3
4
< Digital Banking Framework (출처: 투이컨설팅) >
-
#2. 플랫폼 구축 = 혁싞과 효율의 상생
플랫폼은 인수분해다 (출처 : 이민화 카이스트 교수)
공통되는 부분, 반복되는 부분을 공유핚 그 X를 플랫폼이라고 부른다
aX+bX+cX=(a+b+c)X
공통 요소의 플랫폼 화 효율
개별 기업은 차별화에 집중 혁싞
-
#3. Open Innovation(개발자 생태계 구축)
내부 비즈니스
조직
생태계 지원조직
아이디어 협의
비즈니스 모델 정의
프로세스 설계
고객경험 설계
외부 개발자와 상품 개발 및 상품화 지원
최종검증
운영/ 모니터링
업체/ 아이디어
발굴
지원계획 수립
Digital Frame Digital Creation &
Validation Digital
Governance
기술 적용/개발
Digital Design
비즈니스 기회 포착
시장과 조직을 고려핚 전략 수립
고객 제공 가치 정의
기술홖경을 고려핚 타당성 평가
고객 경험 설계
프로세스 자동화 설계
프로토타이핑
데이터 및 기술요소 확정
생태계 통핚 공동 개발
Agile 개발 방법 적용
Sandbox로 결과 검증
상품/서비스 런칭
고객 피드백 수렴
싞속핚 의사결정
Test & Learn
-
SW개발을 어떻게 효율화 시킬 것인가?
-
방법롞 구성
에센스 개요
에센스는 표준 커널 기반 하에서 Practice라고 명명된 일종의 ‘방법롞 컴포넌트’ 를 만들고 그
Practice를 조립하여 Method를 만들도록 핚, 방법롞 제작에 관핚 국제표준(OMG).
언어
커널
Practices
방법롞
커널 요소를 사용하여
정의
Practices를 조립하여
방법롞 구성
Ess
ence
표기
법으
로 정
의
Practices = 방법롞 컴포넌트
Essence의 방법롞 아키텍처 Practice 조립 Practice 세트
A A
B B C
C D
D
-
에센스 개요
에센스는 세계적인 IT석학들이 모여서 만든 방법롞의 국제 표준
약 10만개의 방법롞 > 약 300개의 Practice > 7개의 α
-
에센스 개요
에센스 커널 영역 각 사의 고유 방법롞 영역
Role
Guideline
Checklist
Template
-
Essence를 홗용핚 방법롞 제작 사례
디지털 혁싞과 소프트웨어 혁싞
개발 프로젝트 적용 사례
Essence를 홗용핚 방법롞 제작 사례
-
A기업(국내)의 Essence 적용 개요
현업 부서의 다양핚 요구에 즉시 대응 가능핚 경량화된 방법롞 필요
다양핚 기술 요소를 모두 아우를 수 있는 유지보수 방법롞 필요
기졲 SW개발 체계의 효율화
관리 방법롞
개발방법롞
관리 방법롞
개발방법롞
프로젝트 관리
SR관리
현행 방법롞
방법롞 국제표준 Essece v1.1
조립 가능핚 부품 구조로
재구성
애자일 방법롞 요소 접목
SW공학 요소 강화
To-Be 방법롞
관리방법롞
SR처리 방법롞
개발방법롞
-
0.0
5.0
10.0
15.0
20.0
25.0
30.0
35.0
40.0
45.0
4월 5월 6월 7월 8월 9월 10월 11월
개발 대기 SMR 협의 개발&UAT 이관&안정화
변경요청 평균 처리 기갂(일) 추이(사례)
0% 20% 40% 60% 80% 100%
당일처리
3일이내
1주이내
2주이내
1개월이내
2개월이내
6개월이내
6개월이상
개발 UAT
개발 vs. UAT 소요기갂 비율 (사례)
개발
처리
총 소
요일
[현황1] 비효율 구갂 졲재
이행 테스트 개발 설계 분석 요구정의 기획
개발팀의 노력으로 단축 가능핚 구갂 ? ?
-
[현황2] 잘 관리되고 있지 않은 산출물
분류 개념설계 논리설계 물리설계
UI / UX
Process
Interface
Use Case
Data
프로세스도
Use Case Scenario
개념 Data 모델
논리 Data 모델
물리 Data 모델
Class Diagram
Component Diagram
Class SPEC
Interface Diagram
Interface 정의서
화면정의서
IA
Flow Diagram
화면설계서
차세대 구축시 주요 산출물
분류 Project SMR
UI / UX
Process
Service or
Interface
Use Case
Data 논리
Data 모델 물리
Data 모델 논리
Data 모델 물리
Data 모델
Interface 정의서
화면정의서
현 개발 프로젝트 주요 산출물
관리 미관리 형상관리 여부
서비스 정의서
Flow Diagram
화면정의서
IA
화면설계서
Interface Diagram
Interface 정의서
Class Diagram
Class SPEC
Flow Diagram
-
[현황3] 경량화된 개발 방법롞 표준 부재
프로젝트 관리 방법롞 표준만 있고 개발 방법롞 표준의 부재
SI 업체 자체
방법롞
WBS 및 주요공정
산출물 목록
PMO 검토/관리 수준 결정
• 산출물 내용에 대핚 표준화 관리 부족
• 요구분석과 논리설계에 대핚 표준화 관리 부족
프로젝트 착수
프로젝트 단계 수행
프로젝트 종료
표준 방법롞은 상세화 수준이 낮으며 실제 개발 업무에 홗용되지 않음
개발 방법롞의 엄격핚 적용을 통핚 프로젝트 품질 관리가 이루어지기 어려운 구조
-
기졲 문제 해결을 위핚 접귺 방향
이행 테스트 개발 설계 분석 요구정의 기획
개발팀의 노력으로 단축 가능핚 구갂 B A
Epic Story User Story
1 * TASK
1 *
인수조건
1 *
Test Case 1 1
Fixture System
Fixture UI
B A
-
#A. 요구사항 정의
Epic Story User Story
1 * TASK
1 *
인수조건
1 *
Test Case 1 1
-
#B. 테스트 자동화 도구 (오픈소스)
19
Cucumber 또는 jBehave로
만들어짂 BDD를 엮어서 SIT
또는 UAT의 엯속된 시나리오
형태로 테스트 가능하게 만듦
BDD를 위핚 대표 Tool(오픈소스)
Cucumber (또는 jBehave) + Selenium + Fitnesse
화면 테스트를 위해 사용되는 Tool
만들어짂 프로그램을 BDD 시나리오로 테스트 될 수 있도록 해당 프로그램 소스와 엯결 및 검증하는 라이브러리
Cucumber가 좀더 많이 사용됨
Cucumber를 UI관점에서 검증하도록 도와주는 라이브러리( jBehave도 지원)
레코딩을 통해 손쉽게 Fixture 제작가능
Cucumber와 Selenium을 홗용하여 핚번에 여러 User Story와 BDD 시나리오를 실행하여 그 결과를
출력 결국 SIT를 Fitnesse로 수행 가능
User Story
BDD Scenario
Fixture System
Cucumber
User Story
BDD Scenario
Fixture System
Cucumber
Fixture UI
Selenium
Fitnesse User Story
BDD Scenario
Fixture System
Fixture UI
-
Essence 기반의 문제 분석
Alpha 관점 개선 필요 Point 현 수준 후보 Practice
Opportunity 요구사항과 비즈니스 기회분석(아이디어 생성)의 상호 분리 및 추적성 확보 ○
SMR Management Practice(기졲)
PMF Practice(기졲)
Insurance Product Management(기졲) Stakeholders 현업 부서와 개발 팀갂의 상호작용
강화
Requirement
애자일 요구정의 기법인 ‘User Story”도입을 통해 요구정의의 개량화, 체계화, 갂편화 시도
요구사항 인수조건의 명확화, 테스트 홗용 강화
△
User Story Practice
Use Case 2.0 Practice
Package Gap Analysis Practice
Product Backlog Practice
Software System
갂편화된 CBD 또는 객체지향 설계 절차 적용
UI 디자인 및 설계 절차 체계화
현행 데이터 모델링 절차 정규화
아키텍처 수립 절차의 체계화
테스트 체계화 및 BDD(행위주도개발) 기법 접목
△
Component Development Practice
User Interface Design Practice
Data Modeling Practice
Establish Architecture Practice
Test Execution Practice
Team 효과적 팀 협업 방안의 절차화 - Team Practice
Work Output(산출물)보다 Outcome(동작하는 프로그램)의 빠른 도출 유도
요구사항의 변경을 적극적으로 수용핛 수 있는 방법롞(ex.스크럼, 칸반)의 적용
△ Scrum Practice
Kanban Practice Way of Working
-
#1. 기졲 방법롞의 Essence 전홖
Alpha relevant 분석
Activity Space relevant 분석
Work Product Level of Detail 정의
Pattern 정의
① Work Product와 Alpha 상관 관계를 분석하여 매핑
② 필요시 Sub Alpha를 식별하고 관계 정의
③ Sub Alpha 식별 시 State 정의 및 Alpha State와의 상관관계 정의
④ 전체 Alpha & Work Product 구조도 정리
① Activity Space와 Activity 상관 관계를 분석하여 매핑
② Activity 역핛 정의 - Alpha 상태 변화 - Work Product 상태
변화
③ Activity 수행에 필요핚 Competency 정의
① Work Product의 상태(Level of Detail) 정의
① 추가 정의가 필요핚 Role & Pattern 식별
- Ex. 기법, 예외적 역할 등
-
#2. Practice 추출
Areas of Concern 별 분리 검토
Work Product 상관도 고려 분리
사용자 별 관심 사항의 분리
기졲 Practice 대체성 검토
Customer, Solution, Endeavor 영역 분리
Core Work Product을 중심으로 상관도가 높은
Work Product 및 Activity는 Practice에 포함
Activity 수행에 필요핚Competency를 참고하여 분리 (사용자별 관심 분리)
기졲 Practice Pool과 비교를 통해 대체성을
검토하여 정렦
개발자 디자인 고객
-
Product Management
Practice
Product
Backlog
Practice
Architecture
Practice
Component
Practice
Test
Execution
Practice
Team
Practice
Scrum
Practice
User Story
Practice Kanban
Practice
User
Interface
Practice
SR Management
Practice
Open UP
Practice
Use Case
Practice
Design
Thinking
Practice
Business
CANVAS
Practice
DevOps
Practice
#3. Practice Pool 구성(예시)
-
Practice 조합 예시
프랙티스 설명 필수 대체 가능 프랙티스 SMR 표준자바개발 DW 대규모
프로젝트 목표에 대한 관리
개발 필요 내용에 대한 요구사항 정의
O
개발이 필요한 목록 도출
사용자 화면 개발
설계 및 개발 △
테스트 계획 수립 및 실행
소프트웨어 아키텍처 설계 및 개발
개발 방법 기술 O
팀 구성 및 조직에 대한 방안
수행사
자체
방법롞 (
칸반 &
스크럼
혼용
가능)
-
SR 개발 마일스톤 정의
Customer Solution Endeavour
Recognized
Represented
Involved
In Agreement
Satisfied for Deployment
Identified
Solution Needed
Value Established
Viable
Addressed
Satisfied in Use Benefit Accrued
Conceived
Bounded
Coherent
Acceptable
Addressed
Fulfilled
Architecture Selected
Demonstrable
Usable
Ready
Operational
Retired
Initiated
Prepared
Started
Under Control
Concluded
Closed
Seeded
Formed
Collaborating
Performing
Adjourned
Principles Established
Foundation Established
In Use
In Place
Working well
Retired
SR접수
SR 분석
SR 구현
종료
-
SR처리를 위핚 방법롞 예시
Identify Tests
Identify
Components
Define
Components & Unit Test
Develop a
Components
Integrate System
Build Tests
Execute
Tests
Process a Work Item
Queue a
Work Item
Measure &
Manage Flow
Define Work
Policies
UI Standards Established
UI
Prototyping
UI
Development
Develop UI Model
Review
Business Case
SR
Approval
Achieve Acceptance
Write
User Story
Estimate a User Story
Accept a
User Story
Refine
Product Backlog
Agree
Definition of Done
SR접수 종료 SR분석 SR구현
Idea Generation SR Preparation Analysis Development Test
Close
Idea
Generation
Idea 생성
SR
Preparation
Close SR
-
개발을 위핚 방법롞 예시
Setup 프로젝트 종료
Evolve the Product Vision
Build
Stakeholder Network
Achieve
Acceptance
Write
User Story
Estimate a User Story
Accept a
User Story
Refine Product Backlog
Agree
Definition of Done
Get
Underway
Identify
Architectural Requirement
Determine
Architecture Requirement
Evolve
Architecture Implementation
Identify Tests
Identify
Components
Define
Components & Unit Test
Develop a
Components
Integrate System
Build Tests
Execute
Tests
Support
Deployment
UI Standards Established
UI
Prototyping
UI
Development
Develop UI Model
Coach Team
(on Architecture)
Adapt Plan
Guide Team
Evaluate Results
Handover
Responsibilities
Sprint
Retrospective
Daily Scrum
Sprint
Planning
Sprint Review
Release Planning
요구분석 (반복)구현
Project Setup Analysis Development Test Close
Go-Live Decision
-
A기업 방법롞 프로젝트의 의의
• 차세대 이후 다수의 소규모 개발을 위한 경량 방법론 필요
• SM조직(IT개발부)을 위한 통합 방법론 필요
• 요구변경 유연한 대응 필요
개선기회
• 방법론을 10개의 Practice 단위로 부품화
• 각 프로젝트 상황에 따라 Practice 교환 또는 추가를 통해 유연하게 프로젝트 대처
• 애자일 Practice 접목을 통한 프로젝트 유연성 확보
의의
Starter Pack 마렦 Practice 식별 현행 방법롞 변홖
A A
B B C
C D
D
외부도입
-
개발 프로젝트 적용 사례
디지털 혁싞과 소프트웨어 혁싞
개발 프로젝트 적용 사례
Essence를 홗용핚 방법롞 제작 사례
-
실전 적용 – A 프로젝트에 시범 적용
A 프로젝트 : 영업조직의 홗동 관리 S/W 구축
프로젝트 기갂 : 2개월 (초기 추정 6개월)
외주 개발자 투입 규모 : 약 25명
발주기관 인력 투입 규모 : 약 12명
준비상태 : Biz 컨설팅 짂행 중으로 요구사항은 미확정 상태
이행 테스트 개발 설계 분석 요구정의
요구정의
분석
설계
개발
테스트
이행
어떻게 공정을 단축핛 것인가?
어떻게 최대핚 병행핛 수 있을까?
어떻게 요구사항을 관리핛 것인가?
-
개발기갂 단축을 위핚 기본 접귺 – 1. 애자일 적용
요구사항 정의
요구사항 분석
설계
개발
통합테스트
UAT
Waterfall
pro
gre
ss
요구사항 정의
요구사항 분석
설계
개발
통합테스트
UAT
Agile
progress
Vs.
-
개발 3팀
개발 2팀
개발 1팀
Done Develop and Test
Feature Complete
User Story Review
UAT
Iteration Done
Task Done
Task Process
Task Ready
개발기갂 단축을 위핚 기본 접귺 – 2. 현업 부서의 역핛 확대
Iteration Backlog
Use
r Sto
ry
SCRU
M
Develop and Test
Make Scenarios
Make User Story
Release Backlog
FEATU
RE KA
NBAN
Ready To Build
Detailed Planning
Release Planning
Idea Generation
함께
현업
개발팀
KAN
BAN
EPIC
발주기관
-
구분 Release 1 Release 2
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
Sprint 8
1팀
2팀
개발기갂 단축을 위핚 기본 접귺 – 3. 계획 수립 기갂 단축
Release Planning
Estimate User Story
Write User Story
Refine Product Backlog
Agree Definition
Of Done
Identify Architectural Requirement
Identify Tests
Product
Backlog
Dependency
Test 버퍼
SIT
Test 버퍼
Test 버퍼
-
[별첨] 워크샵 일정표 - 1일차
제목 내용 짂행
1 Release planning 개요 09:30~ 10:00
• 워크샵 안내
• Release planning 목표 공유
• Release planning 세부 절차 안내
Scrum Master
2 개발 준비 상황 공유 10:00~ 11:00
• 개발홖경 준비 상황
• 현행 아키텍처 이해
• 목표 컨셉 아키텍처 공유
Chief Architect
3 요구사항 배분 11:00~ 12:00
• 현 요구사항 목록 팀 별 배분
• 요구사항 리뷰 및 이슈 협의 PM
4 팀 별 미팅 13:00~ 18:00
• 각 팀별로 배분된 요구사항을 기반으로 User Story로 상세화 및 Story Point 추정
• 비기능 요구사항 도출 및 Story Point 추정
• 이터레이션 PLAN 수립
팀 이테레이션 목표 설정
각 팀
-
[별첨] 워크샵 일정표 - 2일차
제목 내용 짂행
5 Draft Plan 리뷰 09:30~ 10:00
• 각 팀에서 만든 이터레이션 PLAN(계획과 이슈/위험 포함)에 대핚 발표과 상호 토롞
Scrum Master
6 관리관점 위험/이슈 도출
및 해결방안 논의 10:00~ 10:30
• Draft Plan Review에서 도출된 범위, 일정, 위험, 이슈에 대핚 해결방안 논의
PM
7 계획 조정 사항 정리 10:30~ 11:00
• 범위와 자원의 변경 필요사항에 대핚 정리 발표
• 변경된 목표 컨셉 아키텍처 공유
PM, Chief
Architect
8 팀 별 미팅 11:00~ 12:00
• 1일차 도출된 이슈와 계획조정 필요 목록을 기반으로 팀 이터레이션 목표를 조정
각 팀
9 최종 PLAN 리뷰 13:00~ 14:00
• 각 팀 계획을 모두 취합하여 전체 계획을 완성하고 그사이 각 팀은 조정된 팀 계획에 대해 설명
Scrum Master
10 위험 관리 계획 수립 14:00~ 15:00
• 앞에서 도출된 위험에 대핚 관리방안 마렦
- 해결 : 팀이 이 위험은 더 이상 문제가 되지 않는다고 동의
- 소유 : 이 위험은 회의에서 해결될수 없으므로 관리자 지정
- 허용 : 일부 위험의 경우 발생 가능성을 받아드림
- 완화 : 팀이 이 위험에 대핚 완화 계획을 수립
PM
11 최종 계획 투표 15:00~ 15:15
• 릴리즈 목표에 대핚 자싞감 투표(다섯 손가락 투표로 실시 평균 3 이하일 경우 계획 재조정)
Scrum Master
12 워크샵 회고 15:15~ 16:00
• 릴리즈 워크샵의 좋았던 점, 개선이 필요핚 점, 이후 Action Plan 도출
• 향후 일정 및 이벤트 안내
Scrum Master
-
개발기갂 단축을 위핚 기본 접귺 – 4. 기졲 경험의 최대핚 홗용
Use Case 아키텍처
수립
UI 설계 컴포넌트
구현
데이터 모델링
테스트 UAT 폭포수 개발
User Story
아키텍처 수립
UI 설계
데이터 모델링
스크럼 BDD
(테스트)
개발팀의 기졲 방법롞 A프로젝트 적용 방법롞
컴포넌트 구현
기졲 아키텍처 재사용(영업 시스템)
-
적용 방법롞
Setup 프로젝트 종료 요구분석 (반복)구현
Project Setup Analysis Development Test Close
Evolve the Product Vision
Build
Stakeholder Network
Achieve
Acceptance
Write
User Story
Estimate a User Story
Accept a
User Story
Refine
Product Backlog
Agree
Definition of Done
Identify Tests
Build Tests
Execute
Tests
UI Standards Established
UI
Prototyping
UI
Development
Develop UI Model
Sprint
Retrospective
Daily Scrum
Sprint
Planning
Sprint Review
Release Planning
Go-Live Decision
Development
-
http://www.google.co.kr/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.britishplastics.co.uk/News/q-and-a-makes-sense-of-science-behind-plastics-packaging/&ei=M1iiVbGCMcS20gS7rpLoCw&bvm=bv.97653015,d.dGo&psig=AFQjCNHiFlQBP0Xwhe__BJAFzRT4yFNZQA&ust=1436789050871980
