방법론과 반복 개발
분석·설계 방법과 협업 규칙의 역할을 구분하고 작은 반복의 완료 기준과 피드백 기록을 만듭니다.
반복을 선택한 팀도 기능을 어떻게 나누고 모델을 어떻게 만들지, 검토는 언제 할지 정해야 합니다. 방법론은 개발에서 사용하는 절차·모델·역할·기법을 묶은 접근입니다. 특정 도구 하나나 회의 이름과 같지 않습니다.
분석·설계 관점의 선택
구조적 방법은 처리 기능을 분해하고 데이터의 흐름을 살핍니다. 신청 입력→ID 검사→명단 변경→결과 출력이라는 흐름을 그리면 누락된 처리를 찾을 수 있습니다. 정보공학적 접근은 업무의 데이터와 관계를 중심으로 개발을 조직합니다. 모임·참가자·신청 관계가 여러 업무에 재사용될 때 데이터 정의를 맞추는 데 도움이 됩니다.
객체 지향 접근은 상태와 책임을 가진 객체의 협력을 모델링합니다. Session이 어떤 상태 전이를 허용하는지 묻습니다. 모든 함수를 클래스로 감싸는 일이 목적은 아닙니다. 컴포넌트 기반 개발은 명확한 제공·요구 인터페이스를 가진 부분을 재사용해 조립합니다. 외부 저장 컴포넌트를 붙이려면 오류·버전·지원 계약도 확인해야 합니다.
이 관점들은 배타적 선택지가 아닙니다. 같은 앱에서 데이터 관계, 처리 흐름, 모듈 인터페이스를 서로 다른 질문에 사용합니다. 모델링과 모듈 설계가 실제 표현을 다룹니다.
애자일의 작업 단위
애자일은 짧은 피드백, 협업, 작동하는 결과, 변화에 대응하는 가치를 강조합니다. 애자일 선언의 원칙은 지속적인 전달과 검토·적응을 포함합니다. 문서를 없애거나 무제한 요구 변경을 받아야 한다는 뜻으로 읽지 않습니다.
스크럼은 목표와 백로그, 스프린트, 검토·회고 및 명확한 책임을 갖는 프레임워크입니다. 정해진 기간을 쓰더라도 끝에 실행 가능한 결과가 없으면 피드백이 약해집니다. XP에서 강조하는 테스트·지속적 통합·짝 프로그래밍 같은 실천은 변경을 자주 검증하는 데 도움을 줍니다. 두 사람이 키보드를 번갈아 사용하는 것만으로 검토의 질이 자동으로 좋아지지는 않습니다.
모임 교재에서는 간단한 반복 규칙을 사용합니다. 목표는 “취소한 자리에 새 참가자를 받을 수 있다”, 완료 기준은 코드·수락 사례·회귀 결과·사용 안내가 함께 준비되는 것입니다. 목표를 한 번에 너무 크게 잡으면 무엇을 확인했는지 흐려집니다.
반복은 실행 결과를 다음 요구로 돌려보낸다
취소 자리 재사용을 이번 범위로 정한다. 진행자 시나리오로 미정 정책을 드러낸다. 각 단계의 값과 전환 이유를 비교합니다.
SOFTWARE ENGINEERING · READING CLUB
반복은 실행 결과를 다음 요구로 돌려보낸다
취소 구현이 끝났더라도 안내와 마감 정책이 맞아야 완료 증거를 얻습니다.
피드백이 다음 요구와 우선순위를 바꿉니다. 회의 주기만 반복되는 것과 실행 가능한 결과를 반복하는 것은 다릅니다.
이 예의 조건
- 본문과 전체 도표의 예를 따라 반복 목표부터 검토와 다음 목표까지 진행합니다.
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 반복 목표 취소 자리 재사용을 이번 범위로 정한다. |
|
|
| 제작과 확인 취소 함수와 기존 동작을 확인한다. |
|
|
| 검토와 다음 목표 진행자 시나리오로 미정 정책을 드러낸다. |
|
|
반복은 실행 결과를 다음 요구로 돌려보낸다
취소 자리 재사용을 이번 범위로 정한다. 진행자 시나리오로 미정 정책을 드러낸다. 각 단계의 값과 전환 이유를 비교합니다.
SOFTWARE ENGINEERING · READING CLUB
반복은 실행 결과를 다음 요구로 돌려보낸다
취소 구현이 끝났더라도 안내와 마감 정책이 맞아야 완료 증거를 얻습니다.
피드백이 다음 요구와 우선순위를 바꿉니다. 회의 주기만 반복되는 것과 실행 가능한 결과를 반복하는 것은 다릅니다.
이 예의 조건
- 본문과 전체 도표의 예를 따라 반복 목표부터 검토와 다음 목표까지 진행합니다.
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 반복 목표 취소 자리 재사용을 이번 범위로 정한다. |
|
|
| 제작과 확인 취소 함수와 기존 동작을 확인한다. |
|
|
| 검토와 다음 목표 진행자 시나리오로 미정 정책을 드러낸다. |
|
|
스크럼 용어를 작은 결과에 연결한다
공식 스크럼 가이드의 세 책임을 구별합니다. Product Owner는 제품 가치와 순서를 정한 제품 백로그에 책임을 지고, Developers는 사용 가능한 증분을 만들 계획·품질·일일 적응을 담당합니다. Scrum Master는 스크럼의 이해와 팀의 효과적인 실행을 돕습니다. 이 역할을 단순히 지시자·코더·회의 진행자로 치환하지 않습니다.
| 연결 | 모임 예제에서 적어 볼 내용 |
|---|---|
| 제품 백로그와 제품 목표 | 신청·취소·저장 개선 목록, ‘명단을 신뢰하고 운영할 수 있다’는 목표 |
| 스프린트 백로그와 스프린트 목표 | 이번에 선택한 취소 작업·수행 계획, ‘취소 자리를 재사용한다’는 하나의 목표 |
| 증분과 완료 정의 | 기존 기능과 함께 사용할 취소 결과, 정책·회귀·안내가 맞는 공통 품질 조건 |
수락 조건은 특정 취소 기능의 요구를 판단하고, 완료 정의는 증분 전체가 지켜야 할 품질 상태를 드러냅니다. 버튼 한 개의 시연은 이 둘을 대신하지 않습니다. 계획에서는 이번 목표·선택한 작업·만드는 방법을 정하고, Daily Scrum에서는 개발자들이 목표의 진행과 다음 행동을 조정합니다. 리뷰에서는 이해관계자와 결과·앞으로의 선택을 살피고 회고에서는 작업 방식의 개선을 정합니다.
아래 한 사람의 반복 메모는 이런 질문을 연습하는 자습 도구입니다. 전체 스크럼의 팀·이벤트·산출물·규칙을 실행한 사례는 아닙니다. 팀 운영과 이벤트의 시간 제한은 공식 스크럼 가이드로 이어가는 선택 심화 학습으로 둡니다. 취소가 완료 정의를 만족하지 않으면 사용 가능한 증분에 포함했다고 표시하지 않습니다.
반복 기록을 직접 만들기
iteration-2.md를 작성합니다.
# 반복 2: 취소와 자리 재사용
목표: 열린 모임에서 취소한 자리를 새 ID가 사용할 수 있다.
수락 사례: min 신청 → min 취소 → hana 신청 → REGISTERED.
회귀 사례: 잘못된 ID 거절, 만석 중복 안내.
미정 질문: 마감 뒤 취소한 자리는 다시 열 것인가?
완료 증거: 실행 결과와 진행자의 정책 확인.
다음 선택: 마감 정책 확정 후 마감 흐름 추가.node examples/ch6.mjs로 둘째 흐름을 확인합니다. 코드를 실행했다는 표시는 자동 단언의 증거이고 진행자의 확인은 별도 기록입니다. 회고는 이번 작업 방식에서 막힌 원인을 보고 다음 방식의 작은 개선을 정합니다. 버그 목록 회의와 같은 일은 아닙니다.
독립 문제: 완료라고 할 수 있을까?
취소 버튼 구현은 끝났지만 안내가 “모임이 다시 열렸습니다”라고 나오고 코어 상태는 CLOSED입니다. 팀은 일정상 완료로 처리하려 합니다. 수락 조건·완료 정의 중 무엇과 충돌하는지, 리뷰와 회고에서 각각 무엇을 확인할지, 다음 반복에 넘길 수 있는 일을 구분하세요.
힌트
사용자가 보는 정책 충돌과 다음에 추가할 개선 기능을 나누어 봅니다.
해설
정한 마감 정책과 안내가 충돌하므로 해당 목표의 완료 증거가 부족합니다. 안내를 정책에 맞추고 마감 뒤 취소 후 새 신청 거절 시나리오를 확인합니다. 리뷰에서는 사용자에게 보여 줄 취소 결과가 정책과 맞는지와 다음 제품 선택을 살피고, 회고에서는 문구와 코드를 따로 완료 처리하게 된 작업 방식을 개선합니다. 명단 정렬 등 목표와 무관한 개선은 영향과 우선순위를 기록해 다음 반복에 넘길 수 있습니다. 기한을 맞추려면 범위를 다시 합의할 수 있지만 완료의 의미를 몰래 바꾸지는 않습니다.
방법론을 도입할 때는 원칙·필요 산출물·역할·실행 증거를 연결합니다. 공식 스크럼 가이드의 용어를 실제 적용 없이 이름만 붙이는 데 사용하지 않습니다.