조대협의 소프트웨어 개발 발표 자료입니다. 소프트웨어 트랜드, 클라우드, 아키텍쳐의 변화 애자일과 JIRA, 소프트웨어 개발팀의 구조, 테스트링크를 이용한 테스트 관리등을 현장 경험을 기반으로 소개합니다.

1. 조대협의
소프트웨어 개발

2. 조대협
•
•
•
•
•
•
•
•
개발자
웹로직 기술 지원 엔지니어
장애 진단, 성능 튜닝
컨설턴트 (SOA,EAI,ALM,Enterprise 2.0)
아키텍트 (대용량 분산 시스템)
APAC 클라우드 수석 아키텍트
프리렌서
지금은 Chief(Cheap?) 아키텍트
블로그 : http://bcho.tistory.com
이메일 : bw.cho@samsung.com

3. 오늘도?

4. 할 이야기가 많아요
짧게짧게. 요점만 간단히

5. • 오늘 할 이야기
-
소프트웨어 개발 트랜드의 변화
JIRA를 이용한 프로젝트 관리
소프트웨어 개발팀의 조직 구조
(시간되면) TEST LINK를 이용한 테스트 관리

6. 소프트웨어 개발 트랜드의 변화

7. • 소프트웨어 트랜드의 변화
개발 방식
•
•
•
•
•
•
•
•
•
대규모/긴기간 에서 소규모/단기간 (스타트업)
빠르고 잦은 릴리즈 (애자일)
고객의 VOC를 수용 (빅데이타,SNS)
개발과 운영을 통합 (DEVOPS)
열심히 일하는 것으로 감당 안됨 (자동화)
스페샬 리스트에서 제너럴 리스트 (수퍼엔지니어)
대용량 글로벌 스케일
오픈소스
구글링,STACKOVERFLOW,블로그,GITHUB

8. • 소프트웨어 트랜드의 변화
아키텍쳐
자바스크립트
UX + 비지니스 로직
REST API
비지니스 로직
분산형 저장소
(NoSQL,Sharding)
중앙 집중형 저장소
(RDBMS,NFS)
동기식,중앙 집중형,고가용성
클러스터링
• HTML,Servlet/JSP
• EJB,Spring
• RDBMS
비동기식, 분산형, Resilience
Shared Nothing
•
•
•
•
HTML5,AngularJS
REST,WebSocket
Node.JS,IMDG
NoSQL,Sharding

9. • 클라우드 2’ND ROUND
•
•
•
•
개발자가 인프라도… (Devops)
네트워크와 IO가 문제!!!
확실히 차이남
생각보다 비쌈. 아는 만큼 싸짐

10. Atlassian JIRA를 이용한
프로젝트 관리

11. • 전체 흐름
기능 정의
UX 프로토타입
아키텍쳐 디자
인 (ADS)
리뷰
반복
(리뷰,반복 = 생각)
EPIC 정의
릴리즈
플랜
스프린트
플랜
서브태스크
생성
스프린트
시작
노트
스프린트
종료
데모&회고
릴리즈
반복

12. • 기능 정의
 순차적 스토리
 UX 디자인 가능
 테스트 가능
 Level 1
(20개 내외) 직관적 함축적
 Level 2
as a {user}, I want do {something}
리뷰 & REVIEW….!!

13. • UX 프로토타입
 Balsamiq Mock up
 Layout it
그리고 또 리뷰!! & REVIEW !!

14. • 아키텍쳐 디자인
전체적인 큰 흐름과 컴포넌트만 명시
내용이 많아서, 여기에 다 있습니다.
http://bcho.tistory.com/687

15. • 들어가기 앞서서
스크럼 방법론. (아님 Kanban도 좋고)
출처 : http://www.agilebuddha.com/trainings-workshops/scrum-training-workshop/

16. • JIRA 사용 준비
애자일 보드
JIRA AGILE BOARD
 TO DO , IN PROGRESS , DONE
 TO DO , IN PROGRESS , {Testing}, DONE

17. • EPIC 등록




한 스프린트에 끝나지 않음 (길게 간다)
스토리들의 집합
Level 1 Feature
사용자에게 직접 관련 없지만 묶을 필요가 있는 (인프라 셋업,디자인,문서작업)

18. • 스토리 등록
Level 2. Feature from excel
스토리 등록
EPIC 맵핑
Feature detail from Excel

19. • 컴포넌트 정의
시스템을 구성하는 컴포넌트 정의
 이미 대략적인 아키텍쳐가 나와 있어야 함
 컴포넌트별 개발팀 정의 (챔피언, 개발자, 테스터)

20. • 릴리즈 플랜
각 기능이 완성되는 버전을 명시
드래그 & 드롭

21. • 개발 계획 완료
• 전체적인 기능 정의 & 등록 완료
• 제품 릴리즈 일정 정의 완료
• 이제 부터는 스프린트 시작

