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

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

Methodology 측면 Teaming 측면

 기졲 전통적 개발방식과 Agile 개발방식을 Hybrid하게 적용  스크럼 팀 구성 : 제품책임자(고객), 스크럼 마스터, 개발팀
- 사업특성을 고려한 Agile 적용 범위 및 적용 Practice 선정 - 개발팀은 여러가지 기능을 복합적으로 수행하는 Cross-Functional 조직
- 점짂 반복적인 방식의 Lifecycle 모델 적용 - 각 팀의 스크럼 마스터로 구성된 Scrum of Scrums 회의로 팀갂 이슈 공유

순수
高

Agile
기술복잡도(싞기술,

적용
Solution 도입)

전통적
방법롞
적용
低

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

프로젝트 관리 측면 프로젝트 개발 측면

 관리 문화 : 지시/감독 -> 코치/촉짂자/후원적 역할  CI(*) 기반 빌드 홖경구성 및 테스트 강화
- Self-organizing Team : 자율적 문제발견/해결, 협업, Cross-Functional조직 - 지속적(빈번한) 통합을 위한 소스관리 및 CI 서버 연계 구성
- 사람중심의 관리 : 목적의식, 책임감, 자율성, 배움고취 - 화이트박스 기반 개발자 단위테스트 강화 및 코드 품질 점검

 Communication : 주갂 단위 -> Daily 단위 점검 및 개선
- Daily 단위 짂척현황, 장애요소 파악에 따른 문제점 개선
- 생산성 관리를 통한 자원 투입 효율성 향상
- Agile 협업 도구 기반 Comm. 채널 일원화 및 프로젝트 가시성 확보

 요구사항 검증 : 프로젝트 후반 검증 -> 주기적 고객 검증
- 주기적 고객 참여 시연을 통한 요구사항 조기 검증 및 평가
- 고객에게 최우선적으로 중요한 SW를 빠르게 인도 * CI : Continuous Integration

1

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

변화 요소 As-Is To–Be

 계획된 범위의 소프트웨어를 정해짂 시갂과 비용 내에서  지속적으로 가치 있는 소프트웨어를 조속하게 릴리즈
제공하여 고객 만족을 이룸 하여 고객 만족을 이룸
개발
- 정형화되고 상세한 프로세스 중시 - 유연하고 갂소한 프로세스 (팀원갂 상호작용)
Paradigm - 포괄적인 문서화 - 동작하는 소프트웨어 중시
- 고객과의 계약에 따른 계획 준수 - 고객과의 협력 및 변화에 대한 응대

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

제앆/ Life-cycle
 Waterfall 모형  Iteration 모형
착수 - 요구정의-분석-설계-구축-운영전홖 단계 - 도입-구축(n차 iteratoin)-시험-전홖 단계
선정 - Entry/Exit Criteria 준수에 따른 작업 착수/종료 - 짧은 개발 주기 반복 개발을 통한 제품 완성도 향상

 기능 사일로 형태 구성  서비스 중심의 스크럼 팀 구성
- 스크럼 마스터
- 고객, 프로젝트관리자, 사업관리자, 개발팀, DB팀, - 제품 책임자
Teamming
기술지원팀, 테스터, QA 등 - 개발 팀 (개발자,테스터,아키텍트,QA)
(R&R)  고객 조직과 사업 수행 조직 붂리  고객이 스크럼 팀 멤버로 참여
 역할 붂업화 및 개인별 역할 한정  개발 팀 내 복합 기능(Cross-Functional) 수행

 확정된 범위, 시갂과 자원 예측  두 단계 계획/일정 확정, 범위 예측
계획과
 조기에 상세 계획 작성  실시갂 상세 계획 작성
스케쥴
 종료 시점의 데모  항시 데모 가능

Copyright@2012 SK C&C Co.Ltd. All Rights Reserved. 2

Agile 개요 – Agile 적용 변화 주요 Point (프로젝트 관리)
 관리자 주도의 지시 / 감독  스크럼 마스터의 코치 / 후원적 역할
관리 문화  개인 단위의 업무 수행  팀 주도적 리더십 / 협업 및 팀 단위 업무 수행
 프로세스 중심 역할 수행 강조  사람 중심 (동기부여, 자율성, 상호졲중 등) 관리

 주갂, 월갂 단위 커뮤니케이션
 일 단위 커뮤니케이션 및 이슈 점검 (일일 스크럼 회의)
커뮤니케이션  고객-개발팀 갂 커뮤니케이션 적음
 협업 Tool 홗용 커뮤니케이션 채널 통합
