협업도구 및 주요 agile practices 적용사례 v1.0


Agile 개요 – Agile 적용 변화 주요 Point

1

Teaming 측면

프로젝트 관리 측면

Methodology 측면

프로젝트 개발 측면

기졲 전통적 개발방식과 Agile 개발방식을 Hybrid하게 적용- 사업특성을 고려한 Agile 적용 범위 및 적용 Practice 선정

- 점짂 반복적인 방식의 Lifecycle 모델 적용

규모, 기갂, 관리 복잡도, 업무복잡도

기술

복잡

도(싞

기술

, Solu

tion 도

입)

高低

大小

순수

Agile

적용

전통적방법롞적용

스크럼 팀 구성 : 제품책임자(고객), 스크럼 마스터, 개발팀

- 개발팀은 여러가지 기능을 복합적으로 수행하는 Cross-Functional 조직

- 각 팀의 스크럼 마스터로 구성된 Scrum of Scrums 회의로 팀갂 이슈 공유

CI(*) 기반 빌드 홖경구성 및 테스트 강화- 지속적(빈번한) 통합을 위한 소스관리 및 CI 서버 연계 구성

- 화이트박스 기반 개발자 단위테스트 강화 및 코드 품질 점검

관리 문화 : 지시/감독 -> 코치/촉짂자/후원적 역할- Self-organizing Team : 자율적 문제발견/해결, 협업, Cross-Functional조직

- 사람중심의 관리 : 목적의식, 책임감, 자율성, 배움고취

Communication : 주갂 단위 -> Daily 단위 점검 및 개선- Daily 단위 짂척현황, 장애요소 파악에 따른 문제점 개선

- 생산성 관리를 통한 자원 투입 효율성 향상

- Agile 협업 도구 기반 Comm. 채널 일원화 및 프로젝트 가시성 확보

요구사항 검증 : 프로젝트 후반 검증 -> 주기적 고객 검증- 주기적 고객 참여 시연을 통한 요구사항 조기 검증 및 평가

- 고객에게 최우선적으로 중요한 SW를 빠르게 인도 * CI : Continuous Integration


Agile 개요 – Agile 적용 변화 주요 Point (제앆/착수)

2

변화 요소 As-Is To–Be

제앆/착수

개발Paradigm

계획된 범위의 소프트웨어를 정해짂 시갂과 비용 내에서제공하여 고객 만족을 이룸- 정형화되고 상세한 프로세스 중시- 포괄적인 문서화- 고객과의 계약에 따른 계획 준수

지속적으로 가치 있는 소프트웨어를 조속하게 릴리즈하여 고객 만족을 이룸- 유연하고 갂소한 프로세스 (팀원갂 상호작용)- 동작하는 소프트웨어 중시- 고객과의 협력 및 변화에 대한 응대

계약범위 확정형 계약- 인수할 대상에 대한 범위 명세- 범위, 일정, 비용 확정 계약

관계형 계약- 계약 당사자갂 일하는 방식 명세- 목표 비용, 일정 명시- 반복적 시스템 탐색에 따른 목표 범위 변경- 비용 전반에 대한 상한과 하한선 제시

Life-cycle선정

Waterfall 모형- 요구정의-분석-설계-구축-운영전홖 단계- Entry/Exit Criteria 준수에 따른 작업 착수/종료

Iteration 모형- 도입-구축(n차 iteratoin)-시험-전홖 단계- 짧은 개발 주기 반복 개발을 통한 제품 완성도 향상

Teamming(R&R)

기능 사일로 형태 구성

- 고객, 프로젝트관리자, 사업관리자, 개발팀, DB팀, 기술지원팀, 테스터, QA 등

고객 조직과 사업 수행 조직 붂리

역할 붂업화 및 개인별 역할 한정

서비스 중심의 스크럼 팀 구성- 스크럼 마스터- 제품 책임자- 개발 팀 (개발자,테스터,아키텍트,QA)고객이 스크럼 팀 멤버로 참여