22. • 스프린트 플랜
• 모여서
• 스토리를 스프린트에 맵핑
• 각 스토리별 서브 태스크 생성
(스토리를 구현하기 위해 구체적으로 해야할일)
• 스토리 포인트 부여 - 0.5일,1일,2일
• 스프린트 시작
( 2주가 적절, 20%~40% 버퍼)
(상대값이 편함)

23. • 스프린트 시작
• 스프린트 시작
• 상태 업데이트 (Start/Resolved)
• 노트 필수 (자세하게, 휴가가도 될만큼)
• Daily 스크럼 (어제 모했고, 오늘 모하고, 문제는 모가)
※ 절대 보고 아님. 마이크 있는 사람만, 전체 20분 이내, 치킨을 빼는 것도
• 개발된 테스크는 테스터에 ASSIGN

24. • 스프린트 종료
• 릴리즈 & 배포
• 데모
• 같이 앉아서, JIRA에서 스프린트 종료 (닫을거 닫고, 넘길거 넘기고)
• 회고
 몰 잘했고, 몰 잘못했고, 앞으로 어떻게 해보자
 끊임없는 프로세스 개선
 부담 되면 치킨 끼리, 치킨 빼고

25. • 다시 반복
• 스프린트 플랜 부터 반복
• 끊임 없는 개선
• 2달은 해봐야.

26. • 몇가지 팁
스윔레인
워크플로우
VCS 연동

27. • 몇가지 팁
이슈 타입
• 포인트 개념이 있는 타입
 Story - 사용자 기능
 Chore - 비기능
• 포인트 개념이 없는 타입
 Issue
 Bug
 Task (Optional)
되도록이면 간결하게, 최소한으로. 안그럼 헷갈림

28. • 몇가지 팁
프로세스 최적화
• 메뉴얼, 교육
• 끊임 없는 코칭 (중요함 – 아니면 중구난방)
툴은 프로세스를 효율적으로 사용하기 위함
툴에 맞춰서 프로세스 만드는게 아님

29. • 플러그인
기타 좋은 기능 많음.
• Atlassian Market에서 구매해서 추가 가능 (무료도 많음)

30. 소프트웨어 개발팀 조직 구조

31. • PROGRAM,PRODUCT,PROJECT 개념
PROGRAM
PRODUCT
PROJECT
PROJECT
COMPONENT
COMPONENT
COMPONENT
COMPONENT
페이스북
메신져
메신져 개발 프로젝트
모바일메신져 프로젝트
웹메신져
모바일메신져
푸쉬서버
푸쉬서버 V2
PROJECT
COMPONENT
PRODUCT
PROJECT
COMPONENT

32. • PROGRAM,PRODUCT,PROJECT 개념
• PROGRAM : 여러개의 PRODUCT으로 구성 지속적
• PRODUCT : 하나의 의미를 가지는 서비스나 제품
• PROJECT : 일정 기간,자원 목표를 가지고 시스템을 개발
상대적 개념. 나누기 따름

33. • 소프트웨어 개발팀의 구조
페이스북같은 SNS 프로그램
메신저
개발팀
타임 라인 개발자 포탈 프로덕트
개발팀
개발팀
고객 지원
영업/마케팅
운영팀
컴포넌트
푸쉬 서버
개발팀
모바일앱
개발팀
웹 개발팀
테스트팀
빌드배포팀
파트너 관리
전략 기획

34. PROGRAM MANAGER
•
•
•
•
여러개의 PRODUCT와, PROJECT를 관리
필요한 PRODUCT과 PROJECT를 정의 및 기획
개발 이외의 외부 조직과 커뮤니케이션 조율 (전략,기획,영업)
기획에 부터 서비스 전까지 모든것을 총괄 (서비스의 경우 운영 및 고
객 지원까지 책임지는 경우도 있음)
PROGRAM MANAGER
•
주어진 요구사항을 주어진 기간과, 인력, 예산 범위 내에서 구현할 수
있도록 관리
PRODUCT MANAGER
•
•
•
시장 분석, 경쟁 제품 분석, 제품 기획
요구 사항 정의, 우선 순위 조정
기획하고 빠지는게 아니라 개발끝날때까지 같이

35. ARCHITECT
•
•
•
시스템 설계.
기술과 비지니스 조직간의 소통 채널
Enterprise Architect, Solution Architect, Application Architect, Data
Architect, Technical Architect.
SCRUM MASTER
•
•
•
PL / 스크럼팀 리드
애자일 코치
일일 진행 상황 추적
•
•
소프트웨어 개발 및 단위 테스트
요즘 추세는 멀티롤 (개발,테스트,세부 디자인,인프라 셋업,빌드,배포)
DEVELOPER

