7. • 소프트웨어 트랜드의 변화
개발 방식
•
•
•
•
•
•
•
•
•
대규모/긴기간 에서 소규모/단기간 (스타트업)
빠르고 잦은 릴리즈 (애자일)
고객의 VOC를 수용 (빅데이타,SNS)
개발과 운영을 통합 (DEVOPS)
열심히 일하는 것으로 감당 안됨 (자동화)
스페샬 리스트에서 제너럴 리스트 (수퍼엔지니어)
대용량 글로벌 스케일
오픈소스
구글링,STACKOVERFLOW,블로그,GITHUB
21. • 개발 계획 완료
• 전체적인 기능 정의 & 등록 완료
• 제품 릴리즈 일정 정의 완료
• 이제 부터는 스프린트 시작
22. • 스프린트 플랜
• 모여서
• 스토리를 스프린트에 맵핑
• 각 스토리별 서브 태스크 생성
(스토리를 구현하기 위해 구체적으로 해야할일)
• 스토리 포인트 부여 - 0.5일,1일,2일
• 스프린트 시작
( 2주가 적절, 20%~40% 버퍼)
(상대값이 편함)
23. • 스프린트 시작
• 스프린트 시작
• 상태 업데이트 (Start/Resolved)
• 노트 필수 (자세하게, 휴가가도 될만큼)
• Daily 스크럼 (어제 모했고, 오늘 모하고, 문제는 모가)
※ 절대 보고 아님. 마이크 있는 사람만, 전체 20분 이내, 치킨을 빼는 것도
• 개발된 테스크는 테스터에 ASSIGN
24. • 스프린트 종료
• 릴리즈 & 배포
• 데모
• 같이 앉아서, JIRA에서 스프린트 종료 (닫을거 닫고, 넘길거 넘기고)
• 회고
몰 잘했고, 몰 잘못했고, 앞으로 어떻게 해보자
끊임없는 프로세스 개선
부담 되면 치킨 끼리, 치킨 빼고
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/
블랙박스)
빌드배포팀
빌드 엔지니어
운영 조직
비지니스 조직
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로 버그 등록
•
버그와 연결