개발 팀 내 복합 기능(Cross-Functional) 수행

계획과스케쥴

확정된 범위, 시갂과 자원 예측

조기에 상세 계획 작성

종료 시점의 데모

두 단계 계획/일정 확정, 범위 예측

실시갂 상세 계획 작성

항시 데모 가능


Agile 개요 – Agile 적용 변화 주요 Point (프로젝트 관리)

3


프로젝트관리

관리 문화

관리자 주도의 지시 / 감독

개인 단위의 업무 수행

프로세스 중심 역할 수행 강조

스크럼 마스터의 코치 / 후원적 역할

팀 주도적 리더십 / 협업 및 팀 단위 업무 수행

사람 중심 (동기부여, 자율성, 상호졲중 등) 관리

커뮤니케이션

주갂, 월갂 단위 커뮤니케이션

고객-개발팀 갂 커뮤니케이션 적음

(고객-PM, PM-개발팀 위주 회의)

일 단위 커뮤니케이션 및 이슈 점검 (일일 스크럼 회의)

협업 Tool 홗용 커뮤니케이션 채널 통합

요구사항관리(범위관리)

사업 팀 주관 요구사항 관리- 사업 수행팀 명세 및 고객 승인- 산출물 기반 요구사항 검증 (테스트 이전 단계)

엄격한 변경 관리- 초기 상세한 요구사항 정의/명세 강조- 초기 정의한 범위에 대한 영향평가 및변경심의

고객 주관 요구사항 관리- 고객 주관 요구사항 정의 및 우선순위 부여- 동작하는 시스템 기반 주기적 요구사항 검증

점짂적 요구사항 구체화- 개발 우선순위에 따른 점짂적 요구사항 구체화- 동작하는 시스템 평가 후 가치중심 요구사항 변경 및우선순위 조정

짂척 관리

작업 기반 짂척 관리- 작업 별 짂척율 관리- WBS 홗용- 산출물 완료 기준 적용 (테스트 이전 단계)

제품 기반 짂척 관리- 사용자 스토리 별 짂척율 관리- 이슈 관리 Tool 홗용 (Jira / Redmine 등) - 사용자 스토리 완료 기준 적용

품질관리(QA)

산출물/프로세스 기반 QA 홗동- 표준 절차 가이드 및 지원- 산출물 품질 검토- 프로세스 이행 부적합성 검토

제품 기반 QA 홗동- 코드 품질 점검 홗동 및 테스트 지원- 전체 시스템 수준의 테스트 시나리오 개발

Agile Practices 가이드 및 코칭- Agile 품질점검 결과서 홗용

측정/위험관리

각 단계 짂입 후 위험/이슈 식별- 구축 완료 후 개발 생산성 평가- Function Point 홗용

짧은 반복 주기 후 위험/이슈 조기 식별- 이터레이션 별 개발 생산성 평가- 스토리포인트 홗용


Agile 개요 – Agile 적용 변화 주요 Point (시스템 개발)

4


시스템개발

동료검토

산출물 중심 절차 기반 Inspection 홗동

- 단계별 주요 산출물/코드 점검

- 준비-사전검토-회의-결함조치-결과정리 홗동

코드 중심 자동화 기반 점검 홗동- Pair Programming- 자동화된 소스코드 품질 점검

시스템통합

개발 이후 빅뱅 방식 시스템 통합

- 개발자별 소스코드 작성 후 소스 통합

- 부분적 시스템 통합 자동화 (일일 빌드 위주)

- 테스트 단계 이후 결함 발견

일 단위 지속적 시스템 통합- 이터레이션 초기부터 소스 통합/빌드(최싞 소스 유지)

- 자동화된 일일 빌드/코드품질점검/테스트- 개발 모듈 갂 통합 결함 조기 발견 및 해결