36. TEST ENGINEER
•
•
•
•
•
화이트 박스 / 블랙 박스 테스트
테스트 자동화
기능 테스트, API 테스트, UX 테스트
성능 테스트, 장애 테스트, 안정성 테스트, 확장성 테스트
성능 엔지니어링
•
•
•
•
시스템 운영
인프라 (하드웨어) 셋업, 솔루션 설치 및 튜닝
소프트웨어 배포, 모니터링, 장애 대응
운영 시스템 자동화 (배포, 모니터링)
OPERATION
BUILD ENGINEER
•
•
개발,빌드 환경 관리 (GIT,MAVEN,JENKINS,JIRA)
배포 자동화,테스트 자동화
아이콘 이미지 원본 : http://gemmagarner.com/portfolio/heads-up-character-illustrations/

37. PMO (PROJECT MANAGEMENT OFFICE)
•
•
•
BUDGET($$$) 관리
외주,솔루션 계약 관리
전체 프로젝트 상황 모니터링 및 RISK 관리
•
•
•
•
•
•
요구 사항의 원산지이자 잦은 요구 사항의 주체
야근 유발자
그러나 이사람들도 힘듬
프로젝트가 진행되면서 배움 – 그래서 요구사항이 바뀜
외부 고객뿐 아니라, 영업 조직, 내부 기획 조직도 고객
우리편이 되면 제일 든든함. (적이 아니라 스폰서) – 돈 주는 사람임
※ 프로젝트나 프로그램 규모가 클 경우 (프로젝트 단위 또는 프로그램 단위)
고갱님
아이콘 이미지 원본 : http://gemmagarner.com/portfolio/heads-up-character-illustrations/

38. • 소프트웨어 개발팀의 구성원
페이스북같은 SNS 프로그램
프로그램 메니져
CHIEF 프로덕트 메니져
CHIEF 아키텍트
협업
(또는 관리)
협업
고객 지원
메신저
개발팀
타임 라인
개발팀
개발자 포탈
개발팀
영업/마케팅
운영팀
파트너 관리
전략 기획
프로젝트메니져
프로덕트 메니져
아키텍트
푸쉬 서버
개발팀
모바일앱
개발팀
개발 조직
웹앱
개발팀
스크럼마스터
개발자 (4~6)
테스트엔지니어
(단위/화이트박스)
테스트팀
테스트엔지니어
(성능,통합,UAT/
블랙박스)
빌드배포팀
빌드 엔지니어
운영 조직
비지니스 조직

39. TestLink를 이용한 테스트 관리

40. • TEST LINK
 웹 기반 테스트 관리 프로그램
 오픈소스
 1시간만 공부하면 씀
왜 필요한데?
 엑셀 삽질, 아직도 수동 테스트가 많음
 버전마다 바뀌는 TC 추적
 요구사항 TO TC 추적
 테스터에게 작업 지정
 리포팅, 커버리지

41. • 주요 기능
 릴리즈 버전별 테스트 케이스 (TC) 정의
 테스트 대상에 대한 버전 및 플랫폼 정의
 TC 버전 관리 지원
 테스터에게 TC 지정
 테스트 결과 저장
 리포팅
 타 툴과 연동
 Selenieum, SOAP UI,JENKINS 등 다른 테스트 툴과 연동
 JIRA와 연동 (테스트 실패시 BUG LINK 연동)

42. • 순서
1.
테스트 프로젝트 생성
2.
테스트 케이스 생성
3.
테스트 플랜 생성
① 테스트 대상 시스템의 릴리즈 버전, 플랫폼 등을 정의
② 테스트 케이스를 테스터에 지정
4.
테스트 수행
5.
종료 및 리포팅

43. • 순서
1. 테스트 케이스 생성
•
SUMMARY
•
PRECONDITION
•
STEP
•
EXPECTED RESULT
•
그림 첨부
•
파일 첨부

44. • 순서
2. 테스트 배정
•
TC 버전 선택
•
테스트대상 버전 선택
•
테스터에 배정

45. • 순서
3. 테스트 수행
•
성겅 실패여부
•
노트
•
JIRA로 버그 등록
•
버그와 연결

46. • 순서
4. 리포트
•
웹 리포팅
•
TC를 워드로
•
EXCEL로

47. 참 쉬워요.
생각보다 쓸만함.
좋은데 어떻게 설명하지?
1시간만 해보세요
윈도우즈 설치 : (5분) https://bitnami.com/stack/testlink
http://bcho.tistory.com/832 : 해보는데 40분

48. • 팁
 테스트 케이스의 폴더를 EPIC과 맵핑하면 추적성이 좋음
 JIRA에서 스토리별로 TC 만들어도 됨. (잘 안되더라)
 TC 이름에 JIRA Issue #를 사용하면 추적됨
 QA 팀이 나뉘어져 있는 경우에 좋더라.

49. 감사합니다.