(고객-PM, PM-개발팀 위주 회의)

 사업 팀 주관 요구사항 관리  고객 주관 요구사항 관리
- 사업 수행팀 명세 및 고객 승인 - 고객 주관 요구사항 정의 및 우선순위 부여
- 산출물 기반 요구사항 검증 (테스트 이전 단계) - 동작하는 시스템 기반 주기적 요구사항 검증
요구사항관리
 엄격한 변경 관리  점짂적 요구사항 구체화
(범위관리)
- 초기 상세한 요구사항 정의/명세 강조 - 개발 우선순위에 따른 점짂적 요구사항 구체화
- 초기 정의한 범위에 대한 영향평가 및 - 동작하는 시스템 평가 후 가치중심 요구사항 변경 및
프로젝트
변경심의 우선순위 조정
관리
 작업 기반 짂척 관리  제품 기반 짂척 관리
- 작업 별 짂척율 관리 - 사용자 스토리 별 짂척율 관리
짂척 관리
- WBS 홗용 - 이슈 관리 Tool 홗용 (Jira / Redmine 등)
- 산출물 완료 기준 적용 (테스트 이전 단계) - 사용자 스토리 완료 기준 적용
 제품 기반 QA 홗동
 산출물/프로세스 기반 QA 홗동 - 코드 품질 점검 홗동 및 테스트 지원
- 표준 절차 가이드 및 지원 - 전체 시스템 수준의 테스트 시나리오 개발
품질관리(QA)
- 산출물 품질 검토
- 프로세스 이행 부적합성 검토  Agile Practices 가이드 및 코칭
- Agile 품질점검 결과서 홗용

 각 단계 짂입 후 위험/이슈 식별  짧은 반복 주기 후 위험/이슈 조기 식별
측정/
- 구축 완료 후 개발 생산성 평가 - 이터레이션 별 개발 생산성 평가
위험관리 - Function Point 홗용 - 스토리포인트 홗용


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


 산출물 중심 절차 기반 Inspection 홗동  코드 중심 자동화 기반 점검 홗동
동료검토 - 단계별 주요 산출물/코드 점검 - Pair Programming
- 준비-사전검토-회의-결함조치-결과정리 홗동 - 자동화된 소스코드 품질 점검

 개발 이후 빅뱅 방식 시스템 통합  일 단위 지속적 시스템 통합
- 개발자별 소스코드 작성 후 소스 통합 - 이터레이션 초기부터 소스 통합/빌드
시스템
(최싞 소스 유지)
통합 - 부분적 시스템 통합 자동화 (일일 빌드 위주) - 자동화된 일일 빌드/코드품질점검/테스트
- 테스트 단계 이후 결함 발견 - 개발 모듈 갂 통합 결함 조기 발견 및 해결

시스템
개발  파일 기반 산출물 관리  위키 기반 산출물 관리
산출물 - 파일 버전 관리 및 협업 편의성 낮음 - 산출물 통합 관리 및 협업 용이
관리 - 내용 기반 검색 어려움 - 산출물 가시성 및 검색/수정 편의성 향상
- 디렉토리 기반 권한 관리 - 산출물 기반 권한 관리

 대규모, 계획적, 사후 테스트
 지속적, 동시, 조기 테스트
- 개발단계 이후 테스트 수행 - 짧은 반복 주기 내 잦은 테스트 (QA, 고객)
- 대규모 테스트 계획에 따른 테스트 - 사용자 스토리 별 완료 여부 판단 및 요구사항 조기 검증
테스트
 개발자 자율적 단위 테스트 수행  단위 테스트 홗동 강화
- 화이트박스 기반 단위테스트 홗동 미흡 - 테스트 주도 개발 (Test Driven Development)
- 자동화된 테스트 결과 점검 및 회귀 테스트
- 단위테스트 홗동 여부 점검 어려움


Agile 개요 – Agile 적용 유형

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

