ExtremeProgramming - Revision history

Maintenance script: Repair MoniWiki formatting after migration

2026-03-29T00:34:20Z

Repair MoniWiki formatting after migration

← Older revision		Revision as of 00:34, 29 March 2026
Line 1:		Line 1:
	ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.		[[ExtremeProgramming]] 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 [[TestDrivenDevelopment]]([[TestFirstProgramming]]) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.

	http://extremeprogramming.org/map/images/project.gif		http://extremeprogramming.org/map/images/project.gif
Line 5:		Line 5:
	=== 전체 주기 ===		=== 전체 주기 ===

	초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.		초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 [[AcceptanceTest]] 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 [[SpikeSolution]] 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.

	그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki:EnginneringTask 를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 UserStory 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.		그 다음, 최종적으로 Customer 에게 해당 [[UserStory]] 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki:EnginneringTask 를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 [[UserStory]] 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.

	Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 Refactoring, 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.		Iteration 중에는 매일 [[StandUpMeeting]] 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, [[TestFirstProgramming]] 과 Refactoring, 그리고 [[StandUpMeeting]] 나 [[PairProgramming]] 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.

	개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> Refactoring 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. Refactoring 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.		개발시에는 [[PairProgramming]] 을 한다. 프로그래밍은 [[TestFirstProgramming]]([[TestDrivenDevelopment]]) 으로서, [[UnitTest]] Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. [[UnitTest]] Code -> Coding -> Refactoring 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 [[AcceptanceTest]] 를 작성한다. [[UnitTest]] 와 [[AcceptanceTest]] 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration ([[ContinuousIntegration]]) 을, [[AcceptanceTest]] 를 통과하면 Release를 하게 된다. Refactoring 과 [[UnitTest]], [[CodingStandard]] 는 [[CollectiveOwnership]] 을 가능하게 한다.

	그리하여 각 Wiki:EngineeringTask 들이 구현되고, 궁극적으로 UserStory 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)		그리하여 각 Wiki:EngineeringTask 들이 구현되고, 궁극적으로 [[UserStory]] 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)

	=== XP 의 주요 개념들 ===		=== XP 의 주요 개념들 ===
	* On-site customer: 같은 작업실 내에서 프로그래머와 커스터머가 언제든지 대화할 수 있도록 보장한다.		* On-site customer: 같은 작업실 내에서 프로그래머와 커스터머가 언제든지 대화할 수 있도록 보장한다.
	* UserStory: 사용자 관점에서 시스템의 행위에 대한 간략한 서술		* [[UserStory]]: 사용자 관점에서 시스템의 행위에 대한 간략한 서술
	* AcceptanceTest: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.		* [[AcceptanceTest]]: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.
	* ThePlanningGame: 개발자는 UserStory들에 대해서 구현, 예측, 지시들에 대해 토론한다.		* ThePlanningGame: 개발자는 UserStory들에 대해서 구현, 예측, 지시들에 대해 토론한다.
	* UnitTest: 모든 클래스들에 대한 자동화된 테스트 코드들.		* [[UnitTest]]: 모든 클래스들에 대한 자동화된 테스트 코드들.
	* TestDrivenDevelopment : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with Refactoring)		* [[TestDrivenDevelopment]] : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with Refactoring)
	* Refactoring : 코드를 향상시키기 위한 프로세스		* Refactoring : 코드를 향상시키기 위한 프로세스
	* SimpleDesign		* [[SimpleDesign]]
	* PairProgramming: 프로그램코드는 두명 (driver, partner)이 하나의 컴퓨터에서 작성한다.		* [[PairProgramming]]: 프로그램코드는 두명 (driver, partner)이 하나의 컴퓨터에서 작성한다.
	* SpikeSolution: 주어진 문제에 대한 구현의 난이도를 예측하기 위한 작은 실험 프로그래밍.		* [[SpikeSolution]]: 주어진 문제에 대한 구현의 난이도를 예측하기 위한 작은 실험 프로그래밍.
	* CollectiveOwnership: 누구든지 어떠한 오브젝트건 고칠 수 있는 권리를 가진다.		* [[CollectiveOwnership]]: 누구든지 어떠한 오브젝트건 고칠 수 있는 권리를 가진다.
	* CodingStandard: CollectiveOwnership 을 위한. 누구나 이해하기 쉽도록 코딩스타일 표준의 설정.		* [[CodingStandard]]: [[CollectiveOwnership]] 을 위한. 누구나 이해하기 쉽도록 코딩스타일 표준의 설정.
	* ContinuousIntegration: 매일 또는 수시로 전체 시스템에 대한 building 과 testing을 수행한다.		* [[ContinuousIntegration]]: 매일 또는 수시로 전체 시스템에 대한 building 과 testing을 수행한다.
	* [[Metaphor]] : Object Naming 과 프로그램의 해당 수행에 대한 커뮤니케이션의 가이드 역할을 해줄 개념의 정의.		* [[Metaphor]] : Object Naming 과 프로그램의 해당 수행에 대한 커뮤니케이션의 가이드 역할을 해줄 개념의 정의.
	* Forty-hour week: 지친 심신은 실수를 만들어낸다. 가능하면 초과근무를 피한다.		* Forty-hour week: 지친 심신은 실수를 만들어낸다. 가능하면 초과근무를 피한다.