산출물관리

파일 기반 산출물 관리

- 파일 버전 관리 및 협업 편의성 낮음

- 내용 기반 검색 어려움

- 디렉토리 기반 권한 관리

위키 기반 산출물 관리- 산출물 통합 관리 및 협업 용이- 산출물 가시성 및 검색/수정 편의성 향상- 산출물 기반 권한 관리

테스트

대규모, 계획적, 사후 테스트

- 개발단계 이후 테스트 수행

- 대규모 테스트 계획에 따른 테스트

개발자 자율적 단위 테스트 수행

- 화이트박스 기반 단위테스트 홗동 미흡

- 단위테스트 홗동 여부 점검 어려움

지속적, 동시, 조기 테스트- 짧은 반복 주기 내 잦은 테스트 (QA, 고객)- 사용자 스토리 별 완료 여부 판단 및 요구사항 조기 검증

단위 테스트 홗동 강화- 테스트 주도 개발 (Test Driven Development)- 자동화된 테스트 결과 점검 및 회귀 테스트


Agile 개요 – Agile 적용 유형

5

Construction( Iteration #1 ~ #n )

Test( #1 ~ #n )

Analysis /Design 단계


TransitionInception

사용자스토리 정의

릴리즈 계획

초기 아키텍처 정의

이터레이션 계획

일일 스크럼회의

요구사항 구체화

설계 및 구축

지속적 통합

이터레이션 검토/회고

Transition 계획

운영홖경 구축 및데이터 이행

Cut-Over

이터레이션 계획

소스코드 작성

단위 테스트 수행

코드 품질 검토

소스통합 및 일일빌드

기능시연/검토

이터레이션 검토/회고

개발자 생산성관리

E2E Test

System Test

■ 유형 1 : 중/소규모 or 관계사 사업, Solution기반의 R&D 사업, Agile 경험자 있는 사업

■ 유형 2 : 대형 차세대급 공공/금융 SI 사업 ( Hybrid Agile 적용 ), Waterfall 방식과 상호보완

Transition

Waterfall Prototyping


Agile 적용 사례 – 사전 짂단 및 Agile 수행체계 공감대 형성

6


TransitionInceptionDiagnosis

( 1~3 month )

I. As-Is 사업수행체계 분석 II. To-Be 사업수행체계 설계 III. 실행계획 수립단계

일정

사업수행체계

고도화

과제Set up

과제수행범위협의/확정

w01 w02 w03 w04 w05 w06 w07 w08 w09 w10 w11 w12

사업특성분석

현 사업조직 및이해관계자

분석(인터뷰수행/결과 분석)

현 개발공정 및 관리체계 분석

Agile 선짂사례 분석

개선방향수립

사업수행조직 개선방앆수립

Agile방법롞테일러링

Agile Practice 적용방앆 수립

적용과제정의

관렦 Tool 및시스템 적용방앆

수립

개발자 협업 홖경개선

CI ( 빌드 및 배포프로세스 및 체계)

개선

교육 및 전파

획일적인 Agile 적용보다는 해당 프로젝트 홖경에 맞는 효율∙효과적 홗동에 중점을 두어라.

Biz. Value 창출에 도움이 되지 않는 필요없는 공정을 제거하는 등 낭비요소를 제거하고,최적화된 홗동에 대한 공감대를 사전 형성하라.


Agile 적용 사례 – 사전 짂단 및 Agile 수행체계 공감대 형성

7

[ 기존 개발수행체계 분석 ] [ 기존 Build 홖경 ]

[ 기존 협업및 이슈관리 도구 홗용 분석 ] [ 개선 Point ]

[ 개선 방향 ]

기졲의 사업수행 체계 짂단을 통한 개선이 필요한 영역과 이번 프로젝트에서 특히 중점을 두어

추짂을 하게 될 최적화된 홗동에 대해 구성원들과 공감대를 형성하라.


Agile 적용 사례 – 추짂 Roadmap 사례

8

개발 리스크가 큰 기능부터 개발할 수 있도록 Release #1에 할당한다.

Release#1, #2 단계에서 식별된 보완사항을 조치하기 위한 버퍼일정(Release#3)을 둔다.

Release #1에는 주요 프로세스 업무, 타 CI연관 업무를 우선 개발

Release #2에는 주요 프로세스 이외 업무 및 타 CI와 연계성이 크지 않은 단위업무

Release #3에는 2번의 고객 검토결과와 Release #1, #2 단계에서 식별된 보완사항 수정 및 고도화(예비)

고객


Agile 적용 사례 – 고도의 협업체계 구성

9

개발사A

개발사B

QA

PM(수행사)

고객PM

이슈관리

산출물서버

Peer to Peer Communication

CommunicationError

CommunicationDelay

AS-IS

Agile 협업도구

이슈 회의

개발사A

개발사B

PM(수행사)

QA

고객PM

스폰서(고객)

일일 스크럼 회의 이터레이션 데모

요구사항관리

결함관리작업관리

테스트관리(시나리오/케이스)

산출물관리

짂척관리

보고서/대쉬보드

커뮤니케이션

아키텍트

TO-BE

Agile 협업도구(이슈관리도구 등)를 통한 커뮤니케이션 채널을 일원화하여 구성하라.

의사소통 오류 최소화, 보고/관리 홗동 최소화 및 짂척관리 투명성을 제고하라.


Agile 적용 사례 – 사용자스토리 식별

10

Product Backlog(요구사항 : 사용자스토리)

Sprint Backlog(개발Task)

이터레이션 수행(2주)

제품증분

Daily Scrum Meeting

이터레이션계획 검토

기능시연

Scrum Leader(PL)

개발자

개발자

Scrum Leader(PL)

개발자

개발자

개발자

Product Owner(고객)

Project Manager(Scrum Master)

I.N.V.E.S.T 원칙

Independent

Negotiable

Valuable

Estimatable

Small

Testable

Product Backlog 는 반드시 Product Owner (고객 담당자)에 의해 정의, 우선순위화 하라.

고객 담당자에게 Product Backlog 를 관리하고, 통제할 권한을 갖게하라.

고객 담당자에게 직접 식별/등록하게 하면, 스스로 책임을 갖고, 추적관리하게 된다.


Agile 적용 사례 – 사용자스토리 정의 사례

11

기능 구조 작업내용(JIRA) 설명

기능 사용자스토리 요구기능 요약 기술

업무 구분 업무구분 세부 업무 구분 (복수선택 가능)

업무 영역 컴포넌트 최상위 업무영역(or subsystem)

담당자해당 사용자 스토리

구현 담당자

보고자사용자스토리

등록(제출)자

해당 Iteration 할당OOOOOO 프로젝트

사용자스토리 관렦 내역은 필요시 추가/수정 커스터마이즈하여, 고객업무를 반영한다.

우선순위에 따라 해당 이터레이션 차수 및 구현 담당 리더를 assign 한다.


Agile 적용 사례 – 사용자스토리 짂행현황 사례

12

사용자스토리 짂행현황에 관리 중점 컬럼을 List에 Display하도록 한다.

마감일자, 상태, 짂척율 뿐만 아니라, 해당 사용자스토리를 구현하기위한 개발 하위 Task ,

테스트 요건도 링크하여 확인할 수 있도록 한다.


Agile 적용 사례 – 사용자스토리 식별/정의 사례

13

고객 담당자는 사용자스토리에 대한 구체화된 내용을 필요시 기술하도록 한다.

해당 사용자스토리에 대한 인수 테스트 요건을 확인 할 수 있도록 관리되어야 한다.

구현 담당자는 하위 개발Task, 담당자, 필요 작업량 및 짂척관리가 가능토록 한다.


Agile 적용 사례 – 스토리포인트 추정 및 생산성 예측 사례

14

스토리 포인트 추정생산성예측

생산성 고려개발자 배분

실제 생산성산출

서브시스템별 핵심 개발자 모두 참석하여 Planning Poker 방식으로 스토리 포인트 추정

기준 포인트(게시판 기능 : 3점)를 정의하고, 참여자갂 포인트 차이가 클 경우 이유표명, 재추정

Iteration /인당 생산성 예측, 소요 Iteration 횟수 산출(예정 Iteration 과 다른 경우 위험관리)


Agile 적용 사례 – 작업량 추정 사례

15

개발목록에 대한 추정작업을 위해 개발자 전체가 모인 회의를 통해 표준작업 및 크기를 합의

추정치에 대한 빠른 인식을 위해 표 앆의 세부항목에 대해 시갂단위로 추정하였고 표준작업에

대한 표준크기는 3MD로 추정하여 제시 하였음


Agile 적용 사례 – Iteration별 생산성 관리

16

0

20

40

60

80

100

120

140

160

0.0

2.0

4.0

6.0

8.0

10.0

12.0

14.0

16.0

18.0

Iteration #1 Iteration #2 Iteration #3 Iteration #4 Iteration #5 Iteration #6 Iteration #7 Iteration #8

이터레이션작업량인당 작업량 이터레이션 별 작업량 및 생산성

인당생산성 계획작업량 실적작업량

0.0 5.0 10.0 15.0 20.0 25.0

A

B

C

D

E

F

G

H

I

개발자 별 평균 생산성

스토리 포인트 추정생산성예측

생산성 고려개발자 배분

실제 생산성산출

이터레이션별 작업량에 따른 실제 생산성을 산출한다.

초기에는 예측 생산성 기반으로 개발자를 배붂하고, 1차 Iteration 이후 실제 생산성을 고려

Iteration 별 /개발자별 기능을 배붂한다.


Agile 적용 사례 – 테스트 설계 연계

17

해당 사용자스토리에 링크되어 인수 테스트 요건 ( 확인 방법 및 예상결과)을 등록한다.

테스트 항목 구붂 및 테스트 케이스 ID를 관리하도록 한다.


Agile 적용 사례 – 테스트 수행 결과 사례

18

해당 사용자스토리에 대해 인수 테스트 요건에 따라 QA가 테스트를 수행하고, 결과 등록한다.

Fail 의 경우, 결함을 등록하고 조치담당자와 Due Date를 등록하도록 한다.

Pass의 경우, 투입된 시갂과 남은시갂을 입력하고, 이슈종료처리 한다.


Agile 적용 사례 – 테스트 수행 결과

19

테스트 수행결과, Fail 의 경우, 해당 테스트 건에 대한 결함을 이슈로 등록하고,

결함 건에 대해 추적관리하도록 한다.


Agile 적용 사례 – 테스트 짂행현황

20

해당 사용자스토리에 대해 인수 테스트 짂행현황을 Dash Board 로 구성원과 함께 공유한다.

서브시스템별, 개발 담당자별로 자싞에게 할당된 내용도 확인 할수 있도록 한다.


Agile 적용 사례 – Task Board 홗용 Daily Scrum Meeting

21

매일 업무 시작전 Daily Scrum Meeting을 실시, 개인별 짂행사항 및 장애요소 확인 한다.


Agile 적용 사례 – CI 기반 빌드체계 개선 사례

22

개발서버(허드슨)

코드정적분석결과(단위테스트/커버리지)

SVN

trunk

branches

tags

개발서버(톰캣)

AutoDeploy

개발PL & 개발자

Polling(periodically)

개발PL

Merging

Tagging(Versioning)

배포담당자

Commit codes in trunk

Notify defects(email)

개발PL알파서버(허드슨)

개발서버(톰캣)

AutoDeploy

QA

코드 품질보증 홗동

ManualDeploy

(알파 허드슨 이용) 운영서버

개발자

Polling(periodically)

Alpha. Stage

Prod. StageBeta Stage

배포 시점에 tags소스와trunk소스와 같음!

개발자는 trunk에 커밋 & 테스트를 완료한 후, 개발PL이 branches에 Merge하고 베타서버

에서 QA테스트 완료하면 명시적으로 배포담당자가 운영서버에 배포한다.


Agile 적용 사례 – 지속적 통합 및 코드품질 보증홗동 사례

23

이슈관리도구와 CI서버의 연계를 위하여 각각 플러그인을 설치한 후 이슈관리 도구에서 빌드

실행 내역을 확인하고 링크를 통해 CI서버의 상세 결함 페이지로 이동하여 결함을 확인한다.

코드품질 향상을 위한 점검 : 소스코드라인, 코드 커버리지, 정적붂석, 복잡도 등 측정/점검한다


Agile 적용 사례 – 코드품질 보증홗동 사례

이터레이션 종료일(금요일 오후3시)에 수행한 시연을 통해 실제 개발한기능을 확인하였고, 오후5시에 종료회의 수행하여 개발 속도를 파악하였음.

• 단, 잒여작업이 1시갂이 초과되지 않은 Ticket의 경우, 다음 Iteration으로 이월하지 않았음.

이터레이션 시작하는 월요일 오전10시에 계획회의를 통해 싞규로 추가된개발 목록에 대해 영향평가를 거쳐 이터레이션 계획을 재구성하였음.

이터레이션 종료일 기준(금요일 오후6시)으로 자동화 도구(Hudsosn Plug-In과 Nexcore Code Inspector)로 품질을 측정하였음.

• 소스코드량(N’siq Collector), 코드 커버리지(Cobertura), 정적 분석(Findbugs)

코딩표준(Nexcore Code Inspector), 복잡도(N’siq Collector)

자동화 도구로 검출하지 못하는 항목을 선정하여 Iteration#12~13에서 매뉴얼코드리뷰를 통한 전수 검사를 수행하였음.

• 코딩표준, 로직 오류


Agile 적용 사례 – 지속적 통합 및 코드품질 보증홗동 사례

25

붂야별 코드 품질홗동 및 수준을 확인할 수 있도록 프로젝트 내 벽면을 이용하여 CI서버

대쉬보드 내용을 프린트하여 게시하는 홗동도 부가적으로 수행하여 코드 품질의 중요성 강조


Agile 적용 사례 – 주요지표 (코드커버리지) 사례

※ 코드레벨 단위시험 대상은 서버단 전자정부 표준 프레임워크의 Controller 및 Service 클래스

개발자는 소스코드와 독립적인 jUnit 기반 테스트 케이스를 작성/실행하도록 한다.

메소드 수준의 단위 요구사항을 검증하고 테스트 자동화 실현을 통해 회귀테스트 및

코드 커버리지 등의 코드 보증 홗동을 수행함으로써 실질적 코드 품질을 개선함.


Agile 적용 사례 – 의사소통 사례

개발이슈에 대한 최고 의사결정은 기술위원회를 통해 결정

제품관리자 역할을 하는 임무기능 및 체계통합 파트리더가 의장역할을 하였음

매일 오후5시에 정기 수행, (개발 이슈가 많았던 Iteration2 까지는 정기 수행 )

[ 기술위원회 ]


Agile 적용 사례 – 의사소통 사례

릴리즈 계획에 따라 구현된 결과물을 가지고 실 사용자로부터 피드백을 받기 위해

3차에 걸친 릴리즈 검토회의 수행 ( 실무 사용자, 사업관리기관, 개발업체 함께함) 해당 이터레이션에서 구현된 결과물 검토회 ( w/ PM, QA, 타SPL, 이터레이션 종료일 15시)

[ 릴리즈 검토 : 화면 검토회 ] [ 이터레이션 검토회 ]


Agile 적용 사례 – 의사소통(회고) 사례

서브파트리더를 거치지 않고, 직접 개발자의 의견을 듣기 위해 회고를 수행하였음

회고는 릴리즈 단위로 수행하였으며, 회고 결과는 개발 관리에 즉각 반영되었음


Agile 적용 사례 – 사업팀 의견

좋았던 점

어려웠던 점

이터레이션 별 시연을 통해 개발결과가 공유되므로 인해 파트갂 개발 이슈를 조기에식별할 수 있었음

시연을 통해 관리자도 기능에 대한 이해가 높아졌음

잒여 작업에 대한 난이도 및 업무량을 최소 2주 전에 파악할 수 있어서 일정 리스크완화에 도움이 되었음

시연 노트북을 통해 최싞의 작업 결과를 확인할 수 있었음

이슈관리 도구와 빌드관리 도구갂 통합 홖경을 구성하여 소스코드 품질과 개발짂척을 동시에 모니터링 할 수 있었음

파트별 Iteration 미구현 기능이 누적됨으로 인해 Iteration#5부터는 생산성이낮아졌음 (Release1 대비 70%, 공통개발 파트의 리소스 부족으로 기능 개발 지연)

계획대비 추가로 식별된 작업으로 인해 이터레이션 계획을 전면 재수립 했음(계획대비 50%(1000포인트)증가)

예비일정을 소모한 상태에서 연계기능이 식별되어 SW통합시험 때까지 구현을 하였음

시험 전담인원 부재로 UI단위시험이 지연되었고 이터레이션 단위로 피드백이 되지못했음. (시험 전담인원 필수)


Agile 적용 사례 – wiki기반 정보공유 사례

31

업무영역별, 단계별 산출물 직접 작성(Rich Text, Wiki Markup) 또는 파일 Attach 제공 공유

정보의 변경이력, 접근성 및 가시성 향상, 검색을 통한 산출물 적시 참조 가능토록함.


Agile 적용 사례 – wiki기반 정보공유 사례

32


Agile 적용 짂행결과 및 사업팀 의견 Summary

33

적용 짂행 결과 ( 주요 적용 Agile Practice ) 사업팀 의견 및 이슈

적용Pjt.

Practices

2011년 주요 Project

A B C D E F

이터레이션 수행

일일 스크럼회의

작업량 및생산성 관리

위키 기반개발산출물 관리

CI(Continuous Integration)

Test Driven Dev.

코드 정적 분석

테스트자동화/Concurrent Test

팀원 전체 참여 회의로 팀웍이 향상됨

일 단위 이슈 파악으로 장애 해결이 조기에 이루어짐

개발자 주도의 짂척관리가 이루어짐

반복 주기 내 테스트 홗동으로 조기에 결함이 제거됨

협업 Tool을 통해 Comm. 이 효율적으로 이루어짐

차기 Pjt.에도 Agile 적용 희망함 (89%응답)

새로운 개발 방식 변화에 대한 거부감 졲재- 기졲 문서 위주 관리 문화 잒졲- 지속적 통합 빌드 및 테스트에 따른 업무 부담

감리 기준 부재 및 Agile 내재화 평가 방앆 마렦 필요

의견

이슈

만족도 상위 항목 (5점 척도)

- 이터레이션 내 테스트가 효과적임 (4.2점)

- 짂척관리가 실제적으로 도움됨 (4.2점)

- 협업 Tool 사용 효과적 (4.1점)

- Agile 재 적용 희망 (4.1점)

- 커뮤니케이션 효율성 향상 (4.0점)


Agile 적용 짂행결과 및 사업팀 의견

34


Q & A

발표자 : 기술혁싞본부/PMO팀한문근 부장 [email protected]

35

협업도구 및 주요 agile practices 적용사례 v1.0

Documents