Construction
Inception Transition
( Iteration #1 ~ #n )

일일 스크럼회의
사용자스토리 정의 Transition 계획
이터레이션 계획 요구사항 구체화
운영홖경 구축 및
릴리즈 계획
데이터 이행

초기 아키텍처 정의 Cut-Over
이터레이션 검토/회고 설계 및 구축

지속적 통합

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

Analysis / Construction Test
Transition
Design 단계 ( Iteration #1 ~ #n ) ( #1 ~ #n )

 Waterfall  이터레이션 계획  소스통합 및 일일빌드  E2E Test
 Prototyping  소스코드 작성  기능시연/검토  System Test
 단위 테스트 수행  이터레이션 검토/회고
 코드 품질 검토  개발자 생산성관리


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

 획일적인 Agile 적용보다는 해당 프로젝트 홖경에 맞는 효율∙효과적 홗동에 중점을 두어라.
 Biz. Value 창출에 도움이 되지 않는 필요없는 공정을 제거하는 등 낭비요소를 제거하고,
최적화된 홗동에 대한 공감대를 사전 형성하라.

Diagnosis Construction
Inception Transition
( 1~3 month ) ( Iteration #1 ~ #n )

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

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

현 사업조직 및
과제
사업 이해관계자
Set up
특성 분석
개발자 협업 홖경
분석 (인터뷰수행/ 사업수행조 Agile Practice 개선
결과 분석) 직 개선방 적용방앆 수립
앆수립
사업수행
체계 과제 현 개발공정 및 관리 개선방향
교육 및 전파
고도화 수행 체계 분석 수립
범위
협의/
확정 CI ( 빌드 및 배포
Agile 관렦 Tool 및 프로세스 및 체계)
Agile 선짂 적용과제정 개선
방법롞 시스템 적용방앆
사례 분석 의
테일러링 수립


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

 기졲의 사업수행 체계 짂단을 통한 개선이 필요한 영역과 이번 프로젝트에서 특히 중점을 두어
추짂을 하게 될 최적화된 홗동에 대해 구성원들과 공감대를 형성하라.

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

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


Agile 적용 사례 – 추짂 Roadmap 사례

 개발 리스크가 큰 기능부터 개발할 수 있도록 Release #1에 할당한다.
 Release#1, #2 단계에서 식별된 보완사항을 조치하기 위한 버퍼일정(Release#3)을 둔다.

 Release #1에는 주요 프로세스 업무, 타 CI연관 업무를 우선 개발
 Release #2에는 주요 프로세스 이외 업무 및 타 CI와 연계성이 크지 않은 단위업무
 Release #3에는 2번의 고객 검토결과와 Release #1, #2 단계에서 식별된 보완사항 수정 및 고도화(예비)

고객


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

 Agile 협업도구(이슈관리도구 등)를 통한 커뮤니케이션 채널을 일원화하여 구성하라.
 의사소통 오류 최소화, 보고/관리 홗동 최소화 및 짂척관리 투명성을 제고하라.

AS-IS
TO-BE 스폰서(고객)
고객PM 짂척관리
Peer to Peer 개발사A
Communication 요구사항관리 산출물관리

PM(수행사)
고객PM
이슈관리 Communication
Error 일일 스크럼 회의 이터레이션 데모
Agile 협업도구
개발사B 결함관리
작업관리
Communication
아키텍트
Delay
테스트관리
PM(수행사) 보고서/ (시나리오/케이스)
대쉬보드 이슈 회의
QA
커뮤니케이션

QA 개발사A

산출물서버
개발사B


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

 Product Backlog 는 반드시 Product Owner (고객 담당자)에 의해 정의, 우선순위화 하라.
 고객 담당자에게 Product Backlog 를 관리하고, 통제할 권한을 갖게하라.
 고객 담당자에게 직접 식별/등록하게 하면, 스스로 책임을 갖고, 추적관리하게 된다.

Daily Scrum Meeting

이터레이션 수행
(2주)
Project Manager
(Scrum Master) 기능시연
이터레이션 제품
계획 검토
증분

Product Owner 개발자
(고객)
Scrum Leader
Product Backlog Sprint Backlog (PL)
(요구사항 : 사용자스토리) (개발Task) 개발자

 Independent 개발자
 Negotiable Scrum Leader
I.N.V.E.S.T  Valuable (PL) 개발자
원칙
 Estimatable
 Small
 Testable 개발자


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

 사용자스토리 관렦 내역은 필요시 추가/수정 커스터마이즈하여, 고객업무를 반영한다.
 우선순위에 따라 해당 이터레이션 차수 및 구현 담당 리더를 assign 한다.

해당 Iteration 할당
OOOOOO 프로젝트

해당 사용자 스토리
담당자
구현 담당자
기능 구조 작업내용(JIRA) 설명 사용자스토리
보고자
기능 사용자스토리 요구기능 요약 기술 등록(제출)자
업무 구분 업무구분 세부 업무 구분 (복수선택 가능)
업무 영역 컴포넌트 최상위 업무영역(or subsystem)


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

 사용자스토리 짂행현황에 관리 중점 컬럼을 List에 Display하도록 한다.
 마감일자, 상태, 짂척율 뿐만 아니라, 해당 사용자스토리를 구현하기위한 개발 하위 Task ,
테스트 요건도 링크하여 확인할 수 있도록 한다.


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

 고객 담당자는 사용자스토리에 대한 구체화된 내용을 필요시 기술하도록 한다.
 해당 사용자스토리에 대한 인수 테스트 요건을 확인 할 수 있도록 관리되어야 한다.
 구현 담당자는 하위 개발Task, 담당자, 필요 작업량 및 짂척관리가 가능토록 한다.


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

 서브시스템별 핵심 개발자 모두 참석하여 Planning Poker 방식으로 스토리 포인트 추정
 기준 포인트(게시판 기능 : 3점)를 정의하고, 참여자갂 포인트 차이가 클 경우 이유표명, 재추정
 Iteration /인당 생산성 예측, 소요 Iteration 횟수 산출(예정 Iteration 과 다른 경우 위험관리)

생산성 실제 생산성 생산성 고려
스토리 포인트 추정
예측 산출 개발자 배분


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

 개발목록에 대한 추정작업을 위해 개발자 전체가 모인 회의를 통해 표준작업 및 크기를 합의
 추정치에 대한 빠른 인식을 위해 표 앆의 세부항목에 대해 시갂단위로 추정하였고 표준작업에
대한 표준크기는 3MD로 추정하여 제시 하였음


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

 이터레이션별 작업량에 따른 실제 생산성을 산출한다.
 초기에는 예측 생산성 기반으로 개발자를 배붂하고, 1차 Iteration 이후 실제 생산성을 고려
Iteration 별 /개발자별 기능을 배붂한다.

생산성 실제 생산성 생산성 고려
스토리 포인트 추정
예측 산출 개발자 배분

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

16.0 140
14.0
120
12.0
100 개발자 별 평균 생산성
10.0 I
80 H
8.0
60 G
6.0
F
4.0
40
E
2.0 20 D

0.0 0 C
Iteration #1 Iteration #2 Iteration #3 Iteration #4 Iteration #5 Iteration #6 Iteration #7 Iteration #8 B

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

0.0 5.0 10.0 15.0 20.0 25.0


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

 해당 사용자스토리에 링크되어 인수 테스트 요건 ( 확인 방법 및 예상결과)을 등록한다.
 테스트 항목 구붂 및 테스트 케이스 ID를 관리하도록 한다.


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

 해당 사용자스토리에 대해 인수 테스트 요건에 따라 QA가 테스트를 수행하고, 결과 등록한다.
 Fail 의 경우, 결함을 등록하고 조치담당자와 Due Date를 등록하도록 한다.
 Pass의 경우, 투입된 시갂과 남은시갂을 입력하고, 이슈종료처리 한다.


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

 테스트 수행결과, Fail 의 경우, 해당 테스트 건에 대한 결함을 이슈로 등록하고,
결함 건에 대해 추적관리하도록 한다.


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

 해당 사용자스토리에 대해 인수 테스트 짂행현황을 Dash Board 로 구성원과 함께 공유한다.
 서브시스템별, 개발 담당자별로 자싞에게 할당된 내용도 확인 할수 있도록 한다.


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

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


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

 개발자는 trunk에 커밋 & 테스트를 완료한 후, 개발PL이 branches에 Merge하고 베타서버
에서 QA테스트 완료하면 명시적으로 배포담당자가 운영서버에 배포한다.

Commit codes
in trunk
SVN 개발자 Alpha. Stage
Auto
코드정적분석결과 Polling Deploy
(단위테스트/커버리지) trunk (periodically)
코드 품질
보증 홗동 개발서버 개발서버
(허드슨) (톰캣)
QA Merging
Notify
defects(email)
Auto
Deploy Polling 개발PL
(periodically) branches

개발PL 개발PL & 개발자
개발서버 알파서버 Tagging
(톰캣) (허드슨) (Versioning)

Beta Stage 배포담당자

tags Manual Prod. Stage
배포 시점에 tags소스와 Deploy
(알파 허드슨 이용) 운영서버
trunk소스와 같음!


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

 이슈관리도구와 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 적용 사례 – 지속적 통합 및 코드품질 보증홗동 사례

 붂야별 코드 품질홗동 및 수준을 확인할 수 있도록 프로젝트 내 벽면을 이용하여 CI서버
대쉬보드 내용을 프린트하여 게시하는 홗동도 부가적으로 수행하여 코드 품질의 중요성 강조


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

 개발자는 소스코드와 독립적인 jUnit 기반 테스트 케이스를 작성/실행하도록 한다.
 메소드 수준의 단위 요구사항을 검증하고 테스트 자동화 실현을 통해 회귀테스트 및
코드 커버리지 등의 코드 보증 홗동을 수행함으로써 실질적 코드 품질을 개선함.

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


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

 개발이슈에 대한 최고 의사결정은 기술위원회를 통해 결정
 제품관리자 역할을 하는 임무기능 및 체계통합 파트리더가 의장역할을 하였음
 매일 오후5시에 정기 수행, (개발 이슈가 많았던 Iteration2 까지는 정기 수행 )
[ 기술위원회 ]


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

 릴리즈 계획에 따라 구현된 결과물을 가지고 실 사용자로부터 피드백을 받기 위해
3차에 걸친 릴리즈 검토회의 수행 ( 실무 사용자, 사업관리기관, 개발업체 함께함)
 해당 이터레이션에서 구현된 결과물 검토회 ( w/ PM, QA, 타SPL, 이터레이션 종료일 15시)

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


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

 서브파트리더를 거치지 않고, 직접 개발자의 의견을 듣기 위해 회고를 수행하였음
 회고는 릴리즈 단위로 수행하였으며, 회고 결과는 개발 관리에 즉각 반영되었음


Agile 적용 사례 – 사업팀 의견

좋았던 점
 이터레이션 별 시연을 통해 개발결과가 공유되므로 인해 파트갂 개발 이슈를 조기에
식별할 수 있었음
 시연을 통해 관리자도 기능에 대한 이해가 높아졌음
 잒여 작업에 대한 난이도 및 업무량을 최소 2주 전에 파악할 수 있어서 일정 리스크
완화에 도움이 되었음
 시연 노트북을 통해 최싞의 작업 결과를 확인할 수 있었음
 이슈관리 도구와 빌드관리 도구갂 통합 홖경을 구성하여 소스코드 품질과 개발짂척
을 동시에 모니터링 할 수 있었음

어려웠던 점
 파트별 Iteration 미구현 기능이 누적됨으로 인해 Iteration#5부터는 생산성이
낮아졌음 (Release1 대비 70%, 공통개발 파트의 리소스 부족으로 기능 개발 지연)
 계획대비 추가로 식별된 작업으로 인해 이터레이션 계획을 전면 재수립 했음
(계획대비 50%(1000포인트)증가)
 예비일정을 소모한 상태에서 연계기능이 식별되어 SW통합시험 때까지 구현을 하였음
 시험 전담인원 부재로 UI단위시험이 지연되었고 이터레이션 단위로 피드백이 되지
못했음. (시험 전담인원 필수)


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

 업무영역별, 단계별 산출물 직접 작성(Rich Text, Wiki Markup) 또는 파일 Attach 제공 공유
 정보의 변경이력, 접근성 및 가시성 향상, 검색을 통한 산출물 적시 참조 가능토록함.


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


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

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

 만족도 상위 항목 (5점 척도)
적용Pjt. 2011년 주요 Project
- 이터레이션 내 테스트가 효과적임 (4.2점)
Practices A B C D E F - 짂척관리가 실제적으로 도움됨 (4.2점)
- 협업 Tool 사용 효과적 (4.1점)
이터레이션 수행 - Agile 재 적용 희망 (4.1점)
일일 스크럼 - 커뮤니케이션 효율성 향상 (4.0점)
회의 의
견  팀원 전체 참여 회의로 팀웍이 향상됨
작업량 및
 일 단위 이슈 파악으로 장애 해결이 조기에 이루어짐
생산성 관리
 개발자 주도의 짂척관리가 이루어짐
위키 기반
개발산출물 관리  반복 주기 내 테스트 홗동으로 조기에 결함이 제거됨

CI(Continuous  협업 Tool을 통해 Comm. 이 효율적으로 이루어짐
Integration)  차기 Pjt.에도 Agile 적용 희망함 (89%응답)

Test Driven Dev.
 새로운 개발 방식 변화에 대한 거부감 졲재
코드 정적 분석 - 기졲 문서 위주 관리 문화 잒졲
이
- 지속적 통합 빌드 및 테스트에 따른 업무 부담
슈
테스트자동화/
 감리 기준 부재 및 Agile 내재화 평가 방앆 마렦 필요
Concurrent Test


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


Q&A

발표자 : 기술혁싞본부/PMO팀
한문근 부장 jameshan@sk.com


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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à 협업도구 및 주요 Agile practices 적용사례 v1.0

Similaire à 협업도구 및 주요 Agile practices 적용사례 v1.0 (20)

Plus de Sangcheol Hwang

Plus de Sangcheol Hwang (14)

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