Line 44:		Line 44:

	----		----
	See Also HowToStudyXp , [[XpQuestion]]		See Also [[HowToStudyXp]] , [[XpQuestion]]
	----		----
	SE분류, [[지도분류]]		SE분류, [[지도분류]]
Line 52:		Line 52:
	그리고 다른 것도 좀 올려봅시다.		그리고 다른 것도 좀 올려봅시다.

	DeleteMe) 질문에 대해서는 [[Metaphor]] 로 옮겼습니다. 그리고 질문을 하실때는 실명으로 로그인해주시기 바랍니다. (사람들이 203.244.197.254 님 에게 답하기엔 좀 이상하자나요~) --[[1002]]		[[DeleteMe]]) 질문에 대해서는 [[Metaphor]] 로 옮겼습니다. 그리고 질문을 하실때는 실명으로 로그인해주시기 바랍니다. (사람들이 203.244.197.254 님 에게 답하기엔 좀 이상하자나요~) --[[1002]]


	...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --[[1002]]		...여기에서의 XP 와 관련된 글들의 경우도 [[XperDotOrg]] 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. [[XperDotOrg]] 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --[[1002]]

Maintenance script: Repair batch-0002 pages from live compare

2026-03-27T00:16:03Z

Repair batch-0002 pages from live compare

← Older revision		Revision as of 00:16, 27 March 2026
Line 56:		Line 56:

	...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --[[1002]]		...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --[[1002]]

imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:15Z

New page

ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.

http://extremeprogramming.org/map/images/project.gif

=== 전체 주기 ===

초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.

그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki:EnginneringTask 를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 UserStory 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.

Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 Refactoring, 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.

개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> Refactoring 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. Refactoring 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.

그리하여 각 Wiki:EngineeringTask 들이 구현되고, 궁극적으로 UserStory 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)

=== XP 의 주요 개념들 ===
* On-site customer: 같은 작업실 내에서 프로그래머와 커스터머가 언제든지 대화할 수 있도록 보장한다.
* UserStory: 사용자 관점에서 시스템의 행위에 대한 간략한 서술
* AcceptanceTest: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.
* ThePlanningGame: 개발자는 UserStory들에 대해서 구현, 예측, 지시들에 대해 토론한다.
* UnitTest: 모든 클래스들에 대한 자동화된 테스트 코드들.
* TestDrivenDevelopment : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with Refactoring)
* Refactoring : 코드를 향상시키기 위한 프로세스
* SimpleDesign
* PairProgramming: 프로그램코드는 두명 (driver, partner)이 하나의 컴퓨터에서 작성한다.
* SpikeSolution: 주어진 문제에 대한 구현의 난이도를 예측하기 위한 작은 실험 프로그래밍.
* CollectiveOwnership: 누구든지 어떠한 오브젝트건 고칠 수 있는 권리를 가진다.
* CodingStandard: CollectiveOwnership 을 위한. 누구나 이해하기 쉽도록 코딩스타일 표준의 설정.
* ContinuousIntegration: 매일 또는 수시로 전체 시스템에 대한 building 과 testing을 수행한다.
* [[Metaphor]] : Object Naming 과 프로그램의 해당 수행에 대한 커뮤니케이션의 가이드 역할을 해줄 개념의 정의.
* Forty-hour week: 지친 심신은 실수를 만들어낸다. 가능하면 초과근무를 피한다.

=== 관련 사이트 ===
* http://extremeprogramming.org - 처음에 읽어볼만한 전체도.
* [http://www.trireme.com/whitepapers/process/xp-uml/xp-uml-short_files/frame.htm eXtremeProgrammingMeetsUML] - 아직 읽어보지 않았음.
* http://objectmentor.com - Robert Martin 의 글들. OOP 관련 기사들도 많음.
* http://xprogramming.com - Ron Jeffries 의 글들이 많다.
* http://www.martinfowler.com/articles/newMethodology.html#N1BE - 또다른 '방법론' 이라 불리는 것들. 주로 agile 관련 이야기들.
* http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3220 - 4가지 가치 (Communication, Simplicity, Feedback, Courage)
**
* http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3111 - 4가지 변수 (Resource, Quality, Time, Scope)
** http://www.xprogramming.com/xpmag/kings_dinner.htm - 원문

----
See Also HowToStudyXp , [[XpQuestion]]
----
SE분류, [[지도분류]]

위의 전체 그림을 한번 정리해 보고 싶어서 추가함
고치고 싶으면 마음대로 고치세요.
그리고 다른 것도 좀 올려봅시다.

DeleteMe) 질문에 대해서는 [[Metaphor]] 로 옮겼습니다. 그리고 질문을 하실때는 실명으로 로그인해주시기 바랍니다. (사람들이 203.244.197.254 님 에게 답하기엔 좀 이상하자나요~) --[[1002]]

...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --[[1002]]