▣ SW 개발 방법론_애자일(Agile) 개발_기본가치, 원칙, XP, 스크럼 Scrum, Crystal, TDD, DSDM, 스프린트, 번다운, 번업
■ 애자일 기본가치
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
암기 : 고변동개
■ 애자일 원칙
• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것
• 개발 후반에 새로 추가되는 요구 사항도 기꺼이 받아들인다. 애자일 프로세스는 고객의 경쟁력을 위해 요구 사항의 변경을 받아들인다.
• 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달한다. 이때 간격은 짧을수록 좋다.
• 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고받으며 함께 참여한다.
• 정보 전달을 위한 전화, 팩스, 인터넷 등 많은 매체 수단이 있으나 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것이다.
• 진척 사항의 척도를 나타내는 방법은 여러 도구로 표현할 수 있으나, 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것이다.
• 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구 사항, 설계가 나온다.
• 프로젝트의 효율성을 향상시키기 위해 개발 팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아보고 조율 및 수정한다.
■ 스크럼(SCRUM)
- Agile 방법론 중의 하나로, Product Backlog를 바탕으로 하여 기술적으로 분할되고 재해석된 스프린트(Sprint)를
스크럼 팀(team)을 통해 구현해 나가는 개발방법론
1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO(Project Owner, 제품 책임자)가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
3. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
4. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
5. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
6. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
7. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
8. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.
제품 책임자(Project Owner, PO) : 제품 백로그(요구사항) 작성 및 관리
스크럼 마스터(Scrum mater) : 프로젝트 관리자, 스크럼 회의 주관, 외부 소통 창고 역할
스프린트(Sprint) : 반복적인 개발주기(반복 주기, iteration 기간), 계획회의부터 제품 리뷰가 진행되는 날까지의 기간
제품백로그(Product Backlog) : 개발할 제품에 대한 요구 사항 목록, 우선순위가 매겨진 사용자가 요구사항 목록
회고(Sprint retrospective) : 스프린트에서 수행한 활동을 돌아보고 검토하는 과정
번다운차트(Burndown chart) : 계획대비 작업의 진행 정도를 날짜별로 남은 작업량으로 나타낸 것
■ 익스트림 프로그래밍(eXtreme Programming, XP)
12가지 실천사항
- Fine scale feedback
Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
- Continuous process
Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
- Shared understanding
Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
Simple Design: 가능한 가장 간결한 디자인 상태 유지
System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
- Programmer welfare
Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지
| 구분 | SCRUM | XP |
| 형태 | - 개발 프로세스를 위한 프레임워크 - 관리 및 조직적 실천법에 집중 |
- 엔지니어링 방법에 초점 - 프로그램 실천법에 집중 |
| 개발주기 | 4~6주 | 1~2주 |
| 요구사항 변경 |
- Sprint 내의 요구사항 변경은 수용 불가 - 변화를 빨리 발견하며 처리하는 관점 |
- 리팩토링을 통하여 요구사항 변경을 수용 - 요구사항 변경은 당연히 발생한다는 개념 |
| 우선 순위 결정 |
- Team이 개발 우선순위 결정 | - Customer가 개발 우선순위를 결정 |
■ TDD(Test-Driven-Development)
TDD란 Test Driven Development의 약자로 '테스트 주도 개발'
Test First Development 라고도 부름
작은 단위의 테스트 케이스를 먼저 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현함
<Red>단계에서는 작은 테스트 케이스 작성, 컴파일조차 안될 수 있음
<Green>단계에서는 테스트를 통과하는 코드를 작성
<리펙토링>단계에서는 중복 코드 제거, 불명확한 것을 명확히 함
| 개발 진척 파악 용이 | 개발자 자신의 개발 진척 상황을 항상 점검할 수 있음 |
| 소프트웨어 품질 향상 | 간결하고 작동되는 코드 개발 |
| 자동화된 단위 테스트 케이스 | 테스트는 개발자가 필요한 시점에 언제든 수행할 수 있으며 코드의 동작 이상 유무를 바로 확인할 수 있음 |
| 매뉴얼 & 의사 소통의 수단 | 작성된 테스트 케이스는 코드의 사용 설명서이자 동시에 다른 개발자와 소통하는 커뮤니케이션 통로가 됨 |
| 자연스러운 개선 | TDD를 진행하면서 테스트가 가능하도록 코드 구조를 고민하다 보면 자연스럽게 설계/구현 산출물을 개선하게 됨 |
| 성취감 | TDD는 테스트 주기를 짧게 가져가므로 개발자는 성취감을 자주 느낄 수 있으며 이것은 개발 동기부여가 될 수 있음 |
2018년 33번
정답 : 3번
(가) product backlog, (나) burndown chart, (다) sprint retrospective(회고전)
영어 철자 주의 spint respective -> sprint retrospective
2019년 7번 (사업관리)
정답 : 3번
■ 애자일 기본가치
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
암기 : 고변동개
2019년 37번
정답 : 4번
스크럼에서 팀의 퍼포먼스 측정하는 방법은 팀의 속도(Velocity)임
팀의 속도는 스프린트 동안 팀이 완료한 스토리들의 포인트 총합임
스토리 포인트란 스크럼에서 사용하는 작업량의 단위임
1스토리 포인트의 크기는 스크럼에서 규정되지 않으며 자체적으로 정하면 됨(상황, 팀에 따라 달라질수 있음)
예를들어 A조직에서는 화면 10개를 1스토리 포인트라고 정할 수 있지만, B조직에서는 화면 1개를 1스토리 포인트로 정할 수 있음
속도가 25이므로 한 스프린트에서 완료 가능한 스토리 포인트는 25임
전체 400포인트를 완료하기 위해서 16스프린트가 필요함
한 스프린트에 2주가 필요하므로 전체 필요일정은 32주, 즉 8개월이 됨
Quick 풀이 :
한 스프린트가 2주이니, 한달(4주) 하면 속도가 50임
400(전체)/50(월) = 8 개월
2019년 40번
정답 : 3번
스크럼에서 팀의 퍼포먼스를 측정하는 방법으로서, 스프린트동안 팀이 완료한 스토리들의 포인트 총합을 의미함
속도(velocity)의 정의 따라 완성된 스토리 포인트 합을 구하면 됨
B, C, E 스토리 포인트 합 = 7 + 5 +3 = 15
2019년 45번
정답 : 2번
릴리즈 계획 - 스프린트 계획 - 스프린트 리뷰 - 스프린트 회고
릴리즈 계획 : 프로젝트 전체 계획 일정, 제품 백로그(요구사항 목록)
스프린트 계획 : 한 스프린트를 대상으로 단기 일정 계획
스프린트 리뷰 : 고객을 포함 이해관계자에게 계획한 제품 데모
스프린트 회고 : 프로젝트 진행과정에서 좋았던 점, 문제점, 미진한 점 도출 후 개선방법 모색
2021년 28번
정답 : 4번
1번, 2번, 3번 모두 정형화된 것을 추구한다는 것인데,
고객의 요구에 민첩하게 대응하고 변화를 수용하는 Agile 모델과 거리가 멀다.
4번은 XP의 실천지침 '코드 공동 소유(Collective code ownership)'임
2021년 38번
정답 : 1번
1번 보기 '단순한 설계(simple design)는 설계를 간결하게 유지하여 미래의 잠재적 변경에 대비하는 것이다'는
일반적인 관점에서 보면 틀리지 않지만, 미래의 것을 아예 설계하지 않았으니 변경할 것도 없으므로 가장 적절하지 않음
(논란의 소지가 있음)
12가지 실천사항
- Fine scale feedback
Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
- Continuous process
Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
- Shared understanding
Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
Simple Design: 가능한 가장 간결한 디자인 상태 유지
System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
- Programmer welfare
Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지
2011년 26번
정답 : 3번
TDD란 Test Driven Development의 약자로 '테스트 주도 개발'
프로그래머는 코드를 작성하기 전 기능 테스트 코드를 먼저 작성함
Test First Development 라고도 부름
작은 단위의 테스트 케이스를 먼저 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현함
| 개발 진척 파악 용이 | 개발자 자신의 개발 진척 상황을 항상 점검할 수 있음 |
| 소프트웨어 품질 향상 | 간결하고 작동되는 코드 개발 |
| 자동화된 단위 테스트 케이스 | 테스트는 개발자가 필요한 시점에 언제든 수행할 수 있으며 코드의 동작 이상 유무를 바로 확인할 수 있음 |
| 매뉴얼 & 의사 소통의 수단 | 작성된 테스트 케이스는 코드의 사용 설명서이자 동시에 다른 개발자와 소통하는 커뮤니케이션 통로가 됨 |
| 자연스러운 개선 | TDD를 진행하면서 테스트가 가능하도록 코드 구조를 고민하다 보면 자연스럽게 설계/구현 산출물을 개선하게 됨 |
| 성취감 | TDD는 테스트 주기를 짧게 가져가므로 개발자는 성취감을 자주 느낄 수 있으며 이것은 개발 동기부여가 될 수 있음 |
2011년 47번
정답 : 4번
통계적 품질 관리는 아님
12가지 실천사항
- Fine scale feedback
Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
- Continuous process
Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
- Shared understanding
Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
Simple Design: 가능한 가장 간결한 디자인 상태 유지
System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
- Programmer welfare
Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지
2012년 26번
정답 : 4번
단위테스트는 TDD(테스트 주도 개발)에 의해 수행됨
즉, 단위 테스트를 먼저하고 다음 코딩이 이루어짐
익스트림 프로그래밍(eXtreme Programming, XP)
12가지 실천사항
- Fine scale feedback
Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
- Continuous process
Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
- Shared understanding
Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
Simple Design: 가능한 가장 간결한 디자인 상태 유지
System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
- Programmer welfare
Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지
2013년 28번
정답 : 4번
제네릭 프로그래밍은 객체지향 방법론 중 하나로 포괄적으로 어느 상황에서도 기능을 수행할 수 있도록 하는 기법
어느 타입의 자료형이든 간에 형변환 없이 자료형의 주소를 담을 수 있다는 특징이 있음
2016년 50번
정답 : 1번
익스트림 프로그래밍(eXtreme Programming, XP)
가. 사용자 스토리
나. 인수 테스트
다. 작은 릴리즈
2017년 32번
정답 : 4번
도입(Inception) > 정련(Elaboration) > 구축(Construction) > 전이(Transition) 사이클은 Sprint가 아닌 UP(Unified Process) 객체지향 방법론의 사이클임
2020년 30번
정답 : 2번
번업차트(Burn-Up Chart)는 완료된 스토리포인트를 더해가는 방식이고, 번다운차트(Burn-down Chart)는 완료된 스토리포인트를 원래 목표량에서 제하는 방식임
2020년 31번
정답 : 3번
DSDM(Dynamic System Development Method) : 점증적 프로토타이핑, 빠듯한 시간 제약조건, 파레토 법칙, 반복적인 소프트웨어 프로세스, 타당성조사->기능성, 요구사항도출 -> 모델 반복 -> 설계와 구축 반복 -> 시행
RAD를 기반으로 출발하여 분화된, 원칙과 모범 사례 중심의 애자일 방법론
처음엔 Dynamic System Development Method의 약자였지만, IT시스템 개발에 국한되지 않기 위해 해당 풀네임을 버린다고 공표하였음. 종종 Driving Strategy, Delivering More로 불리고 있지만 공식 명칭은 아님
<DSDM 원칙>
| Focus on the business need | 비즈니스 요구에 집중 |
| Deliver on time | 정시 프로젝트 완수 |
| Collaborate | 협업 중심 |
| Never compromise quality | 품질과 타협하지 않음 |
| Build incrementally from firm foundations | 확고한 기초를 기반으로 점진적으로 구축 |
| Develop iteratively | 반복적으로 개발 |
| Communicate continuously and clearly | 지속적이고 명확하게 의사 소통 |
| Demonstrate control | 통제력 유지 |
2020년 36번
정답 : 3번
스토리 A + 스토리 B + 스토리 C = 18
스토리 D + 스토리 E + 스토리 F = 18
스토리 G + 스토리 H + 스토리 I = 18
스프린트 : 스토리 포인트 18임
전체 스토리 포인트 180
180 / 18 = 10개의 스프린트 필요
스프린트 하나당 2주 걸리니 총 20주, 즉 5개월이 이 프로젝트 일정이 됨